The Dataweave language provides MuleSoft users with the ability to quickly transform data either through a graphical interface or using a JSON-like language. Both methods are intended to simplify the mapping and transformation of data.
One of the powerful features of Dataweave is the Preview feature. If you set up a sample message in Dataweave, you can visually verify the output as you build the map, making it much easier to iterate to the full solution.
However, because the EDI Modules are not natively supported in Dataweave, you need to put an EDI module (X12, EDIFACT, HL7, etc.) operation shape in front of the Transform shape in order to parse the raw EDI sample message into the Java Hashmap representation of EDI. Then you can map from the Java structure to the target format. This works fine, but instead of using the Preview feature, you have to execute this flow repeatedly as you iterate your Dataweave mapping code, which can be quite cumbersome.
It turns out, however, there is a trick that you can use get back all the goodness of Preview for EDI documents.
In today’s post, we’ll focus on using Dataweave to help you transform from EDI X12 to JSON, using a purchase order – EDI 850 – as our example.
Convert EDI message to JSON
We’ve included a sample EDI 850 message below for you to use so that you can see the results of our outlined steps as you work through the example.
The “trick” is to create a JSON message mirroring the Java Hashmap format the EDI Module produces, and use this JSON structure as a surrogate in the Dataweave transformations.
Create the Flow
Start by creating a flow to receive an EDI 850 message and parse it using “Transform Message”.
Next, configure the “X12 EDI” connector with the receiver/sender ID/Qualifiers.
Now configure the object reference with the EDI message and the corresponding version.
Dataweave
In order to simply convert the EDI 850 Java Hashmap into a JSON format, we don’t need a complex Dataweave script. Just change the output to JSON and put ‘payload’ as the script, causing the entire Java Hashmap message to be converted into JSON.
(Note: this interim JSON format that mirrors the Java Hashmap representation of an EDI message is usually not the same as the target JSON format you are mapping to, which should be more of a clean “canonical” or “domain driven” model of a purchase order.)
Run the Mule application and post the EDI message thru Postman to get the message converted to JSON.
This output JSON can be used as the sample data input for the transformation.
Using this sample message, let’s create the actual transformation. We’ll use the same flow created at the beginning of this tutorial and update the transformation.
EDI Transformation
Set the Metadata
Begin by clicking on transform message, then go to properties.
On the left-hand side, right click on Payload: Unknown, and then choose Set Metadata. Select the metadata type and then choose the TransactionSets under “InMessage”. Click “Select”.
This defines the metadata of the input message to transform. Now let’s add the sample data for the input message.
Copy the JSON output generated from the previous step (from Postman) and add that to the transform: on the left-hand side, right click on Payload: InMessage and choose ‘Edit Sample Data’, then paste the JSON message in the payload tab.
Now we can write the transformation. We’ll be able to see the output instantly in the Preview section as we evolve our mapping code.
In addition to enabling the Preview feature for EDI messages, this trick has another advantage (and a couple caveats).
It streamlines the list of EDI segments and data elements you need to sort through in building the mapp. EDI documents tend to have exhaustive lists of segment types as the “standard” needs to cover a wide breadth of use cases. This can make it overwhelming as you go through the exhaustive list looking for the segments and data elements you actually need.
By generating the JSON from your sample EDI input message, you are limiting the segments and data elements to the ones actually used by your partner, which greatly simplifies the mapping process. The only caveats are: 1) be sure your sample message is truly representative of all the segments actually needed by the partner, and 2) be aware that Java date formats don’t always translate into JSON accurately, so you may need to do final testing by running the flow and ensuring your dates are translated correctly.
Sample EDI 850 Message:
ISA|00| |00| |11|9876543210 |01|123456789012 |170918|1207|U|00401|990000001|0|P|>~
GS|PO|9876543210|123456789012|20170918|1207|2|X|004010~
ST|850|0001~
BEG|00|NE|100093638||20170918~
REF|KY|MTWRF 8-430~
N1|BS|XYZ Exports|21|K32EWRQ00~
N1|SU||21|033470838~
PO1|1|24|EA|12400||N4|75987007009~
PO1|2|500|EA|4160.25||N4|75987005006~
CTT|2~
SE|9|0001~
GE|1|2~
IEA|1|990000001~
Getting “fatal transaction error, transaction not defined in schema’ at segment 1 (ST) of transaction 0001 in group 0 of interchange 190” while trying to parse 852 request using x12 latest connector in mule 4. Either you refer the proper version of schema or dont refer any schema, its coming for both the cases.
Please help me out.