What are the different types of transactions available for orchestration?

A scope with no transaction is usually used as a try/catch block just to handle exceptions.

BizTalk Server supports two distinct types of transactions: atomic and long-running.

     Transactions are implemented in Orchestrations using Atomic Scope. An Atomic Scope supports ACID properties of Transactions where as Long Running Scope Supports C&D (Consistency and Durability) properties of ACID.



Atomic: An atomic scope cant be placed within a Normal Scope.
There are two other Advantages of Atomic scope in addition to supporting Transactions.

1. Non-Serializable classes can be called from an Atomic Scope.

2. The number of Persistence points within an Orchestration can be reduced as an atomic scope will always induce one Persistence point (at the end of the scope).

Long running:  A business process that might take seconds, minutes, or even days or weeks to complete. This is when a long-running transaction is more suitable.

Enlist Vs UnEnlist (State information about BizTalk Server artifacts)

BizTalk Server has many artifacts such as send ports, send port groups, receive locations, parties, and orchestrations. Of the artifacts, send ports, send port groups, and orchestrations  have a state, which determines whether the artifact can process messages.

We have four variants with messages received by adapter :

1).  After Subscriber is Enlisted and Started, the messages come to the Message box and then routed to the Subscriber.
2). After Subscriber is Enlisted but not Started yet, the messages are waiting inside Message box in the Suspended (Resumable) state. When Subscriber is started, those messages go out from Message box to this Subscriber.
3). If the Subscriber is not Enlisted, and the message type in well-known by BizTalk, we'll get error
Description:
The Messaging engine failed to process a message submitted by adapter:{adapter details}. Details:Could not find a matching subscription for the message. This error occurs if the subscribed orchestration schedule or send port has not been started, or if some of the message properties necessary for subscription evaluation have not been promoted. Please refer to Health and Activity Tracking tool for more detailed information on this failure
It means the message was recognized by BizTalk, because BizTalk knows of its type. But there is no one subscription to this message.

UnEnlist:- Remove subscription information from Message Box.
Stop:-Will not Remove Subscription information form message box but the port or orchestration will not process(send) messages.
Enlist:-Write Subscription information into message Box(Bound).
Start:-Process(send) messages.

Don't confuse with Stop and Enlist
the "Stop" changes the state from "Started" to "Stopped/Enlisted". 
the Enlist will move from Unenlisted to "Stopped/Enlisted" state.

Ex:
you have a mailbox at the local post office.  When you go out of town on vacation, you drop from the "Started" to the "Enlisted" state.  They hold your mail for you, and when you return, they give you the box full of mail.  When you move out of town (or are tired of all the junk mail), you "Stop" your mail and they post master marks it as undeliverable.

InternalServiceFault - The value of a promoted property cannot exceed 256 characters. Property "Action" Namespace "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties".

I tried to invoke a WCF service from within an orchestration and got the below fault message in response


<Fault xmlns="http://www.w3.org/2003/05/soap-envelope"><Code><Value>Receiver</Value><Subcode><Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</Value></Subcode></Code><Reason><Text xml:lang="en-US">The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the &lt;serviceDebug&gt; configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.</Text></Reason></Fault>

after IncludeExceptionDetailInFaults = ture got below exception.

<Fault xmlns="http://www.w3.org/2003/05/soap-envelope"><Code><Value>Receiver</Value><Subcode><Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</Value></Subcode></Code><Reason><Text xml:lang="en-US">The value of a promoted property cannot exceed 256 characters. Property "Action" Namespace "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties".
Parameter name: obj</Text></Reason><Detail><ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><HelpLink i:nil="true" /><InnerException i:nil="true" /><Message>The value of a promoted property cannot exceed 256 characters. Property "Action" Namespace "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties".
Parameter name: obj</Message><StackTrace>   at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance.EndOperation(IAsyncResult result)
   at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance.Microsoft.BizTalk.Adapter.Wcf.Runtime.ITwoWayAsync.EndTwoWayMethod(IAsyncResult result)
   at AsyncInvokeEndEndTwoWayMethod(Object , Object[] , IAsyncResult )
   at System.ServiceModel.Dispatcher.AsyncMethodInvoker.InvokeEnd(Object instance, Object[]&amp; outputs, IAsyncResult result)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeEnd(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage7(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage6(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</StackTrace><Type>System.ArgumentOutOfRangeException</Type></ExceptionDetail></Detail></Fault>

The problem was solved.

In my case WCF service (logical)port operation name from orchestration was not equal with operation name in physical port binding properties.

or 

Go to send port -> Configure and SOAP Action Header section.

Remove below lines

<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Operation Name="OperationXXXName1" Action="OperationXXXName1" />
  <Operation Name="OperationXXXName2" Action="OperationXXXName2" />
</BtsActionMapping>

And keep only one action in the SOAP Action Header section. (i.e OperationXXXName1).

WCF-BasicHttp - ActionNotSupported

Last 4 hours I was hanging with the below error while testing my BizTalk Orchestration to send an request message to External wcf Service.

<s:Fault xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><faultcode xmlns:a="http://schemas.microsoft.com/ws/2005/05/addressing/none">a:ActionNotSupported</faultcode><faultstring xml:lang="en-US">The message with Action '{service url}' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).</faultstring></s:Fault>

Fix is very simple, we have to update the Action value in configure->general-> Action section

In order to integrate external WCFServices in BizTalk, both Schemas have to match.

If the External WCFService schema does not match the BizTalk schema, BizTalk will not be able to send the request. 

WCF adapter tries to match the operation name with an action defined in the BtsActionMapping, and if it can't find the Operation context property in the BTS message, it'll throw exception.

Another thing you can look at is the ENDPOINT properties... and make sure all parameters are properly set.

A good test is to use a Soap Tool to test your External WebService. You can try SoapUI tool

add your service to the SOAPUI and verify the operation action actions in the below shown screen.

if the BtsActionMapping is different, please update latest in the properties and verify. it'll fix the issue.

 

Understanding Design-Time Properties for Custom Pipeline Components in BizTalk Server

http://www.microsoft.com/en-us/download/details.aspx?id=2758

Default Pipelines

When you create a new application, the default pipelines are created and deployed by default and appear in the Microsoft.BizTalk.DefaultPipelines assembly in the \References folder for every BizTalk project. The default pipelines cannot be modified in Pipeline Designer. These pipelines can be selected when configuring a send port or receive location in BizTalk Explorer.

Note:  The XML receive and XML send pipelines do not support XML documents larger than 4 gigabytes.

BizTalk provides 2 Receive pipelines (PassThruReceive, XmlReceive) and 2 Send Pipelines (PassThruSend, XmlSend), we can go and build more custom pipelines if required.

The default PassThruReceive and PassThruSend pipelines doesn't do any processing at all with the message and it will n't have any components. Whereas the XmlReceive pipeline will have a XmlDisassembler pipeline component on the disassembling stage and the XmlSend pipeline will have a XmlAssembler on the Assemble stage as shown in the above figure.

Why do we need a XmlReceive pipeline:
Whenever an Xml message is received via the XmlReceive pipeline the XmlDisassembler will do the following tasks:
1.Promote the "MessageType" context property by taking the combination of TargetNamespace and Rootelement in the format, Targetnamespace#RootElement.
2. Remove Envelopes and disassemble the interchanges
3. Promote the content properties from interchange and individual document into message context based on the configured distinguished fields and promoted properties.

There are 3 important things you need to keep in mind.
1. Maps on the receive side will be applied after the receive pipeline. In order to pick the correct schemas for processing, Maps need the "MessageType" property, which is promoted by the XmlDisassembler. So, if you are using PassThruReceive "MessageType" property won't be present, which in turn will result in Map not being applied.

2. Binding of logical port in the orchestration to a message (inside the orchestration designer), and deploying the orchestration will create the subscription for the particular message type. So, if you are using PassThruReceive "MessageType" property won't be present, which in turn will result in not starting the particular Orchestration instance.

3. If you have configured content based routing based on the properties in the message (Filters in SendPorts, Example: BTS.MessageType = http://tempuri#Person), routing won't happen until the correct properties are present in the message context.


Why do we need a XmlSend pipeline?
XmlSend pipeline does the reverse of what a XmlReceive pipeline did. It got a XmlAssembler component in the Assemble stage  which does the following tasks:
1. XML Assembler Builds envelopes as needed and appends XML messages within the envelope.
2. Populates content properties on the message instance and envelopes.

ref: http://www.digitaldeposit.net/saravana/post/2007/01/31/Difference-between-(PassThruReceive-PassThruSend)-and-(XmlReceive-XmlSend)-Biztalk-Pipelines-(For-Beginners).aspx

String Variables in Orchestration: Use Quotation Marks when Assigning Initial Value

When working with Orchestrations in BizTalk, if you create a variable that’s a string type and assign its initial value, you’ll want to make sure that you put quotation marks around the value.  I failed to do so recently I had errors similar to these pop up when attempting to build the project:

identifier 'YOUR_VARIABLE_VALUE' does not exist in 'YOUR_ORCHESTRATION';  are you missing an assembly reference?