Як ми працюємо з довідниками на інтеграційній шині

Принципи вирішення

При інтеграції корпоративних систем виникає завдання управління довідковими даними. Для вирішення цього завдання часто використовується Master Data Managment (MDM). MDM - це сховище, яке містить «еталонні» довідкові дані, так звані «золоті записи». Довідники MDM містять очищені повні та непротиворечиві дані.

Часто MDM використовується як платформа для централізованого ведення довідників. Введення і валідація довідкових даних проводиться в MDM, а звідти вони реплікуються в IT-системи. Такий підхід має кілька проблем

• Створити еталонну модель даних, яка підійде всім системам не так-то просто.
• Довідкові дані стають відірваними від програм.
• Реплікація даних з MDM часто вимагає серйозного доопрацювання систем. Для систем «з коробки» таке доопрацювання може бути дуже дорогим.

Інший підхід полягає в тому, що кожна бізнес-система зберігає довідники локально, і організовує у себе введення даних. При обміні повідомленнями між системами інтеграційна шина здійснює трансформацію з формату однієї системи в формат іншої. При цьому відбувається і трансформація довідкових даних.

Трансформація на інтеграційній шині.

Ми використовуємо другий підхід. Всі взаємодії бізнес-систем відбуваються через інтеграційну шину. Шина (у нашому випадку Oracle Service Bus) трансформує повідомлення, яке надсилає система Постачальник, у повідомлення, зрозуміле системі Споживача. Така трансформація включає мапування значень довідників.

Дані про те, як довідники мапуються між системами зберігаються в реляційній базі даних, у нашому випадку - Oracle. У таблицях буде записано, як з значення довідника в одній системі отримати значення в іншій системі. Тобто якась така структура:

(source_system, source_value, valid_from, valid_to, target_system, target_value)

Дані в довідниках змінюються дуже рідко, а використовуються дуже часто. Щоб не звертатися кожен раз до бази даних, довідники кешуються на шині, причому у форматі, який шина може відразу використовувати.

Для кешування ми використовуємо Oracle Coherence. Це дуже і дуже платний продукт. Однак, в даному випадку всі його мега-функції не використовуються, тому його цілком можна замінити на безкоштовне рішення (наприклад, hazelcast). Докладніше про coherence можна прочитати тут. Також ліцензія на coherence входить в різні Oracle Suite.

Використання кешу має очевидні переваги:

• дані зберігаються в пам'яті
• дані зберігаються в серіалізованому вигляді
• дані можуть бути проіндексовані
• синхронізація з базою даних може бути проведена асинхронно

Кеш є розподіленим і синхронізація між вузлами проводиться самим Coherence. При додаванні або видаленні сервера кластер здійснює ребалансування даних між вузлами.

Для довідкових даних використовується схема Distributed Cache Map. Під час старту Oracle Service Bus створюється кеш всередині JVM, який тримає дані в пам'яті. На кожному фізичному сервері є coherence сервер, який зберігає довідники (в пам'яті і на диску) і синхронізується з базою даних.

Під час трансформації osb workflow звертається до coherence через Java callout. Можна також звертатися через виклик Enterprise Java Bean.