Schema Elements for Inbound EDI

In the inbound EDI use case, the input to the B2B action has the EDI payload element and the output, which is generated after parsing, has the XML form of the EDI document.

The TranslateInput data element represents the input message to the B2B action, and the TranslateOutput represents the output of the action. Therefore, at a minimum, TranslateInput needs to contain the edi-payload element to which you'll assign a value using the input map action. The TranslateOutput data element then produces the edi-xml-document element, returning the parsed data in the XML format along with validation errors, if any.

Description of edi-translate-inbound.png follows
Description of the illustration edi-translate-inbound.png

The following tables describe each element contained in TranslateInput and TranslateOutput for the inbound EDI scenario.

Elements in TranslateInput

Element	Description
`edi-payload`	You should assign a base64-encoded string value generated from a native EDI X12 payload (starting with the ISA segment and ending with the IEA segment) to this element. Base64 encoding is required because EDI may contain unprintable characters used as delimiters or even binary content such as images. In case the EDI X12 payload contains a batch of transactions, you must use a stage file action along with the B2B action to process the batch.
`tracking-info`	You'll require this element only when you use the B2B action with the stage file action for batch processing. This element contains the tracking information for each EDI transaction that is passed from the stage file action to the B2B action.
`edi-encoding`	The character encoding of the EDI X12 payload (default is UTF-8).
`accept-message-on-errors` and `reject-message-on-errors`	By default, any syntactical error in the input EDI payload is treated as a validation error in translation. You can alter this behavior in two ways: By turning off validation checks for the current message. Or: By keeping the validation turned on for the general case. But, be lenient for certain types of validation errors, allowing the message to be processed successfully even if those validation errors were to occur. These elements offer the second option listed above by providing a fine-grained control over the types of validation errors to ignore. You may need to have this fine-grained control in specific situations where you want to forward the message to a back-end application; for example, despite the B2B layer detecting invalid data. Both these elements are of a string type, and the format of the string allows you to specify one or more validation error types. These elements are semantic opposites of one another. The format is as follows: `error#<error_code1>,error#<error_code2>,...` It is a comma-separated string, where each token starts with `error#` followed by an error code such as `B2B-01752` (for example, a token is: `error#B2B-01752`). The `accept-message-on-errors` element defines validation errors to ignore, while the `reject-message-on-errors` element defines validation errors to treat as real errors. When a validation error is treated as a real error, the B2B action also generates an acknowledgment message (EDI X12 997) with a rejected flag. However, when a validation error is ignored, the 997 is flagged with the `Accepted, but errors were noted` status.
`validate`	By default, any syntactical error in the input EDI payload is treated as a validation error in translation. You can alter this behavior in two ways: By turning off validation checks for the current message. Or: By keeping the validation turned on for the general case. However, be lenient for certain types of validation errors, allowing the message to be processed successfully even if those validation errors were to occur. This element offers the first option listed above. Setting this element to `false` turns off validation checks, which effectively has the same effect as deselecting the check box Perform validations on input data? in the Configure B2B Action Wizard. However, this element overrides the check box setting and can be set for every message (whereas the check box setting is used for all messages). If this element is not set, the check box setting in the wizard controls whether validations are turned on or off.
`functional-ack-required`	If you set this element to `false`, the B2B action does not generate functional acknowledgment messages. If set to `true` or not set, a functional acknowledgment message is included in the `TranslateOutput` element when the B2B action processes the last message in a batch (that is, the last transaction set inside a functional group).
`passthrough-errors`	You'll require this element only when you use the B2B action with the stage file action for batch processing. This element simply transfers certain errors from the stage file action to the B2B action so that a proper functional acknowledgment message can be generated in case of errors. You must not set this element when using the B2B action in standalone mode.
`routing-info`	You'll require this element only when you use the B2B action with the stage file action for batch processing. You must not set this element when using the B2B action in standalone mode.
`input-source-context`	To use this optional element, you can assign any identifier string that the B2B action simply copies to the `TranslateOutput` element. For example, if the B2B action is processing a message from a file, set the file name to this element. The purpose of the element is to make the value available in the output. Therefore, it can be relayed to further actions in your integration or stored inside a tracking variable.

Elements in TranslateOutput

Element	Description
`edi-xml-document`	This element is returned with the translated message in the XML form. See Sample TranslateOutput XML for Inbound EDI.
`edi-xml-document` > `headers` > `interchange-ctrl` `edi-xml-document` > `headers` > `group`	These header elements are returned with values parsed from the EDI X12 ISA and GS envelopes.
`edi-xml-document` > `func-ack-report`	This element is returned only when the document type is a 997 (functional acknowledgment), and carries special content specific to a 997. Here are the child elements: `original-tracking-info`: The tracking identifier of the original outbound message reconstructed from this functional acknowledgment. This tracking identifier has a substring match with the `tracking-info` that is generated in `TranslateOutput > tracking-info` for the outbound EDI case. This is used to correlate an incoming 997 to an outbound message sent to a trading partner originally. For example, the value for `original-tracking-info` is `tc=1013;gc=1013;sn=SenderID;rc=ReceiverID;st=A;` and the corresponding value for `TranslateOutput > tracking-info` is `tc=1013;gc=1013;sn=SenderID;rc=ReceiverID;ic=000000015` (these values have a substring match, that means, the part of the string `tc=1013;gc=1013;sn=SenderID;rc=ReceiverID` from both values have an exact match). `func-ack-status`: The overall acceptance status as reported by the trading partner. Values are: `Success`, `Error`, or `Warning`, which correspond to `Accepted`, `Rejected`, or `Accepted But Errors Were Noted` status. `func-ack-details`: The interpretation of the functional acknowledgment in a human-readable, plain text format.
`edi-xml-document` > `transaction-data`	This element is returned with the hierarchical structure of data segments and elements inside the EDI message, starting with the `ST` segment and ending with the `SE` segment. Each segment or loop inside the EDI X12 data becomes a parent XML element and its constituent EDI elements become child XML elements. For example, this may appear inside the `transaction-data` element: `<ST> <ST01>850</ST01> <ST02>1234</ST02> </ST>` The above XML fragment represents the data values parsed from the EDI X12 data that has this line: `ST8501234~` The XML elements `<ST01>` and `<ST02>` are assigned values based on their corresponding element positions occurring inside the EDI data.
`edi-xml-document` > `trailers` > `group` `edi-xml-document` > `trailers` > `interchange-ctrl`	The trailer elements are returned with values parsed from the EDI X12 IEA and GE envelopes.
`functional-ack-present`	This element is returned as `true` if an EDI X12 997 functional acknowledgment has been generated in the element `functional-ack`. This element is returned as `false` if no acknowledgment message was needed or generated (if `TranslateInput > functional-ack-required` was set to `false`, then an acknowledgment message is never generated). The B2B action automatically generates a functional acknowledgment message as follows: For a singleton transaction (for example, when there is a single purchase order inside an EDI message or file): A functional acknowledgment is generated immediately, at the same time as the transaction is processed. For a batch transaction (for example, when there are fifty purchase orders inside an EDI message or file): A functional acknowledgment is generated when the last transaction inside a batch is processed. A batch means one EDI X12 functional group containing multiple transactions (that is, multiple pairs of `ST`/`SE` segments). The functional acknowledgment then reports the status of all the transactions inside that batch, by including multiple AK2 and AK5 segments. According to the EDI X12 standard, only one functional acknowledgment is expected per batch.
`functional-ack`	If `functional-ack-present` is returned as `true`, the `functional-ack` element is returned with a Base64-encoded EDI X12 997 (functional acknowledgment) document that is ready to be sent to the trading partner. You must apply a Decode64 function to get the native EDI content at the point where you are about to send it out (for example, before writing it to a file to deliver to the trading partner).
`functional-ack-tracking-info`	This element is returned with a string representing a unique transmission identifier for the generated functional acknowledgment message. The string includes control numbers used for the functional acknowledgment. The value is useful for tracking purposes in case the trading partner is unable to process the 997 document.
`validation-errors-present`	This element is returned as `true` if validation errors were detected while parsing the input payload.
`validation-errors` > `error` `validation-errors` > `validation-error-report`	The `error` element is returned with validation errors, with each validation error in an XML structure; the error code and error message are returned as separate XML elements. A maximum of 100 validation errors are reported. The `validation-error-report` element is returned with a concatenated list of up to 100 validation errors, separated by line break characters.
`tracking-info`	This element is returned with a string representing a unique transmission identifier occurring in the input EDI. This string includes control numbers used in the input EDI message (interchange/group/transaction-set control numbers). This value is useful for tracking purposes.
`translation-status`	This element is returned with the values `Success`, `Warning`, or `Error` as follows: `Success`: Indicates that the input EDI was parsed successfully and no validation errors were detected (also occurs when validations are turned off). `Warning`: Indicates there were validation errors but those were minor or that the user chose to treat certain errors leniently, controlled by the `TranslateInput > accept-message-on-errors` value. `Error`: Indicates critical validation errors were detected while translating and the message is marked as rejected in the functional acknowledgment contents. The integration should not send the message to a backend system for further processing; instead, it should route the message to error handing.
`transaction-summary`	This element is returned with the overall counts of transactions parsed with success, warning, or errors across a batch of transactions.
`input-source-context`	This element is returned as a verbatim copy of the `TranslateInput > input-source-context`, so that it is visible in the integration actions that follow.