While helping with functional test automation deployments at two different health insurance providers, I discovered some commonalities in their challenges stemming from EDI data:
- Most EDI workflows are kicked off from an actual file drop. It is challenging to simulate that file drop
- 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
- Driving EDI messages with data is necessary. It can become overly complicated, especially when managing hierarchy and data types
I'll dig into these challenges that testers face when working with EDI and show 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 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 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 way 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) drive the requests and responses with data. (This was both when sending a request and ultimately validating the response.)
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.
Let's go step-by-step through the workflow we put in place to solve this challenge so that you can do it too.
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 dropdowns. 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 the 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 to 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.