Azure Logic App X12 replacing separator characters in payload
Using the B2B X12 connector for Azure Logic App, sometimes the input xml values in the payload has reserved characters which conflict with the X12 encoding that you are attempting. X12 agreement with your external partner defines a segment separator character which then cannot be present as well in the value of the segment. By default if this character is found in the values of the xml payload, the X12 encode action will be failed with bad request http error 400.
There is however an advanced setting in the agreement to enable replacing such reserved character occurrence with another character. Go to the Integration Account in the Azure management portal, select the X12 agreement and click on "Edit as JSON". This will open an UI blade with the agreement raw JSON data such as:
{
"properties": {
"hostPartner": "foo",
"guestPartner": "bar",
"hostIdentity": {
"qualifier": "ZZ",
"value": "foo"
},
"guestIdentity": {
"qualifier": "ZZ",
"value": "bar"
},
"agreementType": "X12",
"content": {
"x12": {
"receiveAgreement": {
"protocolSettings": {
"validationSettings": {
"validateCharacterSet": true,
...
}
},
"sendAgreement": {
"protocolSettings": {
"validationSettings": {
"validateCharacterSet": true,
"checkDuplicateInterchangeControlNumber": false,
"interchangeControlNumberValidityDays": 30,
"checkDuplicateGroupControlNumber": false,
"checkDuplicateTransactionSetControlNumber": false,
"validateEDITypes": true,
"validateXSDTypes": false,
"allowLeadingAndTrailingSpacesAndZeroes": false,
"trimLeadingAndTrailingSpacesAndZeroes": false,
"trailingSeparatorPolicy": "NotAllowed"
},
"framingSettings": {
"dataElementSeparator": 42,
"componentSeparator": 58,
"replaceSeparatorsInPayload": false,
"replaceCharacter": 36,
"segmentTerminator": 126,
"characterSet": "UTF8",
"segmentTerminatorSuffix": "None"
},
Observe that the receive agreement comes first. While it also has the framing settings element, you need to modify the framing settings of the send agreement further down in the JSON. By default the replaceSeparatorsInPayload property is set to false - change that to true. The following property replaceCharacter is the decimal value of the ASCII replacement character to use. For instance 36 is $, 45 is -, or you can change it to 32 for the space character.
I had an existing test input containing for one field:
<N102>Contoso, Inc.</N102>
Which for test purposes I changed to:
<N102>Contoso,:Inc.</N102>
The observed original output was:
ISA*00* *00* *ZZ*1234567 *ZZ*7654321 *171020*2143*U*00401*000000099*1*I*:
GS*IN*11111*22222*20171020*2143*99*T*004010
ST*810*0099
BIG*20150706*9823288299*20150706*P10001102113
REF*AH*01S6S445
REF*ON*6595991
REF*V1*S6
REF*VN*A124634973
REF*ZB*880A5E56
N1*SO*Contoso, Inc.*93*0005065087
...
With the changed payload without fixing the agreement I get a Bad Request response. With the changed payload and agreement updated with replace character 45 ('-') I then get instead:
ISA*00* *00* *ZZ*1234567 *ZZ*7654321 *171020*2259*U*00401*000000099*1*I*:
GS*IN*11111*22222*20171020*2259*99*T*004010
ST*810*0099
BIG*20150706*9823288299*20150706*P10001102113
REF*AH*01S6S445
REF*ON*6595991
REF*V1*S6
REF*VN*A124634973
REF*ZB*880A5E56
N1*SO*Contoso,-Inc.*93*0005065087
...
With replaceCharacter 32 I do get the space character back:
N1*SO*Contoso, Inc.*93*0005065087