Migrating managed X12 decode to built-in X12 decode in Logic Apps Standard

[praveensri]

A few months ago, Logic Apps team has introduced the preview release of X12 built-in connector, one of the issues that customer encounters during the migration of X12 decode action is X12 decode response is different from the managed X12 connector response. We will attempt to address that problem in this blog post. The built-in X12 connector response adheres to the hierarchical structure defined by X12 standard more accurately.

                                    

Some scenarios make it hard to handle the managed X12 decode response because it has a flat structure where all X12 transactions are either good messages, bad messages (if they fail), or receivedAcks (if there are received acknowledgements).

.

       

This non-hierarchical structure has the following issues which we addressed in built-in X12 decode connector:

1. Repetition of information are copied at each transaction level. these repetition of data are stored at each transaction, had this been hierarchical then we need not store these details at each transaction level. This is required to correlate the transaction with the functional group or interchange set.
   • Agreement
   • Delimiters 
   • Control numbers
   • Interchange
   • Functional group 

   

2. Preserve Interchange scenario where we batch all the transaction XML and functional group XML  into single Interchange XML. In this situation where we combine all the transaction XML and functional group XML into one Interchange XML would have a lot of extra information that is not required. For example,

   The transaction set information is irrelevant and wrong (if there are different kinds of ST 810 or 850 messages in the same GS or ISA).

   "transactionSet": {
                       "sT01": "810",
                       "sT02": "ST02",
                       "sE01": "90",
                       "sE02": "ST02"
                   },
   

3. Generated Acks:

   Each ISA should have one technical ack and each GS segment should have one functional ack. To match the ack to the corresponding GS Control number, customer should loop through all functional ack and check the ak102 field which is non-trivial.

   "generatedAcks": [
               {
                   "technicalAcknowledgement": {
                       "tA101": "111111891",                    
                   },
               },
               {
                   "functionalAcknowledgement": {
                       "header": {
                           "aK101": "AA",
                           "aK102": "0123456789"
                       },
                   },
               },
               {
                   "functionalAcknowledgement": {
                       "header": {
                           "aK101": "AA",
                           "aK102": "1123456789"
                       },
                   },
               }
           ],
   

How to migrate the existing managed X12 Decode action?

You may have many reasons to use the built-in X12 connector. The built-in X12 connector has better performance, large message processing, and VNET support without extra work. You may also need to switch from the X12 managed connector to the built-in X12 connector with minimal changes in the workflow definition. There are some scenarios where you require such minimal changes on workflow definition, when you move ISE workflows to Logic Apps Standard, or when you upgrade from Logic Apps Consumption to Standard, or when you replace the X12 managed connector in Logic Apps Standard.

One of the solution is to create a child workflow within the same Logic Apps and invoke from your existing workflow which you are migrating.

1. Create a nested workflow within the same Logic Apps and update the workflow definition using code view as given in https://github.com/Azure/logicapps-connector-extensions/blob/main/test/x12/x12decodmapping.json  or refer the attached file.  This child workflow will map the X12 decode response the same way as managed connector. The rendering of the workflow on the designer should look like: 
2. Invoke the workflow from your existing workflow definition using invoke workflow operation.

3. Change the name of the workflow invoke action to the same name as the X12 decode action preferably using code-view, as shown below. This way, you don't need to change anything in the workflow actions later where you use the X12 decode response.

   .

1. Execute the workflow now you can see the mapped response:      The workflow mapping for EDIFACT message processing is similar, you only need to modify the child workflow definition mostly header and trailer names from ISA , GS and AK to UNB, UNH, UCI and UCT properties name in the child workflow.