What is EDI & How to Manage Complex, Hierarchical Data

While helping with functional test automation deployments at two different health insurance providers, I discovered some commonalities in their challenges stemming from EDI data:

1. Most EDI workflows are kicked off from an actual file drop. It is challenging to simulate that file drop.
2. A single interchange can be a combination of Dialect, Version, and Message type. Generating a message that conforms to that specific schema can be tedious.
3. Driving EDI messages with data is necessary. It can become overly complicated, especially when managing hierarchy and data types.

In this blog post, I’ll dig into these challenges that testers face when working with EDI, and how you can start to solve them with automated testing.

Electronic Data Interchange (EDI)

First, let’s go back to the basics. EDI is a message format standard used to communicate business information between business entities. Businesses used to use paper for these transactions (i.e. purchase orders, invoices, or in the healthcare industry, for instance, enrollment forms), which was extremely complicated and prone to error:

To improve on the process, EDI was designed to standardize communications and make a “paperless exchange:”
Unfortunately, although EDI improved the process by allowing companies to send information electronically rather than with paper, EDI also brought along its own challenges. Recently, I’ve been able to help people solve these problems using our software testing tools, and I’m excited to share the solution with you too.

Managing Data (Easily!) During EDI Testing

At these recent healthcare deployments, I was working with organizations that were using HIPAA standard message definitions to generate 834 files as both requests and responses. These payloads are fixed length and can be very complex.

For both teams, they needed to send and receive files for testing. Since they didn’t have a way to drive the actual EDI message into the system, they have to use physical files. They would receive an email that had the definition of the file, drop that file into the exchange folder, and then manually validate the results that came back. The data was pre-created and put into the proper format in the file, but they didn’t have an easy to alter it. It was extremely difficult to get the appropriate data into the system and drive the validations with the same data source.

Improving the EDI Workflow

In these deployments, I added Parasoft SOAtest and Virtualize to their workflows, which, through message packs, could provide a library of such definitions that could be generated on the fly. This way, both teams were able to generate the necessary messages and (more importantly) data-drive the requests and responses. (This was both when sending a request and ultimately validating the response.)

Want to check out Parasoft Virtualize? Try our free community edition.

Using SOAtest and Virtualize, we also improved how they were dealing with hierarchical EDI. The data repository seamlessly handles hierarchical data, and this allowed them to create very easy-to-interact-with data structures that could be used for both requests and validations. I imagine anyone who is using EDI with File data sources immediately understands why this was so exciting for my customers.

So now let’s go step by step through the workflow we put in place to solve this challenge, so you can do it too.

Here’s how you do it: Using SOAtest and Virtualize to make it easier to work with EDI messages

We started with the included EDI message schema for an 834 file.

Employing SOAtest makes it easier to work with EDI because SOAtest contains a library of these messages built in, and you simply choose the message Dialect, Version and Type from drop downs. Your payload instantly shows up and is ready to drive with data. Next, I can fill in a few values for the default message.  These can be the data values that I know will not change.

Then I can instantly create a Hierarchical Data source for the payload directly from the Editor, and I don’t need to worry about mapping my response elements to my payload, as it is all done automatically. This will generate a data source for me that is easy to work with.

Once that data source is created, I can add, remove, and alter the data just as easily as if I were working with a spreadsheet. The data is represented in Virtualize’s thin client interface – here is what the data editor looks like in the Test Data Manager:

And there you have it: the seamless workflow to take you from EDI definition to intuitive data source.

For my recent deployments, this has been a big headache out of the way, allowing teams to get to the validation pieces that they traditionally struggled with. They could easily add new use cases into the data source and drive validations from them.

Additionally, we were able to send the calls directly into the system using http, but simulate the actual file drop, by transforming the output to a file, placing the form in the proper folder, and setting up the file listener to receive the response.

And Voila! Automated EDI File Processing

And there you have it. Having a functional testing tool that works for you instead of against you can make a huge difference when you have a complex message format or protocol to contend with. When we deploy Parasoft SOAtest & Virtualize, it takes the guesswork out of working with complex, legacy, or uncommon use cases, and all the test cases and simulated services you create with EDI messages seamlessly fit into your existing test design paradigms, saving you a ton of time.

Using EDI or a different industry-specific message format? Get key insights on testing transactions involving EDIFACT, HL7, HIPAA, X12 and other message formats.