Вопрос

Я не уверен, что задаю правильный вопрос, но я пытаюсь запустить следующий сценарий:

Несколько файлов (XML и несколько связанных файлов, «вложений») должны попасть в BizTalk как одно сообщение.Я изучил существующие адаптеры и не увидел, чтобы это было сделано с существующими однажды.Точнее, файлы берутся из файловой системы.Файлы не находятся одновременно, а поступают по одному, когда порядок не обеспечен.XML-файл (контент) — это файл, который знает, какие вложения он должен иметь (какие еще файлы).

Мы изучаем BizTalk 2009, и мне интересно, будет ли за это отвечать специальный адаптер или что-то еще.И где бы я мог поискать образцы.

Спасибо.

Это было полезно?

Решение

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

То, что вы ищете, похоже на конвой или, по крайней мере, на какое-то использование корреляции.

В BizTalk конвой — это шаблон обмена сообщениями (в отличие от функции BizTalk), который позволяет обрабатывать группы сообщений с помощью единой оркестровки.

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

Статья есть [здесь](http://msdn.microsoft.com/en-us/library/ms942189(BTS.10).aspx) Стивен В.Томас о конвоях (это для BT 2004, но концепции все еще актуальны) и в Интернете и в книгах есть много дополнительной информации (на Professional BizTalk server 2006 есть подраздел по ним)

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

Гибкая корреляция

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

Неравномерный последовательный конвой

Если у вас есть немного информации заранее, один из способов может быть следующим (по сути, неравномерный последовательный конвой):

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

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

Эта оркестрация будет иметь единую форму получения активации, настроенную для вашего файла содержимого.

Как только оркестровка запускается с помощью файла контента, вторая коррелированная форма приема начинает собирать сообщения, соответствующие этому файлу контента.(этот второй прием может быть в цикле, чтобы обеспечить переменное количество файлов)

Затем вы упаковываете их все вместе в один исходящий файл вашего дизайна и отправляете его после получения полного количества файлов.

Другие советы

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

Что вы можете сделать, так это разработать собственный адаптер BizTalk для взаимодействия с файловой системой и реализации логики прослушивания и цикла.Затем вы можете разработать собственный компонент конвейера для создания одного сообщения BizTalk, возможно, с типом данных base64 для двоичных данных.Кроме того, вы также можете продвигать сообщения прямо в этом компоненте, чтобы включить подписки на оркестрацию.

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

Ответ Дэвида – правильный ответ.

Даже в тех случаях, когда вы совершенно ничего не знаете о содержимом ожидаемых вложений, вы наверняка знаете их названия и расположение.Поэтому вы можете использовать Гибкая корреляция ссылка на ответ Дэвида такая:

Ключом к решению является сопоставление встроенного свойства BTS.ReceivedFileName.

Сначала создайте пользовательский конвейер приема с настраиваемым компонентом конвейера, который продвигает свойство контекста BTS.ReceivedFileName полученных сообщений.Этот простой пользовательский компонент довольно легко написать, но вы можете упростить его, используя сторонние платформы, такие как (бессовестная пробка, здесь) мой ТрубопроводКомпонентБаза класс или отлично Мастер компонентов конвейера BizTalk Server.

Теперь о самом простом:

  • Вложения принимаются в определенное место, обозначенное путем в файловой системе.
  • Создайте место приема, которое прослушивает альтернативное место, используется только для контроля того, когда файлы фактически поглощаются BizTalk.
  • В оркестрации создайте тип корреляции со свойством BTS.ReceivedFileName и набор корреляций, основанный на этом типе корреляции.
  • Если вы хотите получать двоичные вложения, отправьте фиктивное сообщение со свойством контекста BTS.ReceivedFileName, равным имени файла двоичного вложения, но с путем, соответствующим альтернативное местоположение ;тот, который используется местом приема.Инициализируйте корреляцию в форме отправки.
  • Используйте форму выражения, чтобы скопировать двоичный файл из исходного местоположения в тот, который используется местом приема.
  • Наконец, используйте форму получения, привязанную к порту приема, содержащую расположение приема, чей пользовательский конвейер приема будет продвигать свойство BTS.ReceivedFileName.

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

Эти два решения позволяют избежать накопления большого количества файлов где-то во временном месте только ради инициализации корреляции!

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top