You’ll hear it said that BizTalk provides 'native functionality' for EDI (Electronic Document Interchange). BizTalk is built directly into the product, not an add-in, so we at MethodFactory rate this statement mostly true. EDI formats are extremely complex, and though BizTalk parses the data for you, anyone who has seen how much information is contained in one small EDI message would wonder how much a general implementation can do with the EDI material. So if you are considering using BizTalk for EDI, do not assume that the native functionality requires no additional work on your part.
One thing BizTalk does with EDI that seems small at first, but is really huge, is to help you specify which businesses you will be communicating with, what their EDI identifiers are, and which version of EDI you and your partner will use. In BizTalk lingo, these key pieces of data are managed as Parties and Agreements. It’s very simple to specify these settings. If you need to replicate these settings between environments or for multiple businesses, BizTalk provides a quick export and import featureset that makes this task easier. Another advantage of BizTalk is that you are protected from non-approved businesses sending messages to your system. If an EDI message does not contain the correct identifiers, BizTalk will reject the message. Also, if the EDI message is good, BizTalk automatically sends an acknowledgement in EDI format. For the techies among you, this message is referred to as a 997. Similarly, if the EDI format is bad, BizTalk automatically rejects the message.
Another feature of BizTalk is the ability to “read” data from the EDI message, and store that data in memory for use during processing later. As with any message, “later” means, “every potential processing point after the message is received.” These pieces of data are then available to BizTalk for decision making, while receiving or sending messages to and from other systems, or when processing them with its own features.
But as with any software written for general use, there is still work that needs to be done for a specific implementation. BizTalk takes an EDI message and transforms (or maps) the data into a generic form, known as an xml message, with data names that are similar to those of the EDI Specification. BizTalk provides the schema for each EDI message type and version for use in your application. The schema can then be used by an application component to identify where a piece of data is in the message and therefore can be used to move the data into application memory or use it for processing, or store the data it finds into a database.
In addition to EDI, BizTalk provides support for communicating EDI messages using a security protocol named AS2 over the internet. When using AS2 with BizTalk there are additional configuration steps that require exchanging Encryption Certificates generated at each computer involved in the communication (one for your server, one for you partners server). BizTalk will use these certificates with AS2 to ‘Sign’ and ‘Encrypt’ messages used between you and your business partner. BizTalk and AS2 even support compression so that a document appears smaller during transmission.
Why would you go to all this trouble?
- Point to Point Security - You know a message came from a trusted partner.
- Transmission Security - While data is in transit, you want it encrypted in a way that makes it hard (practically impossible) for anyone but you and your partner to read the message.
- Consistent Format - Rather than making up a standard format for each trading partner, you want to use the same format for a message type with every trading partner, you adopt a message standard like EDI or EDIFACT.
- Flexibility - Once a message is agreed to by you and your business partner, you want the flexibility to process it according to your own rules and maybe even different rules for different partners.
The BizTalk EDI Framework provides you with:
- Message Format
MethodFactory recommends BizTalk EDI/EDIFACT for those companies that need a solid start in exchanging information with trading partners in a standard way.