Мельница данных- Интеграция функций  (раздел целиком)  (19.04.2024)
Интеграция функций
Данный тип развития интеграции в свою очередь можно разделить на 2 пути:

1. Взаимные вызовы

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

Доступ к функциям возможен с помощью выполнения хранимых процедур (каждое бизнес-действие, которое производит пользователь, обязательно оформляется в виде хранимой процедуры на уровне СУБД Платформы). Процедуру можно вызывать, получив доступ к СУБД. Аналогично тому, как создаются select-запросы, запросы к данным, можно делать запросы, вызывающие бизнес-функции. Все методы, отчеты, и все, что доступно пользователю, может быть вызвано и через RESTful-сервис. При этом методы будут выполняться, отчеты будут формироваться в виде Excel, Word, PDF, HTML, в соответствии с запросом вызывающей стороны. Данный функционал обеспечивается готовым "обработчиком", входящим в состав поставки Платформы.

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

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

Пример

 Пример реализации:

В ВУЗе при формировании приказа о зачислении студента в Платформе, также автоматически создается объект "Приказ" в системе документооборота ВУЗа. В дальнейшем, передвижение приказа по маршруту согласования в решении на Платформе аналогично отображается в системе документооборота. 

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


2. Встраивание

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

Существуют разные способы реализации данного пути:

- В open-source системах, как правило, слой доступа к данным вынесен в некий отдельный модуль. Характерный пример - это LMS eFront. Это Open-Source разработка, содержащая в себе большой объем php-кода, с развитым web-интерфейсом, и, в том числе, содержащая модуль доступа к данным. В процессе работы создается база MySQL база достаточно примитивной структуры. В этом случае можно изменить модуль доступа, так, чтобы вместо запросов к MySQL-базе механика делала бы запросы к базе данных Платформы. Тогда исполнение php-кода, его интерпретация происходит в рамках сервера приложений Платформы.

Пример

  Пример реализации:

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

- В тех случаях, когда решения Платформы сами являются частью какой-либо более общей системы, и должны предоставлять свои функции, то это решается на уровне СУБД. То есть, сгенерированный Платформой прикладной код (код на соответствующем диалекте SQL) может быть интегрирован в код более масштабного хранилища, функционировать там, исполняться там, если в этом есть необходимость.

Пример
 Прикладные системы на базе СУБД Teradata позволяют использовать PL/SQL-код для каких-либо наборов данных, притом, что сама база гораздо имеет продвинутые возможности автоматического контроля версий, хроникальности, аналитики.