Описание на проекта

Преди година работих по дългосрочен проект за автоматизация на IT инфраструктурата на голяма международна компания. Проектът включваше автоматизирано предаване на данни между няколко системи от различни производители като SAP, Microsoft, IBM и др., както и автоматизирано предаване на данни към разработени от компанията бизнес решения.

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

 

Бяха дефинирани поне 8 интеграции от тип „точка до точка”, т.е. от дадена система или бизнес решение към друга система или бизнес решение.

Първи вариант – интеграции тип „точка до точка”

При този тип интеграции се разработва отделен конектор за всяка двойка системи или бизнес решения, които трябва да си обменят данни. Този конектор отговаря за трансформацията на данните, интеграцията между системите и всякакви други услуги за съобщения между двете системи или бизнес решения.

Ето как трябваше да изглежда нашия автоматизация на инфраструктурата, ако бяхме избрали интеграции от тип „точка до точка”:

 

Един недостатък на този тип интеграции е, че всеки конкетор е потенциална „точка на срив”. Срив на даден компонент в определени случаи би довел до срив на цялата инфраструктура.

Друг значителен недостатък на този тип интеграции е, че ако решим да сменим дадена система или бизнес решение с нови – трябва да изменим всички конектори, които комуникират с тази система или бизнес решение.

Което също означава, че трябва да бъдем изключително внимателни с промените, които имплементираме във всяка система или бизнес решнение, понеже промените в тях може да доведат до срив в даден конектор, което от своя страна пък да доведе до срив в цялата автоматизирана инфраструктура.

С други думи, архитектура базирана изцяло на интеграции тип „точка до точка” не отговаря на следните качествени характеристики:

  • Изменчивост – определя до колко лесно, ефективно и бързо може да се изменя дадена система.
  • Поддръжка – определя до колко лесно, ефективно и бързо може да се извърши операция по поддръжка на дадена система.
  • Изправност – определя до колко дадена система е устойчива на дефекти и сривове.

Една добра архитектура би трябвало да е възможно най-опростена, с малък брой конектори и връзки тип „точка до точка”, които могат да доведат до потенциален срив, също да може да се документира, поддържа и изменя лесно.

Интеграциите тип „точка до точка” са подходящо решение, когато дадена инфраструктура има малък на брой компоненти. За жалост, броят компоненти на една инфраструктура, обикновенно се увеличава с времето и това прави този тип интеграции трудно управляеми, и податливи към изменения.

Втори вариант – ERP архитектура

От опростената схема на IT инфраструктурата показана по-горе установихме, че най-много различни системи и бизнес решения изпращат данни към финансовата система.

Финансовата система в случая беше Enterprise Resource Planning система („Система за управление на ресурси в предприятията”), или накратко ERP.

Затова решихме да подходим, базирайки архитектурата на инфраструктурната автоматизация, на типичната ERP архитектура, в която имаме ERP система в центъра на архитектурата и различни видове други системи и бизнес приложения комуникиращи си с нея (CRM, BI, вътрешни уеб сайтове и т.н.).

 

Комуникацията между две различни системи (едната от които не е ERP системата) се реализира, чрез доработка на централната ERP система. По този начин имаме една централна „точка на срив”, която в случая е самата ERP система.

В случая, бе планирано да реализираме следните доработки в ERP системата:

  • Канал за комуникация между HR системата и вътрешен уебсайт за преразпределяне на ресурси по проекти.

Доработката изискваше данните да бъдат извлечени от HR системата, обработени от услуги, които щяхме да разработим като част от ERP системата, записани в ERP системата (в нови таблици, които щяхме да създадем за тази интеграция), след което щяха да бъдат теглени на определен период от време от вътрешния уебсайт използвайки CRON job-ове създаденни в Hangfire.

Детайлно описание на създаването и настройването на Hangfire CRON Job-ове, можем да прочетем тук: https://docs.hangfire.io/en/latest/background-methods/performing-recurrent-tasks.html

  • Канал за комуникация между CRM системата на отдел „Продажби” и вътрешен уебсайт за преразпределяне на ресурси по потенциални проекти.

Подобно на доработката за HR системата, тази доработка също включваше извличане, обработка и зареждане на данни от CRM системата в ERP системата (използвайки допълнително разработени услуги и таблици за съхранение на обработените данни) и периодичното им теглене от вътрешния уебсайт използвайки Hangfire CRON job-ове.

  • Канал за комуникация между CRM системата, HR системата и ERP системата и BI системата за бизнес анализ.

Особенното тук беше, че данните щяха да се извличат и обработват от допълнителни услуги разработени в ERP системата, но щяха да се пазят в съществуващи таблици, част от CRM модула на ERP системата (където се пазят извлечените от CRM данни) и HR модула на ERP системата (където се пазят извлечените от HR системата данни).

Ето как трябваше да изглежда нашата автоматизация на инфраструктурата, ако бяхме избрали да реализираме ERP базирана архитектура.

 

ERP базираната архитектура поддържаше следните качествени характеристики:

  • Поддръжка – предвид, че почти цялата тежест на интеграцията падаше върху ERP системата, при правилно реализирана архитектура на новите таблици и услуги, интеграцията щеше да бъде сравнително бързо и лесно поддържана от малък брой ERP разработчици.
  • Изправност – предвид, че ERP системата, сама по себе си е критична за бизнеса на клиента, той беше се подсигурил да държи системата в изправност, като правеше ежедневни backup-и на базата на ERP системата и всички доработки, така че стара изправна версия на базата да може да бъде възстановена във всеки един момент, при откриване на дефект, който не може да се отстрани бързо.
  • Сигурност – определя до системата може да устои на опити за неразрешена употреба, без това да пречи на легитимните потребители. Сигурността предполага „единична точка на срив”, която в случая беше самата ERP система.

Въпреки, че като цяло, тази интеграционна архитектура беше по-добър избор от интеграциите тип „точка до точка”, тя също не поддържаше качественият параметър „Изменчивост”, понеже в зависимост от изискваната промяна, щеше да се наложи значителна промяна на database архитектурата на таблиците използвани за каналите за комуникация с различните видове системи или пък значителни доработки по HR и CRM модулите на ERP системата.

Също взехме в предвид, риска от причиняване на дефекти в основните функционалности на ERP системата в следствие на доработки за целите на интеграцията и затова се насочихме към разработка на специализирано интеграционно решение.

Трети вариант – ESB решение

Насочихме се към ESB базирано интеграционно решение.

Enterprise Service Bus е архитекурна концепция за интегриране на разнородни системи използвайки шиноподобна инфраструктира за комуникация (така наречената “Message bus” или „Шина за съобщения”).

ESB базираното решение щеше да се води от следните два принципа:

  • Оркестрация – изнасяне на различните компоненти за интеграция тип „точка до точка” между две бизнес системи в специално разработена услуга, част от ESB решението. Това води до по-добро управление и преизползване на различните интеграционни компоненти.
  • Трансформация – ESB базираното решение, щеше да извършва трансформация на данните от формат в който са получени от една от системите във формат в който ще се изпратят до друга от системите. За целта решението щеше да разполага със собствена база данни, която е проектирана за целите на интеграцията между различните системи.
  • Администриране – ESB базираното решение, щеше да предостави лесен начин за наблюдаване на производителността на интеграцията, и потока на прехвъляне на данните, следейки че валидна информация се получава от една система, трансформира се правилно и се подава на друга система. Това щеше да се реализира чрез добавяне административен интерфейс (за потребители с администраторски права) и поддържане на подробен log на всички операции извършвани от ESB решението и резултатът от тях.

Детайлно описание на особенностите на Enterprise Service Bus архитектурата, можем да прочетем тук: https://searchmicroservices.techtarget.com/definition/enterprise-service-bus-ESB

Взимайки в предвид описаните характеристики и особенности на ESB архитектурата, интеграционното решение, което щяхме да разработим за автоматизиране на IT инфраструктурата на клиента, щеше да изглежда по следният начин:

 

Трети вариант – потенциална реализация

Щяхме да реализираме ESB решението като разработим ASP.NET Core проект използващ RabbitMQ брокер за съобщения.

На кратко, RabbitMQ е софтуер за управление на опашки за съобщения, поддържащ различни видове протоколи за прехвърляне на съобщения.

Детайлно описание на особенностите на RabbitMQ можем да намерим тук: https://www.rabbitmq.com/ като по-долу е показана графично структурата на едно RabbitMQ базирано решение:

 

За проекта бяхме избрали да използваме Microservice архитектура, така че всяка услуга да отговаря за определена интеграция тип „точка до точка” и да има отделна база данни съхраняваща трансформираните данни за дадената интеграция.

Детайлно описание на особенностите на Microservice архитектурата, можем да прочетем тук: https://microservices.io/ като по-долу е показано как би изглеждала подобна архитектура с три услуги (съответно и три отделни бази данни).

 

Ето как би изглеждала една задача използваща RabbitMQ брокер за съобщения и  реализирана като част от Microservices базирана услуга:

Трети вариант – подобрения

ESB базираните решения разполагат със следните няколко недостатъка, които се опитахме да избегнем или ограничим:

  • Трудно управление на последователността на изпълнение на операциите – предвид, че ESB решението получава и обработва съобщения получени от различни системи паралелно е трудно да се реализира даден процес включващ изпращане на данни между няколко системи постъпково.
  • Трудно прехвърляне на голямо количество данни – голямо количество данни е трудно да се прехвърля използвайки събития.
  • Проблеми с изправността – въпреки, че като архитектура с „единна точка на срив” ESB архитектурата си остава едно добро решение за интеграции между различни системи, срив в ESB решението би предизвикало срив в цялата автоматизация на IT инфраструктурата.

Опитахме се да ограничим първият от тези недостатъци използвайки подход на  „приоритетна опашка”, чиято схема е показана по-долу. Детайлна информация за приоритетните опашки можем да намерим тук.

 

Като в нашия проект решихме да не използваме стандартна имплементация на този подход, понеже не поддържахме приоритетно базирани опашки, а разработихме различни опашки за съобщения с различен приоритет.

С други думи – интеграциите „точка до точка”, които бяхме реализирали използвайки Microservices базирани услуги, част от цялостното ESB решение бяха с различни приоритети.

Примерно съобщенията подавани от дадена система или бизнес решение към финансовата ERP система бяха с най-голям приоритет, а съобщенията подавани към вътрешните уебсайтове или BI решението с по-малък. Схема на подобна импелементация на подход „приоритетна опашка” е показана по-долу:

 

Трети вариант – допълнителни недостатъци

Други недостатъци на ESB базираните решения, които ни накараха да изберем друг вид интеграционно решение, са следните:

  • ESB базираните решения са „много комплексни” – изискват разработка на множество различни услуги и опашки за тях, имат нужда от голямо количество ресурси и са трудни за поддръжка.

Допълнително те са „единична точка на срив” и биха довели до срив в цялата интеграционна инфраструктура, в следствие на промени по част от услугите или опашките.

  • ESB базираните решения имат слаба „изменчивост” – трудно се имплементират нови промени по тях, докато се поддържа останалата част от бизнеса.

Например ако HR процесите и финансовите процеси (обработвани от ERP системата) се променят, това ще изисква промяна в приоритета на опашките и в имплементацията на различни услуги, и тези промени биха били времеемки. Също, понякога е особенно трудно да се приоритизира, кои промени са по-важни от други промени.

Четвърти (финален) вариант – API базирана интеграция

Най-накрая се спряхме на разработката на API базирано интеграционно решение.

Основната цел на API базираните решение е да позволи на отделните интеграционни елементи да бъдат преизползваеми в интеграционната платформа. Позволявайки преизползваемост на логиката, разработиците могат по-бързо и по-безопасно да я изменят.

Особенноста на този тип интеграция е, че е базирана на слоеве, позволяващи преизползваемост и лесно добавяне на нови системи и услуги. Предвид, че елементите за преизолзване вече са успешно тествани, те директно могат да се добавят към новите логики, което би ускорило процеса на разработка.

Слоевете на API базираните решения са следните:

  • Системен слой

Основния слой на архитектурата. API-тата, които се дефинират тук отговарят за точно определени системи (например ERP системата). Тези API-та предоставят метод за достъп до тези системи и техните записи, като предоставят данните в подходящ за обработка от по-горните слоеве формат.

 

  • Процесен слой

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

  • Канален (experience) слой

Тези API-та предоставят лесен достъп до различни бизнес процеси (процесни API-та) или системи (системни API-та) за различни видове клиенти (мобилен клиент, уеб клиент или др.). Това са API-тата, за които трябва да се предостави потребителски достъп, докато останалите видове API-та остават скрити за потребителя.

Предимства на API базираните решения пред ESB решенията

ESB базираните решения не правят разлика между различните видове интеграции реализирани с интеграционни API-та, докато API базираните решения се ползват от тяхните предимства изброени тук:

  • Предимства на системни API-та пред ESB решенията

Логиката на системните API-та може да бъде изменяна без това да повлияе на другите видове API-та (процесните и каналните). Например, ако дадено системно API използва SAP ERP, но в бъдеще тази ERP система трябва да бъде заменена с Axapta ERP, това изменение може лесно да се извърши в системното API, без да се извършват промени в процесния слой.

  • Предимства на процесните API-та пред ESB решенията

Общата бизнес логика може да бъде споделена в различни процеси в организацията. Примерно ако вече имаме дефинирана логика за обработка на поръчки, тя може да бъде преизползвана в различни бизнес процеси, когато се наложи.

  • Предимства на каналните API-та пред ESB решенията

Каналните API-та са прости. Практически те включват единствено трансформацията на данните. Тези API-та дават достъп на различни клиенти приемащи данни в различни формати и позволяват добавянето на нови клиенти да става бързо.

Заключение

Добрите архитекти планират дадена архитектура още преди разработката на даденото бизнес решение, а не в следствие на архитектурни затруднения.

Също взимат в предвид, архитектурата да покрива не само определени функционални характеристики, а и определени качествени характеристики.

Към момента API базираните интеграционни решения са едно от най-добрите архитектурни решения за интеграция на голям брой системи, позволяващи бързо, евтино и ефикасно тази интеграция да се разширява, изменя и управлява. Този вид архитектура също е силно устойчив към бизнеси с често променящ се приоритет и чести промени в бизнес процесите.

За допълнителна информация относно особенностите на API базираните интеграционни решения, можете да прочетете тук.


Автор:
Евгени Дюлгеров

>>> Работи като Senior .NET Developer – Contractor в KPMG ITS, като официалното му работно място е в ScaleFocus;
>>> Завършил е бакалавър „Компютърни системи и технологии“ в ТУ-София, а също така и магистратура „Информационни технологии за управление на бизнеса“ в английския факултет на ТУ-София.
>>> Хобитата му са плуване, латино танци, играене на футбол на маса.
>>> Интересите му също са разнообразни – писане на проекти с нови технологии, разработка на freelance проекти през свободното време.


Стани част от потребителските групи на DEV.BG. Абонирай се и ще ти изпращаме информация за всичко, което предстои в групата.

Прочети още:
Serverless бекенд за трансформация на данни (Част 1)
Как можем да използваме Azure WebApps за решаване на проблеми, с които CRM Online не може да се справи

Share This