Using an alternate pipeline with a BizTalk WCF service

1
votes

I'm attempting to create a BizTalk orchestration that deals with an XML format, then expose this orchestration as a WCF service that receives and returns a string, using specific send and receive pipelines to convert the string to and from the XML format used by the orchestration.

What I've done is this:

  1. Create the orchestration based on the XML format (in my case a healthcare EDI XML schema)
  2. Create a two-way port in the orchestration that is not yet bound to a physical port
  3. Deploy the orchestration
  4. Run the BizTalk WCF Service wizard to expose the orchestration as a service

At this point, the service is published expecting the BizTalk EDI XML schema. Since this is complex and I don't want to do the work of converting an EDI string to this schema when BizTalk has a pipeline built-in to do this.

In order to accomplish this, I then did the following steps:

  1. Create a dummy orchestration with a two-way port that accepts a string
  2. Run the service wizard again to publish this orchestration as a service
  3. Copy the string schema from the published string service to the App Data folder of the published real service
  4. Modify the service XML file in the real service to use the new string schema instead of the complex EDI schema
  5. Open the receive location for the two-way WCF port and change the receive pipeline to "EDI Receive" and the send pipeline to "EDI Send"

While this does let the service work and publish the WSDL, it doesn't seem to be correct. When I add a service reference to this service, the service reference just accepts a raw WCF Message object (it isn't typed as anything specific). When I try to construct a message manually and submit it, I get a fault response telling me that the operation is not implemented (like you'd see from a NotImplementedException).

Am I doing this wrong? This doesn't seem like it should be that complex, but I'm stumped.

1
biztalkedibiztalk-2013

1 Answers

1
votes

So, I do think you're making things a lot more complicated then they need to be.

Here's where I think your plan is breaking. When you Publish the Service with the Xml Schema, you're creating the metadata for a document based service, basically just an Xml document wrapped in a SOAP envelope.

However, you can't do that with a string, which the EDI is. In that case, the string has to be passed as a string parameter.

So, my first question would be does it have to be a SOAP Service? In practice, a simple HTTP post is all that needed 9/10 times.