Soa debit что это

[От редакции OM/RE: Когда эта статья нашего постоянного автора Антона Шмакова была уже принята к публикации в очередном (февральском) выпуске «Oracle Magazine/Русское Издание», на сайте публикаций корпорации Oracle появилась статья Марка Риттмана (Mark Rittman, Oracle ACE Director) и Джоэл Крисп (Joel Crisp) «Integrating Oracle Business Intelligence Enterprise Edition Plus with SOA» на ту же тему, что и работа А.Шмакова. Естественно, что статья А.Шмакова абсолютно независима от публикации М.Риттмана, хотя Антон не скрывает, что для введения в предлагаемую читателям данную работу он пользовался блогом метра-директора коллегии «Асы Oracle».

Перевод статьи M.Rittman и J.Crisp «Integrating Oracle Business Intelligence Enterprise Edition Plus with SOA» планируется к публикации в следующем выпуске журнала OM/RE.]

Введение

Технология Business Intelligence (BI) продолжает активно развиваться. За последние несколько лет компании стали представлять свои хранилища данных и BI-системы как web-сервисы для использования другими приложениями и процессами, связанными сервисно-ориентированной архитектурой (SOA) или ПО промежуточного уровня, таким как корпоративная сервисная шина (enterprise service bus — ESB).

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

В центре внимания СОА находятся не данные, а сервисы, которые являются бизнес-функциями, предназначенными для обеспечения согласованной работы больших, состоящих из множества частей приложений. С другой стороны в фокусе BI находятся данные, которые надо обрабатывать и отображать. Технология SOA имеет очень хороший потенциал в отношении BI-систем.

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

В этой статье рассматривается применение и реализация SOA технологий в Oracle Business Intelligence Enterprise Edition.

SOA архитектура в Oracle BI EE

BI системы последнего поколения представляют собой не просто отдельную программу, в которой пользователи строят и публикуют отчеты, а обширный комплекс технологий и приложений, созданный для удовлетворения всех потребностей BI. Именно таким продуктом и является Oracle Business Intelligence Enterprise Edition (подробнее см. «Oracle BI Suite EE — самая «всеядная» и «интеллектуальная» из аналитических платформ», Oracle Magazine RE, Октябрь 2007.

• Включение BI в бизнес процессы компаний позволяет добавить аналитическую составляющую в Workflow и обработку различных событий.
• Интеграция BI-систем и бизнес приложений позволяет объединить транзакционную и аналитическую обработку данных в едином интерфейсе;
• Интеграция исторических и данных реального времени позволяет строить хранилища данных нового типа, заниматься мониторингом различных аналитических показателей в режиме реального времени.
• Создание проактивной аналитики позволяет инициировать бизнес процессы из BI систем.

• Бизнес-процессы (Business Processes) и BPEL – язык формального описания бизнес процессов и протоколов их взаимодействия между собой;
• Бизнес правила (Business Rules);
• Бизнес события (Business Events) и корпоративная сервисная шина (ESB);
• Мониторинг бизнес деятальности (BAM). Внедрение BI в SOA среду позволяет расширить каждый из перечисленных выше компонентов:
• Аналитические бизнес процессы (Analytic BPEL, ABPEL)

• Использование различных аналитические условий и метрики в BPEL процессах;
• Заниматься оркестровкой сервисов с использованием данных из BI систем;

• Возможность генерации бизнес событий (в том числе в шину данных) из агентов (Alert) в BI системах;
• Использование данных и отчетов для генерации бизнес событий;
• Возможность строить отчеты и запускать аналитические модели и вычисления из BPEL процессов;
• Интеллектуальная маршрутизация бизнес событий;

Oracle BI EE и BPEL

По своей сути Oracle Business Intelligence является не монолитным приложением, а набором различных сервисов, которые работают на единой информационной платформе и выполняют каждый свои определенные функции. В Oracle BI EE сервером, на котором реализуются все сервисы, называется Oracle BI Presentation Services. Кроме внутренних сервисов, в нем существует целый набор стандартных SOAP Webсервисов, которые можно использовать при построении различных композитных приложений с использованием BPEL.

• Получать отчеты и данные из них
• Доставлять отчеты внешним системам
• Управлять каталогом метаданных
• Запускать бизнес-процессы и агенты исполнения (iBot)

Формальное описание сервисов и методов представлено в WSDL-файл, который находится по адресу http://host:port/analytics/saw.dll?WSDL. XSD-файл для сервисов называется SawServices.xsd и находится в папке WebAppResWsdlSchemas.

• HtmlViewService – сервис, позволяющий встраивать отчеты в HTML формате в любые внешние приложения или порталы. Кроме того сервис, позволяет в режиме реального времени изменять конечное представление отчета;
• iBotService – сервис, позволяющий запускать агенты исполнения (iBot). Создавать или изменять iBot с помощью этого сервиса нельзя;
• MetadataService – сервис, с помощью которого можно получать метаописания для различных объектов включая
• ReplicationService – сервис, позволяющий производить экспорт и импорт метаданных из файлов;
• ReportEditingService – сервис, с помощью которого можно настраивать параметра для отчетов;
• SAWSessionService – сервис, обслуживающий все сессионные переменные, такие как имя пользователя, пароль, ключ сессия и т.д. Является обязательным и самым первым сервисом в работе;
• SecurityService – сервис, отвечающий за вопросы безопасности в системе;
• WebCatalogService – сервис, с помощью которого можно управлять Web-каталогом, позволяет создавать, изменять, удалять любые объекты;
• XMLViewService – сервис, позволяющий выполнять произвольные запросы к модель данных и получать результаты в XML формате.

• Запускать бизнес процессы из BI системы

• Интерактивное взаимодействие (Interactive Dashboards, Answers);
• Регламентированное взаимодействие (Alerts/ iBots);

• Возможность вызова отчетов и получения результатов;

Пример

В качестве примера взаимодействия Oracle BI EE и BPEL построим простой процесс, который будет авторизоваться в Oracle BI EE, а затем получать данные из него.

Запускаем JDeveloper 10.1.3.1 и создаем новый BPEL Process Project, в качестве шаблона выбираем Synchronous BPEL Process, получаем готовый шаблон, который мы дальше будем расширять.

Выбираем Invoke метод в списке инструментов и вставляем его между receiveInput и replyOutput. Заходим в его свойства и нажимаем на кнопку обзора Partner Link. В появившемся окне создаем новый Partner Link – BI_SAWSession. В окне редактирования Partner Link в строке WSDL File вписываем путь к Oracle BI EE WSDL файлу в виде http://host:port/analytics/saw.dll?WSDL и нажимаем на копку Parse WSDL. В строке Partner Link Type выбираем SAWSessionServiceSoap_PL, а в строке Partner Role – SAWSessionServiceSoap_Role.

Возвращаемся обратно в свойства Invoke метода. В строке Partner Link должен быть выбран только что созданный объект, в строке Operation выбираем logon. Вводим название BI_Logon_Invoke и нажимаем кнопки для автоматического создания входной и выходной переменной.

Теперь нам надо для вызова операции logon во входную переменную метода BI_Logon_Invoke передать имя пользователя и пароль. Выбираем в палитре инструментов Assign метод, открываем его свойства. На закладку Copy Operation создаем две Copy Operation для параметров ns1: name и ns1:password для входной переменной метода BI_ Logon_Invoke. Значение параметров есть имя пользователя и пароль для входа в Oracle BI EE.

Таким образом, получаем следующий бизнес процесс, который обращается к Oracle BI EE, авторизуется на сервере и получает ключ авторизации.

Между методом BI_Logon_Invoke и replyOutput вставляем еще один Invoke метод – BI_SQL_Invoke, который будет передавать серверу Oracle BI SQL запрос и получать результат его выполнения. Создаем новый Partner Link – BI_XMLView, в качестве WSDL файл указываем такой же путь как и в предыдущий раз, в Partner Link Type выбираем XmlViewServiceSoap_PL, Partner Role – XmlViewServiceSoap_Role.

В новом методе выбираем операцию executeSQLQuery и создаем автоматически входную и выходную переменную.

Между методами BI_Logon_Invoke и BI_SQL_Invoke вставляем новый Assign метод – Assign_SQL. Создаем в нем три Copy операции:

Для sessionID из выходной переменной метода BI_Logon_Invoke;

Для передачи SQL запроса: select Markets.Region, “Sales Measures”.Units from Paint

Для установки значения параметра async

Последнее что, надо создать, это Assign метод между методом BI_SQL_Invoke и replyOutput, чтобы скопировать результаты работы SQL запроса в выходную переменную всего бизнес процесса.

BPEL процесс целиком готов, теперь если разместить его на Application Server и запустить из BPEL Process Manager, получим следующий результат:

Т.е. мы получили данные из стандартной схемы Paint, которая поставляется вместе с Oracle BI EE.

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

Вызов BPEL из Oracle BI EE

• iBot – возможность запустить другой агент
• Custom Script – выполнить любой скрипт на JavaScript или VBScript;
• Workflow – запустить Siebel CRM Workflow;
• Custom Java Program – выполнить произвольный Java код.

В качестве интеграции с BPEL подходят два варианта: Custom Script или Custom Java Program.

В первом случае можно написать небольшую программу, например на JavaScript, которая будет обращаться к некому сервлету (Servlet) и передавать ему параметры, а он будет запускать BPEL процессы. Если BPEL Process имеет HTTP форму запуска, то JavaScript может напрямую обращаться к BPEL процессу и передавать ему параметры.

Второй вариант взаимодействия через Custom Java Program позволяет писать на Java абсолютно любые вызовы и обработки.

В скором времени Oracle обещает добавить полноценную поддержку BPEL в Oracle BI EE, тогда в списке возможных действий в iBot появится еще один пункт BPEL.

Заключение

В качестве некого заключение хочется отметить, что общая тенденция к созданию приложений и систем, работающих в реальном времени, способных реагировать на различные бизнес события и инициировать бизнес процессы становится абсолютно очевидной. Для Oracle одним из главных приоритетов становится интеграция SOA технологий во все решения и продукты, не является исключением и BI. Думается, что уже в 2008 году выйдет релиз Oracle BI, который будет полностью интегрирован с SOA и BPEL.

Источник: citforum.ru

Возврат дебиторки через облачный сервис. Новые конкурентные преимущества

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

Существующие решения

В крупных компаниях есть юридические отделы, любая из них может нанять юристов, но судебные разбирательства длятся годами, арбитражный процесс имеет непростую специфику, а его ведение стоит немалых средств, вплоть до 20% от всей дебиторки с учетом последующих взысканий. При этом вернуть удается в среднем до 25% от общего объема.
Мало чем помогают сегодня и коллекторы, поскольку их деятельность строго регламентирована законом и замыкается на тот же судебный процесс. А в случае нарушения коллекторами закона в отношении должника тень падает на добросовестного кредитора, уступивший свой дебиторский портфель коллекторам буквально за полцены. И это при самом хорошем раскладе!

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

Особенности сегодняшнего дня

В кризисные времена проблемы с дебиторской задолженностью объективно растут быстрее. Многие компании закрылись, многие ушли из России и понесли значительные убытки, в связи с чем они вряд ли будут торопиться в первую очередь рассчитываться по «дебиторке». Многие структуры находятся на грани закрытия или имеют собственную еще более внушительную дебиторскую задолженность, что, в свою очередь, также замедляет соответствующие процессы. Эксперты практически не сомневаются в том, что объем дебиторской задолженности юридических лиц в России в ближайшее время вой­дет в тренд на штурм психологически значимой отметки в 3 трлн руб­лей.

Сервис легко интегрируется напрямую или через API банка-­партнера с любыми бухгалтерскими системами

Новое эффективное решение

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

Облачный сервис Debit-­Pay (www.debit-pay.online) позволяет выстраивать финансовые цепочки взаиморасчетов и оптимальным образом ускорять оборачиваемость средств без привлечения дополнительного финансирования.

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

Сервис легко интегрируется напрямую или через API банка-­партнера с любыми бухгалтерскими системами и предоставляет клиентам необходимый формат для экспорта файлов и онлайн-­подключения. Это дает возможность не только поставить денежные потоки на дополнительный электронный контроль, но и увидеть полный, гораздо более широкий контекст, поскольку к Debit-­Pay подключено множество компаний со всей России, а также за ее пределами, что позволяет находить даже не связанных напрямую контрагентов и проводить с ними взаимозачеты.

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

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

Источник: plusworld.ru

Master Data Management, EDA, ESB, SOA: собираем все вместе

Реализация повторно используемых интерфейсов предполагает, что мы будем хотя бы чуть-чуть абстрагироваться от конкретных задач и требований сегодняшнего дня. Иначе интерфейсы нам придется переделывать постоянно. Повторю пример из комментариев к сообщению Как сделать хороший API? При разработке программного интерфейса к каталогу книг методы

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

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

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

Описание структуры данных принято выносить в мета-данные (meta-data management). Т.е. у нас должен появиться справочник, в который мы будем вносить эти данные и программные интерфейсы для чтения этих справочников из приложений. Вот мы и добрались до управления основными данными (master data management, нормативно-справочная информация) о котором говорили в сообщении Интерес к управлению данными возвращается Это станет особенно актуальным если информацию получать мы будем из нескольких разнородных приложений с различными программными интерфейсами. Кстати именно в этом случае нам понадобится ESB и управляемая событиями архитектура (Even-driven architecture) Может показаться, что я противоречу своим более ранним сообщениям. Однако, если разобраться чуть глубже, то станет понятно почему это не так (см. рисунок)

В каждом из унаследованных приложений свои структуры данных и свои программные интерфейсы (в одном книжки, в другом компакт-диски ). В каждом, в лучшем случае, свои справочники свойств или же тривиальный хардкод, что встречается чаще. Первое что нужно сделать – научить приложения уведомлять MDM-систему обо всех изменениях в справочниках (Event Driven стиль).

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

Gregor Hohp Programming Without a Call Stack – Event-driven Architectures) И в завершении картинки у нас появляется сервисная шина предприятия (ESB), которая берет на себя функции преобразования запросов из getItemProperty() в реализованный унаследованным приложением getBookAuthor(), а так же маршрутизации запросов между приложениям. Кроме того, ESB окажется полезным и при чтении MDM, например, для сокрытия задержек обновления данных в MDM, кеширования запросов и т.д. Сам процесс обновления данных в MDM системе можно и даже нужно реализовать в ESB, т.к. это позволит нам реализовать достаточно эффективные стратегии управления данными. Не стану углубляться в подробности, т.к. описание данных стратегий потребует некоторого погружения в описание архитектуры Web. Интересующихся отсылаю к диссертации изобретателя стиля RESTful Роя Филдинга (краткое введение в тему RESTful и Enterprise 2.0)

Master Data Management, EDA, ESB, SOA: собираем все вместе: 21 комментарий

думаю, задача ETL/Eventing-актуализация данных в MDM – в том числе может отдаваться в ESB, где обычно подобные возможности/адаптеры поддерживаются.

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

Боюсь эта проблема не решается в общем случае — см. теорему CAP. В каждом конкретном случае есть потребность в определённом уровне согласованности, от этого и нужно отталкиваться.

Да, можно, это называется http://en.wikipedia.org/wiki/Eventual_consistency

ну эта тактика обеспечивает только AP (типа Cassandra), в обсуждаемом же случае может быть интереснее CA (типа HBase)… – а лучше всётаки баланс, который я предложил поискать:) Думаю, это тема отдельного обсуждения… Моя цель была лишь обратить внимание на появление проблемы консистентности и её снижение за счёт событийности.

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

Вместо этого приложение имеет объектную модель или схему данных, где эти имена и семантика зацементированы — это их модель предметной области. Следовательно при подключении приложения к системе MDM возникает потребность в адаптере, который будет запрашивать getItemProperty(itemId, “author”) и делать book.setAuthor(…).

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

Во-вторых, нельзя полагаться исключительно на событийное обновление. Событийно-управляемый адаптер — штука дорогая. Проще и дешевле везде где позволяет специфика обновлять базу данных под приложением в пакетном режиме еженощно, а это уже не очень хорошо ложится на ESB и EDA, лучше традиционный ETL.

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

И это всё только про состав полей. А ещё ведь нужно согласовать их семантику, а так же следить, чтобы последняя не оторвалась со временем от синтаксиса (“Мы раньше заводили юриков как физиков и указывали наименование и номер договора в полях Имя и Фамилия”). В общем, MDM это целая дисциплина, которую наскоком не взять. Впрочем, это справедливо и для большинства проблем enterprise IT. За это нам и платят деньги

относительно событийного обновления хочу заметить, что сейчас основной тренд связан с достаточно реактивной работой ИТ близком к реальному времени, особенно, если бизнес-процессы выходят наружу предприятия (связываются с клиентами, поставщками, партнёрами и т.п.). Другими словами, в текущих условиях/требованиях развития предприятия уже нет времени ждать, пока ночью какой-то batch-ETL выкачает и обновит данные в БД – “все изменения должны проявляться сразу” в портале клиентов, они “сразу же” имеют возможность использовать эти данные и т.п. В качестве примеров: высокопосещаемые сайты-магазины, CRM и продажи, системы оперативного управления и т.п. Другой пример (из oss, saas etc), когда используется оплата по выработке ресурса продукта использующего ресурсы сторонних систем-поставщиков, а контроль QoS для использования затруднительно организовать – это может приводить к проблеме списания средств за использование в реальном времени, а не раз в сутки и т.п.

Слава :
относительно событийного обновления хочу заметить, что сейчас основной тренд связан с достаточно реактивной работой ИТ близком к реальному времени, особенно, если бизнес-процессы выходят наружу предприятия (связываются с клиентами, поставщками, партнёрами и т.п.). Другими словами, в текущих условиях/требованиях развития предприятия уже нет времени ждать, пока ночью какой-то batch-ETL выкачает и обновит данные в БД – «все изменения должны проявляться сразу» в портале клиентов, они «сразу же» имеют возможность использовать эти данные и т.п. В качестве примеров: высокопосещаемые сайты-магазины, CRM и продажи, системы оперативного управления и т.п. Другой пример (из oss, saas etc), когда используется оплата по выработке ресурса продукта использующего ресурсы сторонних систем-поставщиков, а контроль QoS для использования затруднительно организовать – это может приводить к проблеме списания средств за использование в реальном времени, а не раз в сутки и т.п.
Другая проблема, что многие поставщики таковы, что объём всех данных за прошедшие сутки не получается за всю ночь забрать:) Особенно, если поставщик готов только полные логи выработок отдавать, без агрегации.

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

с тем, что мир не идеален – я и не спорил:) Переносите всё на промежуточный уровень ESB и т.п. Делать адаптацию в каждой подсистеме возможно и не имеет смысла… Как пример решения: на уровне платформы ориентируемся на событийность, а если подключаемая система испытывает трудности с публикациями событий или их приёмом – мы переводим из событий в RPC, ETL и др. (и обратно), как способна работать система. Т.е., даже если система только по ночам отдаёт логи – они прогоняются через ESB, которая переводит информацию в формат событий, публикует их, отрабатывает CEP. Т.е. концептуально, имеется некое событийное ядро, которое работает через адаптеры на ESB с разными источниками событий, публикации логов и др. – тем самым достигается нативная поддержка реального времени и agile-сть интеграции новых систем.

Область для использования ETL, действительно, сжимается, а очередей растет. Например, Oracle AQ вполне зрелый механизм. ETL остается для систем, которые выгружают большие объемы данных по расписанию, например все звонки абонентов за последние X часов. Ну и еще отдельная тема стейджинговые таблицы

Не совсем понял как Specification тут поможет. Насколько я понимаю, это такая “объектифицированная” форма представления произвольного критерия, помогающая отбирать подмножество объектов. Как это связано со справочными данными и как клиентские системы могут это понимать? Замечу однако, что пары ключ-значение по сути то, что Максим в своём посте и предлагает: getItemProperty(…) принимает ключ в качестве параметры и возвращает значение. И проблему это не решает.

1. Спецификации могут помочь в создании абстракции поиска/фильтрации сущностей в MDM для клиентов, если сама MDM будет их поддерживать под нужные юзкейсы и актуализировать по мере появления новых данных в справочниках. Это позволит значительно сократить изменения на стороне клиентов при изменении в MDM. Если рассматривать связку через сервисы, то клиенты знают список критериев выборки, которые указывают при запросах.
2. да, Максим указывал на KV, а я предлагаю дополнить ключи метаданными, которые настолько полны (в смысле документированы ключи), что возможно их отрендерить в GUI (типа user-friendly description) или легко понимать, как их отражать в предметную область клиента.
3. ESB может на себя брать функции поддержки спецификации и трансформации элементов данных MDM или др. в формат данных клиента (в тот самый book) – почти прозрачно стыкуя предметные области, выполняя enriching данных и т.п. – когда клиент может на самом деле даже не знать, что за структура данных используется из MDM и это не потребует перепрограммирования при изменении и т.п., в том числе, если случайно параметр пропал. Хочу сказать, что подобный подход использовался для некого решения, которое прозрачно связывает поставщиков услуг и их потребителей (клиентов и реселеров), обеспечивая операционное обслуживание, CRM, fraud detection и биллинг таких связей. При этом сама система прозрачно работает именно с KV-представлением сущностей поставщиков, автоматически их отрисовывая в пользовательских GUI и используя в бизнес-логике. И самое главное: если поставщик меняет структуры своих данных – конечно сразу для клиентов новые структуры не доступны. Это возможно только после верификации изменений и возможно правки конфигурации в ESB.

Если честно, я опять-таки не врубаюсь какое отношение 1 и 2 имеет к проблеме обновления справочных данных в произвольно взятых системах. Мы либо о разных проблемах говорим, либо о каких-то специальных системах. На счёт 3 хочу заметить, что принципиальной разницы между адаптером “в ESB” и адаптером “в приложении” нет — писать и поддерживать нужно и тот, и другой.

И вообще, мы настолько далеко отошли от темы моего исходного комментария, что мне уже неудобно перед Максимом. Всё, на что я хотел обратить внимание, это то, что существет ряд проблем, которые в MDM не решаются простым “втыканием” всех в событийную шину. Право формат обмена комментариями не позволяет ни Вам, ни мне полностью раскрыть тему.

согласен, что обсуждение вышло за рамки дозволенного…
Извиняюсь.

Если я правильно понял статью Programming Without a Call Stack – Event-driven Architectures, то там предлагается такой подход: информация “размазывается” по приложениям (например, адреса) и приложение работает со своим собственным состоянием. Обновление справочника (тех же адресов) передается не из приложения в некий MDM, а наоборот в приложение. Т.е. при обработке какого-либо запроса (или события) приложение не лезет за справочником в некий MDM, а использует свое собственное состояние. Возникает вопрос, какова роль MDM при таком подходе и так ли уж он становится нужен?

Очень хороший вопрос! Вообще, это не подход из статьи, так MDM и работает — все приложения сами по себе, имеют свои справочники, а MDM (точнее MDMS, мы уже о системе говорим) обеспечивает единую картинку для всех. Что предполагает движение информации в обе стороны, ведь справочники где-то должны обновляться, а делать это в ценрализованной MDMS не всегда удобно. Теперь по вопросу.

Как справедливо отмечал Максим, это в первую очередь административная проблема: кто отвечает за ведение справочников, кто мониторит обновления, кто моделирует структуру справочников и пр. Это многим мешает правильно понять суть MDM. Техническая же составляющая вторична: это может быть EDA, ETL или какой-нибудь Data Grid — словом то, что проще и дешевле для каждого конкретного приложения.

Источник: mxsmirnov.com