integrating your business

Some time ago, with a client using BizTalk 2006 and Covast Accelerator 2006, we suddenly had the following issue popping up in their event log:

There was a failure executing the send pipeline: "Covast.BizTalk.Pipeline.EDI.CovastEDISendPipeline, Covast.BizTalk.Pipeline.EDI.Default, Version=5.0.0.0, Culture=neutral, PublicKeyToken=68bef120a46b49ad" Source: "Covast EDI Assembler" Send Port: "sp_MySendPort" URI: "D:\BTS2006\DumpLocation\%MessageID%.edi" Reason: Message translation failed: (2217) Unknown error (-2217)

The source of the problem was Covast.
Somehow, it was no longer able to perform valid assembling and disassembling (both were failing).

After a lot of digging and research I finally came to the "Covast EDI Accelerator 2006 Reports" screens, hidden deep within the BizTalk Administration Console HAT :-)

When you double click the interchange which was in error, you saw the following error:

The format of the document has not been configured

Finally, this led me to the source of the problem.

Someone at the client fiddled around with one particular ASC file trying to add some extra segments to the schema to accompany a change in one of their flows. No harm done, but unfortunately when re-generating the XSD, he also regenerated the SYNTAX schema and deployed.

The result was that there were now 2 SYNTAX schemas deployed within BizTalk and Covast doesn't know how to handle that.
Reverting back to the old version of the flow fixed the error and after that we just removed the SYNTAX schema from the project, rebuilt and deployed and now it worked.

Reason for posting this is that at the time, neither search engine could come up with a decent answer, so hopefully someone benefits from this post.

Let us know in any case!

Pieter

I had some fun in converting my build/deploy scripts. These scripts are made to build and deploy a BizTalk project with one click on your local development machine to avoid to much clicking. The scripts are making use of MSBuild.

On my current project, the development BizTalk Servers are remote machines, the scripts were still working fine, except adding an assembly to the GAC on the remote machine caused some problems.

The first step to add an assembly is finding the right MSBuild task to do this. I'm using the MSBuild extension pack, this extension pack contains a GAC task (makes use of Gacutil.exe). The task is used as follows:

 <MSBuild.ExtensionPack.Framework.Gac TaskAction="AddAssembly" AssemblyPath="$(asseblyPath)" RemoteAssemblyPath="$(remoteAssemblyPath)" MachineName="$(Server)" Force="true" /> 

As taskaction, I choose 'AddAssembly', specify a local and remote assembly path and a machine name (the remote server). If your user account does not have the necessary privileges to add the assembly to the remote GAC, you can specify a remote user/password combination.

Although this looks ok, this is not enough...

The remote machine is a server, without the .NET 2.0 SDK installed. The gacutil.exe tool is shipped with the .NET 2.0 SDK. We could install the .NET 2.0 SDK but it is enough to deploy gacutil.exe on the remote server.

This still did not work...

One final thing should be done! The GAC MSBuild task does not know where to find gacutil.exe. To fix this, we must add the path to gacutil.exe to the PATH environment variable.

If these three steps are done, we can GAC our assembly on the remote machine....

Peter Borremans