EDI Scheduling and File Transfer Best Practices

The following is an extract from the EDI Fundamentals & Best Practices training course offered by The EDI Academy (https://ediacademy.com/). This small extract is just one element of the whole course and should not be considered as an EDI tutorial.

This article attempts to do three things:

  1. Stress that scheduling in EDI projects should not be taken for granted
  2. Explain the difference of PUSH method vs. PULL Transmissions
  3. Explain event-driven scheduling
  4. Explain how AS2 is the most natural solution for Event Driven Processing


Scheduling is a critical success factor:

Unless an organization is starting jobs using an adhoc method, scheduling plays a major role in EDI implementations. Scheduling during EDI projects is unfortunately very often taken for granted. However, very frequently a lot of EDI jobs error out in their first few weeks of production because enough thought does not go into the scheduling process.

Common Scheduling Pitfalls/Solutions:

The consequences of the following pitfalls are hours wasted for un-necessary troubleshooting and most importantly the cost of business-to-business transaction delay. Also, in the retail EDI industry this could be a major root cause of chargebacks that end up costing thousands of dollars to due to a scheduling oversight that could have been prevented.


PUSH vs. PULL Transmissions:

Data transmission method PULL vs. PUSH should be carefully taken into consideration for protocol design. The decision will have implications on security and usability.

PULL: The pull method is when an organization decides for example to initiate an FTP connection to the trading partner's server or a VAN to download the transaction and process it.


PUSH: The push method is when an organization decides for example to initiate an FTP connection to the trading partner's server or the VAN and push the data instead of pulling it. The most successful method of implementing this is when both trading partners use the PUSH-PUSH method.


Event-Driven Scheduling:

Event-driven scheduling happens when jobs are triggered by an event, for example on data arrival or even a record update in a database.

One of the easiest ways to accomplish event-driven scheduling is by using the push-push method between by both the sending and receiving parties. In this method trading partners do not schedule jobs for the transmission of the data. They set up host servers and push data do each other as soon as the data becomes available. There are many communication gateway tools that specialize in what's called Managed File Transfer (MFT) that can make this process easier to implement.

For example, consider the following scenarios to easily tell apart Event-Driven scheduling vs Batched Scheduled Jobs:


AS2: The most natural solution for Event Driven Processing:

A separate article can be done AS2 alone, so this section does not attempt to define what AS2 is.

If a company has ever chosen to implement to AS2 (or AS1/AS3) as the protocol of choice for data transmission they have automatically signed up for a PUSH-PUSH method. In order for AS2 to work both parties must have AS2 software installed and installing AS2 automatically makes the machine that it is installed on a web-server.

When trading partners are ready to exchange data they do AS2 HTTPS posts of the data. The data is pushed to the trading partner's AS2 web-server for processing. AS2 is usually tightly integrated with the EDI translation software so the arrival of the data immediately triggers the translation jobs.

AS2 also makes the operations and the monitoring process simpler with MDNs. MDN stands for Message Disposition Notification. Typically trading partners will want some kind of confirmation that the data transmitted was indeed successfully sent. Upon the receipt of the data and successful signature or decryption validation an MDN message is sent to the sender for confirmation. This MDN message can be sent back via HTTP/HTTPS immediately via AS2 w/ "Sync" MDNs or at a later time via AS2 w/ "ASync" MDNs. The MDN option maybe turned off if trading partners agree that no such confirmation is required. Also, the MDN maybe sent back via EMAIL which is very rare.