BizTalk Orchestration со схемой конверта

У меня есть схема плоского файла, в которой я установил для параметра Разрешить разрыв сообщения в корне Infix значение true. А также я установил Record Max Occurrence 1. Чтобы отправить сообщение и отправить множественное сообщение на порт отправки. Я использовал конвейер приема (с дизассемблированием плоских файлов) и конвейер отправки (передача XML) в портах приема и отправки. До этого все работало нормально.

Схема плоского файла

Входной файл .txt на порте приема

1000 ABC IT 1001 DEF Maintenece 1002 GHI Заработная плата

Результатом были три файла .xml, например

  <?xml version="1.0" encoding="utf-8" ?> 
  <Record xmlns="http://FlatFilewithEnvelop.FlatFileSchema1">
  <Employee xmlns="">
  <ID>1000</ID> 
  <Name>ABC</Name> 
  <Dept>IT</Dept> 
  </Employee>
  </Record>


 <?xml version="1.0" encoding="utf-8" ?> 
 <Record xmlns="http://FlatFilewithEnvelop.FlatFileSchema1">
 <Employee xmlns="">
 <ID>1001</ID> 
 <Name>DEF</Name> 
 <Dept>Maintenece</Dept> 
 </Employee>
 </Record>

 <?xml version="1.0" encoding="utf-8" ?> 
 <Record xmlns="http://FlatFilewithEnvelop.FlatFileSchema1">
 <Employee xmlns="">
 <ID>1002</ID> 
 <Name>GHI</Name> 
 <Dept>Payroll</Dept> 
 </Employee>
 </Record>

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

Msg(FlatFilewithEnvelop.PropertySchema.ID) == 1000

Оркестрация

Если я отправляю то же сообщение в порт приема, я получаю четыре сообщения в порту отправки (как показано ниже). Я не знаю, в чем была ошибка. Кто-нибудь может сказать мне, в чем ошибка.

<?xml version="1.0" encoding="utf-8" ?> 
<Record xmlns="http://FlatFilewithEnvelop.FlatFileSchema1">
<Employee xmlns="">
<ID>1000</ID> 
<Name>ABC</Name> 
<Dept>IT</Dept> 
</Employee>
</Record>

<?xml version="1.0" encoding="utf-8" ?> 
<Record xmlns="http://FlatFilewithEnvelop.FlatFileSchema1">
<Employee xmlns="">
   <ID>1000</ID> 
   <Name>ABC</Name> 
   <Dept>IT</Dept> 
  </Employee>
 </Record>

<?xml version="1.0" encoding="utf-8" ?> 
<Record xmlns="http://FlatFilewithEnvelop.FlatFileSchema1">
<Employee xmlns="">
<ID>1001</ID> 
<Name>DEF</Name> 
<Dept>Maintenece</Dept> 
</Employee>
</Record>

<?xml version="1.0" encoding="utf-8" ?> 
<Record xmlns="http://FlatFilewithEnvelop.FlatFileSchema1">
<Employee xmlns="">
  <ID>1002</ID> 
  <Name>GHI</Name> 
  <Dept>Payroll</Dept> 
  </Employee>
  </Record>

person trx    schedule 26.08.2014    source источник


Ответы (2)


Вероятно, происходит то, что вы изначально создали порт отправки с фильтром, подписывающимся на сообщения.

Затем вы создали оркестровку, которая также подписывается на сообщения и привязана к порту отправки.

Если вы посмотрите в консоли администрирования BizTalk Server и выполните новый запрос и Search For Equals Subscriptions, вы увидите фильтр для вашего порта отправки, как показано ниже.

    Property    Operator    Value   Group by
    http://schemas.microsoft.com/BizTalk/2003/system-properties.SPTransportID   ==  {GUID}  Or
    http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType ==  MesageType  And

Обратите внимание на то, что подписка имеет ИЛИ, первая часть будет идентификатором GUID для порта, а вторая часть будет фильтром, который вы добавили к порту. Любое сообщение, опубликованное оркестровкой, привязанной к порту, устанавливает SPTransportID равным GUID порта.

Фильтр на порту отправки все еще ищет сообщения, а оркестровка также публикует сообщение на порт, отсюда и четыре сообщения.

Решение. Снимите фильтр с порта.

person Dijkgraaf    schedule 26.08.2014

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

person Hichamveo    schedule 26.08.2014
comment
Да, но у вас должна быть подписка также для тех, кто вам не нужен, иначе они не сработают, и подписчиков не будет найдено. - person Dijkgraaf; 27.08.2014