B2B Action Input and Output Schema Reference

While configuring data mappings for the B2B action, you use the TranslateInput and TranslateOutput elements and map the incoming and outgoing data to or from these elements.

This section describes the schema elements contained within the TranslateInput and TranslateOutput data elements. These schema elements drive the behavior of the B2B action.

Topics:

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.

Sample TranslateOutput XML for Inbound EDI

This section provides a sample TranslateOutput XML file for inbound EDI.

<ns0:executeResponse xmlns:ns0="http://xmlns.oracle.com/cloud/adapter/ediAdapter/EDI_Translate_REQUEST/types">
    <TranslateOutput xmlns="http://xmlns.oracle.com/b2b/X12/4010/transactionset-850/default" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <edi-xml-document format="X12-4010-850" ver="1.0.20200326">
            <headers>
                <interchange-ctrl ack-requested-code="0" auth-info="" auth-info-qualifier="00" ctrl-standards-id="U" ctrl-version-num-code="00401" date="190312" element-separator="|" interchange-ctrl-num="000001894" receiver-id="22222" receiver-id-qualifier="01" sec-info="" sec-info-qualifier="00" segment-terminator="0xa" sender-id="111111T" sender-id-qualifier="01" subelement-separator="~" time="0845" usage-indicator-code="T"/>
                <group app-receivers-code="ACME" app-senders-code="0124578" date="20190312" func-identifier-code="PO" group-ctrl-num="0123456" resp-agency-code="X" time="084515" version-identifier-code="004010"/>
            </headers>
            <transaction-data>
                <ST>
                    <ST01>850</ST01>
                    <ST02>1013</ST02>
                </ST>
                <BEG>
                    <BEG01>99</BEG01>
                    <BEG02>BA</BEG02>
                    <BEG03>Purchase Order Number</BEG03>
                    <BEG05>20061103</BEG05>
                    <BEG06>Contract Number</BEG06>
                    <BEG09>01</BEG09>
                </BEG>
                ....
                <SE>
                    <SE01>25</SE01>
                    <SE02>1013</SE02>
                </SE>
            </transaction-data>
            <trailers>
                <group count-of-txnsets="1" group-ctrl-num="1013"/>
                <interchange-ctrl count-of-groups="1" interchange-ctrl-num="100000020"/>
            </trailers>
        </edi-xml-document>
        <functional-ack-present>true</functional-ack-present>
        <functional-ack>SVNBfDAwfCAgICAgICAgICB8MDB8ICAgICAgICAgI...</functional-ack>
        <functional-ack-tracking-info>tc=1016;gc=1016;sn=22222;rc=111111T;ic=000000016;</functional-ack-tracking-info>
        <validation-errors-present>true</validation-errors-present>
        <validation-errors>
            <error>
                <code>B2B-01757</code>
                <category>data_codelist</category>
                <summary>Element BEG01 (element id 353) contains an invalid identification code [99] that is not listed in the allowed codes for this element (for example: 00, 44, 01, 45, 02, 46 ...).</summary>
                <location>segment-BEG &gt; BEG01 (element id 353) | segment position 2 (starting with ST segment) | element position 1 | character position 174</location>
            </error>
            <validation-error-report>[1] Error code: B2B-01757 | category: data_codelist | message: (Severe) Element BEG01 (element id 353) contains an invalid identification code [99] that is not listed in the allowed codes for this element (for example: 00, 44, 01, 45, 02, 46 ...). | segment-BEG &gt; BEG01 (element id 353) | segment position 2 (starting with ST segment) | element position 1 | character position 174</validation-error-report>
        </validation-errors>
        <tracking-info>tc=1234;gc=0123456;sn=111111T;rc=22222;ic=000001894;seq=1;tot=1;</tracking-info>
        <translation-status>Error</translation-status>
    </TranslateOutput>
</ns0:executeResponse>

Schema Elements for Outbound EDI

In the outbound EDI use case, the input to the B2B action has the XML form of the EDI document and the output has the document assembled into the EDI format.

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

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

Elements in TranslateInput

Element	Description
`edi-xml-document`	The XML form of the data to use to form the output EDI message during translation. At the minimum, you must assign values to the following child XML elements in the input: `headers > interchange-ctrl`: The attribute `sender-id-qualifier` must contain a value for the interchange sender ID qualifier. This value is inserted into the ISA05 element. The attribute `sender-id` must contain a value for the interchange sender ID qualifier. This value is inserted into the ISA06 element. The attribute `receiver-id-qualifier` must contain a value for the interchange receiver ID qualifier. This value is inserted into the ISA07 element. The attribute `receiver-id` must contain a value for the interchange receiver ID qualifier. This value is inserted into the ISA08 element. `headers > group`: The attribute `app-senders-code` must contain a value for the application sender's code. This value is inserted into the GS02 element. The attribute `app-receivers-code` must contain a value for the application receiver's code. This value is inserted into the GS03 element. `transaction-data:` The child elements inside it represent the structure of the business message, such as a purchase order. Mapping these elements require knowledge of the EDI X12 segments and elements that form the business message. You must assign values to mandatory segments and elements, and assign values to conditional elements based on the presence of other elements defined by the syntax rules specified for each segment. Other elements and attributes inside headers and trailers are assigned default values, so these are optional. Note: The B2B action automatically generates unique control numbers for the interchange, group, and transaction set. Note: Customizing Delimiters for Outbound EDI By default, the `element-separator` is `*`, the `segment-delimiter` is `~`, and the `subelement-separator` is `:`. You can override them by specifying values in the input XML as follows: `headers` > `interchange-ctrl` > `attribute 'element-separator'` `headers` > `interchange-ctrl` > `attribute 'subelement-separator'` `headers` > `interchange-ctrl` > `attribute 'segment-terminator'` `headers` > `interchange-ctrl` > `attribute 'repetition-separator'` (only applies to X12 4020 or later versions) If the delimiter character you want to use is an ASCII printable character, simply assign a string value such as `"\|"` to the corresponding attribute. If you want to use a special character as a delimiter, specify it in a hexadecimal format. For example, `0xA`, where `0x` is a fixed prefix and `A` is the hexadecimal representation of the ASCII line-feed character. If your EDI payload uses a different encoding such as UTF-8, you can use the hexadecimal format to specify a Unicode character as a delimiter. For example, specify `0x03A60` to use the Unicode character `Φ` as a delimiter. Note that the receiving trading partner should be prepared to receive a UTF-8 EDI payload for this to work correctly. Note that the delimiter string value you specify must equate to only a single character. Multiple characters are not allowed. The only exception is the `segment-terminator`, which allows one character plus an optional ASCII carriage-return and a line-feed character at the end. For example, a `segment-terminator` value of `~0xd0xa` uses `~` followed by `<CR>` and `<LF>` as a `segment-terminator`, which means each EDI segment is output on a separate line, making it more readable.
`accept-message-on-errors`	See Accept Message on Errors.
`reject-message-on-errors`	See Reject Message on Errors.
`validate`	See Validate.
`input-source-context`	See Input Source Context.

Elements in TranslateOutput

Element	Description
`edi-payload`	This element is returned with the translated message in the EDI format, starting with the X12 ISA header envelope and ending with the IEA trailer envelope. The control numbers are automatically generated and inserted in the EDI content. Note that the EDI content is Base64 encoded.
`validation-errors-present`	See Validation Errors Present.
`validation-errors` > `error` `validation-errors` > `validation-error-report`	See Validation Errors - Error and Error Report.
`tracking-info`	This element is returned with a string representing a unique transmission identifier occurring in the output EDI. This string includes control numbers used in the output EDI message (interchange/group/transaction-set control numbers). This value is useful for tracking purposes.
translation-status	See Translation Status.
`input-source-context`	See Input Source Context.

Sample TranslateOutput XML for Outbound EDI

This section provides a sample TranslateOutput XML file for outbound EDI.

<executeResponse xmlns="http://xmlns.oracle.com/cloud/adapter/ediAdapter/EDI_Generate_REQUEST/types">
    <TranslateOutput xmlns="http://xmlns.oracle.com/b2b/edi/generic/document">
        <edi-payload>SVNBKjAwKiAgICAgICAgICAqMDAqICAgI...E1fg==</edi-payload>
        <validation-errors-present>true</validation-errors-present>
        <validation-errors>
            <error>
                <code>B2B-01757</code>
                <category>data_codelist</category>
                <summary>Element BEG02 (element id 92) contains an invalid identification code [00] that is not listed in the allowed codes for this element (for example: PR, LS, DR, DS, UD, UE ...).</summary>
                <location>edi-xml-document &gt; transaction-data &gt; segment-BEG &gt; BEG02 (element id 92) | segment position 2 (starting with ST segment) | element position 2</location>
            </error>
            <validation-error-report>[1] Error code: B2B-01757 | category: data_codelist | message: (Severe) Element BEG02 (element id 92) contains an invalid identification code [00] that is not listed in the allowed codes for this element (for example: PR, LS, DR, DS, UD, UE ...). | edi-xml-document &gt; transaction-data &gt; segment-BEG &gt; BEG02 (element id 92) | segment position 2 (starting with ST segment) | element position 2</validation-error-report>
        </validation-errors>
        <tracking-info>tc=1015;gc=1015;sn=Acme Foods;rc=Global Chips;ic=000000015;</tracking-info>
        <translation-status>Error</translation-status>
    </TranslateOutput>
</executeResponse>