Archive

Posts Tagged ‘Orchestration Subscriptions for SOAP’

Logical ReceivePort Operation Name as an extra XML element:Publishing Orchestration as a Service

April 24, 2012 Leave a comment

Issue :

While Publishing an Orchestration as a service using WebServices wizard, the xml input expected by the generated service operation is wrapped within an extra xml element, which is the name of the logical receive port of the published orchestration

  <soap12:Body>
    <Operation_1 xmlns=”hhtp://MyTestNameSpace”>

Cause :

The Orchestration that is published as a service creates 2 types of subscriptions behind the scenes(logically a single subscription as they are seperated by an OR).

1.For the requests coming from the generated SOAP receive port,  the subsciption is as follows.

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {47E7FAA7-D285-4C69-A591-510F8074AEEC} And

http://schemas.microsoft.com/BizTalk/2003/soap-properties.MethodName == Operation_1

2.The second subscription is based on regular messagetypes which are not from the SOAP transport types.

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID== {47E7FAA7-D285-4C69-A591-510F8074AEEC} And

http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType== http://OrchFiltertest.In#Root And

http://schemas.microsoft.com/BizTalk/2003/system-properties.InboundTransportType != SOAP

 So when a message arrives  through the SOAP recieve  port, an extra xml  element that matches the name of the logical recieve port is added in order to match the subscription.This extra element header will be automatically ripped off by the engine when it hands over the message to the orchestration

Resolution:

No manual action is required in this scenario and it is a built in behavior. The message will reach the orchestration as it has to.