Текущее время: Вт, янв 22 2019, 15:12

Часовой пояс: UTC + 4 часа




Начать новую тему Ответить на тему  [ Сообщений: 13 ] 
Автор Сообщение
 Заголовок сообщения: удачные решения
СообщениеДобавлено: Пт, июл 09 2010, 14:18 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
Хочу поделиться некоторыми удачными решениями (не архитектурными а мелкоремесленными) тех задач, что возникают при любой интеграции, может быть кому-то будет интересно.

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

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

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

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Вс, июл 11 2010, 22:03 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Вт, авг 12 2008, 08:40
Сообщения: 196
Откуда: Екатеринбург
Пол: Мужской
неплохо бы блоги тут заделать

_________________
ай, каррамба


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Пн, июл 12 2010, 15:11 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
Получение писем от множества слабоконтролируемых источников

Есть и интересная обратная задача -- на один и тот же почтовый адрес поступают письма с аттачами полезной информации. Пока разных источников было немного и они были роботами, всё в целом было нормально:
  • фильтрация содержимого делалась на уровне 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 была поставлена заказчиком. Работает в продуктиве около полугода.

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Пн, июл 12 2010, 15:12 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
ivanovio написал:
неплохо бы блоги тут заделать

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

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Ср, июл 14 2010, 16:11 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
chumpa написал:
Решение конечно несложное и очевидное -- реализовать ejb-модуль к ресивер-каналу SMTP и указывать в параметрах модуля новые значения атрибутов, которые будут вписаны после меппинга.


Написал на форуме, прошло 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) выглядит так:
Code:
<?xml version="1.0" encoding="utf-8"?>
<ns:SqlClause xmlns:ns="urn:1">
   <row>
      <COLUMN_VALUE>&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;ROWSET&gt;
&lt;ROW&gt;
  &lt;ZZZZ_ID&gt;2251018&lt;/ZZZZ_ID&gt;
  &lt;TYPE_ID&gt;1&lt;/TYPE_ID&gt;
  &lt;YYYY_ID&gt;121634470&lt;/YYYY_ID&gt;
&lt;/ROW&gt;
&lt;/ROWSET&gt;
</COLUMN_VALUE>
   </row>
</ns:SqlClause>
Сделать unescaping такого дерева совсем не трудно. И построить в Оракле его тоже нетрудно, по 1 курсору на таблицу + один селект из 50 курсоров, а затем DBMS_XMLGEN построит дерево сам!

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

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Чт, июл 15 2010, 09:30 
Директор
Директор

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

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

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

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

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

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Пт, авг 13 2010, 17:21 
Ассистент
Ассистент
Аватара пользователя

Зарегистрирован:
Вт, сен 25 2007, 14:27
Сообщения: 45
Откуда: Москва, АНТ-Информ (Газпром)
Пол: Мужской
По поводу выноса параметров из меппингов в канал: в 7.1 же можно параметры для меппингов прописывать в Interface Determination, а еще хороший подход это использовать value mapping.

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

_________________
Ерин Саня: А я напишу свой SAP ...с блэкджеком и шлюх*ми


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Пт, авг 13 2010, 18:13 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
erinsasha написал:
По поводу выноса параметров из меппингов в канал: в 7.1 же можно параметры для меппингов прописывать в Interface Determination

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

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


Так тут вопрос в параметрах, как их протягивать в запрос к БД из шины. Удобно, конечно же вот так: (пример части реального конфига с заменой названий):
Code:
<Rules runAt="(curday)T15:30:00" name="Z.Ships.Present">
        <Z.Ships minDate="(trunc(add_months(curday,-1),'M'))" maxDate="(last_day(curday))" factory="30" />
        <Z.Ships minDate="(trunc(add_months(curday,-1),'M'))" maxDate="(last_day(curday))" factory="31" />
        <Z.Ships minDate="(trunc(add_months(curday,-1),'M'))" maxDate="(last_day(curday))" factory="32" />
</Rules>

  <Rules runAt="(curday)T(lastrunt+300)" name="YYYCNP">
     <ZZZZZ.Assigns fromParty="P_CNP" fromComponent="BSP_ZZZZZZZZZZZZ" persistence="1" />
     <ZZZZZ.Assigns fromParty="P_NP" fromComponent="BSP_ZZZZZZZZZZZZ" persistence="1" />
  </Rules>
, а это преобразуется в поток селектов. Хотя конечно можно это как-то из шины генерить как джобы БД.... кстати занятная идея ))) шина генерит джобы с заданиями в конкретную БД и запуливает их туда, а БД действительно по HTTP стучится в шину. Кстати такой траффик в отличии от jdbc receiver будет бесплатным как мне в сапе объяснили.

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Пт, авг 13 2010, 20:52 
Ассистент
Ассистент
Аватара пользователя

Зарегистрирован:
Вт, сен 25 2007, 14:27
Сообщения: 45
Откуда: Москва, АНТ-Информ (Газпром)
Пол: Мужской
chumpa написал:

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


Так тут вопрос в параметрах, как их протягивать в запрос к БД из шины. Удобно, конечно же вот так: (пример части реального конфига с заменой названий):
Code:
<Rules runAt="(curday)T15:30:00" name="Z.Ships.Present">
        <Z.Ships minDate="(trunc(add_months(curday,-1),'M'))" maxDate="(last_day(curday))" factory="30" />
        <Z.Ships minDate="(trunc(add_months(curday,-1),'M'))" maxDate="(last_day(curday))" factory="31" />
        <Z.Ships minDate="(trunc(add_months(curday,-1),'M'))" maxDate="(last_day(curday))" factory="32" />
</Rules>

  <Rules runAt="(curday)T(lastrunt+300)" name="YYYCNP">
     <ZZZZZ.Assigns fromParty="P_CNP" fromComponent="BSP_ZZZZZZZZZZZZ" persistence="1" />
     <ZZZZZ.Assigns fromParty="P_NP" fromComponent="BSP_ZZZZZZZZZZZZ" persistence="1" />
  </Rules>
, а это преобразуется в поток селектов. Хотя конечно можно это как-то из шины генерить как джобы БД.... кстати занятная идея ))) шина генерит джобы с заданиями в конкретную БД и запуливает их туда, а БД действительно по HTTP стучится в шину. Кстати такой траффик в отличии от jdbc receiver будет бесплатным как мне в сапе объяснили.


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

_________________
Ерин Саня: А я напишу свой SAP ...с блэкджеком и шлюх*ми


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Сб, авг 14 2010, 14:20 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
>> Я бы не стал извращаться и переложил бы эту работу на БД, ведь заведомо известно, как сгенерить параметры, так почему бы это не делать в БД?)) Тут конечно вопрос еще в том, что консалту часто трудно прогнуть что-либо в заказчике))

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

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

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Ср, авг 25 2010, 14:45 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
(про шедулер пока не дописал т.к. есть идеи переделать его нахрен)
Универсальный меппинг, или 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 динамически, в данном меппинге. Работает :)

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Вт, сен 21 2010, 20:14 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
хочу поделиться радостью: в шедулере удалось (в основном) избавиться от кошмара состояния, то есть теперь вместо простыни с BPEL рисуется много маленьких простыней (носовых платков скорее), а все трансформы убиты в пользу меппингов между процессами.

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

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: удачные решения
СообщениеДобавлено: Чт, дек 02 2010, 23:30 
Директор
Директор

Зарегистрирован:
Вт, июл 18 2006, 18:44
Сообщения: 994
Откуда: что и все
Пол: Мужской
в рамках шлифовки нового шедулера нашёл любопытную возможность грузить свои ресурсы (любые файлы) из импортированных архивов. Правда, только из текущего пока удаётся -- в котором находится вызываемый джава-меппинг.

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

Цитата:
package ru.hixay;
...
public class Classname extends AbstractTransformation {
public void transform(TransformationInput in, TransformationOutput out)
{
InputStream is = getHelper().getResourceAsStream("ru/hixay/Classname.java");
// тут is это просто поток
}


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

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

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

_________________
Telegram-chat: PO, CPI-PI, java, groovy


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 13 ] 

Часовой пояс: UTC + 4 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Majestic-12 [Bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB