Like

Welcome On Mobius

Mobius was created by professionnal coders and passionate people.

We made all the best only for you, to enjoy great features and design quality. Mobius was build in order to reach a pixel perfect layout.

Mobius includes exclusive features such as the Themeone Slider, Themeone Shorcode Generator and Mobius Grid Generator.

Our Skills

WordPress90%
Design/Graphics75%
HTML/CSS/jQuery100%
Support/Updates80%

Best practices for BizTalk EDI solutions

By Usman Shaheen 6 years ago

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.  

BAM Reporting

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

Category:
  Biztalk
this post was shared 0 times
 000
About

 Usman Shaheen

  (10 articles)

Usman Shaheen is a Partner in Allied Consultants and an Integration Consultant with more than 17 years of experience in a wide variety of scenarios such as custom .NET solution development, large enterprise integrations, designing and building API's and cloud solutions, SQL Server and PowerBI consulting with his domain knowledge in retail, utility, banking, healthcare and manufacturing.