# Thursday, June 21, 2007

Ouch! Look at this map. I need to see what is happening in some of these functoids. What is a developer to do?????

BadMap

A map is just complex XSL.... So to debug the functoids we need to treat it as such. First, lets Validate our map and get the location of the XSLT.

Validate

Since it validated (no errors) we have the XSLT output location in the Output Window. Copy this location to your clip board. 

Location

Open the file with Visual Studio:

OpenXSLT

Now, right click on your XSL working area and select properties. Here you will enter the input file that will be used for the transform:
InputFile

Mark your break points, just as you would a code file, and start the debug:

DebugXSLT

Now you can step through just as if it was .Net code:

Step1

Even step into the functoid code:

Step2

 

Ed K.

Technorati Tags: ,
posted on Thursday, June 21, 2007 3:06:48 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
# Wednesday, January 31, 2007

"Microsoft BizTalk Server 2006 requires a hotfix to comply with the new start and end dates for DST in the United States. This hotfix will be available in February 2007. We will update this article when the hotfix is available." (Microsoft, 2007)

http://support.microsoft.com/kb/931961

 

Ed K.

posted on Wednesday, January 31, 2007 8:49:03 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
# Thursday, January 25, 2007

This will be a rather short blog post because I intend to write a much longer blog post about a this topic once I finishing coding a side project that uses WMI with BizTalk. So for now I am just going to throw down some quick, dirty code and explanation to show the power and usefulness of this topic.

If your a BizTalk guy, you probably get tired of opening the HAT and saving messages then terminating. Unless of course your BizTalk solution is just perfect and this never happens to you...ya ok.

What I am going to do is show you quick example of how to generate Managed WMI classes for BizTalk and show an example of how useful it can be.

First thing is to download this:
Management (WMI) Extensions for Visual Studio .NET 2003 Server Explorer

Next thing is connect to the BizTalk box with Server explorer in Visual Studio. Right click on the "Management Classes" and click "Add Classes"
 

Now Select "ROOT\MicrosoftBizTalkServer" and click "ADD>"

Now you see all the classes you can deal with in your Server Explorer.
Right click on "MSBTS_ServiceInstance" and select "Generate Managed Class"
Now you have a class file in your solution that you can program with.
 

Pretty cool eh?
Go ahead and generate one more class from "MSBTS_MessageInstance"

So, lets writes some quick dirty code to do something. I am sure I have at least 100 suspended messages on my local BizTalk server box to work with here :).

   11  ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance.ServiceInstanceCollection _colServiceIns;
   12 
   13   //get a collection a ServiceInstance that are in "Suspended Not Resumable" status
   14   _colServiceIns= ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance.GetInstances
(String.Format("ServiceStatus='{0}'", 32));
   15 
   16   //Loop though them
   17   foreach(ROOT.MICROSOFTBIZTALKSERVER.ServiceInstance _serviceIns in _colServiceIns)
   18   {
   19 
   20       Console.WriteLine("ServiceInstance GUID: "+ _serviceIns.InstanceID + "\n");
   21       Console.WriteLine("Error: " + _serviceIns.ErrorDescription);
   22 
   23       ROOT.MICROSOFTBIZTALKSERVER.MessageInstance.MessageInstanceCollection _messCol;
   24 
   25      //get a Collection of messageInstance with a condition that the ServiceInstanceID 
   26      //of ServiceInstance is equal to ServiceInstanceID of MessageInstance
   27      _messCol= ROOT.MICROSOFTBIZTALKSERVER.MessageInstance.GetInstances
(String.Format("ServiceInstanceID='{0}'", _serviceIns.InstanceID ));
   28 
   29      //Loop though the MessageInstance collection and save off the message
   30      foreach(ROOT.MICROSOFTBIZTALKSERVER.MessageInstance _messIns in _messCol)
   31      {
   32          Console.WriteLine("Saving to File");
   33          _messIns.SaveToFile(@"C:\here\");
   34          Console.WriteLine("Done Saving");
   35      }
_serviceIns.Terminate();
   36   }

All that happens here is, we get a collection of ServiceInstance that are "Suspended Not Resumable", loops through some of the properties and displays them. Then, matches up the MessageInstance with its ServiceInstance and saves off the message to a location on disk and Terminate.

Here is our output.

 

Ed K.

posted on Thursday, January 25, 2007 10:29:16 PM (Central Standard Time, UTC-06:00)  #    Comments [2] Trackback
# Thursday, November 30, 2006

I ran across this issue when building my HIPAA Schemas in Release mode for deployment.

(-1040) The engine input file compilation process is already active

There are good reason for receiving this, such as, someone else doing a compile and/or accessing the EIF file at the same time you are. If you are sure that is not the case then you can manually unlock the repository. Do do this open Query Analyzer and run this script:

USE BizTalkHIPAA_EDIDb
GO
UPDATE parame SET repolock= NULL
GO

What initially caused this issue was, at one time I was building the Schemas and I canceled the build which killed the COMPEIF.exe process leaving the table in a locked status.

Ed K.

posted on Thursday, November 30, 2006 1:50:44 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
# Monday, November 06, 2006

If your working in HealthCare with BizTalk odds are you have a solution for the 837. The 837 is the standard for a HealthCare Claim. There are three different flavors of the 837, Dental, Professional and Institutional. There are many differences between these formats, impeticular, the beginning name of each node, TS837Q3 for Institutional, TS837Q1 for professional and TS837Q2 for Dental. The differences I speak of are very subtle. The one I want to share is the a node in the 2300 segment that we currently use to store a unique ID which we call the BizTalkID; it is how we track claims as we send it to different vendors for repricing. I am not saying that is a best practice but its what we have to deal with in the current BizTalk solution we have adopted.

Listed below is the node and its attributes on an Institutional claim:

<TS837Q3_2300_REF_ClaimIdentificationNumberForClearinghousesAndOtherTransmissionIntermediaries TS837Q3_2300_REF01__ReferenceIdentificationQualifier="D9" TS837Q3_2300_REF02__ValueAddedNetworkTraceNumber="02397SC05232604" />

Listed below is the node and its attributes on an Professional Claim:

<TS837Q1_2300_REF_ClaimIdentificationNumberForClearingHousesAndOtherTransmissionIntermediaries TS837Q1_2300_REF01__ReferenceIdentificationQualifier="D9" TS837Q1_2300_REF02__ClearinghouseTraceNumber="03497SC05318645" />

Can you spot the difference's.... besides the Q1 and Q3? That's right they are subtle.

The first and most oblivious is REF02 segment. One is ValueAddedNetworkTraceNumber and the other is ClearinghouseTraceNumber. The difference that has bitten us time and time again in XSL Transforms and XPaths is the node name. One has a capital H and the other has a lower case h.

TS837Q3_2300_REF_ClaimIdentificationNumberForClearinghousesAndOtherTransmissionIntermediaries
TS837Q1_2300_REF_ClaimIdentificationNumberForClearingHousesAndOtherTransmissionIntermediaries

 

Why is this? Their both are based off the 837 spec.......The answer is, who knows. Maybe different people were in charge of each sub type of the 837 and did not communicate. Just be careful and don't assume that they are the same.

 

Ed K.

posted on Monday, November 06, 2006 7:57:02 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
# Wednesday, September 27, 2006

Tim Rayburn of TimRayburn.net is trying to drum up some interest from the DFW area for a BizTalk Special Interest Group (SIG). This is a great idea seeing the need for BizTalk is becoming more relevant for business and there is little talent out there to guide and nurture solid BizTalk solutions for companies. If you are interested please visit his blog and shoot him an email.... Tell him "The Ed's" sent ya. Ed B and I will of course become members of this SIG since we love BizTalk :)

Ed K. & Ed B.

posted on Wednesday, September 27, 2006 7:27:59 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
# Friday, August 18, 2006

Just to save you a lot of time and hassle with a BizTalk installation... the computer name has to be 15 characters or less!  I guess only those of us with long names ever run into these kinds of problems :)

Ed B.

Here is a great post by Tim Rayburn on this issue. Here: http://www.timrayburn.net

Ed K.
posted on Friday, August 18, 2006 1:33:09 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
# Thursday, June 22, 2006

Debugging .Net assemblies can be tricky in BizTalk 2004. When working with Orchestrations you need to make sure that the version of the Orchestration dll and .Net assembly corresponded. There are two way in which to do this and be able to debug successfully.

 

1. If your Orchestration project and .Net assembly project are in the same solution. Build/Rebuild solution that contains the Orchestration project and your .Net assembly project. Make sure your .Net assembly project is in debug mode. This can be configured in the 'Configuration Manager". Then, Delete their dll from GAC and install the new ones. Now you can debug by attaching to the process "BTSNTSvc.exe".

 

2. If your Orchestration project and .Net assembly project are in different solutions then you will need to change the versioning from the default VS configuration. To change this, open your projects "AssemblyInfo.cs" file and change [assembly: AssemblyVersion("X.X.X.*")] to a hard coded value such as[assembly: AssemblyVersion("1.0.0.1")]. Make sure your .Net assembly project is in debug mode. This can be configured in the 'Configuration Manager". Then, Delete their dll from GAC and install the new ones. Now you can debug by attaching to the process "BTSNTSvc.exe".

 

 

Ed K.

posted on Thursday, June 22, 2006 11:06:29 AM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback