Oct 112006
 

 

A recent post in the BizTalk forum, order promted this entry.

The question was asked how you can put the MessageID into a dynamic send port. I suggested that you would put a rule SendPort(Microsoft.XLANGs.BaseTypes.Address)=@”file://c:”+DocumentMsg(BTS.MessageID)+”.xml”;
The next post was telling that you can put the macro in the Expression, story which is true, pharm you can, but in the below demo, it shows why it would be preferable not to use the macros.
I created a simple orchestration that shows both ways, here is the orchestration:
MessageID2.JPG

Here is the expression rule:

Here is the results of running the file through the orchestration:

MessageID5.JPG

In HAT, which is where I think that the real value of which method you use lies, here is the message flow, notice the filename is right in the first page of the message flow for the first outbound message, and the macro %MessageID% is found on the second message:

MessageID3.JPG

The message that uses the macro, you have to click on the link to see the actual message ID of what was saved.

MessageID4.JPG

Again, here is the output:
MessageID5.JPG
At a recent client site, I used the macro initially, but then moved to the BTS.MessageID to ease in troubleshooting. Saving a couple of clicks when attempting to find the file really adds up after a while.

Oct 102006
 

 

Here is a list of the behaviors that I have found when using the custom pipeline component vs the adapter for receiving and sending data:

Pipeline

  • Allows multiple recieve ‘locations’ for a single party, search where you define a receive location that has the configuration information and then multiple pick ups and drop offs, order where they can be any adapter (file, order ftp, http, MQ Series, etc.) can be used
  • Ability to use Send Port Groups (archiving is an example of this usage)
  • Does not check the interchange control number for duplication per party
  • Data that is recieved or sent, is not archived in the location defined in the documentshome location in the parame table
  • No information is logged to the audin and audout tables, so the HIPAA_EDI reports in HAT is not available
  • Promoted properties in the WPC schemas are not invoked
  • No ACK is generated for delivery back to client

Adapter

  • Only a single port can be defined for receiving and sending
  • Copies of both edi and xml data is stored in the documentshome location
  • Interchange control number checking is done
  • Information is stored in the audin and audout tables, so the HIPAA_EDI reports are accessable
  • Using the DefaultXML pipelines; promoted properties can be used for correllation/filtering/orchestration usage

I have put together a really simple example of both usages, so differences can be seen.

Instructions:

  1. Deploy the Solution
  2. Using the Deployment wizard, import the Binding.xml file
  3. In the Management Console, in the HIPAA_EDI adapter, in the properties of the Send Handler, set the the Party to Us
    HIPAAConfig1.JPG
    HIPAAConfig2.JPG
  4. Restart the HIPAA service
  5. Enable the Receive Locations
  6. Start the Send Port
  7. Drop the file into the ..input directory and see if the file is produced in the ..output directory
  8. Notice the following information in HAT – HIPAA_EDI Reports