I just got the HL7 DASM pipeline working with two custom Decode pipeline components (String Replace and Archive).

I was receiving batched messages, and if there was an error in any of the trigger messages, the entire batch was being rejected with no discernable error message other than the context property: ParseError=True (wow, I can really troubleshoot with that indicator)

So I was given hotfix KB 973910 and started testing it. I did not seem to fix the problem.

I changed and used the out of the box HL7 DASM, and it started working (debatching the file and suspending only the trigger message that was actually in error). I decided to rebuild the custom pipeline, I removed the HL7 DASM pipeline component from the .btp file, removed the HL7 DASM from the tool box, and the re-added the pipeline to the tool box and then added it to the .btp file. I then deployed it and ran a file through successfully.

Here is the wives’ tale: If you have a custom HL7 pipeline component, you need to remove the HL7 DASM completely from Visual Studio and then re-add it so that BizTalk will see the new behavior.

 

Please let me know if this is a fallacy, and what the minimum amount of work that I have to do to have BizTalk see a newly hotfixed pipeline component.

 

This has happened now three times to me, and I just received an email from a friend about this.

When you install the HL7 accelerator on a 64bit machine, you need to create a 32bit host; as the HL7 DASM and ASM are 32bit only.

A hint as to what kind of host needs to be set up is found in the root drive:

RootDrive 

To do this, you need to create a 32 bit host:

32BitHost

Create the Host Instance:

32BitHostInstance

Create a new send and receive handler using the new 32 bit host that is just created:

 Handler

Which ends up looking like this:

AllHostInstances

And now to change the actual receive or send port to use the 32 bit host instance

32BitReceiveHandler

 

To summarize what they are using to migrate gigabytes of data is:

  1. 5 hours before the actual move, they make a full backup of their data in the database (SQL Server 2000)
  2. They use RoboCopy in triplicate to move the more than 20gb of data from one server to another
  3. They restore the data
  4. They do a differential of the last few hours of data

The entire process takes about two hours to fully migrate. The reason why they have allocated an additional 3 hours is so that if there is any problems during the migration, they have enough time to analyze the data and run a complete migration again.

Some of the things that they are looking at and testing is Virtualization using Hyper-V or VMWare to break their dependence on hardware.

© 2012 HL7 and BizTalk Blog Suffusion theme by Sayontan Sinha