与BizTalk WCF服务一起使用备用管道

我正在尝试创建一个处理XML格式的BizTalk业务流程，然后将此业务流程公开为接收和返回字符串的WCF服务，使用特定的发送和接收管道将字符串转换为业务流程使用的XML格式或从中转换过来

我所做的是：

基于XML格式创建编排（在我的例子中是医疗EDI XML模式）

在业务流程中创建尚未绑定到物理端口的双向端口

部署编排

运行BizTalk WCF服务向导以将业务流程作为服务公开

此时，服务将按BizTalk EDI XML模式发布。因为这很复杂，我不想在BizTalk内置管道时将EDI字符串转换为此架构

为了实现这一点，我随后执行了以下步骤：

使用接受字符串的双向端口创建虚拟业务流程

再次运行服务向导以将此业务流程发布为服务

将字符串架构从已发布的字符串服务复制到已发布的real服务的App Data文件夹

修改真实服务中的服务XML文件，以使用新的字符串模式而不是复杂的EDI模式

打开双向WCF端口的接收位置，将接收管道更改为“EDI接收”，将发送管道更改为“EDI发送”

虽然这确实让服务工作并发布WSDL，但它似乎并不正确。当我向这个服务添加一个服务引用时，服务引用只接受一个原始的WCF消息对象（它不是特定类型的）。当我试图手动构造一条消息并提交它时，我得到一个错误响应，告诉我操作没有实现（就像你从

NotImplementedException

中看到的那样）

---

我做错了吗？这看起来不应该那么复杂，但我被难住了。

所以，我确实认为你让事情变得比需要的复杂得多

这就是我认为你的计划失败的地方。当您使用Xml模式发布服务时，您正在为基于文档的服务创建元数据，基本上只是封装在SOAP信封中的Xml文档

但是，您不能使用字符串来实现这一点，因为EDI是。在这种情况下，字符串必须作为字符串参数传递

---

所以，我的第一个问题是它必须是SOAP服务吗？实际上，一个简单的HTTP post只需要9/10次。

它不是一个SOAP服务的要求，但我们所有现有的服务都是，如果有人需要调用它，我们希望在我们的组织内发现该服务。但是，如果使用不同的绑定可以解决这个问题，我洗耳恭听。SOAP很棒，但我总是使用HTTP POST打开，因为对于共享文档、Xml或EDI，SOAP实际上提供的不多。要发送或接收简单的HTTP POST，请使用自定义绑定和wither httpTransport或httpsTransport，一种编码器（textMessageEncoding通常有效）以及哪种安全行为是合适的。就这样。POST'ed流是管道中的关键，为EDI反汇编程序做好了准备。我关心的是异常处理，如果我们确定在某个时候需要传递额外的数据，但今天我将尝试连接更简单的绑定。