Застосування продуктів WebSphere DataPower і WebSphere MQ File Transfer Edition для керованої передачі файлів

1. Малюнок 1. Мережеве розгортання пристрою DataPower
2. Таблиця 1. Вибір між B2BGW і MPGW
3. приклади конфігурації
4. Конфігурація WebSphere MQ FTE
5. Малюнок 2. Конфігурація WebSphere MQ FTE
6. Сценарій застосування 1. Вихідна передача файлу з використанням B2BGW
7. Лістинг 1. Команда fteCreateTransfer, що включає DPMQFTE-заголовки
8. Малюнок 3. Конфігурація одиниць роботи (Unit of Work) DataPower
9. Сценарій застосування 2. Вихідна передача файлу з використанням MPGW (потокова передача)
10. Малюнок 4. Завдання правил DataPower
11. Лістинг 2. Команда fteCreateTransfer, що використовує заголовок DPMQFTEDestination
12. Лістинг 3. XML-таблиця стилів DataPower для MPGW-маршрутизації
13. Малюнок 5. Конфігурація DataPower для потокової передачі
14. Сценарій застосування 3. Вхідна передача файлу з використанням B2BGW
15. Лістинг 4. URL-адресу бекенд mqfte при використанні об'єкта DataPower MQ Q-Manager
16. Лістинг 5. Команда fteCreateMonitor для сценарію застосування 3
17. Лістинг 6. XML-визначення завдання для монітора FTE
18. Сценарій застосування 4. Вхідна передача файлу з використанням MPGW (потокова передача)
19. Висновок
20. Подякою
21. Ресурси для скачування

У даній статті описується інтеграція продуктів WebSphere DataPower і WebSphere MQ File Transfer Edition (FTE). На момент написання статті значна частина наявної документації застаріла, крім того, ця документація орієнтована переважно на використання керованої передачі файлів в контексті B2B. У микропрограммном забезпеченні DataPower версії V4.x (вбудоване програмне забезпечення V4.x) реалізований спеціалізований обробник протоколу WebSphere MQ FTE, що дозволяє поліпшити інтеграцію між цими двома продуктами. У версії вбудованого ПЗ V5.x реалізована підтримка розширеної пам'яті, що знімає ряд обмежень для великих файлів.

Малюнок 1. Мережеве розгортання пристрою DataPower

Порівняння сервісів B2BGW (B2B Gateway Service) і MPGW (Multi-Protocol Gateway) в контексті керованої передачі файлів

До появи версії вбудованого ПЗ 4.0.0 інтеграція між DataPower і WebSphere MQ FTE базувалася переважно на спільно використовуваних файлових системах. Така інтеграція була достатньою для багатьох контекстів, однак вона не використовувала такі просунуті функції WebSphere MQ, як транзакційність (transactionality) і гарантована доставка (assured delivery). Крім того, інструмент B2B Transaction Viewer не був повністю інтегрований з продуктом WebSphere MQ FTE.

В даний час для транспортування B2B-документів зазвичай використовуються протоколи FTP і SFTP. З цієї причини найпоширенішим сценарієм застосування є інтеграція продуктів WebSphere MQ FTE і DataPower за допомогою B2B-шлюзу. Більш детальну відповідну інформацію можна отримати в документі WebSphere DataPower Release 4.0.1 B2B MQFTE .

Сервіс B2BGW (B2B Gateway Service), доступний тільки в моделі XB *, підтримує такі широко поширені протоколи обміну B2B-повідомленнями, як EDIINT AS1, AS2, AS3, а також протокол ebMS v2.0. Це дозволяє належним чином управляти передачами файлів в рамках B2B-транзакції, реєструвати операції в персистентному сховище і інтегрувати метадані FTE з інструментом B2B Transaction Viewer.

Крім того, B2BGW-сервіс дозволяє організувати маршрутизацію файлів за допомогою об'єктів типу Business Partner (бізнес-партнер). Ця абстрактна конструкція, що дозволяє зберігати інформацію про об'єкті типу "бізнес-партнер" в профілі торгового партнера, використовується для примусового застосування партнерських бізнес-угод між двома сторонами, а також для логічного зв'язування ідентифікаційних даних партнера з одним або декількома цільовими URL-адресами.

Необхідно відзначити, що в цій конфігурації потокова передача неможлива, тому файли завжди буферизується в пам'яті. Навіть в тих випадках, коли великий файл сегментируется на безліч повідомлень WebSphere MQ, описуваний B2BGW-сервіс спочатку відновлює весь файл в пам'яті і тільки потім обробляє його.

З огляду на характеристики B2BGW, на стадії проектування необхідно розглянути кілька критично важливих аспектів, а саме:

• протоколи
• Інтеграція з B2BViewer
• розміри файлів
• аудит
• інтенсивність транзакцій
• Транзакційність і обробка помилок
• Планування ресурсів, B2B-метадані, періоди збереження корисного навантаження

Протоколи критично важливі, оскільки якщо зовнішні партнери використовують специфічні B2B-протоколи, наприклад, протоколи AS / 1/2/3, то сервісу B2BGW немає ніякої альтернативи. Це справедливо і в тих випадках, коли ключовою вимогою рішення є інтеграція з B2BViewer або коли замовник бажає використовувати унікальні можливості сервісу B2BGW в галузі управління профілями або перегляду.

Наступний ключовий аспект - розмір файлу. Зазвичай для дуже великих файлів краще підходить MPGW-сервіс (Multi-Protocol Gateway), оскільки він підтримує потокову передачу і за замовчуванням не зберігає корисне навантаження повідомлення. Однак MPGW-сервіс не здатний забезпечити подання, яке демонструвало б стан транзакції, а також немає можливостями для управління профілями.

Цей момент приводить нас до наступного аспекту, а саме, до аудиту. Як було зазначено вище, B2BGW-сервіси призначені для обслуговування критично важливих B2B-транзакцій. За умовчанням вони підтримують широкий вибір функцій, включаючи аудит транзакцій, а також надають метаінформацію інструменту B2B Transaction Viewer.

MPGW-сервіси - це більш прості об'єкти без вбудованих можливостей аудиту. Для будь-якої обробки, в тому числі для журналирования і для аудиту, потрібно явне конфігурація і, в кінцевому підсумку, написання певного обсягу XSLT-коду (зазвичай мінімального).

Крім можливостей для потокової передачі, простота і гнучкість MPGW-сервісів дають ще одна перевага, а саме високу інтенсивність транзакцій. Як правило, MPGW-сервіси пропонують більш високу продуктивність, ніж B2BGW-сервіси, оскільки вони не зберігають метаданих або корисних навантажень.

І, нарешті, ще один важливий аспект, який підлягає розгляду - транзакційні ь і обробка помилок, яка тепер може спиратися на традиційні функції інтеграції DataPower-MQ, такі як одиниця роботи (unit-of-work) і відкат (back-out). Конкретні деталі транзакційності і обробки помилок залежать від напрямку передачі (тобто, від того, чи є WebSphere MQ джерелом або місцем призначення переданого файлу) і йтиме мова нижче одному з наступних розділів даної статті.

У таблиці 1 узагальнено основні аспекти, які слід враховувати при виборі між сервісами B2B Gateway і Multi-Protocol Gateway, а також при інтеграції DataPower з WebSphere MQ FTE.

Таблиця 1. Вибір між B2BGW і MPGW

Транзакційність і персистентність повідомлень

Для переміщення файлів в масштабі підприємства продукт WebSphere MQ FTE використовує інфраструктуру WebSphere MQ. З міркувань продуктивності цей продукт був спроектований в розрахунку на надійне переміщення файлів з використанням неперсістентних повідомлень для передачі даних файлу. Обмін персистентного повідомленнями використовується для початкового квітірованія зв'язку між агентами WebSphere MQ FTE, а також для передачі повідомлень при відновленні з'єднання між агентами. При переміщенні файлу в чергу за допомогою команди fteCreateTransfer повідомлення за замовчуванням є персистентного. З точки зору WebSphere MQ FTE в цей момент передача завершується. Якби повідомлення не були персистентного і компонент Queue Manager відмовив би вже після завершення передачі FTE, але до запуску передачі DataPower, то переданий файл зник би з системи без будь-яких явних помилок передачі.

Використання персистентних повідомлень має важливий наслідок стосовно налаштування Queue Manager, описане в статті під назвою Конфігурація та налаштування WebSphere MQ для підвищення продуктивності в середовищах Windows і UNIX . У цій статті, зокрема, стверджується, що персистентні повідомлення вимагають відповідної настройки журналів Queue Manager. Цей момент дуже важливий, оскільки відповідно до нашого досвіду недостатнє журнальне простір у елемента Queue Manager є найбільш поширеною причиною помилок.

Ще один аргумент на користь настройки журналів Queue Manager полягає в тому, що в контексті B2B повідомлення зазвичай споживаються в рамках транзакції. Це означає, що підсумкова фіксація відбувається тільки тоді, коли система DataPower завершила передачу файлу на цільову систему. В результаті транзакції можуть дуже довго перебувати в стані очікування - в залежності від загального розміру файлу і від величини мережевий затримки.

І, нарешті, не забувайте про важливість вибору належного значення персистентності для кожної черги, оскільки за замовчуванням DataPower налаштовує персистентність повідомлення згідно з відповідним параметром черзі. Що забезпечити більш тонке управління, поведінка DataPower за замовчуванням можна перевизначити, явно задавши прапор персистентності в MQMD-заголовку (MQ Message Descriptor) політики обробки. Персистентность черзі за замовчуванням не є критично важливою для WebSphere MQ FTE, оскільки вона покликана оптимізувати використання персистентних повідомлень.

приклади конфігурації

У даній статті розглядаються наведені нижче типові сценарії застосування.

Використовується наступна базова конфігурація.

• Пристрій DataPower XB62 з сервісом B2B Gateway і з сервісом Multiprotocol Gateway
• Образ VMware з встановленим продуктом WMQFTE, який діє як внутрішній партнер
• Додатковий спосіб VMware з FTP-сервером, а також з клієнтом, який діє як зовнішній партнер

З урахуванням цієї конфігурації ми будемо використовувати прості протоколи. У реальному виробничому середовищі всі комунікації були б захищені за допомогою шифрування.

Ця конфігурація DataPower надзвичайно проста; деякі її деталі будуть розглянуті докладніше при розгляді сценаріїв застосування.

Конфігурація WebSphere MQ FTE

У будь-якої конфігурації WebSphere MQ FTE повинні бути присутніми наступні елементи.

• Один елемент WebSphere MQ Queue Manager, конфігурований як WebSphere MQ FTE Coordination Queue Manager. Елемент Coordination Queue Manager використовує черги WebSphere MQ для обробки передач файлів і для публікації / підписки WebSphere MQ з метою збереження інформації, яка відноситься до агентам WebSphere MQ FTE, асоційованим з цією конфігурацією. Як WebSphere MQ FTE Coordination Queue Manager повинен використовуватися продукт WebSphere MQ версії 7 або вище, що володіє необхідною функціональністю публікації / підписки.
• Один або більше елементів WebSphere MQ Queue Manager, що діють як WebSphere MQ FTE Command Queue Manager. Елемент Command Queue Manager використовується для передачі запитів команд в WebSphere MQ FTE ..
• Один або більше елементів WebSphere MQ Queue Manager, що діють як WebSphere MQ FTE Agent Queue Manager. Елементи типу Agent Queue Manager підтримують черги WebSphere MQ, необхідні для передачі файлів між агентами за допомогою повідомлень WebSphere MQ.
• Один або кілька агентів WebSphere MQ FTE, які здійснюють передачу файлів. Кожен агент пов'язаний з одним елементом типу Agent Queue Manager. Один елемент типу Agent Queue Manager здатний підтримувати безліч агентів.

В нашій конфігурації WebSphere MQ FTE використовувалися версії WebSphere MQ V7.0.1.8 і WebSphere MQ FTE V7.0.4.1. Всі компоненти WebSphere MQ і WebSphere MQ FTE виконувалися в середовищі Windows®. Після випуску версії WebSphere MQ V7.5 продукт WebSphere MQ FTE став необов'язковим компонентом WebSphere MQ 7.5 під назвою WebSphere Managed File Transfer.

Ми використовували просту конфігурацію WebSphere MQ FTE в середовищі Windows для тестування описаних вище сценаріїв застосування DataPower і WebSphere MQ FTE. До складу цієї конфігурації входив одиночний елемент WebSphere MQ Queue Manager, який мав ім'я FTE_QM. Цей елемент виконував описані вище ролі, а саме Coordination Queue Manager, Command Queue Manager і Agent Queue Manager. За замовчуванням елемент FTE_QM створюється з циклічної записом в журнали (три первинних і два вторинних журнальних файлу). Ми прийшли до висновку про необхідність коригування цієї ситуації, коли почали передавати великі файли. Для виробничої конфігурації більш характерно підключення агентів до кількох різних елементів типу Agent Queue Manager.

У конфігурації FTE_QM ми позначили дві черги WebSphere MQ як FTE_TO_B2BGW і як FTE_TO_MPGW відповідно. Ці черги використовувалися в якості цільової черги для передач типу File-to-Queue, ініційованих між AGT1_FTE_FROM_FILE і AGT3_DP_FTE_QM. Повідомлення, поміщені в ці черги, потім зчитувалися пристроєм DataPower з метою їх передачі в кінцевий пункт призначення. У кожної черги була чергу відкату (backout queue): B2B_BACKOUT у черзі FTE_TO_B2B і MPGW_BACKOUT у черзі FTE_TO_MPGW відповідно.

Для передач від DataPower до FTE була створена додаткова чергу з ім'ям DP_TO_FTE. За замовчуванням прапор персистентності для цієї черги отримав значення "persistent" (персистентний).

Потім на тій же Windows-машині ми створили три агента WMQ_FTE.

• AGT1_FTE_FROM_FILE: Це агент джерела для передач від WebSphere MQ FTE до DataPower. Цей агент використовується для читання з джерела тих даних, які підлягають передачі з файлової системи Windows.
• AGT2_FTE_TO_QUEUE_FOR_DP: Це агент призначення для передач від WebSphere MQ FTE до DataPower. Файли, передані з AGT1_FTE_FROM_FILE, відсилаються цього агенту як передача типу File-to-Queue, тому файл надходить в чергу призначення у вигляді групи повідомлень WebSphere MQ. Пристрій DataPower здійснює моніторинг цієї черги; після прибуття всіх повідомлень цієї групи пристрій DataPower виконує передачу в кінцевий пункт призначення, заданий в DataPower. У нашому випадку кінцевим пунктом призначення для передач від WebSphere MQ FTE до DataPower був FTP-сервер, що виконувався на окремій Windows-машині (тобто не на машині з продуктами WebSphere MQ і WebSphere MQ FTE). Для того щоб вирішити передачі файлів типу File-to-Queue, властивості enableQueueInputOutput в файлі властивостей agent.properties агента AGT3_DP_FTE було присвоєно значення "true".
• AGT3_DP_TO_FTE: Це агент джерела для передач від DataPower до WebSphere MQ FTE. Файл зчитується пристроєм DataPower, після чого надсилається як одне з повідомлень WebSphere MQ в чергу WebSphere MQ. Моніторинг цієї черги здійснюється агентом WebSphere MQ FTE Monitor. При надходженні повідомлень в цю чергу агент запускає передачу WebSphere MQ FTE. У такій триггерной (triggered) передачі цей агент є агентом джерела, а AGT1_FTE_FROM_FILE є агентом призначення.

Ці три агента WebSphere MQ FTE підключені до менеджера FTE_QM A gent Queue Manager за допомогою механізму cross-memory - тобто за допомогою зв'язування (binding), а не за допомогою з'єднання з клієнтом WebSphere MQ. Всі три агента були сконфігуровані для виконання в якості Windows-сервісів. На рис. 2 показана конфігурація WebSphere MQ FTE, в тому числі агенти, менеджер черги і самі черги.

Малюнок 2. Конфігурація WebSphere MQ FTE

Взаємодія WebSphere MQ FTE з MPGW відбувається аналогічним чином. Єдина відмінність полягає в тому, що для вихідних передач використовується чергу WebSphere MQ з ім'ям "FTE_TO_MPGW".

Сценарій застосування 1. Вихідна передача файлу з використанням B2BGW

На даний момент B2BGW-маршрутизація добре визначена і описана в документі під назвою WebSphere DataPower Release 4.0.1 B2B MQFTE .

Перший крок полягає в створенні внутрішнього і зовнішнього партнерів. В якості зовнішнього партнера додається FTP-сервер як пункт призначення. В якості внутрішнього партнера додається WebSphere MQ FTE як пункт призначення.

Передачу файлу по частинах рекомендується здійснювати за допомогою активації транзакційності за цільовим URL-адресою WebSphere MQ FTE і перейменування цього файлу після його передачі в пункт призначення (FTP-сервер).

Аналогічним чином створюється фронтальний обробник WebSphere MQ FTE для прийому файлів від внутрішнього партнера і FTP-сервера FSH для прийому файлів від зовнішнього партнера.

Останній крок полягає в створенні B2BGW-сервісу за допомогою додавання двох фронтальних оброблювачів і двох бізнес-партнерів.

При передачі файлів WebSphere MQ FTE використовуються наступні заголовки.

• DPMQFTESenderID: Бізнес-ідентифікатор (Business ID) внутрішнього партнера
• DPMQFTEReceiverID: Бізнес-ідентифікатор (Business ID) зовнішнього партнера
• DPMQFTEContentType: Тип контенту в корисне навантаження повідомлення

Приклад показаний в лістингу 1.

Лістинг 1. Команда fteCreateTransfer, що включає DPMQFTE-заголовки

У команді fteCreateTransfer, показаної в лістингу 1, параметри -sa і -da позначають відповідно агент джерела (AGT1_FTE_FROM_FILE) і агент призначення (AGT2_FTE_TO_QUEUE_FOR_DP) продукту WebSphere MQ FTE. Параметр -dm позначає елемент Queue Manager (FTE_QM) призначення, а параметр -dq позначає ім'я черги призначення (FTE_TO_B2BGW), а також задає тип передачі (File to Queue). Значення true параметра -dqp вказує, що повідомлення, що поміщаються в чергу призначення, будуть персистентного. Значення true параметра -qmp вказує, що перше повідомлення, записане в чергу призначення, буде містити набір властивостей повідомлення.

Значення после параметра -md представляються собою парі "значення-имя", что передаються в WebSphere MQ FTE. І, нарешті, значення 1M параметра -qs дає вказівку WebSphere MQ FTE розділяти передачу на кілька повідомлень, що утворюють групу повідомлень WebSphere MQ. Максимальний розмір повідомлення в цій групі становить 1 МБ. Ми виявили, що якщо не використовувати параметр -qs для великих файлів, то передача WebSphere MQ FTE завершиться помилкою з кодом 2030 (MQRC_MSG_TOO_BIG_FOR_Q). Щоб запобігти цю помилку, ми скоригували максимальні розміри повідомлення для елемента FTE_QM Queue Manager і для черги FTE_TO_B2BGW. За замовчуванням цей параметр для MAXMSGL має значення 4 МБ. Рекомендації зі зміни параметра MAXMSGL для WebSphere MQ і властивості maxInputOutputMessageLength для агента WebSphere MQ FTE наведені в документі Посібник з налаштування властивостей WebSphere MQ і WebSphere MQ File Transfer Edition, що мають відношення до розміру повідомлення .

Одиниці роботи (Unit-Of-Work, UOW) активуються в об'єкті DataPower Queue Manager (див. Рис. 3). У разі помилок повторні спроби передачі будуть здійснюватися аж до досягнення заданого значення лічильника відкатів (backout count), після чого передається файл буде переміщений в чергу відкату (backout queue). Слід пам'ятати, що спочатку файл збирається в пам'яті і тільки потім переміщається в чергу відкату, тому розміри повідомлення в черзі відкату можуть відрізнятися від розмірів повідомлень у вихідній черзі (request queue).

Малюнок 3. Конфігурація одиниць роботи (Unit of Work) DataPower

І, нарешті, необхідно відзначити, що настройки GMO в обробнику протоколу WebSphere MQ FTE перезаписувати настройками в об'єкті DataPower Queue Manager Object. Якщо одиниця роботи (UOW) активована, то повідомлення - незалежно від їх персистентності - споживаються під управлінням точки синхронізації (syncpoint), і навпаки.

В якості опції продукт WebSphere MQ FTE здатний реєструвати подробиці передачі в базі даних. Інструмент DataPower B2B Transaction Viewer здатний витягувати і візуалізувати цю інформацію в рамках передачі файлів. Для цього необхідно конфігурувати об'єкт DataSource на панелі розширених налаштувань B2B Gateway.

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

Сценарій застосування 2. Вихідна передача файлу з використанням MPGW (потокова передача)

Цілком ймовірно, це найпростіша конфігурація. На стороні DataPower є сервіс Multi-Protocol Gateway з динамічним бекенд і фронтальний обробник протоколу WebSphere MQ FTE.

Дана конфігурація призначена для потокової передачі великих файлів, тому політика обробки, як правило, надзвичайно проста (см. Рис. 4).

Малюнок 4. Завдання правил DataPower

Мінімально необхідна обробка полягає у встановленні пункту призначення. Агент WebSphere MQ FTE здатний передавати метадані в DataPower за допомогою RFH-заголовків, які пристрій DataPower зможе використовувати для встановлення пункту призначення.

У наступному прикладі (лістинг 2) використовує спеціальний заголовок з ім'ям DPMQFTEDestination. MQ FTE передає файл в чергу за допомогою наступної команди (див. Лістинг 2).

Лістинг 2. Команда fteCreateTransfer, що використовує заголовок DPMQFTEDestination

Щоб уникнути невиявлених помилок, повідомлення в черзі WebSphere MQ, тобто в кінцевому пункті передачі WebSphere MQ FTE, є персистентного.

При потокової передачі сегментованих повідомлень WebSphere MQ FTE рекомендується підтримувати порівняно малі розміри таких повідомлень (менше 1 МБ).

У цьому прикладі заголовок DPMQFTEDestination задає FTP-сервер, доступ до якого здійснюється за допомогою ідентифікатора користувача "user" та пароля "password". Цей FTP-сервер має IP-адресу xx.xx.xx.xx. Цей файл можна відправити по частинах, імена яких мають префікс foo.part. Після завершення передачі ім'я файлу має префікс Foo.Complete.

Маршрутизація в таблиці стилів DataPower використовує цей заголовок для встановлення реального пункту призначення (див. Лістинг 3).

Лістинг 3. XML-таблиця стилів DataPower для MPGW-маршрутизації

Параметри MPGW налаштовуються наступним чином: тип запиту (request type) - NON-XML, тип відповіді (response type) - Pass-Thru, управління потоком (flow control) включено, запит і відповідь передаються в потоковому режимі (див. Рис. 5) .

Малюнок 5. Конфігурація DataPower для потокової передачі

Як зазначалося вище, в микропрограммном забезпеченні DataPower версії V5.x реалізована підтримка розширеної пам'яті, що в значній мірі зменшує потребу в потокової передачі. Проте для дуже великих файлів (більше 1 ГБ) потокова передача як і раніше може виявитися найкращим варіантом. Необхідно враховувати, що в режимі буферизації дві передачі - від FTE до DataPower і від DataPower до FTP-сервера - виконуються строго послідовно. Однак в потоковому режимі ці дві передачі файлів відбуваються в значній мірі паралельно, що зменшує загальний час затримки.

І, нарешті, цей сервіс не інтегрований з B2BViewer.

Сценарій застосування 3. Вхідна передача файлу з використанням B2BGW

Конфігурація DataPower така ж, як в сценарії застосування 1 .

У даному сценарії маршрутизація, в тому числі встановлення ідентифікаторів партнерів, виконується згідно звичайною схемою B2BGW. Для вихідних двійкових файлів повинна бути налаштована таблиця стилів b2b-маршрутизації. У нашому прикладі ми ідентифікуємо зовнішнього партнера по IP-адресою джерела, а внутрішнього партнера - по каталогу призначення.

Пунктом призначення внутрішнього партнера є URL-адресу WebSphere MQ FTE. Зверніть увагу, що DataPower включає в пересилається повідомлення кінцевий пункт призначення в мережі WebSphere MQ FTE. Типовий пункт призначення WebSphere MQ FTE показаний в лістингу 4.

Лістинг 4. URL-адресу бекенд mqfte при використанні об'єкта DataPower MQ Q-Manager

Обов'язкові параметри URL-адреси:

• DestAgent: Агент призначення в мережі WebSphere MQ FTE, який отримує повідомлення.
• DestQM: Менеджер черги призначення, в яку агент джерела відправляє повідомлення.
• DestFile: Файл, в якому агент призначення зберігає отримане повідомлення.

Для цього сценарію застосування ми створили третього агента WebSphere MQ FTE з ім'ям AGT3_DP_TO_FTE, який також функціонує як Windows-сервісу і у якого в файлі agent.properties властивість enableQueueInputOutput має значення true з метою вирішення передач типу Queue-to-File. Продукт WebSphere MQ FTE повинен здійснювати моніторинг черги призначення WebSphere MQ, в яку DataPower записує отримані елементи, і ініціювати передачу WebSphere MQ FTE з метою обробки файлу. Для виконання цих завдань ми створили відповідний монітор WebSphere MQ FTE за допомогою команди fteCreateMonitor, показаної в лістингу 5.

Лістинг 5. Команда fteCreateMonitor для сценарію застосування 3

У цій команді параметр -ma вказує ім'я агента моніторингу (в даному випадку - AGT3_DP_FTE_QM). Агент, який ми створили для цього сценарію застосування, використовується в якості агента джерела для критичної передачі. Значення параметра -mq (в даному випадку, DP_TO_FTE) - це ім'я черги WebSphere MQ, що підлягає моніторингу, яка і є метою передачі від DataPower.

Параметр -mn задає ім'я створюваного монітора (в даному випадку, XB62_Monitor). Параметр - pu має значення seconds (секунди), тому значення параметра -pi (в даному випадку, 10) задає інтервал опитування, рівний 10 секундам. Параметр -tr має значення completeGroups, згідно з яким команда передачі WebSphere MQ FTE, що задається значенням параметра -mt, ініціюється тільки тоді, коли вся група повідомлення WebSphere MQ надійшла в подвергаемую моніторингу чергу. Ця команда передачі WebSphereMQ FTE, що запускається з надходження всієї групи повідомлення, описується в файлі визначення завдання монітора, зазначеному в параметрі -mt. Це XML-файл, який в нашому сценарії має такий вигляд (див. Лістинг 6).

Лістинг 6. XML-визначення завдання для монітора FTE

Цей файл був створений за допомогою опції -gt команди fteCreateTransfer. Використання опції -gt для створення даного файлу - це найпростіший спосіб гарантувати коректність його формату. Згодом згенерований файл визначення завдання може бути модифікований так, як слід, зокрема, з метою заміни змінних.

У показаному вище файлі визначення завдання змінна sourceAgent задає агента джерела WebSphere MQ FTE. Він асоціюється з Queue Manager в інтересах передачі, яка повинна ініціюватися при надходженні групи повідомлень з DataPower. В даному випадку, це агент AGT3_DP_TO_FTE і менеджер FTE_QM, відповідно. Мінлива destinationAgent задає ім'я цільового агента, який є менеджером черзі для передачі. У показаному вище прикладі менеджеру черги присвоєно значення "$ {DPMQFTEDestinationQM}, а агенту присвоєно значення" $ {DPMQFTEDestinationAgent} ". В процесі виконання цих значень замінюються значеннями змінних DPMQFTEDestinationQM і DPMQFTEDestinationAgent, які задаються пристроєм DataPower.

І, нарешті, ім'я файлу призначення задається в XML-тезі "file". В даному випадку шлях жорстко закодований у вигляді "d: \ temp \ FromXB62 \", проте саме ім'я файлу задає змінна DPMQFTEDestinationFile.

Необхідно відзначити, що за замовчуванням DataPower пересилає повідомлення з використанням значення персистентності, установленого для черги. Тому дане значення необхідно ставити з достатньою обачністю.

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

Сценарій застосування 4. Вхідна передача файлу з використанням MPGW (потокова передача)

У цьому сценарії WebSphere MQ FTE має точно таку ж конфігурацію, як в попередньому сценарії.

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

Ця конфігурація підтримує потокову передачу для вхідних файлів і добре підходить для передачі дуже великих файлів.

Висновок

У статті були описані конкретні критерії вибору між сервісами B2BGW і MPGW при інтеграції продуктів DataPower і WebSphere MQ FTE. Крім того, були розглянуті короткі приклади працездатних конфігурацій.

Подякою

Автори висловлюють подяку за сприяння в написання даної статті і за її рецензування Річарду Кайнарду (Richard Kinard) і Едріану Престону (Adrian Preston).

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів