I have switched to two new blogs that represent more of what this blog is about:

http://blog.biztalk-info.com - my problems and concurrent resolutions on general BizTalk and other general BizTalk related issues.

http://blog.hl7-info.com - ditto, except for it is just HL7 stuff

See you there…

I just want to try the Live Writter to see if it makes my blogging easier.

I downloaded it from here.

It seems pretty easy, actually much easier than the admin tool that I normally have to use to make the entries. Not bad, it is even using the CSS that the site has. I am actually kind of impressed.

There are certain cases where a sending application will not send the ending CR as part of the HL7 message.

The HL7 parser will complain at not finding the ending CR, because it continues to look for it past the EB.

The resolution is simply to leave the CR blank in the adapter configuration and the adapter will work as expected.

Gotta tip your hat to the guys at MS for that bit of functionality!

One of the tricks to getting custom file names out of the HIPAA Accelerator is to add an extra component in the orchestration.

These are the steps I took to get a custom filename generated from the HIPAA_EDI adapter.

1. Created a property schema with a element defined as a string and have it be a context property
2. Create an schema with the delimiters that will be defined in the HIPAA_EDI send port with an element that repeats 30 times
3. Create both a flat file send pipeline and receive pipeline using the schema defined in step 2
4. Create a single element and associate this element with the element defined in step 1
5. In the orchestration, assign a variable a time
6. From that assigned time do three things in a message assignment
1. Assign the BHT_05 from the variable 
2. Assign a string variable the date as a string in HHMMSSDD format
3. Assign the message with the context property created in the property schema
7. Create a Correllation Type set to the context property
8. Create a Correllation Set defined from Step 7
9. Initialize the Correlation Set in the send shape
10. Have a recieve shape using the message created in step 2 and have a following correlation set
11. Assign the recieved message to a new message and assign the FILE.ReceivedFileName to whatever you want the filename to be
12. Send the newly created message out
13. Deploy
14. Create a temporary folder that you assign the HIPAA_EDI adapter to write to
15. Assign a recieve location to the the folder created in step 14
16. Use the recieve pipeline created in step 3
17. Create a send port using the pipeline created in step 3
18. In the file name use %SourceFileName%
19. Set the directory to the real directory where the HIPAA file is to be placed
20. Bind the logical ports to their respective physical ports

The experts in Redmond have released a troubleshooting guide that might keep you from doing Google searches so much and accidently finding my site!

A client I have been working at has a very large message (150 mb message) that needs to be passed through BizTalk from the results of a stored procedure.

I was continually getting System.OutofMemoryException in the event log.

I read through this article and also this one both sites options did not appeal to me.

Another option is to use custom XSLT instead of the code inside of the map (which seems to stream the entire message into memory).

The solution is actually very easy:

1. Create your map
2. Inside of the mapper, create all of your links, functiods and everything
3. Validate the map
4. Take the XSLT that is generated and add it to your project
5. In the mapper grid, point to the xslt (by following these instructions)
6. Deploy it

It does not process the file very quickly, but it does not error, and I get the output.

A co worker asked me how she could take dlls that were developed by a third party and use them in BizTalk; that requires that they be compiled as strong named assemblies (which they weren’t).

This can be done by using the Type Library Importer. An example is here on how to use Tlbimp.exe.

I just attended the first (of I am sure) many HiMSS conferences. I am kicking myself for not going to them sooner. I got to meet a few friends that I have been in contact with, and other fellow bloggers, well I wouldn’t call him just a blogger, but that is another discussion. I also met with some guru’s that offered a lot of insight!

There were great sessions for a whole spectrum of Health Care Professionals, from developers to IT Pros, to management for both the partners and more importantly customers. There were a lot of great things that partners had presented and even more cool things that Microsoft has in store. I did enjoy the other perks that were offered to the attendees, especially the sessionitis I seemed to come down with!

I was very interested in the Connected Health Framework (CHF) and will be blogging about my experiences with my take on best ways to implement the CHF to add additional value to the development life cycle. I don’t think that the CHF is readily available (at least I could not find it), however, as soon as it is published, I will be adding a few entries to my blog.

There are great things going on, and I am glad that I got to be an attendee there. Hopefully I can meet up with you again next time.

I am not sure how many times I have come across this error. I finally had a few moments to actually troubleshoot this error.

The reason for this message is that the orchestration is expecting as the first message part being the MSH segment, whereas it actually finds the BodySegments component. The orchestration then attempts to pick up the message, which is where it errors.

The key to getting this issue resolved is the order that you create the multi-part message.

I know I have made this mistake multiple times, I create the multi-part message type, and renamed the MessagePart_1 to BodySegments, since the IsBodyPart property was already set to true, I then would create the MSHSegment and ZSegments.

This would cause me headaches because the orchestration picking up the message would create the error.

Looking at the code, you have to create the message parts in the correct order. In the Type window, you see the parts in alphabetical order.

However, behind the scenes, it remembers the order that it was created. I have the following excerpt of the odx that shows what is going on behind the scenes: The ADT_A02Type is correct, whereas the ADT_A03Type is incorrect.

So make sure that you create the parts in the correct order and you will not have a problem. If they are created in the wrong order, the only solution I have used is to delete the multi-part message and recreate it again.

By the way, this is only an issue on message that are inbound, outbound messages, the pipeline component is intelligent enought to put things together (even if they are defined in the wrong order), it is the orchestration that consumes the message that is finicky.

One question I have been asked often is how to only produce one acknowledgement from within BizTalk. This is a common requirement of many HL7 applications, only to recieve one ACK. If there is an error, you want the pipeline component to create the NAK and then send back the NAK, otherwise, you want to create the ACK/NAK (depending on BizTalk logic) that represents whether BizTalk was able to process the correctly formatted HL7 message.

The first thing is to configure the Accelerator to generate the NAK only on errors:

Notice that in HL7 1.3 there is a check mark box for Routing ACKs to send Pipeline. Having this check mark box binds the ack that is generated in the receive pipeline to the original message. (This is the standard behavior in the HL7 1.0 accelerator.) I am leaving this checked so it can be set up simarly in the 2004 version. If this box is not checked, the ACK is not bound to its orignal message and the dependency for both messages to have a destination is broken, so ACK or Messages can find themselves in the Message box with no place to go.

You want to have MSH 15 set to NE (Never) and MSH 16 to ER (Error), so you will only create an application error if there is structural errors. If you set MSH 15 to anything but NE, you will get an ACK of CA and also a possible Application NAK, which normally the sending application is not expecting. So this setting will only cause a possible one NAK to be produced (if there is only an error).

Then you need to configure your orchestration to only accept good HL7 messages. In your receive port, you need to set the following properties:

Where there is a HL7 property to only activate when there are no parse errors. If this is not set, orchestrations will spin up if there are messages that are invalid (the HL7 receive pipeline will drop the bad HL7 message as a text blob and the orchestration will pick it up, and will immediately become suspended).

This is in 1.0 and 1.3, this functionality has been expanded to all BizTalk parsing in 2006 using the ErrorReport… context properties.

The last thing that needs to be done is to set up a port that will drop the HL7 messages off if there is an error. Because we have enabled the ack to be sent on the request-response port, for the NAK to be sent, we need to have a place for the bad HL7 message. I have created a seperate HL7 port using the Default.PassThru pipeline and writing it out at %MessageID%”.txt. The filter I use is the following:

If we do not set up this port, and there is an error parsing the data, the messages (NAK and original HL7 message) get stuck in the Message Box because there is no place for the bad message to go.

Using the Sample ADT^A03.txt and Sample Bad ADT^A03.txt in this solution, you can create a two-way receive port and one Bad HL7 Dump port you can test the configuration and see that only one HL7 ACK/NAK is created. This is a very simple orchestration that creates the HL7 ACK, but it is here in the orchestration is where you would create the MSA 1 ‘AA’ or ‘AE’ depending on your business logic.