Текущее время: Чт, ноя 15 2018, 02:19

Часовой пояс: 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 часа


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

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