Interfaces for EDI 850 & 855 Messages

This is the PilotFish eiConsole. It’s the developer’s workstation that you use to build, test, maintain and deploy all of your integration interfaces. We’re looking at the supply chain EDI route – doing some purchase order ingestion (EDI 850 & EDI 855). 

EDI Message Processing Overview

The PilotFish integration model uses a common model for mapping. We have our source systems on the left, each row represents a place for getting data “from”.  Our target systems are on the right, each row represents a place that we’re sending data “to”. Then no matter how many source and target systems we have, the data goes through the same assembly line process – where it’s ingested by the listener, transformed, routed to any number of target systems and then finally sent on to its final destination. For this route here, since we’re doing some purchase order ingestion, we’re taking in some EDI by an FTP here.  Then we’re using our processor stage here to do some asymmetric PGP decryption along with some conditional execution.  (Learn more about EDI data mapping with PilotFish software.)

EDI Message Transformation

Next, we move into the source transform stage.  At the transform stage, we’re taking our raw EDI and turning it into this XML format that we’re going to use in the rest of our mappings. PilotFish uses a common model to mapping and we use XML as our canonical for all of our underlying data transformation. We do this in a two-part process. 

First, we’re using a transformation module to take our raw EDI and convert it into XML.  Along the way, we’re also adding some human-readable friendly names and some segment indexing. The second half of our source transform is a logical mapping. This is an XML to XML map and we’ll be using our data mapper which we’ll look at quickly here.  

This is our 3-pane graphical drag-and-drop mapping tool.  We have our source format on the left (our incoming expected XML structure) and we have our target format on the right (the XML structure that we’re trying to produce). You drag & drop into the center pane here, using the tools palette from the top to build your mapping. 

EDI Validation

Since we’re just doing some EDI validation, we’re not altering our structure in any way.  All we’re doing is validating our CTT elements. We’re making sure that the count of our P01’s equals that CTT by checking that our line items all equal to our total. If they don’t match, then we’re reverse spitting out this validation element.  We’re actually adding on to our XML structure here if we have a mismatch – which we will then use later in our validation steps. 

Routing EDI Messages

Next, we move into the routing stage. In this stage, we’ve got some routing rules set up – this is the primary way of sending a certain message to any subset of target systems. For example – here, I have this rule that I’ve assembled to say if my BEG07 equals AC, then my receiver requests an acknowledgment. Then I’ll go ahead and send the message to my EDI 855 creation route. In all cases, I want to go ahead and update my database. 

Updating Database with EDI Transactions

Moving into our target systems – since we’re updating a database, we’re using an SQLXML. We’ll do another transform here to produce some SQL statements that our database transport will then run. Here on our second target transform, this is where we’re actually producing an EDI 855 (Purchase Order Acknowledgment). We’re using the data mapper to take our EDI 850 (Purchase Order) and take that information that’s required to produce this EDI 855. Again, we are using our data mapper and then using our EDI transformation module to produce that final EDI transaction. So let’s see it in action.

Testing EDI Interface

We’ll switch over here to testing mode. I’ll feed in this sample EDI 850 file that I have, hit “execute test” and we’ll see the data move through the system. We get green checkmarks for all successes and red X’s for any failures. Here we can look at our EDI transformation module and see that EDI transformed into that XML structure.

Next, going through our validation route, we see that we haven’t changed that structure at all. And since it looks like our line-item total matches up with our baseline data, we haven’t added any validation there. Next, moving into our target side, we’re taking that EDI 850 and producing our EDI 855 – using our EDI transformation module to produce that final EDI 855 message to send back to our caller. Then, on the transport side, we see that our database insert was successful – but it looks like we had a failure down here on our RESTful endpoint, probably because our sender wasn’t ready to receive our response. 

It’s just that easy using the PilotFish eiConsole.  In just a few short steps, we were able to put together this purchase order ingestion workflow, taking in some EDI 850 data, doing some EDI validation, then updating a database and sending back an EDI 855 purchase order acknowledgment response to our caller. 

I hope you’ve enjoyed this video, thank you.

Try It!

Download a Free 90-day trial of the eiConsole for EDI X12 and test it out for yourself or learn more about the powerful eiConsole for EDI X12.

 

X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.