Использование альтернативного конвейера со службой BizTalk WCF

Я пытаюсь создать оркестровку BizTalk, которая имеет дело с форматом XML, а затем представить эту оркестровку как службу WCF, которая получает и возвращает строку, используя определенные конвейеры отправки и получения для преобразования строки в формат XML, используемый оркестровка.

Я сделал вот что:

  1. Создайте оркестровку на основе формата XML (в моем случае - XML-схемы EDI для здравоохранения)
  2. Создайте двусторонний порт в оркестровке, который еще не привязан к физическому порту
  3. Разверните оркестровку
  4. Запустите мастер службы BizTalk WCF, чтобы предоставить оркестровку как службу.

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

Для этого я сделал следующие шаги:

  1. Создайте фиктивную оркестровку с двусторонним портом, который принимает строку
  2. Снова запустите мастер службы, чтобы опубликовать эту оркестровку как службу.
  3. Скопируйте строковую схему из опубликованной строковой службы в папку App Data опубликованной реальной службы.
  4. Измените XML-файл службы в реальной службе, чтобы использовать новую схему строк вместо сложной схемы EDI.
  5. Откройте место приема для двустороннего порта WCF и измените конвейер приема на «EDI Receive», а конвейер отправки на «EDI Send».

Хотя это позволяет службе работать и публиковать WSDL, это не кажется правильным. Когда я добавляю ссылку на эту службу, она просто принимает необработанный объект сообщения WCF (он не вводится как что-то конкретное). Когда я пытаюсь создать сообщение вручную и отправить его, я получаю ответ об ошибке, в котором говорится, что операция не реализована (как вы могли видеть из NotImplementedException).

Я делаю это неправильно? Это не кажется таким сложным, но я в тупике.


biztalk edi biztalk-2013
person Adam Robinson    schedule 01.08.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Итак, я действительно думаю, что вы усложняете вещи намного сложнее, чем они должны быть.

Вот где, я думаю, твой план нарушается. Когда вы публикуете службу с помощью схемы Xml, вы создаете метаданные для службы на основе документов, в основном просто XML-документ, завернутый в конверт SOAP.

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

Итак, мой первый вопрос: должна ли это быть служба SOAP? На практике 9 из 10 раз требовалось всего лишь простое сообщение HTTP.

person Johns-305    schedule 01.08.2014
comment
Это не требование, чтобы это была служба SOAP, но все наши существующие службы соответствуют требованиям, и мы хотели бы сделать службу доступной для обнаружения в нашей организации, если кому-то еще понадобится ее вызвать. Но если это исправит использование другой привязки, я все уши. - person Adam Robinson; 01.08.2014
comment
SOAP - это здорово, но я всегда открываю с помощью HTTP POST, поскольку для обмена документами, Xml или EDI SOAP действительно не предлагает многого, IMO. Чтобы отправить или получить простой HTTP POST, используйте customBinding с httpTransport или httpsTransport, кодировщиком (обычно работает textMessageEncoding) и любым подходящим поведением безопасности. Вот и все. POST-поток - это то, что попадает в конвейер, готовый для дизассемблера EDI. - person Johns-305; 01.08.2014
comment
Меня беспокоит обработка исключений, и если мы определим, что нам нужно передать дополнительные данные в какой-то момент, но сегодня я попытаюсь подключить более простую привязку. - person Adam Robinson; 04.08.2014