Electronic Data Interchange (EDI) is the most common way to exchange data between business entities. EDI communication is based on specific message syntax, standards, messaging protocol and communication mechanisms. The EDI solutions are more centric on message processing and transformation and less on Application or User workflows. Here are a few tips to design, architect and manage EDI integration projects better:
Use Canonical Schema
Always use separate External and Internal Schemas. Transform incoming messages to Canonical Format and then use Canonical messages for all processing within BizTalk. On the way out, convert Canonical message to External message format. This makes your internal implementation independent from external schemas revisions (decoupling) and can reduce the number of maps for transformations between incoming and outgoing messages.
Client specific Receive and Send Ports
Always use separate set of Receive and Send Port for each client. Client specific Maps can be applied on Receive Ports to convert incoming messages from External to Canonical format. Similarly Maps on Send port can be used to transform from Canonical to External format. Separate Receive ports also allows to disable message processing from a specific client as well as we can have specific client specific pipeline configurations. This approach provides high performance message transformation due to no message box roundtrips (which are required if you implement as Orchestration)
Use Built in AS2/EDI Status Reporting
Party Configuration in BizTalk Administration Console provides out of the box EDI/AS2 reporting which is quite useful to track EDI messages received, processed and Acknowledged. After enabling EDI or AS2 status reports in Party configuration, you can view status report from the EDI Status Reports or EDIINT Status Reports section in the BizTalk Server Administration Console. Five different EDI and AS2 status reports are available ( Types of EDI and AS2 Status Reports)
Centralized Audit and Logging
One of the biggest challenges in integrated environments is the lack of end to end visibility of data as it passes through applications. When designing make sure all systems are providing visibility of key input/output data. Ideally this should be presented in a common logging format that can then be consolidated to paint a consistent picture. ESB Exception Handling framework provides a standardized approach for detecting and handling exceptions that occur in the BizTalk Server environment. Raw EDI messages received from external parties can be logged through EDI Status reporting or using third party BizTalk Archiving component
Review and Resubmission
Message Review and submission capabilities are driven from the business requirement and often required in complex EDI scenario where a message can be corrected and resubmitted for processing by a User . A custom implementation can be done with InfoPath forms in SharePoint for message Review, Correction and Resubmission.
Business Activity Monitoring (BAM) captures business data and process milestones and allows business decision makers and IT support staff to gain insight of EDI processes. Without BAM, sometimes it becomes tricky for a support guy to figure out current state of an EDI process and reason of message processing failure.
Disable Fallback Settings
Fallback settings in Party configuration applies to both X12 and EDIFACT-encoded message and these properties apply only when BizTalk Server has not determined the agreement to which an incoming our outgoing message resolves to. Although Fallback settings serves as a general exception handler for agreement resolution failure, sometimes it may have unintended consequences like message routed to some other application deployed on the same server and there would be no suspended messages to indicate agreement resolution failure. Disabling fallback settings will generate a suspended message on party agreement resolution failure and it will alerts support staff to fix the issue with incoming messages
Written by Usman Shaheen