But how could I access it?

You need to reference the following assembly in your project:

C:Program Files (x86)Microsoft BizTalk 2009 Accelerator for HL7BinMicrosoft.Solutions.BTAHL7.HL7Schemas.dll

Once you do that, you can add the following filter:

The issue is that the hot fix does not know the username/password that the Logging Service uses, so it wipes it out:

So you set the credentials and continue and you are ready to go.

Event Type:    Information
Event Source:    BizTalk Accelerator for HL7
Event Category:    None
Event ID:    4119
Date:        3/10/2010
Time:        2:35:25 PM
User:        N/A
Computer:   
Description:
An empty batch was received with fragmentation turned on. The 1st 1kb of the message is

MSH|^~&|…

 

Username:
Time: 3/10/2010 2:35:24 PM

However, when searching for this, I was not apparent that it is referring to the following KB 973910 article

I went happily creating the schema, deployed it and ran it, and received the following errors:

Event Type:    Error
Event Source:    BizTalk Accelerator for HL7
Event Category:    None
Event ID:    4097
Description:
Fatal error encountered in 2XDasm. Exception information is Object reference not set to an instance of an object.

followed by

Event Type:    Error
Event Source:    BizTalk Server 2009
Event Category:    (1)
Event ID:    5719
Description:
There was a failure executing the receive pipeline: “BTAHL72XPipelines.BTAHL72XReceivePipeline, BTAHL72XPipelines, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ Source: “BTAHL7 2.X Disassembler” Receive Port: “One Way Receive Port” URI: “D:DataLabMedicityInput*” Reason: Object reference not set to an instance of an object.

and

Event Type:    Error
Event Source:    BizTalk Server 2009
Event Category:    (1)
Event ID:    5753
Description:
A message received by adapter “FILE” on receive location “Medicity Pickup” with URI “D:DataLabMedicityInput*” is suspended.
Error details: There was a failure executing the receive pipeline: “BTAHL72XPipelines.BTAHL72XReceivePipeline, BTAHL72XPipelines, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ Source: “BTAHL7 2.X Disassembler” Receive Port: “One Way Receive Port” URI: “D:DataLabMedicityInput*” Reason: Object reference not set to an instance of an object. 
MessageId:  {E182624C-BD9A-422A-B13B-CD7E108B5B30}
InstanceID: {72120031-57DB-418B-AEE3-A4E3A039017F}

This is the schema that I had created:

If I look at the documentation on Z Segment creation I see this:

Type the name of the field, starting the name with the first three digits of the segment name, followed by a period and the number of the field, followed by an underscore and then a short description of the field. The description should be one or a series of words, without spaces, with the first letter of each word capitalized. Press Enter.

…

To create a field with components, create the field as a record, and then create a child element of that record for each component. To create a field with subcomponents, create the field and components as records, and the subcomponents as child elements. Note that subcomponents cannot be composite data types. For example, for the segment named ZPP_PatientPreferencesSegment, you might create a ZPP.1_Dietary field and a PD.1 Allergies component with a PD.1.1_FoodGroupAllergy subcomponent. The PD.1.1_FoodGroupAllergy subcomponent would have to be a simple data type.

So this is a special behavior for the Z Segments, where you MUST use the period instead of the underscore if the first character is a number, notice the difference between two segments:

Error happened in body during parsing
Error # 1
Segment Id: GT1_Guarantor
Sequence Number: 1
Field Number: 51
Error Number: 102
Error Description: Data type error
Encoding System: HL7nnnn

The data looks like this:

|^NOT EMPLOYED|

The first sub element needs to be set to a max of 0 instead of blank (default 1)

As I discover other fixes I will update this entry…

Make sure that your host is running under 32bit mode, if it is running in 64 bit mode, you will get this error.

“Import/Copy failed as there are active/pending batches. Stop active/pending batches and try importing/copying. (Microsoft.BizTalk.Edi.PartnerAgreementManager)

I was deploying a lot of pipeline components and by simply stopping the BizTalk service(s), it installed successfully.

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.

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:

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

Create the Host Instance:

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

Which ends up looking like this:

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

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.