July 2005 - Posts

TO "UNDEPLOY" OR "NOT TO UNDEPLOY"

If you have been working with Biztalk for a considerable amount of time like me
you would have gone through the pains of the Undeploy Regac - Deploy loop , Sometime when you are making changes to Schema , it is quite unavoidable but at lot of time you really don't need to , Just re-gacing your dll and restarting the Biztalk service will do the trick . I have not seen a comprehensive documentation for the same . So the list below is mostly from my own experiences

Schemas
=======

Any changes to Schemas like Namespace , Root Node Name , Promoted properties require a UNDEPLOY - DEPLOY Cycle.

Changing a node which is not a promoted one and not a root node , you can get by with just a GAC and restart

The reason for the same is Your Schema#rootnode is used in subscription evaluation , A changes to this without deploy undeploy will give you an subscription not found error


Maps
====
Changing mapping or Functoids in maps DO NOT require a UNDEPLOY - DEPLOY unless the Schema itself has changed ( See schema Above )


Orchestrations
==============
Changes in Orchestration DO NOT require a UNDEPLOY - DEPLOY Cycle unless Send/receive Port shapes are changed

This is mostly because Schemas would change or you add a new port based on a new schema which needs to get updated in the subscription viewer and this requires undeploy - deploy

Pipelines
=========
Changes in Pipeline DO Require a UNDEPLOY - DEPLOY


Assembly
========

External Assembly change DO NOT require a UNDEPLOY - DEPLOY Cycle unless you change the version number

In VB assembly info if the assembly version is set to 1.1.* it will increment the assembly number for every small change. Though it is good from a certain point of view , it can quickly become a pain if you just want to make a little minor change .
So I suggest you control the version number manually , So you can just re-gac the assembly

Please note Gac-ing the change and restart of the BTSservice is needed for all steps

Last but not the least , you should learn ,try and use BTSNANT tool , It is well worth the effort you spent

SEHException While Enlisting Orchestration

I am posting one of the errors we encountered over which considerable time was spent debugging.

You will get the below Error in Event Log


Event Type: Error
Event Source: XLANG/s
Event Category: None
Event ID: 0
Date: 5/5/2005
Time: 3:22:32 PM
User: N/A
Computer: Machine12

Description:
An SEHException exception occurred while the XLANG/s runtime enlisted a service.
Error message:External component has thrown an exception.
Call stack: at Microsoft.BizTalk.MetaDataOM. ICLRType.GetFields(UInt32 dwBindingFlags) at Microsoft.BizTalk.XLANGs.BTXEngine. BTXServiceStaticState._createStringLookup(String svcFullTypeName,
IAssemblyManager asmMgr) at Microsoft.BizTalk. XLANGs.BTXEngine.BTXServiceStaticState. PersistState (String mgmtDBServer, String mgmtDBName, String MsgBoxGroupName, String ApplicationName, String serviceAssembly, String serviceTypeName, Guid[] PortIDs, Guid[] LrpIDs, ITransaction transaction)
at Microsoft.BizTalk.XLANGs. BTXEngine. BTXService.GoLive (String configDBServer, String configDBName, String msgBoxGroupName, String applicationName, String servicePath, String serviceTypeName, Guid[] portIDs, Guid[] lrpIDs, ITransaction transaction)

Exception type: BTXEnlistmentException
Source:
Target Site:
Help Link:
Additional error information:

External component has thrown an exception.

Exception type: SEHException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: System.Collections.IEnumerator GetFields(UInt32)
Help Link:
Additional error information:


This normally occurs when you don't have a dependent file of the assembly not in GAC . That is an orchestration which references other Dll's must have the dependencies already GAC'd

Another variation of this enlistment error is OutOfMemory exception which is due to some limitation of WMI , which can be increased with a custom Script


But in our case this was not the case I checked and rechecked the dependencies of our project they were all there .

What we found out was that our Production server did not have Biztalk SP1 applied whereas the dev machine had SP1.

So apparently the issue is still I guess of DLL's Missing in GAC but not of the application but that of Biztalk Later version Assemblies !!