Sep 302008
 

This seems to be a big complaint, there are many companies that would like to have access to the envelope information in the map. There are a few VERY KLUDGY ways of getting data from the message into the map. All of them are VERY BRITTLE. The EDI logger now will create an additional message part called ‘envelope’ and send it to the message box.

If you are familiar with the multi part message that the BTAHL7 accelerator creates, this will be a breeze. For those of you not in the provider world, I will walk through the instructions on how to create a process to access the envelope information (you will see that there is a LOT more than just the envelope information).

To start off with, there are now two message parts to the message that shows up in the message box. The body part is the transaction itself (so you can still use the message in a send port map if necessary).

Here is a screen shot of the multi part message:

MultiPartEnvelope

The schema that is deployed to the GAC that you can reference (C:\WINDOWS\assembly\GAC_MSIL\EDIArchiveProperties\1.0.0.0__e7dd178931a8d66e\EDIArchiveProperties.dll) in your project that will host your orchestration has this structure (click to enlarge):

ContextDataSchema

I normally create at least two different projects for each solution. One that represents the schemas, and the other that represents the mapping/orchestrations. For simplicities sake, I have called the schema project Schemas, and the location that I am going to put my maps and orchestrations will be called Logic. Here is a snapshot of the Solution Explorer:

SolutionExplorer1

I added the reference to the EDIArchiveProperties by adding a reference and pasting the dll mentioned above:

AddReference

 

Let’s create an orchestration, here you will want to create a multi-part message, making sure you define the body segment first and then the envelope segment second (click to enlarge):

MultiPartMessage

Next you will create the necessary port and message from this multi-part message. I will jump to the creation of the map. You have a message defined from this multi-part type and you are mapping it to an output. You open up the map configuration dialog window and you fill in two lines, one that represents the envelope and the other that represents the EDI transaction on the input and the output message on the destination window.

MapDialog1

MapDialog2

And when pressing <OK>, this is the map that is created (click to enlarge), notice that the transaction is at the bottom of the source:

Map

 

This allows you to access both the envelope and context data for that transaction, giving you the ability to map everything that would need to without going through a unnecessary hoops to get data injected into the message.

For pricing on this component, please refer to our services page.

Sep 302008
 

By popular demand I have made some significant changes to the EDI logger. None I don’t think are more important than the rest, but some do address a REAL thorn in a lot of peoples sides. I will get to that in the next entry about the change to the message. This one deals with the pipeline itself. Below is a picture of the receive pipeline configuration:

Receive Pipeline Configuration

The send pipeline configuration:

Send Pipeline Configuration

And the following table on how to configure the values:

Row Type Meaning
Database string BAM Database to store data
Server string BAM Server to store data
Active boolean Activates the logging mechanism, if not, it is simply a pass thru pipeline component
Count1 string Either XPath or Regex.Match (string count)
Count2 string Either XPath or Regex.Match (string count)
Count3 string Either XPath or Regex.Match (string count)
FromAddress string email address representing BizTalk as source
FromName string Friendly Name representing FromAddress (ex: BizTalk Prod biztalkprod@company.com)
Notify boolean Activate flag for email notification
NotifyOnlyOnError boolean Only send out email if there are validation errors
SMTPHost string SMTP Host address
Secure boolean True: Do not include ISA01/02/03/04 as components to be used
False: Include ISA01/02/03/04 as components to be used
SubjectLine string Macros and regular text to create customized email subject line
ToAddress string Allows multiple email addresses to be included in email notification (semicolon separates email addresses)
Sep 242008
 

To give the ability to customize the subject line in the new email component of the EDI logger, you can use following macros:

Macro Description
%ISA01% ISA01 Value
%ISA02% ISA02 Value
%ISA03% ISA03 Value
%ISA04% ISA04 Value
%ISA05% ISA05 Value
%ISA06% ISA06 Value
%ISA07% ISA07 Value
%ISA08% ISA08 Value
%ISA09% ISA09 Value
%ISA10% ISA10 Value
%ISA11% ISA11 Value
%ISA12% ISA12 Value
%ISA13% ISA13 Value
%ISA14% ISA14 Value
%ISA15% ISA15 Value
%GS01% GS01 Value
%GS02% GS02 Value
%GS03% GS03 Value
%GS04% GS04 Value
%GS05% GS05 Value
%GS06% GS06 Value
%GS07% GS07 Value
%GS08% GS08 Value
Other Values Description
%Adapter Type% Adapter Type of receive transmission
%Received Filename% Received ftp or file name
%AdapterReceive Completed Time% When file was picked up
%Port Name% Port Name of receive location
%Inbound Transport Type% Inbound Transport Type
%Receive Location Name% Receive Location Name
%Message Type% Message Type (http://namspace#rootelement)
%ISA Segment% Entire ISA Segment (beware that private information might be displayed)
%GS Segment% Entire GS segment
%Party Name% Party Name
%Transaction% Transaction
%Transmission ID% ID that represents entire transmission
%Error Flag% ‘Yes’ or ‘No’ – if there were validation errors or not
%Count 1 Query% Entire text contained in the Count 1 pipeline field
%Count 1% Actual value of query 1
%Count 2 Query% Entire text contained in the Count 2 pipeline field
%Count 2% Actual value of query 2
%Count 3 Query% Entire text contained in the Count 3 pipeline field
%Count 3% Actual value of query 3
%Error Description% Entire error description
%FileGUID% Unique ID representing this transaction
%Inbound Transport Location% Pickup Location

Which will create an email that looks like this:

EDILoggerSampleEmail

Aug 192008
 

In the initial entry, cialis and the follow up entry, view I showed the table/view structure of the components that I built.

Here are some examples of what is available so you can see the real values for each transaction reported.

Here are the settings for the pipeline configuration: (notice I am tracking 3 different objects in the data, pill so I can monitor these values through the flow of the data so I have a point of reference as far as counts)

edireport0

Because the table is so large, I am going to break it into chunks:

ediReportingView

 

edireport1
edireport2
edireport3
edireport4
edireport5
edireport6
edireport7
Jun 182008
 

I finally was able to start working with BizTalk R2, and we do HIPAA/EDI. Within hours of ‘playing’ with it, I was SHOCKED! How did this get out the door?! Who signed off saying this solves anyone’s EDI integration problems?

Okay — so you are right — it allows the EDI shop to be able to handle eleventeen million different transactions out of the box, yes that is cool, and actually quite useful.

However, the part that keeps me up at night is not: “how am I going to translate this transaction?” but “what happened to this file yesterday, or the other file two weeks ago?”

I had gone to plenty of MS conferences where during the beta bits were shown and the reporting was going to be done using BAM, “cool” I thought, if MS is going down the BAM trail, I should too, so my whole paradigm of reporting changed and now I am an even bigger proponent of BAM.

Once I started playing with the R2 bits, maybe hour two, I was scratching my head, where was all of this famed reporting?

Let me not bore you too much with what R2 has for reporting, I will bullet list the things I required that are not present in the current reporting architecture

Error information in a repository that associated the file with the error

I am not a big fan of reading through the event log to try to find the message that failed and then equally tasking process of finding the event log entry that actually tells me what the error actually is. Even MS was not correct when they stated that the BizTalk 2006 Server message id error and the corresponding BizTalk Server 2006 EDI error are paired together:

ediErrors

 

Being able to associate the TA1/997 to the original message.

Yes, I know that there is a column in the BAM tables to associate it, but it is not used! The only suggestion was to put a warm and fuzzy query that pulls the control number/sender id/receiver id to associate the original message to the corresponding acknowledgment. This did not work for me, as I test like crazy, throwing the same file at a process eleventeen million times a time before I a satisfied, and there isn’t a great way to pair up the values programmatically.

AckCorrelationId

interchangeAckId

 

Finding the original filename.

I know that in the perfect world, we don’t care about file names, we simply care about sender id/control numbers, etc: but our trading partners are in love with filename, bordering on creepy! When they call up the first thing that they say is “I dropped of ‘ABCDEFG12345.edi’ last Wednesday – I never got an ACK, what happened?” I have never gotten, without pulling out my crowbar; what their id is, and the control number.

Ability to see the entire EDI on both the receive and send side.

The transaction (that is stored deep in the DTADb database) doesn’t help me if I have a hard time associating it with it’s entire interchange.

 

What I did:

I wrote a little email to Steve Ballmer that got some people calling me to assist on an issue where if I wanted to reject an entire EDI interchange if any transaction was in error. It was/still is pretty hard to get a non documented feature limitation corrected. I decided that I had fought my battles and was not going to do it again, so I wrote some of my own components:

MY NEW EDI REPORTING

I have a separate datastore that is located on the same database as the BAMPrimaryImport (yes I know I shouldn’t) it is SQL 2005 so I can store quite a large amount of data in the following table:

ediRepository

The other things I wanted to log was all of the context properties that are part of the message (and some that aren’t). Here is a snapshot of the view that takes all that will need to know when a trading partner calls up:

ediData

Some notes, I have been testing with 50mb – 100mb files and the view was coming up pretty slowly, so I limited what is shown  in the last column is limited in the view to 2500 bytes, and added the Archive Interchange Id so if you need to look at the whole interchange you can run a query against the EDI_Repository.

To get all of this data to show up, I created a couple of pipeline components:

Receive Pipeline

receiveEDIPipeline

Which you have the following pipeline properties to set when you define your receive location:

receivePipelineConfig

And for our outbound EDI data:

Send Pipeline

sendPipeline

Which you have the following pipeline properties to set when you define your send port:

sendPipelineConfig

You have should specify the database and server, if it can’t find one that is associated with them message (if it wasn’t already attached from the receive side (an automatically generated 997/TA1 for example)) then it will put it in the database you specify.

This is only geared to ANSI X12 transactions, including HIPAA transactions, I have not tested it for UN/EDIFACT.

If you are interested in having this, refer to the services page.