integrating your business

Hello,

One of our Managed Services customers had a problem where a message got suspended with the following error:

They already looked into the issue, tested the username and password for the share, etc ...
The platform is a multi-server platform with 2 BizTalk servers within the same BizTalk group.

Troubleshooting

I was digging into the issue and saw that it was very likely that only one of the servers had the issue (the server where the message got suspended was always the same). 

So during the retry within BizTalk, some messages got processed by the other server as BizTalk chooses the processing server depending on load...
Sometimes though, a message got only processed through the first server, leading to a suspended message eventually.

I was digging into the eventlog and stumbled into this (system eventlog):

I checked and there was indeed a stored username/password on the first server for connecting to the server hosting the file-share:

(This were credentials of a BizTalk operator and his password had changed recently).

When I removed the stored credentials the issue was resolved. (Also when you define the credentials in the send port configuration).

So stored credentials were used instead of the credentials defined in the BizTalk host to connect to the fileshare!

For more information on stored passwords, please see MSDN: http://technet.microsoft.com/en-us/library/cc733968(v=ws.10).aspx

Hope this helps,

Brecht

Today I was deploying a new release for one of my BizTalk applications. I updated logic on several places in two assemblies containing orchestrations.

I decided to deploy to the testing server manually: the first assembly was no problem to deploy, however the second assembly gave me the following error:

Failed to update binding information. (mscorlib)

Party 'PartyName' enlisted under role 'Provider(Codit.MyRoleLinkType)' has not bound all the operations of role link port types. (Microsoft.BizTalk.ExplorerOM)

You do not find a lot of information on the above error online, so I tried to check where the problem lied myself to no avail.

I found one similar blog post from Steve Harclerode which claims that there is no other way than to delete the entire BizTalk application and then recreate it.

However, I found that if I delete this particular resource and then add it again, I have no issues.
Off course, by removing the resource and thus also removing the artifacts and bindings, you also lose your role link setup. In my case however, this is easily put back by importing the bindings I exported before removing the assembly.

Hope this helps someone, please feel free to comment if you have any cause or solution.

Lately I came across a weird exception while building a BizTalk project with Team Foundation Server.  Let’s have a look.

The error

Although the build succeeded locally, we got this error while building our BizTalk project with TFS:

FlatFileSchema.xsd.cs: The type or namespace name '<ContextPropertyName>' could not be found in the global namespace (are you missing an assembly reference?)

The troubleshooting

After some try/error, we discovered that the error only occurred when building a BizTalk project in TFS that contains a flat file schema, using property promotion.   The first reflex was to compare the installed software on our local development machine and the Team Foundation Server.

• Local machine: Full BizTalk 2010 Installation
• TFS server: BizTalk 2010 Build Component

The solution

The solution was to install also the Developer Tools and SDK on the TFS server.  Although MSDN states that the Build Component should be sufficient.  This extra installation adds “Developer Tools\Schema Editor Extensions” to the BizTalk folder.  This is apparently needed for building flat files schemas that use property promotion.

Today I've encountered a problem with the party configuration, specifically while reconfiguring send ports from a party. An error occurred when I removed a send port from a party and saved my settings.

The error

The error occurred during the removing of a send port from a party: Sendport Reference [Microsoft.BizTalk.B2B.PartnerManagement.SendPortReference] cannot be deleted as it is use by agreement [Microsoft.BizTalk.B2B.PartnerManagement.SendPortReference]. (Microsoft.BizTalk.B2B.PartnerManagement)

The troubleshooting

Based on a forum thread on MSDN, this seems to be a bug in the BizTalk console, but has never been officially announced or patched. The forum thread suggests waiting for the next cumulative update for BizTalk server [link: cumulative updates Biztalk]. But even when I applied an update for BizTalk to the next version, the problem didn't got solved.

Based on the error message, a constraint prohibits removing the send port record assigned to this party. The OnewayAgreementSendPortReference table contains all send port records for each party. A foreign key is present between OnewayAgreementSendPortReference.SendPortReferenceId and the SendPortReference.Id colomn.

The solution

I had to manually remove the Foreign key record from the SendPortReference table.

Connect to the BizTalk SQL database instance of the BizTalkMgmtDb catalog.
Change the @Name variable to the name of the send port you would like to remove from the party.

DECLARE @NAME varchar(100)
SET @NAME = 'spo_3025816970108_3014683300200_INVRPT_EDI_FTP_PRD'

DECLARE @ID int
SELECT @ID = id
  FROM [BizTalkMgmtDb].[tpm].[SendPortReference]
  WHERE Name = @NAME  
  
DELETE FROM [BizTalkMgmtDb].[tpm].[OnewayAgreementSendPortReference]
  WHERE SendPortReferenceId = @ID

  DELETE FROM [BizTalkMgmtDb].[tpm].[SendPortReference]
  WHERE Name = @NAME

After running this query, refresh your BizTalk administration console and the send port is now removed from the party.

Important note:
Be aware that fiddling with the BizTalk internal databases is not a recommended approach and is not supported by Microsoft.
Any support case dealing with issues after manually changing the BizTalk internal databases will have to be paid fully or result in a re-installation!