BizTalk

Be careful when setting GenerateCSFiles to 1

plundberg — Wed, 11 Mar 2009 17:19:40 GMT

If you, like me, have set the GenerateCSFiles property to 1 (as described here) to get BizTalk to keep the .cs files after they have been generated from the orchestrations and maps, be a bit aware that it can cause some weird problems sometimes.

I just had one of my orchestrations indicating that there was an error with some of the shapes. The map was missing, seemingly. The odd thing was that the whole solution was compiling correctly, so the problem seemed only to affect the editor.

When looking at the "configure map" settings, the map the shape was referring to had just disappeared. Yeah, you heard me. It was completely gone. Why? I don't know. The file was located in the project, it was set to Compile on build, but... it didn't work.

The solution: close down Visual Studio. Remove all .cs files from the folder with the orchestration and the folder with the maps. Open the solution, and the problem was gone...

Script calling external assemblies - be aware that it uses "dynamic binding"

plundberg — Mon, 15 Dec 2008 19:48:57 GMT

I've been having an error lately that looks like this in the event log:

Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'SomeRoutines.OrderHandler(1f254f9a-5838-1051-30a3-ca1c40b2906f)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 875947d5-5c01-4ad7-9d62-a033902a3133
Shape name: ConstructUpdateMessage
ShapeId: 43a0909e-5877-4e6e-a6a0-c4bbb7c5c644
Exception thrown from: segment 1, progress 12
Inner exception: Error encountered while executing the transform SomeRoutines.SomeTransformation. Error:Unable to create the transform..

Exception type: XTransformationFailureException
Source: Microsoft.XLANGs.Engine
Target Site: Void ApplyTransform(System.Type, System.Object[], System.Object[])
The following is a stack trace that identifies the location where the exception occured
   at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)
   at SomeRoutines.OrderHandler.segment1(StopConditions stopOn)
   at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
Additional error information:

        Could not load file or assembly 'Xxxxxxxxxxx.XxxXxxxxx.Integration.HelperFunctions, Version=1.0.0.1, Culture=neutral, PublicKeyToken=aaaaabbbbbccccdddd'
or one of its dependencies. The system cannot find the file specified.

Exception type: FileNotFoundException
Source: mscorlib
Target Site: System.Reflection.Assembly nLoad(System.Reflection.AssemblyName, System.String, System.Security.Policy.Evidence, System.Reflection.Assembly,
System.Threading.StackCrawlMark ByRef, Boolean, Boolean)
The following is a stack trace that identifies the location where the exception occured
   at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark,
Boolean throwOnFileNotFound, Boolean forIntrospection)
   at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   at System.Reflection.Assembly.Load(String assemblyString)
   at Microsoft.XLANGs.BaseTypes.TransformBase.get_TransformArgs()
   at Microsoft.XLANGs.RuntimeTypes.TransformMetaData..ctor(Type transformBaseType)
   at Microsoft.XLANGs.RuntimeTypes.TransformMetaData._creator(Type t)
   at Microsoft.XLANGs.RuntimeTypes.MetadataCache._slowFor(Type t)
   at Microsoft.XLANGs.RuntimeTypes.MetadataCache.For(Type t)
   at Microsoft.XLANGs.RuntimeTypes.TransformMetaData.For(Type t)
   at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)

The problem with this was that the .dll version number had been increased from 1.0.0.1 to 2.0.0.0, causing the above error. I had recompiled the project in question and deployed it again, but I still got this error and today I decided to take a look at its cause. It turned out that what I have in the .btm file (BizTalk map) is a scripting function, calling an external assembly. Now, when you do that, this is what it looks like in the .btm file:

<ScripterCode>
  <Script Language="ExternalAssembly" Assembly="Xxxxxxxxxxxx.Xxxxxxx.Integration.HelperFunctions, Version=1.0.0.1, Culture=neutral, PublicKeyToken=aaaabbbbbbcccccdddd" 
          Class="Xxxxxxxx.Xxxxxxxxxxx.Integration.HelperFunctions.WrapperClass" Function="GetDiscount" 
          AssemblyPath="..\IntegrationFunctoids\obj\Debug\Xxxxxxxxxxxx.Xxxxxxxxx.Integration.HelperFunctions.dll" />
</ScripterCode>

What this means in reality is that the binding is not done using the project's "assembly references"; rather, the .dll is loaded at runtime. Sure, that's a pretty convenient thing at times. Right now in this case though, it would have been better to have the .dll files be more "statically" bound to each other.

The problem with dynamic binding (or "dynamic references" might be a better phrase) is that you don't get the errors when you want them: at compile time. Rather, you get it at run time. However: what you do get is that you get the error when you try the "Test Map" function in Visual Studio. Once again, clearly, this nice function can not be over-emphasized. :-)

Remember to make callable orchestrations "public"

plundberg — Fri, 28 Nov 2008 16:09:40 GMT

If my previous posting was kind of sophisticated, this one is a lot more down-to-earth and basic...

I've been struggling during the morning trying to use the "Call Orchestration" feature of BizTalk. A pretty straightforward feature. But, I couldn't just get it to work. If the called orchestration was in the same project as the calling orchestration, it worked Just Fine<tm>, but as soon as I tried to put the called orchestration in its proper place, it just failed.

The solution? Well, I got the answer from someone who is much more experienced with BizTalk than me: Make the called orchestration public. This is pretty straightforward if you think about: orchestrations are really standard CLR classes (even though not generated manually by writing C# or VB.NET code), and as such, they have visibility parameters just like classes usually have.

If it doesn't immediately work after making sure the callee orchestration is public, try rebuilding the project that is referring to the callee. Yes, you heard me right. Even thought it might fail (since you are likely to have a Call Orchestration shape that is unconfigured), something happens when you build it that sometimes makes it work.

Restarting Visual Studio is also something that can be helpful. For me, in this specific case, building the project didn't work straight away - one of the files was being locked. But when I restarted Visual Studio, it found the callee orchestration anyway, so - problem solved.

Weird problems with document with only one node, the root node (no content nodes)

plundberg — Fri, 28 Nov 2008 15:47:15 GMT

I ran into a strange issue the other day with BizTalk Server 2006 R2. Imagine a map (.btm file) that takes multiple messages as its input. Imagine two of those messages being of the same document type, having the same schema. Now... make the first message be normal, like this (this is an excerpt from the full multipart input message to the map):

  <InputMessagePart_2>
    <ns4:stock_warehouse_fetch_response xmlns:ns4="http://StockWarehouse">
      <ns4:stock_warehouse stock_warehouse_id="170A9532-BD20-11DD-85B6-3DFC55D89593" 
                           company_id="1EBB0C44-BD20-11DD-9025-69FC55D89593" 
                           [... More attributes existed but have been removed to preserve 
                           the integrity of the customer ] />
    </ns4:stock_warehouse_fetch_response>
  </InputMessagePart_2>
  <InputMessagePart_3>
    <ns4:stock_warehouse_fetch_response xmlns:ns4="http://StockWarehouse">
      <!-- This is the part that causes the problems -->
    </ns4:stock_warehouse_fetch_response>
  </InputMessagePart_3>

When I used the message above (with more messages in the multipart message and so forth), a very weird thing occured: the map output was completely empty, the only thing that remained was the root node! Obviously, many of the input elements existed in the input messages, so this is clearly a bug in BizTalk (IMO). The problem first occured when running the application in BizTalk Server 2006 R2, but was reproduced with the Visual Studio-integrated "test map" function.

The solution? Add a "content node" in the document, like below. It seems like BizTalk really, really dislikes documents with only a root node. There must be at least one content node in all the input documents to a map. Otherwise, the map output is completely eradicated, except for the root node.

  <InputMessagePart_3>
    <ns4:stock_warehouse_fetch_response xmlns:ns4="http://StockWarehouse">
      <ns4:stock_warehouse></ns4:stock_warehouse>
    </ns4:stock_warehouse_fetch_response>
  </InputMessagePart_3>

Well, that's it for this time. I hope this helped you, it would have helped me.