Streamlining EDI 850 to 855 Processing with Mapping, Validation and Testing

Yes. The interface pattern shown here applies broadly to X12 EDI processing, including additional supply chain transactions as required by your partners. PilotFish is an X12 Partner.

They are typically implemented as processors early in the route, immediately after ingestion, so the rest of the workflow operates on decrypted content.

No. In the demo, validation checks totals like CTT and only enriches the XML when a mismatch is detected, so you can act on exceptions without rewriting the message.

Use the Data Mapper to map required values into the target XML structure, then convert that structure back into EDI using the transformation module.

Switch to testing mode, execute with a sample EDI 850 file, review pass/fail indicators and inspect transformation outputs at each stage.

Yes. PilotFish is optimized for Docker deployments, which supports consistent promotion across environments.

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 take our raw EDI and turn it into XML format that we’ll use in the rest of our mappings. PilotFish uses a common mapping model, and we use XML as the canonical format for all of our underlying data transformation. We do this in a two-part process.

First, we’re using a transformation module to convert our raw EDI 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 & 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 P01s 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 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 set up some routing rules, which are 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 the 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 to testing mode. I’ll feed in this sample EDI 850 file that I have hit “execute the test,” and see the data move through the system. We get green checkmarks for all successes and red Xs 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 to 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.

Using the PilotFish eiConsole is just that easy. 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, 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.