Задача такая : сканируем ftp location; для каждого обнаруженного там файла - обновляем базу, соответственно его содержанию. Например, файлы, кот. будут находиться на ftp, имеют такую структуру:

всего с одним attributed element для простоты. В базе обновляем таблицу, в кот., скажем, одно из полей равняется атрибуту batchNum.

Можно, конечно, писать orchestration - receive shape для получения из ftp, transform shape (obviously embraced by construction block) with mapping и send shape, связанный с SQLAdapter-generated-schema, в кот. есть вызов stored procedure или updategram на обновление. Работает.

Но можно и не писать orchestration вовсе : создаем receive port (with ftp receive location), в его inbound maps добавляем наш map из transform shape, т.е. любой поступающий туда документ из ftp будет сразу преобразовываться в SQL updategram - 2 shape из orchestration уже не понадобятся. Можно, кстати, добавить несколько inbound maps - каждый для документов со своей schema. Можно добавить и несколько receive locations - send port ведь привязывается к receive port, не к receive location. Осталось добавить send port для SQL. Добавили. Теперь свяжем его напрямую с уже созданным receive port. Через filter : Edit->Filters & Maps->Filters. Фильтр будет такой : Property->BTS.ReceivePortName, Operation->'==', Value->[Имя созданного receive port].Вот и все. Orchestration не понадобился, а вместе с ним и its performance penalty.

Как же это работает? Чтобы понять, стоит просто взглянуть на BTSSubscriptionViewer - сконфигурированный так send port просто создает свой subscription