Pages

Showing posts with label MessageBox. Show all posts
Showing posts with label MessageBox. Show all posts

BizTalk : How To : Cluster BizTalk Server Databases

Wednesday, March 20, 2013

If the BizTalk Server databases become unavailable, the BizTalk Server environment will not function correctly. To provide high availability, you can create a Microsoft SQL Server cluster for the BizTalk Server databases, as shown in the following figure.

BizTalk Server Database Tier

To create a highly available solution for the BizTalk Server databases, you must have at least two computers that are running SQL Server and a shared disk array in the cluster.
Determine the best cluster configuration for the BizTalk Server databases for your business needs. Here is a list of the options:
  • Active/passive. High availability for the BizTalk Server databases typically consists of two or more database computers configured in an active/passive server cluster configuration. These computers share a common disk resource (such as a RAID 1+0 SCSI disk array or storage area network) and use Windows Clustering to provide backup redundancy and fault tolerance.
  • Active/active. Windows Clustering and SQL Server allow you to run SQL Server in Active/Active mode where each node of the cluster is “active” and running one or more SQL Server instances. For example, this would allow you to have the MessageBox database on one node and all other BizTalk Server databases on the other node. This allows you to maximize cluster hardware usage, but an active/active SQL Server configuration should be used with care.

    Can each node simultaneously handle the load of all SQL Server instances during a SQL Server cluster node failover scenario? Are there enough CPU resources? Is there sufficient memory? What about network bandwidth? How about disk I/O contention?

    These are just some of the questions that need to be answered in order to determine if an active/active SQL Server cluster is right for your BizTalk applications. If it is determined that one node cannot handle all SQL Server instances in a failover scenario, an alternative is to use active/active/passive clustering.
  • Active/active/passive. The run-time processes write to the BizTalk Management database, MessageBox databases, Tracking Analysis Services database, BAM Analysis database, BAM Star Schema database, BAM Primary Import database, and BAM Archive database. Therefore, these databases are especially important if a disaster occurs, and must have greater priority when determining what databases to cluster. Only users or tools write to the other databases. For the MessageBox databases, you can consider an active/active/passive or active/active/active/passive configuration to minimize the hardware needed.
Gg634455.note(en-us,BTS.70).gifNote
SQL Server 2008 R2 and SQL Server 2008 SP1 Standard Edition supports 2-node failover clusters. If you decide to use the active/active/passive configuration on SQL Server 2008 R2 or SQL Server 2008 SP1, you must use the Enterprise Edition of SQL Server.
Make sure you meet the following prerequisites before you start clustering the BizTalk Server databases.
  • When you create the domain groups for your BizTalk Server environment, you must create global domain accounts.
  • Configure the SQL Server cluster before you install and configure BizTalk Server. For more information about clustering SQL Server 2008 R2, see Getting Started with SQL Server 2008 R2 Failover Clustering (http://go.microsoft.com/fwlink/?LinkId=156820).
  • If you are also clustering the master secret server, configure that server first. For more information about high availability for Enterprise Single Sign-On, see High Availability for the Master Secret Server.
  1. Install BizTalk Server 2010 on a runtime server.
  2. Launch the BizTalk Server Configuration program. Click Start, point to Programs, point to Microsoft BizTalk Server 2010, and then click BizTalk Server Configuration.
  3. To apply a custom configuration, follow the steps in Working with the Custom Configuration Manager (http://go.microsoft.com/fwlink/?LinkId=156822) in BizTalk Server Help. To specify the SQL Server cluster for the BizTalk Server databases enter the name of the SQL Server cluster in the Databases dialog of the configuration.
  4. Complete the BizTalk Server configuration by following the instructions in Custom Configuration (http://go.microsoft.com/fwlink/?LinkId=156823) in BizTalk Server Help.
For more information about clustering BizTalk Server databases, see Improving Fault Tolerance in BizTalk Server by Using a Windows Server 2008 Failover Cluster or Windows Server 2003 Server Cluster (http://go.microsoft.com/fwlink/?LinkId=156819). 
For more information about behavior of BizTalk host instances during SQL Server failover, see Behavior of BizTalk Server Host Instances during SQL Server Failover(http://go.microsoft.com/fwlink/?LinkId=151287).
For more information about using SQL Server database mirroring with respect to BizTalk Server database clustering, see Use of SQL Server database mirroring or the Volume Shadow Copy service (http://go.microsoft.com/fwlink/?LinkId=151288) in BizTalk Server help.
Read more ...

Advanced Users Biztalk WIKI : Useful How to Links Part - 3

Thursday, June 14, 2012
Useful How to Links Part - 3

BizTalk Administrator's Checklist Compiled by Microsoft BizTalk Support

Muenchian Grouping and Sorting in BizTalk Maps

Xslt Template StyleSheet For Biztalk Mapping : Query in Biztalk Map

AppFabric-enabled WCF Data Service Walkthrough (C#)

Querying DataSets – Introduction to LINQ to DataSet

Accessing BRE RuleEngine Using .Net Framework
Few links that may help:
http://msdn.microsoft.com/en-us/library/aa995566.aspx                                                                

(MSDN: Walkthrough: Executing the Policy Programmatically)

Read more ...

Advanced Users Biztalk WIKI : Useful How to Links Part - 4

Friday, June 8, 2012
Useful How to Links Part - 4

Iterate ArrayList in BRE Business Rules

Programming with Business Rules Framework

How to Script Import/Export and Deployment of Business Policies using FileRuleStore

SSO Configuration Store Application





Tool Source Code:

Here are a few TechNet Wiki articles that have become available recently. I have usually found it difficult to find relevant content on the TechNet Wiki so I thought it would be good to highlight a few of these.
Improving performance when executing a BRE rule:

Implement ordered messaging with BizTalk and SSIS:

BizTalk load testing in VS 2010:

Load testing for simultaneous BizTalk unit tests:

Read more ...

Advanced Users Biztalk WIKI : Useful How to Links Part -2

Wednesday, June 6, 2012
Useful How to Links Part -2


Implementing Biztalk Pipeline Trace

Biztalk Orchestration Tracing Using Biztalk Diagnostics Library

High Performance Message Transform Alternative to XslTransform vs Xsl 
CompileTransform

Dynamic Mocking With N-Mock

Biztalk 2010 Documentation

Validating Incoming Xml using BRE

BizTalk: Delivery Notification in Direct Send Ports

BizTalk XSLT Reuse (xsl:include) by using MS Build



BizTalk Server: Performance Tuning & Optimization
http://social.technet.microsoft.com/wiki/contents/articles/7253.biztalk-server-2010-database-biztalkdtadb.aspx
Read more ...

Saving suspended messages in BizTalk (filtering on orchestration or port name)

Tuesday, August 30, 2011

  Post By:  Thiago Almeida.
Last week, I needed to save 700+ suspended messages to file. I didn’t want to go in to each instance and click ‘save to file’ 700 times. A quick search in the web did not find what I want, however there were a number of articles about extracting messages from the BizTalk tracking database.
My scenario was for an existing BizTalk 2004 implementation in the company and is only a once-off thing I need to do. For the newer BizTalk 2006 applications, there is the ‘Failed Message Routing’ feature that can be enabled on send ports and receive ports. The failed messages could then be easily subscribed to a send port to output to file.
Then it occured to me that the WMI script Terminate.vbs has the option to save the messages before terminating the instances (http://go.microsoft.com/fwlink/?LinkID=107591 and slightly updated for 2009). Thus changing this script to do what I want required the least effort. I could just use the script as it is to save all the messages and terminate the instances. However it didn’t take much to modify it to take a parameter for filtering on an instance name and to only save messages (and not terminate them). Below is the usage description of the save_messages.vbs script and the actual script. It works for BizTalk 2004, 2006 and 2009.
There is also a replacement of the Terminate.vbs script: Biztalk Terminator.
Usage:
cscript save_messages.vbs < -Z | -A | -DIS | -SR | -SNR > [Port/Orchestration name]
-Z saves all “Zombie” instances (e.g. completed with discarded messages)
-A saves all suspended and zombie instances as well as all routing failure reports
-SR saves suspended resumable instances only
-SNR saves suspended non-resumable instances only
-DIS saves all dehydrated ‘isolated adapter’ instances
optionally supply the name of the orchestration or port name to filter on specific instances
Ensure that the C:\Temp folder exists before running as that is where it saves the instances
Example: cscript save_messages.vbs -z “E-Reporting Data Transform Port”
Visual Basic Script:
‘ save_messages.vbs
‘ Enter save_messages.vbs with no arguments from a command prompt for usage
‘ This script needs to be run under a user account that is a member of the BizTalk Administrators
‘ group. This script needs to be run on a machine that is configured with BizTalk administration
‘ tools.
dim objBtsWmiNS, objMsg, svcinsts, inst, msg, ndx, size
Dim aryHostNames()
Dim aryObjQueues()
Dim aryHostBatchSize()
Dim strKey2Instance
Dim strQuery2Msg
Dim strServiceName
On Error Resume Next
Dim objArgs: Set objArgs = WScript.Arguments
If ( objArgs.Count = 0 OR objArgs.Count > 2) Then
PrintUsage()
wscript.quit 0
End If
wmiQuery = “”
‘ServiceStatus = 16 – ‘Completed With Discarded Messages’ in BizTalk Server 2004
‘ServiceStatus = 32 – ‘Suspended (not resumable)’
‘ServiceStatus = 4 – ‘Suspended (resumable)’
‘ServiceClass = 64 – ‘Routing Failure Report’
‘ErrorId = “0xC0C01B4C” – is how ‘Completed With Discarded Messages’ are exposed in BizTalk Server 2006
If (objArgs(0) = “-Z” OR objArgs(0) = “-z”) Then
wmiQuery = “select * from MSBTS_serviceinstance where ServiceStatus=16 OR ErrorId=’0xC0C01B4C’”
End If
If (objArgs(0) = “-A” or objArgs(0) = “-a”) Then
wmiQuery = “select * from MSBTS_serviceinstance where ServiceStatus=4 OR ServiceStatus=32 OR ServiceStatus=16 OR ErrorId=’0xC0C01B4C’ OR ServiceClass=64″
End If
If (objArgs(0) = “-SR” or objArgs(0) = “-sr”) Then
wmiQuery = “select * from MSBTS_serviceinstance where ServiceStatus=4″
End If
If (objArgs(0) = “-SNR” or objArgs(0) = “-snr”) Then
wmiQuery = “select * from MSBTS_serviceinstance where ServiceStatus=32″
End If
If (objArgs(0) = “-DIS” or objArgs(0) = “-dis”) Then
wmiQuery = “select * from MSBTS_serviceinstance where ServiceClass=32 AND ServiceStatus=8″
‘ServiceClass = 32 ‘Isolated Adapter
‘ServiceStatus = 8 ‘Dehydrated
End If
saveMessagesBeforeTermination = True
If ( objArgs.Count > 1) Then
strServiceName = objArgs(1)
End If
If(wmiQuery = “”) Then
PrintUsage()
wscript.quit 0
End If
wscript.echo “–>Connecting to BizTalk WMI namespace”
Set objBtsWmiNS = GetObject(“WinMgmts:{impersonationLevel=impersonate, (security)}\\.\root\MicrosoftBizTalkServer”)
If Err <> 0 Then
CheckWMIError
wscript.quit 0
End If
wscript.echo “–>Getting BizTalk host collection”
Set hosts = objBtsWmiNS.ExecQuery(“select * from MSBTS_HostSetting”)
If Err <> 0 Then
CheckWMIError
wscript.quit 0
End If
hostCount = hosts.count
ReDim aryHostNames(hostCount – 1)
ReDim aryObjQueues(hostCount – 1)
ReDim aryHostBatchSize(hostCount – 1)
wscript.echo “–>Retrieve BizTalk host names and loading host queues”
ndx = 0
For Each host in hosts
wscript.echo “Found host ” & host.Properties_(“Name”)
aryHostNames(ndx) = host.Properties_(“Name”)
Set aryObjQueues(ndx) = objBtsWmiNS.Get(“MSBTS_HostQueue.HostName=”"” & aryHostNames(ndx) & “”"”)
If Err <> 0 Then
CheckWMIError
wscript.quit 0
End If
ndx = ndx + 1
Next
wscript.echo “–>Getting collection of service instances”
Set svcinsts = objBtsWmiNS.ExecQuery(wmiQuery)
‘Iterate through instances and save them in host-specific arrays.
wscript.echo “–>Start iterating service instances”
totalCount = 0
For Each inst in svcinsts
If (objArgs.Count = 1 Or (objArgs.Count > 1 And strServiceName = inst.Properties_(“ServiceName”) ) ) Then
wscript.echo “Found suspended instance “”" & inst.Properties_(“ServiceName”) & “”" on host ” & inst.Properties_(“HostName”)
‘Resolve host index
For hostIdx = 0 To hostCount-1
If aryHostNames(hostIdx) = inst.Properties_(“HostName”) Then
Exit For
End If
Next
’16 is an internal service class that cannot be terminated
If 16 = inst.Properties_(“ServiceClass”) Then
wscript.echo “Skipping BizTalk internal service instances (they cannot be terminated anyway)”
Else
’64 is a routing failure report and doesn’t have messages that can be saved
If 64 = inst.Properties_(“ServiceClass”) Or 16 = inst.Properties_(“ServiceClass”) Then
saveMessagesBeforeTermination = False
End If
errorCountSavingMessages = 0
If saveMessagesBeforeTermination Then
strQuery2Msg = “select * from MSBTS_MessageInstance where ServiceInstanceID=”"” & inst.Properties_(“InstanceId”) & “”"”
Set msgInsts = objBtsWmiNS.ExecQuery(strQuery2Msg)
For Each msg in msgInsts
msg.SaveToFile “C:\Temp”
If Err <> 0 Then
CheckWMIError
wscript.echo “Failed to save MSBTS_MessageInstance”
wscript.echo Err.Description & Err.Number
errorCountSavingMessages = errorCountSavingMessages + 1
Else
wscript.echo “Saved message ” & msg.Properties_(“MessageInstanceID”)
End If
Next
End If
totalCount = totalCount + 1
End If
End If
Next
‘ Delete whatever is left
For hostIdx = 0 To hostCount-1
If aryHostBatchSize(hostIdx) > 0 Then
TerminateAccumulatedInstacesForHost hostIdx
End If
Next
wscript.echo “SUCCESS> ” & totalCount & ” instances were found and attempted to be saved”
‘This subroutine deals with all errors using the WbemScripting object.
‘Error descriptions are returned to the user by printing to the console.
Sub CheckWMIError()
If Err <> 0 Then
On Error Resume Next
Dim strErrDesc: strErrDesc = Err.Description
Dim ErrNum: ErrNum = Err.Number
Dim WMIError : Set WMIError = CreateObject(“WbemScripting.SwbemLastError”)
If (TypeName(WMIError) = “Empty” ) Then
wscript.echo strErrDesc & ” (HRESULT: ” & Hex(ErrNum) & “).”
Else
wscript.echo WMIError.Description & “(HRESULT: ” & Hex(ErrNum) & “).”
Set WMIError = nothing
End If
‘wscript.quit 0
End If
End Sub
Sub PrintUsage()
wscript.echo “Usage:”
wscript.echo “cscript save_messages.vbs < -Z | -A | -DIS | -SR | -SNR > [Port/Orchestration name]“
wscript.echo
wscript.echo “  -Z saves all “”Zombie”" instances (e.g. completed with discarded messages)”
wscript.echo “  -A saves all suspended and zombie instances as well as all routing failure reports”
wscript.echo “  -SR saves suspended resumable instances only”
wscript.echo “  -SNR saves suspended non-resumable instances only”
wscript.echo “  -DIS saves all dehydrated ‘isolated adapter’ instances”
wscript.echo “  optionally supply the name of the orchestration or port name to filter on specific instances”
wscript.echo
wscript.echo “  Ensure that the C:\Temp folder exists before running as that is where it saves the instances”
wscript.echo
wscript.echo “  Example: cscript save_messages.vbs -z “”E-Reporting Data Transform Port”"”
wscript.echo
End Sub
Read more ...

Synchronous To Asynchronous Communication Without An Orchestration in BizTalk

Monday, August 29, 2011

Source : MSDN Blog  Paulo Salvatori

Scenario

Some months ago I had the chance to work with a customer who asked me a very interesting and tricky question: does BizTalk Server 2006 R2 support synchronous-to-asynchronous messaging only flows, without the need of an orchestration to couple a Two Way Request Response Receive Location with a One-Way Send Port to send out the request and a One-Way Receive Location to get response back from the invoked system?
The use case the customer wanted to reproduce was the following:
  1. A Two-Way SOAP Receive Location receives a request message and publishes it to the BizTalkMsgBoxDb.
  2. The message is consumed by a MQ Series One-Way Send Port which writes the document into an outgoing MQ queue.
  3. The response message is received by a given MQ Series One-Way Receive Location which reads the document from an incoming MQ Queue and publishes the message to the BizTalkMsgBoxDb.
  4. The response message is finally received by the Two-Way SOAP Receive Location which received the original request and then the document is returned to the caller.
I started to create a POC of this scenario, using the FILE adapter in place of the MQ Series Adapter and folders in place of MQ queues. In the majority of BizTalk applications that use a Request-Response receive port, the request message is used to start a given Orchestration or it is directly relayed to a solicit-response Send Port. When the Orchestration or Send Port provides the response message, this message is routed back to the Two-Way Receive Location that submitted the original request message. These two design patterns are fully supported by the product group and the picture below depicts the case where a Two-Way Request Response Receive Location is directly coupled with a Two-Way Solicit Response Send Port which is responsible for invoking an external web service.
SyncToAsync01
But what about our case in which the request and response are respectively sent and received to/from an external target system not using a Two-Way Solicit-Response Send Port, but using a One-Way Send Port while and a One-Way Receive Location? The standard solution is using an Orchestration to correlate the request submitted to the external system with the response received from this latter. But as you can see from the picture below, this pattern requires 8 roundtrips to the BizTalkMsgBoxDb to complete, 4 message writes and 4 message reads.
SyncToAsync02
In other words, this approach requires multiple roundtrips to the MessageBox to publish and consume messages to/from the BizTalkMsgBoxDb and to hydrate and dehydrate the internal state of the orchestration and all these operations can dramatically increase the contention on SQL and reduce the overall throughput and speed of the application.
So the following question spontaneously emerged: is there any technique to implement the same behavior getting rid of the orchestration? This pattern would allow to eliminate 2 messages publications and 2 message reads and this would allow to speed up the execution and to decrease the contention on the BizTalkMsgBoxDb.
The solution to this problem rests in understanding how BizTalk matches a response message to an initial request message. After you understood the internal subscription matching mechanism implemented by BizTalk, the second step is to individuate the context properties that need to be propagated along and promoted in the One-Way Receive Location in order to allow the Two-Way Receive Location to receive the response when this latter is published to the BizTalkMsgBoxDb.
When a message is received through a Request-Response Receive Location and published to the BizTalkMsgBoxDb, an instance subscription is created to allow the Receive Location to receive the response back when this latter is published to the MessageBox. This subscription expression is always composed of the EpmRRCorrelationTokenpromoted property that is in the request message's context, and a RouteDirectToTP promoted property with a value of True.
Subscription
In particular the EpmRRCorrelationToken is a string containing the name of the BizTalk node which received the request, the process id of the host instance which received the message and a GUID which represents a correlation id. For more info on these and other context properties you can review the following article on MSDNhttp://msdn.microsoft.com/en-us/library/ms966048.aspx.
I made some tests and I quickly realized that those properties were not sufficient to correlate a response back to the original request. In other words, even if the subscription expression is composed of EpmRRCorrelationToken and the RouteDirectToTP properties, promoting them with the expected value in the message context of the response document before publishing this latter is not sufficient to pass message back to the Receive Location. It was clear that it was necessary to propagate some additional context properties, even if they were not used by the subscription expression. After some attempts, I was able to identify the set of context properties that were necessary to correlate a response message back and I was able to create a sample were a synchronous WCF Request Response is couple to 2 asynchronous One-Way FILE Ports.

The Solution

I created a sample BizTalk application called SyncToAsync containing a Two-Way Receive Port called SyncToAsync.Request.ReceivePort. Subsequently, I created a WCF-NetTcp Request Response Receive Location called SyncToAsync.Request.WCF-NetTcp.ReceiveLocation and a WinForm driver application to submit requests to it. Using the WCF Service Publishing Wizard I created a MetadataExchange Endpoint for the web service exposed by the WCF Receive Location and then I used the Add Service Reference command provided by Visual Studio 2005 to create a proxy class in order to submit messages to it. I selected the XmlReceive and PassThruTransmit pipelines on theSyncToAsync.Request.WCF-NetTcp.ReceiveLocation to process respectively the incoming request and the outgoing response messages. In particular, The XmlReceivepipeline contains the Xml Disassembler component which is responsible to probe and individuate the message type and to promote this information along with other context properties. The second step was creating a One-Way FILE Send Port that subscribed all the messages published by the former Receive Location. In order to that I just used theBTS.ReceivePortName = SyncToAsync.Request.ReceivePort predicate as Filter expression. At this point I enabled the SyncToAsync.Request.WCF-NetTcp.ReceiveLocation WCF Receive Location and maintained disabled the SyncToAsync.Request.FILE.SendPort Send Port. Then, using the .NET driver application, I submitted some messages to the BizTalk application. Since no subscribers were active, those messages were suspended. Therefore, using the Administration Console I could review the promoted properties of the incoming request message. After some attempts, I realized that the properties highlighted below (CorrelationToken, EpmReqRespCorrelationToken,ReqRespTransmitPipelineID, IsRequestResponse) plus the RouteDirectToTP that is not promoted on the original request message, were the properties that had to be propagated and subsequently promoted on the One-Way FILE Receive Location used to publish the response to MessageBox.
Context
For the demo I created a very simple XML Schema to represent the basic attributes of a Book entity. I called the schema below InboundBook and this represents the format of the incoming message sent by the .NET Driver application and received by the WCF Receive Location.
Schema
Then I created an extended version of the above XML schema in order to demote some of the aforementioned context properties inside the outgoing message. I called this schema OutboundBook. As you can see in the picture below, this schema is composed of a Header and a Body:
  • The Header contains the CorrelationToken, EpmRRCorrelationToken and ReqRespTransmitPipelineID elements. In particular, this latter will contain the GUID of the transmit pipeline used by the WCF Receive Location to process the outbound response message. I promoted these 3 elements respectively to the properties with the same name exposed by the BTS.bts_system_properties schema contained in the Microsoft.BizTalk.GlobalPropertySchemas assembly. In this way, if on the Send Port I use any send pipeline containing the XML Assembler component (e.g. the XmlTransmit standard pipeline), at run-time, when the pipeline is executed, the value of those message context properties are demoted to those elements.
  • The Body contains the payload of the message, that is the ISBN and Title elements.
Schema2
Then, I created a map to transform an InboundBook message into a OutboundBook document on the FILE Send Port.
Map
For the response message, I created an XML Schema to represent the author of a certain book. Even in this case, the schema is composed of a Header and Body elements. The Header contains the following elements:
  • CorrelationToken.
  • EpmRRCorrelationToken.
  • ReqRespTransmitPipelineID.
  • IsRequestResponse.
  • RouteDirectToTP.
Each of those elements are promoted to the context properties having the same name and contained in the Microsoft.BizTalk.GlobalPropertySchemas assembly. In particular, the IsRequestResponse and RouteDirectToTP elements are defined as boolean and they have a Fixed value equal to 1.
Schema3
Finally, I created a One-Way Receive called SyncToAsync.Response.ReceivePort and a corresponding FILE Receive Location calledSyncToAsync.Response.FILE.ReceiveLocation. I set the standard XmlReceive pipeline on this Receive Location which contains the XmlDisassembler component that is responsible for promoting contained in the Header section of an Author message.
Inside the configuration file of the Driver application you can specify the location of the inbound and outbound folder used respectively by the FILE Receive and Send Ports. The client application used a FileSystemWatcher instance to trigger when a file is published by the Send Port on the outbound folder. When this event happens, a dialog opens where you can review the book information and enter the name and surname of the corresponding author. When you press the Submit button, an instance of the Author message is created for you by the Driver application, the value of the Header elements of the OutboundBook message are copied to the corresponding elements inside the Header of the Author message and the value of the IsRequestResponse and RouteDirectToTP elements is set to true. Then, the Author message is written in the inbound folder where it is received by the SyncToAsync.Response.FILE.ReceiveLocation which promotes the context properties and publishes the message to MessageBox. When the XML document is published, subscriptions are evaluated and the response message is passed to the WCF Receive Location which returns the message to the client application. The following picture depicts the overall architecture of the demo.
SyncToAsync03
You can download the code here.

Conclusions

This technique is a good way to couple a synchronous Request Response Port with 2 Asynchronous One-Way Ports without using an Orchestration. This approach, compared with the standard approach which makes use of an Orchestration to implement the same behavior, allows saving 4 roundtrips to the MessageBox. Therefore, this pattern allows to decrease the contention on the SQL Server instance running the master BizTalkMsgBoxDb and speed up the overall message processing. By the way, I don’t think that the Product Group would support this solution, even if it doesn’t require any custom component. In fact, it uses context properties that were not probably meant to be used by developers, even if the BizTalk programmers’ community knows and uses them. Remember in fact that Microsoft could in any moment release a fix or a service pack that could change the behavior of the subscriptions evaluation and of the request-response correlation, invalidating this technique. On the other hand, this eventuality is not likely because the request-response correlation mechanism is quite consolidated and I don’t think they would have time and will to re-engineer this mechanism.
I have also some ideas on how to modify/customize the technique I described to obtain the same behavior in a slightly different way: for example, instead of including all the necessary context properties in the header of the response message and promote all of them, you could promote the EpmRRCorrelationToken, CorrelationToken andRouteDirectToTP, since the IsRequestReponse and ReqRespTransmitPipelineID are originally written properties. The solution I implemented is probably the fastest one, but it requires all the 5 properties to be propagated and promoted. Another approach could be to save the value of these properties in a custom DB or in a distributed cache likeAppFabric Caching with a custom pipeline component in the transmit pipeline run by the One-Way Send Port and retrieve them in the receive pipeline on the One-Way Receive Location. This mechanism would allow you to propagate just one unique identifier or correlation id that should be repeated in the response message. If you don’t want to use the EpmRRCorrelationToken or the CorrelationToken, you could even use an existing ID already present in the request and response documents as the OrderID orCustomerID.  This approach is less performant (since you need to access a custom DB on the send and receive pipelines) but more flexible and less intrusive, and it’s relatively easy to implement.
Read more ...