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

Отправка писем -- смесь статики и динамики
Казалось бы простая задача и полный фарш возможностей реализации, каковых две -- Mail-пакет и статическое указание атрибутов получателя (To, From, Subject, и т.д.). Хотим динамически формировать атрибуты -- используем Mail-пакет и в меппинге заполняем атрибуты. Внезапно захотелось странного -- чтобы часть атрибутов можно было бы принудительно указывать в канале, переписывая сформированные динамически. Это удобно например в таких случаях:

* Список получателей проще вести не в меппинге а в канале. При измененениях в нём не надо протаскивать в продуктив изменения в меппингах (а Body напротив удобнее заполнять в меппинге)

* Для систем разработки, тестирования, продуктива можно заполнять получателей или тему или ещё чего по-разному, меняя в канале настройки -- в меппинге такое реализовать без закладывания на SID'ы или имена бизнес-систем нельзя

Решение конечно несложное и очевидное -- реализовать ejb-модуль к ресивер-каналу SMTP и указывать в параметрах модуля новые значения атрибутов, которые будут вписаны после меппинга.

Автор идеи и реализации -- Дима Ольшанский. Используется в продуктиве года 2, вроде ничего лучше не добавишь.

неплохо бы блоги тут заделать

Получение писем от множества слабоконтролируемых источников

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

• фильтрация содержимого делалась на уровне IMAP-сервера, на котором были настроены папки и правила раскладывания писем по папкам (каждый канал смотрит в imap://server/Inbox/FolderName1/FolderName2
• на стороне XI было несколько каналов-отправителей типа IMAP, каждый настроен на свою папку

Время шло, постепенно число источников увеличивалось и подключились человеческие существа. Тут же выявились две проблемы:

• один робот может отсылать 2 разных вида информации таких, что по атрибутам письма они никак не отличаются (поля To:, From:, Subject:, Body: неотличимы в обоих случаях). Не отличаются ничем, кроме вложения. А многие IMAP-серваки не умеют "заглядывать" в аттачи, то есть решить на сервере, в какую папку из двух возможных поместить письмо, невозможно
• люди могут как попало отсылать письма -- то в архиве аттач, то без, то одна тема, то другая, то с одного адреса, то с другого -- и всё для логически одной и той же информации

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

Итак, сортировка на почтовом серваке и индивидуальные почтовые каналы отработали в продуктиве года 2, примерно до 10-15 каналов.

Было решено отказаться от сортировки писем на почтовом серваке и переместить её в XI. Как оно сделано теперь:

1. Настроено 2 почтовых канала-отправителя, каждый берёт письма из своего адреса, протокол IMAP.

2. Настроено 2 Sender Agreement, по одному на каждый канал, оба на единый сервисный интерфейс.

3. Сделан меппинг определения вида данных (исходя из атрибутов письма и вложений), интеграционный процесс сортировки IP. Определение вида данных выглядит примерно так:

Code:
public static String getAdvice(String AttachName, String FromAddr, String Subject) {
    String sAdvice = "unknown";
    String sUpperAttach = AttachName.toUpperCase();
    if (AttachName.startsWith("prices-")) {
        sAdvice = "Prices";
    } else if (FromAddr.equalsIgnoreCase("_______@____________.__")) {
        sAdvice = "KP1";
    } else if (sUpperAttach.matches("REQUEST.*XLS.*")) {
        sAdvice = "Request";
    } else if (sUpperAttach.matches("SECURITY.*XLS.*") ) {
        sAdvice = "Security";
    }
...           
    } else if ( FromAddr.equalsIgnoreCase("_______@______.__.___") && (
            Subject.equalsIgnoreCase("Logistics") ||
            Subject.equals("Information"))
            ) {
        sAdvice = "LogNInformation";
    } else if (FromAddr.toLowerCase().matches(".*asdfghj@qwerty\\.com.*") &&
                Subject.toLowerCase().matches(".*((vbnm)|(tyuio)).*")) {
        sAdvice = "A1";
    } else if (FromAddr.toLowerCase().matches(".*asdfghj@qwerty\\.com.*") &&
                Subject.toLowerCase().matches(".*((a2)|(b2)).*")) {
        sAdvice = "A2";
    }
return sAdvice;
}

Указанные sAdvice далее используется во всех RD/ID, по нему проще задавать роутинг сообщений. По сути один sAdvice == один вид информации.

4. Настроен один Receiver Determination из данного интерфейса/IP: сейчас 9 правил, 5 получателей, 13 видов данных.

5. Настроено 5 Interface Determination из данного интерфейса/IP -- здорово облегчает выбор меппинга то, что можно задавать условия и здесь. КрутоСемьОдин. Для каждого меппинга параметрами задаётся поведение универсального меппинга (который меняет местами Mail package и Attachment).

6. Все operation mappings выглядят единообразно -- первым идёт универсальный меппинг для перестановки письма и аттача, дальше идут меппинги по месту.

Удалось реализовать универсальный (но не всем удобный) раззипователь, преобразователь из DBF и Excel в XML в этом же универсальном меппинге (ранее писалось для других целей, потом расскажу подробнее).

Все опознанные письма отправляются к зашитому в RD получателю (Enhanced RD не сделан принципиально, так как статический удобнее в документировании и понимании незнакомому человеку). Все письма с неизвестным содержимым выкладываются на FTP как 2 файла (один с текстом письма, один с аттачем).

Что нравится -- всё удобно поддерживать и расширять. Что не нравится или не реализовано ещё:

1. Иксайный сервак на солярке. Соответственно обработка нетривиальных форматов архивов (7z, rar, FreeArc), которыми пользователи могут запаковать данные и для которых нет готовых джавошных библиотек, на солярке трудоёмка. Хочется реализовать внешний виндовый веб-сервис, который бы принимал любой архив и распаковывал его (при наличии развёрнутого на данном серваке разархиватора). К тому же джава + zip + неюникодные русские имена внутри архивов это тот ещё зоопарк. Приходится зашиваться на cp866, что неправильно.

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

3. Много в конфигурации обработки сообщений сейчас прибито гвоздями. Так, например, все архивы всегда распаковываются -- а вдруг в каких-то случаях это не требуется? Для DBF/Excel преобразование в XML конфигурируется, но это для каждого отдельного вида информации конфигурируется отдельно.

4. Работа с многотомными архивами попросту не реализована. А с учётом ограничений на размер письма это реальное требование.

Автор идеи и реализации -- я, задача перехода от сортировки на почтовом сервере к сортировке в XI была поставлена заказчиком. Работает в продуктиве около полугода.

Люди умудряются в phpBB книги писать, так што вполне реально.

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

Работа с БД

Сама шина XI не является полноценным ETL-средством и работа с базами данных в ней реализована достаточно примитивно, ну а что делать, для простых задач хватает и этого. "Но есть нюансы".

Если требуется работать с большим количеством исходных БД/таблиц, лучше сразу отказаться от идеи использования sender-каналов. Иначе ситуация легко выходит на монструозный уровень в Directory: сначала 3-4 базы данных и по одному селекту на каждую БД. Такое ещё можно представить как 4CC + 4SA + 1RD + 1ID + 4party + 1BusinessSystem = 15 объектов в директори. Однако Заказчик может потом сказать "давайте из каждой БД тащить по 5 таблиц, а в будущем будет 10БД", и что же делать православному христианину в таком случае? На самом деле есть как минимум 5 подходов которые стоит рассмотреть:

1. Использовать существующий подход. Тогда число объектов Directory будет: 50CC + 50SA ну и т.д. уже не столь страшно, особенно при универсальных меппингах. Для неручного создания и сопровождения такого зоопарка есть IDAPI, каковой можно использовать. Однако это решение порождает собственные проблемы и не гарантирует победы над сложностью, каковая победа должна являться смыслом любой осмысленной деятельности. Хотя создание в директори помогает документировать решение и даёт стандартные рычаги остановки/старта CC по расписанию.

Но! в моей реальности селекты очень часто пишутся не в расчёте на иксайную логику выборки! Иксайная логика предполагает либо статические селекты по флаговым признакам (какой-нибудь XI_FLAG с двумя состояниями) либо предполагает отсутствие/наличие записей в таблице как естественный флаговый признак. У меня же на входе часто pipelined-процедура вида `select * from table(procedure_name( to_date('01012010','ddmmyyyy'), to_date('31122010','ddmmyyyy') ))', то бишь возвращает какие-то бизнес-данные за указанный период дат. Вместо pipelined-процедуры можно подставить обычный select с выборкой по WHERE того же диапазона дат, не в этом проблема. При этом состояние исходной БД вообще не меняется, а интервал надо задавать учитывая запросы бизнеса и пропускную способность шины (как правило эффективная обработка сообщений размером более 100 метров невозможна на большинстве инсталляций).

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

2. Вынести все сендеры во внешний Plain J2SE Adapter Engine с возможностью лёгкой модификации запросов на нём, возможно что эти изменения должны делаться отдельными людьми службы сопровождения в составе команд на их собственных базах данных. То есть каждую БД обслуживает свой человек, правит свои селекты и все довольны -- в XI всё приходит по XI-протоколу, в directory всё просто.

Подход имеет смысл только при необходимости делегировать полномочия, так как ручная работа никуда не девается а размазывается, что ещё хуже (из 10 человек гарантированно кто-нибудь налажает).

3. Фантастический подход -- реализовать свой EJB-модуль либо свой вообще свой адаптер для JDBC sender. Вариант с EJB какое-то время обсуждался и прорабатывался, но по многим очевидным причинам был отвергнут. Свой адаптер это уже более интересная тема, но результат непредсказуем.

4. Прагматический подход, породивший множество продуктивных идей -- на каждую БД завести один-единственный receiver-CC и инициативу запроса переложить на внешний шедулер. Это будет описано отдельным постом "О шедулере".

5. Реализовать на каждой БД единую точку отдачи данных в XI, одинаковую хранимую процедуру с унифицированным интерфейсом. Потребуются права разработчика БД и соответствующие знания, и я даже применял такой подход дважды, от невозможности в тот раз применить подход №4 из-за его малой пропускной способности.
В ходе развития данной темы было придумано целых 2 оригинальных, не встречавщихся мне в других местах, подхода:
* Все 50 исходных таблиц объединяются в один union, обобщённый табличный формат. Писать такой SQL руками конечно же невозможно, приходится писать генерирующий скрипт. Вместе с данными передаётся информация о структуре/меппинге полей для обработки в шине. Выбор таблиц для помещения в результирующую выборку происходит либо как параметр pipelined-процедуры, либо как функция от времени. В целом слабожизнеспособно, но сама идея объединять разные таблицы в одну выборку заслуживает внимания (поскольку унифицирует меппинги и уменьшает число интерфейсов).
* Все 50 исходных таблиц выбираются как XML-дерево. Это супер-идея Димы Ольшанского, каковая помогла вообще по-новому взглянуть на возможности сендер-канала JDBC. Результат выборки (см. пакет DBMS_XMLGEN для Oracle) выглядит так:
Сделать unescaping такого дерева совсем не трудно. И построить в Оракле его тоже нетрудно, по 1 курсору на таблицу + один селект из 50 курсоров, а затем DBMS_XMLGEN построит дерево сам!

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

О шедулере
Как уже писалось ранее, прагматический подход к опросу любых источников данных (и отказ от такового средствами SenderCC + Availability Time Planning) позволяет здорово сэкономить на объектах в Directory и на сложности обслуживания. Повторюсь, очень многие из сделанных решений основаны на сильном влиянии ETL-задач, не совсем свойственным шинам и XI.

Что умеет ATP? Лишь включать/выключать каналы, при этом если надо задать нетривиальное условие времени запуска то надо не слабо заморочиться. К тому же настройки ATP не переносятся между системами и их трудно документировать (нет отчёта).

Что хочется от новоизобретённого шедулера?
1. Просто и удобно формировать запросы к источникам данных, имея на входе высокоуровневое описание
2. Регулировать загрузку (последовательно/параллельно)
3. Вызывать обработчики запросов удобно и по Enhanced Receiver Determination
4. Легко тестироваться и мониториться
5. Встраиваться в ограничения XI так, чтобы причинять минимум неудобств в человеческом интерфейсе к шедулеру

Сразу отмечу что в текущей версии удалось полностью решить задачу 1 и частично 3, 4. Пункт 2 вообще наверное полностью нереализуем. Но даже текущая реализация сильно облегчает жизнь православного консультанта.

(в процессе написания)

По поводу выноса параметров из меппингов в канал: в 7.1 же можно параметры для меппингов прописывать в Interface Determination, а еще хороший подход это использовать value mapping.

Вообще из большинства БД можно посылать HTTP запросы, тем самым забить на JDBC sender, а так конечно по ситуации, где-то и через ресиверный канал и шедул, а где-то и сендерный не страшно использовать.

Да, в 7.1 так и делаем, изначально было для 7.0 сделано. Сейчас переписываем при поломках.
По поводу VM, интересное предложение. Кстати ты с UKMS разобрался? Я с первого раза не смог реализовать, пока отложил.



Так тут вопрос в параметрах, как их протягивать в запрос к БД из шины. Удобно, конечно же вот так: (пример части реального конфига с заменой названий):, а это преобразуется в поток селектов. Хотя конечно можно это как-то из шины генерить как джобы БД.... кстати занятная идея ))) шина генерит джобы с заданиями в конкретную БД и запуливает их туда, а БД действительно по HTTP стучится в шину. Кстати такой траффик в отличии от jdbc receiver будет бесплатным как мне в сапе объяснили.

Я бы не стал извращаться и переложил бы эту работу на БД, ведь заведомо известно, как сгенерить параметры, так почему бы это не делать в БД?)) Тут конечно вопрос еще в том, что консалту часто трудно прогнуть что-либо в заказчике))

>> Я бы не стал извращаться и переложил бы эту работу на БД, ведь заведомо известно, как сгенерить параметры, так почему бы это не делать в БД?)) Тут конечно вопрос еще в том, что консалту часто трудно прогнуть что-либо в заказчике))

ненене, Девид Блейн )))
во-первых этих БД -- штук 30
во-вторых шедулер не только к БД ходит но и к веб-сервисам которых тоже штук 10 серваков*сколько-то операций в каждом
в-третьих иметь конфиг такого ETL-вытягивания, панель экстракции, в одном месте гораздо удобнее чем джобы руками настраивать
в-четвёртых помимо автошедулера есть и ручные задания (в схожем формате), которые тем же шедулером обрабатываются -- люди выкладывают файлики с заданиями на закачку вручную

вот из шины генерить джобы в базах данных это гуд )))

(про шедулер пока не дописал т.к. есть идеи переделать его нахрен)
Универсальный меппинг, или xsl в рантайме

В интеграционных процессах часто много мелких преобразований (выдачу логов или диагностики), которые муторно прописывать отдельными меппингами. Конечно никуда не деться от самих объектов Repository -- абстрактных интерфейсов и операционных меппингов над ними -- но зато для каждого из них можно не писать конкретный меппинг (джаву, xslt, abap). Создаём 10 строковых параметров p1..p10, пишем в них прямо в интеграционном процессе XSLT-преобразование -- только его потроха без преамбулы -- а в универсальном джавашном меппинге реализуем вычисление входного потока внутри данного xslt.

Да, и конечно этот же подход можно в ID использовать. Однако это уже изврат по двум причинам:
1) нафиг не надо
2) в 7.1ehp5 отломалось корректное включение в change list параметров. Теперь operation mapping, имеющий параметры, почти гарантированно при транспорте их потеряет, а в случае если в них будет записан меппинг, это очень плохо.

Конечно проверки типов и компиляции никакой нет, но с другой стороны где они вообще в XI есть? (риторически)

Upd: Другой режим, помимо транформации входа в выход, это создания payload'а из ничего. Иначе в IP генерить константы муторно.

Upd2: Второе полезное применение xslt-режима -- быстро отлаживать идеи, которые неправильно работают из-за SAP XML Toolkit или JAVAX-особенностей реализации XSLT в PI. Так как стандартный деплой (через IA) работает долго, то есть смысл отлаживать нетривиальный xslt динамически, в данном меппинге. Работает

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

Upd1: более всего это похоже на лисповский REPL, когда и программа и данные в одном списке (в данном случае -- в дереве XML). Отличная штука с богатыми перспективами... прямо ЛЕГО-бипиэм!

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

Для этого надо в IA положить файл и написать:



основной проблемой (после того как увидел такую классную штуку) было -- как подобрать формат названия ресурса, это просто УРЛ внутри ИА!

Теперь можно включать XSLTшки в джавашные меппинги и их выполнять подконтрольно.
Или можно xml-справочники какие или наборы констант не хардкодить и не в VMG держать (если им там не место по логике). Не всё имеет смысл в value mapping тащить.

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