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.
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.
Additional X12 EDI Information
For more on PilotFish’s EDI tools and resources, visit our X12 EDI Integration and EDI Parsing and X12 EDI Data Mapping web pages. Also available for more detailed information is our X12 EDI Tools Technical Video Demonstration. Read how PilotFish’s EDI Software improved these companies’ performance and their bottom line. Review our X12 EDI Case Studies for use cases.
Test Drive PilotFish’s eiConsole Integration Engine
We invite you to take advantage of PilotFish’s eiConsole for X12 EDI by downloading a full FREE 90-Day Trial Version. Users can try out our new EDI Transformation Module and Format Builder. With the EDI Quick Start Tutorial, users can complete an end-to-end interface in less than 20 minutes and get a real sense of the ease-of-use of PilotFish’s interface engine solution.
For more information, please call us at 813 864 8662 or click the link below to email us.
X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.