Here, is a nice wiki article on Application Configuration options in BizTalk Server.

https://social.technet.microsoft.com/wiki/contents/articles/6494.biztalk-server-application-configuration-options.aspx

The interesting thing was that on another BizTalk environment , whenever that element was not present in the input message, property was not getting promoted and hence subscription worked as expected. One difference I could find out between these two environments,  was that where it worked as expected was BizTalk 2006 R2 and other where it promoted null values was BizTalk 2006. I am not sure if there is a change in behavior on promoted properties between BizTalk 2006 and BizTalk 2006 R2.

Searching on internet, I found https://support.microsoft.com/kb/942250 which says, “Properties that have a null value are not permitted in the message context. Therefore, if a null value is written into the message context, this value will be deleted.” So definitely promoting null values is not expected and may be, this could be a bug with BizTalk 2006.

We needed to have a quick workaround as there was some other testing which depends on it. Now I tried adding a filter with a blank value <empty string> as below.

But when I clicked Apply, it threw error: “The filter expression statement element is missing the value attribute”

So it means that I cannot add a filter on a blank value or empty string.

But surprisingly, there was a easy workaround. Just put a space in the Value and there we go, we were able to Apply the filter successfully. And it worked too, i.e. it didn’t subscribed to the messages with null promoted property.

I still need to find out why it promoted null values at the first place or if it is a bug with BizTalk 2006. Will update this blog post if I am able to find out any further information on it.

Event Type:    Error
Event Source:    ENTSSO
Event Category:    Enterprise Single Sign-On
Event ID:    10728
User:        N/A
Description:
This version of the SSO server is not compatible with the SSO database. Please upgrade your master secret server.
SQL Server Name: xxxxxxxxxxx
SSO Database Name: SSODB
SSO Database Version: 0.0
Required Version: 3.0

This error was confusing since there was no change made to the SSODB or the SSO Server. Troubleshooting here and there, we didn’t got any clue. That time, I wanted to gather a MsgBoxViewer report to see if it gives any insight as to what caused this incompatibility. But, MsgBoxViewer tool itself threw error “Cannot generate SSPPI context” while trying to connect to BizTalkMgmtDB. It meant that from BizTalk server we were not able to connect to SQL Server hosting BizTalk databases. This got confirmed when we tried to test the connectivity using a UDL file with Windows Integrated Security.

We then worked to resolved the error “Cannot Generate SSPI Context” while connecting to SQL databases. This issue was resolved once we ran the SQL server under Local System account. Apparently, looks like we were running into issue similar to what is described in https://blogs.msdn.com/b/sql_protocols/archive/2005/10/15/481297.aspx.

Once, the error “Cannot Generate SSPI Context” was resolved, we were able to start the SSO Service successfully.

Basically, when we deploy a BAM Activity, it creates the packages at the following location:

1. Data Maintenance(DM) packages are stored on the BAM Archive Database server.
2. Analysis(AN) packages are stored on the BAM Star Schema Database server.

bm.exe also needs a few components from SSIS management API's to create BAM packages, therefore the servers from where you deploy (typically it will be BizTalk Server) also need to install them. You can go through the following posts if  you are interested to find out what is the minimum requirement for the server from where you run bm.exe: https://blogs.msdn.com/joscot/archive/2009/05/25/do-i-need-to-install-ssis-on-my-biztalk-server-to-configure-and-use-bam-no.aspx and https://blogs.msdn.com/joscot/archive/2009/08/04/an-update-to-bam-ssis-pre-requisites.aspx

So now the question is where the SSIS package will be deployed if you do not have the SSIS installed on the SQL server (star schema, archive). These SSIS packages are stored in the MSDB database. If you are interested to know where it will be stored if you are running a named instance of SQL, I will recommend to go through another blog post by John Scott: https://blogs.msdn.com/b/joscot/archive/2009/05/25/do-i-need-to-install-ssis-on-my-biztalk-server-to-configure-and-use-bam-no.aspx

Now, you have got the SSIS packages stored in the MSDB database of SQL Server (star schema, archive). You can now remotely run these packages from another server which have got SSIS installed on it. A SSIS package runs on the same computer which starts the package. If a remote package is directly run from a local computer, the package will load and run from the local computer itself. As long as we have the right permissions, the packages should be able to run from anywhere. Considering these, SSIS must be installed on the server from where you plan to run these packages. You can go through https://blogs.msdn.com/b/michen/archive/2006/08/11/package-exec-location.aspx for more details on it.

We can now say that it is not mandatory to have SSIS on the SQL Server hosting BizTalk Databases and it is very much possible to have a dedicated SSIS Server to run these packages. Thanks to Rajat from BizTalk Product Group for providing me the information!

Atin Agarwal

Typically, this happens when we are calling a map from inside the Orchestration and the map is inside a large assembly. This was a known issue and was documented at https://support.microsoft.com/kb/918643

“The System.Policy.Security.Evidence object is often used in transforms and can consume much memory. Whenever a map contains a scripting functoid that uses inline C# (or any other inline language), the assembly is created in memory. The System.Policy.Security.Evidence object uses the object of the actual calling assembly. This situation creates a rooted object that is not deleted until the BizTalk service is restarted.

Most of the default BizTalk functoids are implemented as inline script. These items can cause System.Byte[] objects to collect in memory. To minimize memory consumption, we recommend that you put any map that uses these functoids into a small assembly. Then, reference that assembly.”

So for example if you have got the map inside a 10 MB Assembly, it will always create 10 MB System.Byte[] objects in the memory and you can imagine how quickly you could run into the OOM Exception if you are on a 32 bit environment. Earlier only workaround was to put map in the small assembly but if you are not able to split the maps and other artifacts by different project, then the good news is that this issue is fixed in https://support.microsoft.com/?id=975118.

This hotfix has been released for BizTalk 2006, BizTalk 2006 R2 and BizTalk 2009. Also, this hotfix is part of BizTalk 2006 R2 SP1.

I have seen that this hotfix improves memory utilization by the orchestration hosts. This also helps increase performance and stability of the BizTalk applications. If you haven’t got this fix as of yet, I will highly recommend to apply this fix ASAP.

My customer was receiving below error and the strange thing was that though we receive this error in the event log, but we do not see any suspended or dehydrated orchestration in the BizTalk Group which would mean that it got processed successfully.

Event Type: Error
Event Source: XLANG/s
Event Category: None
Description:
Suspending due to exception occurring during dehydration of instance a09542e6-ebe5-489d-af31-ece26de13cf4.
Exception type: DehydrationFailedException
Additional error information:
Exception from HRESULT: 0xC0C01B05
Exception type: COMException
Source: mscorlib
Target Site: Void ThrowExceptionForHRInternal(Int32, IntPtr)
The following is a stack trace that identifies the location where the exception occured
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXXlangStore.PrepareForActivationComplete(Boolean wait)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXService.PerformDehydration(Boolean wait)
at Microsoft.XLANGs.Core.Service.Dehydrate()

On further investigation, it was found that this is an transactional orchestration with type atomic (not an atomic scope but complete orchestration is atomic). Also, we found that there is a Send Shape in the end which has got delievery notification to transmitted. Once we changed delievery notification to none, it resolved the error.

I tried to repro this issue only on BizTalk 2006 R2 box. I was able to repro this only when the orchestration is atomic not when we put a send shape with delivery notification under an atomic scope.

Atin Agarwal

In Native SQL Adapter, this kind of composite operation can be achieved using updategram by capturing the value generated for the Identity field using the updg:at-identity attribute. This is documented at whitepaper: Working With BizTalk Adapter for SQL Server. But when it comes to WCF-SQL Adapter (Adapter Pack 2.0), since it would not work with updategram, only way I could figure out is to write a Stored Procedure which will do all the stuff in a single transaction and you can then call it from the Send Port. Of course, you can do the same in multiple operations without calling Stored Procedure where you first write to Parent table and get the identity value back as response and then write to child table; but this would not be a single transaction and any failures will writing to child table will not rollback the insertion into Parent table by itself.

Now, when it comes to writing Stored Procedure, if you just need to insert into one parent record and one child record, it would be simpler. But what about if there are multiple child records for a single parent record? For this, we would need to create an Xml message and pass this to the Stored Procedure as an Xml parameter. And then inside the stored procedure, we need to retrieve the values from the Xml message and insert it to our Parent and Child tables. Parsing the Xml message inside Procedure will be not an easy task if the message schema is complicated (especially for EDI Schemas :) ) and will involve good knowledge of writing Xpath Queries. But this becomes really simpler with use of Table Types and Table-Valued Parameters in SQL 2008. (Thanks to Mustansir Doctor for pointing me to this new feature of SQL 2008)

Here is an example of how we can achieve the same using Table Types and Table-Valued Parameters.

Lets say we have two tables Orders & Order Details in SQL 2008 with Primary Foreign relationship  and OrderId is an auto incrementing field.

Now, first step will be to create Table Types for the above two tables:

We do not need to have OrderId field in the Table Type created as this is an incrementing field and we do not need to pass this in parameters passed to Stored Procedure.

Now, create a stored procedure to which we will pass this Table Type as parameter and inside it we will first insert into Orders table and read out the Identity value and use it to insert into OrderDetails table. Also, notice that reading out values from the Table Type objects is as simple as reading out form a Table.

Now, what all we have to do is to use Consume Adapter Service through Visual Studio to generate Schema.

It will generate two schemas TableType.dbo.xsd and TypedProcedure.dbo.xsd along with a binding file for the WCF-SQL Adapter.

TableType.dbo.xsd

 TypedProcedure.dbo.xsd

TypedProcedure.dbo.xsd contains the request and response schema for WCF-SQL Adapter.

Now, only thing remaining is to construct a message of the request schema type inside the Orchestration and send it to WCF-SQL Adapter which will execute the Stored Procedure. I am not going into it more detail on how we do it inside Orchestration as it will be similar to any other operation we do using WCF-SQL Adapter.

You can see that using the Table Types simplify the things to a large extent and we do not need to write a single line of code to parse the XML.

I hope it helps.

on BizTalk Server

Event ID: 5740
Description:
The adapter "MQSeries" raised an error message. Details "Error encountered on opening Queue Manager name = <queue manager>  Reason code = 2354."

on MQ Server

Event Source: Microsoft BizTalk Server 2006 Adapter for MQSeries
Event Category: Devices
Event ID: 264
Description:
Error encountered as BizTalk attempts to retrive a message from MQSeries, description = Error encountered on opening Queue Manager name = <queue manager> Reason code = 2354. hresult = 0XC0C11007. This error will also be reported on the BizTalk server.

Most probably, this issue arises due to lack of DTC connectivity between the BizTalk and MQ Server.

To resolve it, we have to make sure the DTC communication between two computers is fine. Make sure that the MSDTC security settings on both BizTalk as well as MQ Server looks like in the below screen shot.

Also, DTC communication can usually fail if the name resolution or RPC communication between two computers is failing. To test it, we can use a small but useful tool named as DTCPing.

DTCPing Download: https://www.microsoft.com/downloads/details.aspx?FamilyID=5e325025-4dcd-4658-a549-1d549ac17644&DisplayLang=en

Troubleshooting MSDTC issues with the DTCPing tool: https://blogs.msdn.com/distributedservices/archive/2008/11/12/troubleshooting-msdtc-issues-with-the-dtcping-tool.aspx

I hope it helps!

Below is the error thrown by EDIReceive pipeline at run time.

Event Type: Error
Event Source: BizTalk Server 2009 EDI
Event Category: None
Event ID: 4097
Description:
Fatal error encountered in EDI Disassembler, error information is Object reference not set to an instance of an object.

The issue would not happen if we were using the default 837I HIPPA schema which comes out of the box with BizTalk. Now, it means that something going wrong with the node which we have added to schema and the error is also of not much help here. Also, if we remove the data from the input instance corresponding to the node added in the schema, it would get successfully parse.  

After we did a thorough examination of schema (all thanks to Farida for this), we found that the child node added under DTP segment in the schema was missing the HIPPA Schema Trigger Field Annotations. First learn what are HIPPA Schema Trigger Field Annotations, for that click here. Here it was happening that, for DTP segment, we had other default child nodes which have got their Trigger Field Annotations specifying what their qualifier values (or trigger values) are. Now when the EDI Disassembler encounters DTP segment followed by the qualifier value, it should be able to resolve it to the corresponding XML child node under DTP segment. But when it encountered DTP segment for the child node added to the schema, it was not able to resolve the qualifier value to any node since there is no child node matching that qualifier value and hence the error.

Once we added the Trigger Field Annotations to the node added manually, it resolved the error. Note that, for adding the trigger info, we have to open the schema in a text editor.