Сделайте сервисы ERP более открытыми!

Микросервисы Архитектура Spring API

1. Адрес загрузки исходного кода

Ссылка на источник: https://github.com/samt007/xygerp-api-demo

Это Spring Cloud Micro Services Architecture для создания набора сервисных систем на основе API EBS.

Если у вас есть какие-либо вопросы по этой статье, свяжитесь со мной: samt007@qq.com

2. Введение

Это технический документ, который эффективно сочетает в себе традиционную систему ERP и микросервисную архитектуру на основе Java.

Традиционная ERP фокусируется на управлении информацией внутри предприятия. Когда система ERP может публиковать свои услуги (в сочетании с архитектурой микросервиса), она может обеспечить беспрепятственное соединение со сторонними системами и в то же время также может выполнять функции расширения самой ERP. Цель состоит в том, чтобы сделать услуги ERP более открытыми!

2.1 Для чего это?

Проще говоря, это:

Это эквивалентно тому, чтобы быть промежуточной платформой услуг, создавая API ERP в веб-сервис для интеграции с другими системами.

Его функция подробно описана ниже.

1. Без него...

Если единой платформы стыковки API нет, то стыкуются ERP и сторонние системы, и это будет структура, показанная на следующем рисунке:

这里写图片描述

Как видно из приведенного выше рисунка, каждая сторонняя система связана с ERP, будь то DBLINK или собственная веб-служба,Все запутано и не управляется единым способом. Проще говоря, он отдельный, и все, что нужно сделать для подключения, — по частям.

Когда сторонних систем становится все больше и больше, это будет катастрофа для повседневной эксплуатации и обслуживания. Например, простое управление и обслуживание: изменение пароля, есть много мест, которые нужно настроить, и их легко пропустить.

В частности, проблемой является повторное использование функций интерфейса. Предполагая интерфейс для запроса запасов, можно использовать как систему CRM, так и систему онлайн-заказов, и их необходимо разрабатывать дважды.

2. С тех пор, как он...

С этой унифицированной системой API связь между системой ERP и другими системами становится следующей структурой:

这里写图片描述

Следовательно, с его помощью API, эквивалентный ERP, может быть разработан через эту сервисную платформу, и в основном все бизнес-процессы, которые могут быть выполнены с помощью интерфейса, могут быть выполнены через эту сервисную платформу.

можно реализовать:

  • Объединение внешних сервисов
  • Сервисы API могут вызывать друг друга и унифицировать логику получения и обработки сервисов.
  • Объединение кода повышает эффективность развития. Особенно часть Comm код.
  • Улучшить стабильность взаимодействия со сторонними системами: Вам нужно только обратить внимание на стабильность работы микросервисной системы.

3. Какие примеры?

Например:

1) Система управления вводом и выводом готовой продукции со штрих-кодом:

Вероятно, это требование: Когда готовый продукт помещается на склад, его можно поставить на склад напрямую, отсканировав штрих-код или QR-код с помощью сканера штрих-кода; когда готовый продукт продается со склада, его также можно отправить напрямую, отсканировав штрих-код готового продукта. JIT-менеджмент.

Реализуя логику этой системы являются: Система APP может войти в систему через имя пользователя и пароль EBS пистолета со штрих-кодом. Затем, штрих-код кисти, он может генерировать соответствующую транзакцию с помощью веб-службы! Например, в готовом виде, обработка отдельных материалов и т.п.

Ниже приведены некоторые скриншоты системы

Примечание. Фоновый API этой функции предоставляется этой микрослужбой, а передний план — приложение для Android.

这里写图片描述

2) Интеграция с различными сторонними системами:

На каждом предприятии есть различные сторонние системы, которые в большей или меньшей степени нуждаются в интеграции с EBS. Традиционный метод интеграции — через DBLINK.

Но с этой системой веб-службы вы можете использовать веб-службу в качестве посредника для интеграции и взаимодействия с данными EBS!

2.2 Что такое микросервисы?

В интернете много информации о его анализе. Вот резюме великого бога (цитата: http://blog.51cto.com/ityouknow/1974080), и анализ на месте:

Концепция микросервисов от марта 2014 года Мартин Фаулер написал статью «Микросервисы».

Архитектура микросервисов — это архитектурный шаблон, который поддерживает разделение одного приложения на набор небольших служб, которые координируют и взаимодействуют друг с другом, чтобы обеспечить максимальную ценность для пользователей. Каждая служба работает в своем собственном процессе, и службы взаимодействуют друг с другом с помощью упрощенного механизма связи (обычно на основе HTTP RESTful). API). Каждая услуга строится вокруг определенного бизнеса и может быть независимо развернута в производственной среде, среде, подобной производственной, и т. д. Кроме того, следует по возможности избегать унифицированного и централизованного механизма управления услугами.Для конкретного сервиса следует выбирать соответствующие языки и инструменты для его построения в соответствии с бизнес-контекстом.

Микросервисы — это архитектурный стиль, в котором большое сложное программное приложение состоит из одного или нескольких микросервисов. Каждая микрослужба в системе может быть развернута независимо, и каждая микрослужба слабо связана. Каждый микросервис ориентирован на выполнение только одной задачи и делает ее хорошо. Во всех случаях каждая задача представляет собой возможность малого бизнеса.

Преимущества микросервисной архитектуры

Контролируемая сложность: при декомпозиции приложения предотвращается бесконечное накопление исходной сложности. Каждая микрослужба фокусируется на одной функции и четко выражает границы службы через четко определенные интерфейсы. Благодаря небольшому размеру и низкой сложности каждый микросервис может полностью контролироваться небольшой командой разработчиков, что позволяет легко поддерживать высокую ремонтопригодность и эффективность разработки.

Независимое развертывание: поскольку микросервисы имеют независимые запущенные процессы, каждый микросервис также может быть развернут независимо. Нет необходимости компилировать и развертывать все приложение при изменении микросервиса. Приложение, состоящее из микросервисов, эквивалентно ряду параллельных процессов выпуска, что делает выпуск более эффективным, снижает риск для производственной среды и, в конечном счете, сокращает цикл доставки приложения.

Гибкая технология Выбор: в архитектуре Micro Services, выбор технологий децентрализован. Каждая команда может развиваться в соответствии с статусом потребностей и промышленности их обслуживания, свобода выбора наиболее подходящего технологического стека. Поскольку каждый микросервис является относительно простым, ему необходимо обновить технологический риск стека, с которыми сталкивается меньше, или даже полностью реконструируют микросхемы.

Толерантность к неисправностям: при формировании сбоя, в традиционной архитектуре одного процесса, вероятно, будет распространяться в процессе, глобальная форма применения недоступна. В архитектуре Micro-Service неисправность будет изолирована в одном обслуживании. Если хорошо спроектировано, другие услуги могут повторяться, устойчивые механизмы разложения для достижения устойчивости к неисправности уровня.

Расширение: Приложения с монолитной архитектурой также могут обеспечивать горизонтальное расширение, то есть полностью реплицировать все приложение на разные узлы. Когда разные компоненты приложения предъявляют разные требования к масштабированию, архитектура микросервисов демонстрирует свою гибкость, поскольку каждый сервис можно масштабировать независимо в соответствии с реальными потребностями.

2.3 Описание архитектуры микросервисной системы ERP API

2.3.1 Описание логики разработки системы

Из вышеприведенного анализа мы знаем, что микросервис — это техническая архитектура, которая разбивает огромную сервисную систему на несколько подсервисов для выполнения. Вопрос в том, как его разделить? То есть, каков принцип разделения услуг.

Этот вопрос похож на то, как разбить большую таблицу, на самом деле, я думаю, что это конкретный анализ конкретных проблем. Поскольку я разрабатываю микросервисную систему на основе EBS, обычно более разумное правило разделения должно основываться на модулях EBS.

Эквивалент каждого модуля разбит на отдельный микросервис. Например, модуль FND, модуль INV, модуль WIP и так далее.

Иногда для целей могут быть настроены некоторые функции, нам необходимо извлечь данные с несколькими модулями, а другие модули для повторного использования, вероятность, очень низко. Таким образом, на самом деле он также может быть настроен на разделение подразделения Micro-Services.

На данный момент система включает в себя 2 подсервиса:

  • Сервис xygerp-ald: модуль ald

Это основной модуль всего API микросервиса. Основная функция этого модуля — проверка входа пользователя и обеспечение единой аутентификации по токену для всех модулей API.Эквивалент модуля FND ebs.

  • Сервис xygerp-albc: подмодуль albc

Этот проект является одним из модулей API, принадлежащих микросервисам: система управления штрих-кодом предоставляет API для данных и обработки данных. В основном используется для системы передачи штрих-кода.

Конечно, в будущем можно добавить несколько услуг. Архитектура микросервисов — очень хорошее преимущество масштабируемости!

2.3.2 Схема архитектуры микросервисной системы

Ниже представлена ​​архитектурная схема системы.

这里写图片描述

Уведомление:

1. В модуле Spring Cloud фактически Spring Security не является отдельным модулем, а интегрирован в каждый бизнес-микросервисный модуль!Каждый микросервис должен иметь токен аутентификации, чтобы разрешить доступ к API, это очень важно!Поэтому я перечислил его в модуле Spring Cloud.

2. По некоторым модулям в настоящее время цифра не достигнута. В настоящее время создайте общую архитектуру, включая следующую службу (в следующей главе будет указано назначение каждого модуля):

xygerp-ald

xygerp-albc

xygerp-server-eureka

xygerp-server-zuul

Примечание. Дополнительные модули будут добавлены позже по мере необходимости.

3 Процесс разработки системы

Следующим шагом является пошаговая разработка набора этой микросервисной системы на основе Spring Cloud.

3.1 Базовые технические знания по развитию, которые необходимо освоить

Система развития должна закладывать прочный фундамент. Поэтому вот список методов разработки, которые необходимо освоить для разработки микросервисной системы на основе Spring Cloud.

Ниже я не буду подробно объяснять, как изучается каждый метод разработки, потому что это не является целью данной статьи. Если работник хочет сделать работу хорошо, он должен сначала наточить свои инструменты, и должен быть заложен фундамент.

1) язык Java

Вы должны быть знакомы с java, иначе вам в принципе не нужно читать документацию. Сначала заложите фундамент!

2) Инструмент управления проектами Maven

Проекты, разработанные системой, управляются maven, поэтому сначала необходимо установить и освоить инструмент maven.

3) база данных Oracle + PLSQL + язык SQL

Технология разработки баз данных. Здесь выбрана база данных Oracle, поскольку EBS — это ERP-система, основанная на базе данных Oracle.

3.2 Требуется знакомый фреймворк Java

С развитием технологии Java появилось множество отличных сред с открытым исходным кодом, и мы можем использовать эти среды для быстрой разработки систем.

3.2.1 Стек технологий Spring Framework (семейный сегмент)

Spring — это текущий основной пакет технологий с открытым исходным кодом. Основные технологические стеки, используемые в этой системе: Spring boot, Spring Security и Spring Cloud.

  1. Spring Boot

Система быстро развивается на основе SpringBoot. Выберите SpringBoot, который в настоящее время очень популярен, чтобы свести к минимуму сложность конфигурации и посвятить много энергии развитию бизнеса.

  1. Spring MVC

Используйте платформу Spring MVC для обработки всех запросов URL, которая проста и удобна в использовании.

  1. Spring Security

Spring security — это мощная и настраиваемая структура аутентификации и контроля доступа. Это стандарт для защиты приложений на основе Spring. Здесь мы в основном используем инфраструктуру Spring Security для работы с механизмом Token.

  1. Spring Cloud

Spring Cloud — это упорядоченный набор фреймворков. Он использует удобство разработки Spring Boot для тонкого упрощения разработки инфраструктуры распределенной системы, такой как регистрация обнаружения служб, центр конфигурации, шина сообщений, балансировка нагрузки, автоматический выключатель, мониторинг данных и т. д., все из которых можно сделать в стиль разработки Spring Boot для запуска и развертывания одним щелчком мыши. Примечание. В настоящее время эта система использует 2 модуля Spring Cloud.

  • Запрос унифицирован для доступа к внутренним службам через шлюз API (ZUUL).
  • После того, как шлюз получает запрос, он получает доступные услуги из реестра (Eureka).

3.2.2 MyBatis

Фреймворк ORM использует MyBatis.

В основном с учетом того, что он может очень хорошо поддерживать операторы SQL: MyBatis — это отличная структура уровня сохраняемости, которая поддерживает общие запросы SQL, хранимые процедуры и расширенное сопоставление. Кроме того, также используются некоторые плагины MyBatis для повышения эффективности разработки, особенно общие плагины пейджинга Mapper и PageHelper!

3.2.3 Alibaba druid

DRUID — это реализация пула соединений с базой данных на платформе с открытым исходным кодом Alibaba. Он сочетает в себе преимущества C3P0, DBCP, PROXOOL и других пулов БД, а также добавляет мониторинг журналов, который может хорошо отслеживать подключения к пулу БД и выполнение SQL.

3.2.4 Swagger

Единственным соединением между интерфейсом и сервером становится интерфейс API.

Документация API стала связующим звеном между разработчиками интерфейса и бэкенда, и это становится все более и более важным. swagger — это фреймворк, который позволяет вам лучше писать документацию API.

3.3 программные инструменты для подготовления

3.3.1Redis

В настоящее время основной функцией использования Redis является доступ к токенам, чтобы взаимодействовать с реализацией механизма безопасности Spring Security для доступа к API.

В будущем вы можете рассмотреть расширенные функции, такие как кэширование или очереди сообщений.

3.3.2Docker

Контейнерное развертывание на основе Docker.

После использования микросервисной архитектуры наша система будет состоять из множества подсистем. Чтобы достичь цели изоляции среды между несколькими системами, мы можем развернуть их на нескольких серверах, но стоимость будет относительно высокой, а производительность каждого сервера может быть использована не полностью.

Поэтому мы, естественно, думаем о виртуальных машинах, запуская несколько виртуальных машин на одном сервере для изоляции среды, и каждая виртуальная машина запускает независимую службу.

Однако стоимость изоляции виртуальных машин по-прежнему очень высока, поскольку она должна занимать больше аппаратных и программных ресурсов сервера. Таким образом, в рамках микросервисной структуры Docker — лучший выбор для достижения изоляции сервисной среды. Он легче, чем виртуальные машины, требует меньше ресурсов и обеспечивает быстрое развертывание.

Примечание. Существуют специальные разделы, посвященные установке и использованию этого инструмента. Из-за недостатка места этот документ пока не охватывает контейнерное развертывание.

3.3.3 Jenkins

Инструмент автоматизированной сборки Jenkins.

Когда мы примем микросервисную архитектуру, мы обнаружим такую ​​проблему. Вся система состоит из множества сервисов, и эти сервисы нужно запускать в отдельных контейнерах, поэтому сложность каждого релиза будет очень высокой.

В первую очередь нужно разобраться с зависимостями между этими сервисами и последовательностью запуска, а затем скомпилировать, упаковать и опубликовать несколько подсистем одну за другой. Эти операции технически несложны, но подвержены ошибкам.

Итак, какие инструменты могут помочь нам решить эти проблемы? Ответ - Дженкинс.

Это инструмент автоматизированного строительства.Проще говоря, нам нужно всего лишь нажать кнопку в его интерфейсе, чтобы реализовать описанную выше серию сложных процессов.

Примечание. Существуют специальные разделы, посвященные установке и использованию этого инструмента. По этой причине в этом документе не объясняется конструкция автоматизации.

3.4 Конкретный процесс разработки

Теперь начните строить такую ​​систему своими руками.

3.4.1 Создание организационной структуры проекта Maven

Сначала создайте родительский проект микросервисной системы: xygerp-api.

Затем создайте следующие подпроекты в рамках этого проекта:

название проекта инструкция
xygerp-ald альд модуль, порт: 8180. Это основной модуль всего API микросервиса. Основная функция этого модуля — проверка входа пользователя и обеспечение единой аутентификации по токену для всех модулей API. Эквивалент модуля FND ebs.
xygerp-albc подмодуль albc, порт: 8181. Этот проект является одним из модулей API, принадлежащих микросервисам: система управления штрих-кодом предоставляет API для данных и обработки данных. В основном используется для системы передачи штрих-кода.
xygerp-comm Проект модуля связи является основной зависимостью всех проектов API. Грубо говоря, сюда можно извлечь общий код всех проектов API-микросервисной архитектуры.
xygerp-basic-support Основной модуль базовой поддержки Этот проект является базовым проектом поддержки данных для всех проектов API. Здесь все сущности собраны единообразно! Потому что для Entity он должен быть общим для всего микросервиса.
xygerp-server-eureka Центр обслуживания и обнаружения Spring Cloud. Порт: 8101. Этот модуль является основным модулем облака Spring и используется для обработки сервисных вызовов между различными микросервисами.
xygerp-server-zuul Шлюз Spring Cloud Service. Порт: 8102. Все микросервисы в системе архитектуры Spring Cloud обеспечивают единый вход доступа через Zuul, и все запросы, которым необходимо взаимодействовать с внутренними сервисами архитектуры микросервисов, проходят через унифицированный шлюз.

Их результаты каталога выглядят так:

这里写图片描述

Уведомление: О xygerp-basic-support: основной модуль базовой поддержки

У вас могут возникнуть вопросы: почему бы не объединить сущность в модуль, которому она принадлежит? На самом деле так оно и есть.Я в основном рассматриваю проблему звонка друг другу между сервисами.

Хотя микросервис объективно является отдельным сервисом, на самом деле большинство функций должны вызывать друг друга. Например, для модуля заказа на продажу нормально вызывать функцию модуля инвентаризации для запроса инвентаря, верно?

Если сущность не является общей, результат модуля инвентаризации, эквивалентный модулю продаж, не может быть агрегирован в bean-компонент для обработки, что принесет большие неудобства для фоновой обработки!

3.4.2 Построение зависимостей модулей

Затем нужно указать зависимости между ними через файл pom, как показано на следующем рисунке.

1. Деловая сервисная часть:

这里写图片描述
Обратите внимание, что указанные выше 4 проекта имеют зависимости. Итак, как развернуты xygerp-ald и xygerp-albcПереход к военному развертыванию(в основном для автоматического развертывания с помощью jenkins).

Однако xygerp-comm и xygerp-basic-support обеспечивают только базовую поддержку кода для каждой микрослужбы, поэтому развертывания jar достаточно.

Кроме того, чтобы упростить настройку каждого модуля, мы помещаем общие зависимости всех модулей в pom-файл проекта, а затем делаем все модули подмодулями проекта. Таким образом, подмодули могут наследовать все зависимости от родительского модуля без необходимости их самостоятельной настройки.

Укажите подмодуль в родительском pom

Тег modules указывает, кто является подмодулем текущего модуля, но недостаточно указать подмодуль в pom-файле родительского модуля, необходимо также указать, кто является родительским модулем в pom-файле подмодуля.

    <modules>
        <module>xygerp-comm</module>          <!--核心Comm模块 -->
        <module>xygerp-basic-support</module>    <!--核心基础支撑模块 -->
        <module>xygerp-server-eureka</module>   <!--Eureka服务治理模块 -->
        <module>xygerp-server-zuul</module>      <!--zuul动态路由模块 -->
        <module>xygerp-ald</module>             <!--核心ald模块 -->
        <module>xygerp-albc</module>           <!--子模块：albc模块，提供条码对接API服务 -->
    </modules>

Необходимо указать родительский модуль в подмодуле

<parent>
        <artifactId>xygerp</artifactId>
        <groupId>com.xygerp</groupId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
</parent>

Примечание. Конкретный код см. непосредственно в исходном коде. Здесь упоминаются только некоторые ключевые настройки.

Итак, на данный момент зависимости модуля настроены! Но обратите внимание на порядок, в котором модули упакованы.

Так как все модули зависят от модуля xygerp-comm и модуля xygerp-basic-support, при сборке модуля сначала необходимо скомпилировать, упаковать, установить модуль xygerp-comm и модуль xygerp-basic-support и запаковать его. в локальный репозиторий, чтобы можно было сослаться на модуль верхнего уровня. После установки модуля соберите модуль верхнего уровня. В противном случае возникнет проблема, что библиотека классов в модуле xygerp-comm не может быть найдена при сборке модуля верхнего уровня.

Советы: На самом деле, если родительский каталог напрямую упакован с пакетом mvn в целом, порядок упаковки и построения прямо указывается в родительском pom!

2. Часть управления службами микросервисной архитектуры

xygerp-server-eureka: регистрация и обнаружение службы Spring Cloud. Является ли иметь дело с управлением между службами.

xygerp-server-zuul: служба единого шлюза API для Spring Cloud.

СОВЕТЫ. Эти два проекта являются основными службами, используемыми для создания микросервисной архитектуры. Поэтому они относительно независимы. Не нужно полагаться на отца POM.

3.4.3 Код пакета с командой компиляции mvn

После создания вышеуказанных проектов добавьте зависимости, которые должны использовать все проекты (конкретный код см. в моем исходном коде).

Если нет проблем, вы можете использовать команду mvn для упаковки проекта:

mvn clean install -Dmaven.test.skip=true -P dev

Вот краткий анализ команды:

mvn: Единая команда для Maven.

чистая установка: указывает, что проект должен быть собран.

-Dmaven.test.skip=true: указывает, что тестовый модуль следует пропустить при сборке.

-P dev: указывает, что при сборке включитьdevПараметры загрузки Spring для запуска системы.

Если все в порядке, нормальный результат выглядит следующим образом:

这里写图片描述

3.5 Локальная компьютерная тестовая система

Код готов, теперь нужно подумать, как его протестировать. В конце концов, все системы должны быть протестированы, особенно те, которые имеют множество конфигураций и широкий спектр систем.

Это должно говорить о преимуществах весеннего ботинка. Упакованное приложение Spring Boot имеет встроенный Tomcat Service по умолчанию. Другими словами, вам нужна только команда Java для выполнения целевого результата, упакованного на Spring Boot, чтобы начать службу Tomcat! Действительно легко проверить!

3.5.1 Запуск локальных системных служб

Предположим, мой проект xygerp-api находится здесь: D:\JSP_MyEclipse\xygerp-api

Затем откройте 4 командных окна cmd соответственно и выполните:

D:\JSP_MyEclipse\xygerp-api\xygerp-server-eureka\target>java -jar xygerp-server-eureka-1.0-SNAPSHOT.war
D:\JSP_MyEclipse\xygerp-api\xygerp-server-zuul\target>java -jar xygerp-server-zuul-1.0-SNAPSHOT.war
D:\JSP_MyEclipse\xygerp-api\xygerp-ald\target>java -jar xygerp-ald-1.0-SNAPSHOT.war
D:\JSP_MyEclipse\xygerp-api\xygerp-albc\target>java -jar xygerp-albc-1.0-SNAPSHOT.war

Как показано ниже:

这里写图片描述

3.5.2 Локальная тестовая сервисная система API

Запускается служба локальной тестовой среды, а затем выполняется проверка конкретных данных.

Сначала проверьте регистрацию и обнаружение службы Eureka, чтобы убедиться, что службы зарегистрированы в системе:

这里写图片描述

Затем используйте swagger для проверки функции входа пользователя: http://127.0.0.1:8102/xygerp/ald/swagger-ui.html В настоящее время необходимо проверить, может ли токен нормально генерироваться.

这里写图片描述
这里写图片描述
Это означает, что вход в систему прошел успешно и токен для этого посещения сгенерирован!

Запишите токен и протестируйте его. Продолжайте тестировать функциональность запроса: http://127.0.0.1:8102/xygerp/albc/swagger-ui.html

这里写图片描述

Обратите внимание, что здесь используется инфраструктура Spring Security, поэтому все заголовки запросов API должны содержать информацию о токенах. В противном случае запрос вернет 401.

Если тест в порядке, это означает, что в основном система была успешно построена. Следующий шаг — как развернуть его в тестовой или формальной среде и как собрать проект одним щелчком мыши.

Проще говоря, система развертывается с использованиемдокеринструментыиспользует проект развертывания одного щелчкаДженкинстулс. Использование этих двух инструментов будет объяснено позже в специальных темах.

3.6 Функциональные трудности, реализуемые системой микросервисов API

3.6.1 Решить проблему переменных среды сеанса базы данных, особенно языковой среды и пользовательской среды.

Что касается этой проблемы, метод, который я использую в настоящее время, может быть не оптимальным решением.Если есть другой Xiongtai с лучшим решением, пожалуйста, оставьте мне сообщение, большое спасибо!

Источник проблемы:

Xiongtai, знакомый с разработкой EBS, должен знать, что после входа в ERP каждый раз, когда мы открываем форму, система будет запрашивать новый сеанс базы данных.Автоматически помогает нам инициализировать переменные среды сеанса: например, базовая локаль, пользовательская среда, бизнес-объекты и т. д.

В настоящее время мы можем напрямую использовать такие функции, как FND_GLOBAL.USER_ID в пакете, чтобы очень удобно получать информацию о переменных среды.

Однако в веб-разработке на Java все по-другому!

В концепции доступа к базе данных в Java приложение Session является чрезвычайно ресурсоемким действием! Поэтому большинство программного обеспечения Java, которое подключается к базе данных, предлагаетпул соединений с базой данныхконцепции (такие как пул соединений с базой данных DRUID). Проще говоря, это обмен сессиями!

Публичный сеанс вызовет проблему параллелизма: пользователь А использует систему и инициализирует переменную среды сеанса для пользователя А; когда пользователь А не использует систему, сеанс будет бездействовать и возвращен в пул соединений для других пользователей. использовать.

В это время, если пользователь B, вероятно, будет использовать сеанс, если переменные среды не будут повторно инициализированы, тогда пользователь B все равно будет использовать переменную среды системного сеанса пользователя A, что приведет к ошибкам данных! Как справиться с этой проблемой - трудная проблема, возникающая при разработке системы.

проблема решена:

Мое текущее решение: на уровне службы используйте AOP для автоматического мониторинга этого параметра. Пользователь AuthUser уровня службы

Пока параметр пользователя AuthUser находится в конце уровня службы, АОП автоматически инициализирует переменные среды сеанса. (Следует отметить, что транзакция базы данных моей системы включена на уровне службы!)

Кроме того, переменные среды локали, переменные входа в систему входа в систему среды и т. Д., Буду автоматически инициализированы вместе. Потому что Authuser будет нести это определение!

Основной код обработки выглядит следующим образом:

private static final String SQL_GLOBAL_INIT
	    = " DECLARE "
		+ "    L_session_id NUMBER;L_user_id NUMBER;L_login_id NUMBER;L_LANG VARCHAR2(10); "
		+ " BEGIN "
		+ "    L_user_id:=:P_USER_ID; L_login_id:=:P_LOGIN_ID; L_LANG:=:P_LANG;"
		+ "    APPS.fnd_global.INITIALIZE("
		+ "       session_id=>L_session_id, user_id =>L_user_id, resp_id =>NULL, "
		+ "       resp_appl_id=>NULL, security_group_id=>NULL, site_id=>NULL, login_id =>L_login_id, "
		+ "       conc_login_id=>NULL, prog_appl_id=>NULL, conc_program_id=>NULL, conc_request_id=>NULL, "
		+ "       conc_priority_request=>NULL"
		+ "     ); "
		+ "    IF NVL(L_LANG,'US') <> USERENV('LANG') THEN "
		+ "        IF L_LANG='ZHS' THEN "
		+ "            APPS.fnd_global.set_nls_context(p_nls_language => 'SIMPLIFIED CHINESE'); "
		+ "        ELSE "
		+ "            APPS.fnd_global.set_nls_context(p_nls_language => 'AMERICAN'); "
		+ "         END IF;"
		+ "    END IF;"
		+ " END; ";
	
    /*** 
     * service层调用之前先自动初始化环境变量
     * 需要注意的是，用户变量必须的参数放在最后！
     * 只要在Service层将参数AuthUser user放在最后，AOP会自动初始化Session的环境变量。
     * @throws Exception 
     */  
	@SuppressWarnings("static-access")
	@Before("execution(* com.jebms.*.service..*.*(..))  && args(..,user)")  
    public void oracleDBInit(JoinPoint joinPoint,AuthUser user) throws Exception{
		Long dbLoginId=devDao.getJdbcTemplate().queryForObject("SELECT FND_GLOBAL.LOGIN_ID FROM DUAL", Long.class);
if(user.getLoginId()!=null&&user.getLoginId()>0&&!user.getLoginId().equals(dbLoginId)){
			Map<String,Object> inParamMap=new HashMap<String,Object>();
	    	inParamMap.put("P_USER_ID", user.getUserId());
	    	inParamMap.put("P_LOGIN_ID", user.getLoginId());
	    	inParamMap.put("P_LANG", user.getLanguage());
			devDao.getDevJdbcTemplate().execute(this.SQL_GLOBAL_INIT, inParamMap);
        }
    }

Исходный код: com.jebms.comm.utils.AopUtil

3.6.2 Решить проблему входа пользователей EBS: единообразно использовать учетную запись и пароль системы EBS для входа в систему API.

Описание проблемы:

Поскольку я являюсь сторонней системой API, информация об имени пользователя и пароле на самом деле не является тем, чем должна управлять система API.

Это эквивалентно тому, что система API не может проверить имя пользователя и пароль в соответствии с обычным процессом: введите имя пользователя и пароль, система проверит имя пользователя и пароль фоновой базы данных, а затем вернется к результату проверки.

Вместо: введите логин и пароль, системаВызвать пакет проверки имени пользователя и пароля ERPПодтвердите и верните результат. Вкратце: необходимо добавить логику для пользовательской проверки.

К счастью, среда Spring Security поддерживает гибкую логику проверки.

Добавьте шаги:

Сначала напишите собственный класс аутентификации: MyAuthenticationProvider.

Затем в определении инфраструктуры Spring Security добавьте эту пользовательскую проверку.

AbstractWebSecurityConfig

частный провайдер MyAuthenticationProvider;//Пользовательская аутентификация auth.authenticationProvider(поставщик);

который может идеально достичь этого эффекта

Основной код:

    /**
     * 自定义验证方式
     */
    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String username = authentication.getName();
        String password = (String) authentication.getCredentials();
        AuthUser user = (AuthUser) userService.loadUserByUsername(username);
        System.out.println("username:"+username+",password:"+password);
        if(user == null){
            throw new BadCredentialsException("Username not found.");
        }

        //加密过程在这里体现
        if (!sysService.xygErpValidateLogin(username, password)) {
            throw new BadCredentialsException("Wrong password.");
        }
        
        user.setPassword(passwordEncoder.encode(password));

        Collection<? extends GrantedAuthority> authorities = user.getAuthorities();
        return new UsernamePasswordAuthenticationToken(user, password, authorities);
    }

3.6.3 Единый стиль разработки.

1. Инкапсуляция базового класса сущности.

Он инкапсулирует поле 5who и метод, аналогичный FND_SET_WHO из Form, который можно легко разработать.

Кроме того, для предотвращения потери обновлений перед каждым обновлением фактически проверяется согласованность данных, а также инкапсулируются соответствующие действия.

2. Инкапсуляция логики запроса.

Условно говоря, функций запросов по-прежнему много, и передать значения для сложных условий запроса — сложная задача.

Это инкапсулирует накопление SearchInfo, которое может единообразно помещать все условия запроса в этот класс, а затем определять условия запроса, соответствующие соответствующим полям на уровне контроллера Java, и система может автоматически генерировать соответствующие условия и.

Например:

   @GetMapping(value = "/getPageLocator")
    @ApiOperation(value = "货位分页列表接口")
    public ResultEntity<PageInfo<EslipLocatorRE>> getPageLocator(
    		@ApiParam(value = "库存组织ID",required = true) @RequestParam(required = true) int organizationId,
    		@ApiParam(value = "库别代码",required = true) @RequestParam(required = true) String subinventoryCode,
    		@ApiParam(value = "货位代码",required = false) @RequestParam(required = false) String locatorCode,
    		SearchInfo searchInfo) throws Exception {
    	searchInfo.getConditionMap().put("organizationId", organizationId);
    	searchInfo.getConditionMap().put("subinventoryCode", subinventoryCode);
    	searchInfo.getConditionMap().put("locatorCode", locatorCode);
    	searchInfo.setAuthUser(this.authUser);
    	searchInfo.initSqlCondition();
    	searchInfo.andSqlCondition("MIL.ORGANIZATION_ID","organizationId");
    	searchInfo.andSqlCondition("MIL.SUBINVENTORY_CODE","subinventoryCode");
    	searchInfo.andSqlCondition("MIL.SEGMENT1","locatorCode");
        return eslipService.selectForPageLocator(searchInfo);
    }

3. Инкапсуляция унифицированных результатов обработки.

По сути, любой процесс либо завершается успешно, либо завершается ошибкой (предупреждения фактически считаются ошибками).

Это инкапсулирует базовый класс ResultEntity, который возвращает результат, который может выполнять эффективное взаимодействие на стороне приложения или на стороне Java.

这里写图片描述

@ApiModelProperty(value = "状态码,0表示成功 其他表示失败", example = "0",position = 1)
private String code;

В частности, следует указать, что внешний интерфейс для получения или обработки данных также унифицирован с возвратом этого базового класса результата обработки.

Проще говоря, будет единый идентификатор возвращаемого результата для успеха/неудачи обработки данных. Обратите внимание, что этот флаг отличается от флага результата ответа на запрос (200)!

Идентификатор запроса-ответа указывает только на то, что ответ веб-сервера нормальный, но конкретным результатом обработки может быть сбой обработки.

这里写图片描述

Ниже приведен конкретный пример (результаты обработки интерфейса фактической разработки и обработки в это время будут одинаковыми):

{
	"code": "0",
	"message": "",
	"description": "",
	"obj": [{
		"createdBy": -1,
		"creationDate": "2017-10-10 09:37:03",
		"lastUpdatedBy": 10,
		"lastUpdateDate": "2017-11-16 14:47:48",
		"lastUpdateLogin": 96,
		"valueUUID": null,
		"id": 2,
		"applId": 1,
		"respCode": "BASIC_SET",
		"menuId": 2,
		"startDate": "2017-10-10 09:37:03",
		"endDate": null,
		"respName": "系统设置职责",
		"description": "系统设置职责",
		"menuCode": "SYSTEM_SET",
		"menuName": "系统设置菜单",
		"enabled": true
	}],
	"param1": null,
	"param2": null,
	"param3": null,
	"param4": null,
	"param5": null,
	"ok": true
}

Ссылка на документацию: https://juejin.cn/post/6844903560010792968 http://blog.51cto.com/ityouknow/1974080

Категории