Settings for X12 Business Services
Summary
X12 business services have the following settings:
Group | Settings | See |
---|---|---|
Basic Settings | Target Config Names, Doc Schema Category, Batch Handling | Settings for Business Services |
Acknowledgement | Reply Target Config Names (File), Validation Mode, Validation, SNIP Level, Batch Error Action, Batch Reply Type, AddNackErrText, Reply Mode, BadMessageHandler | sections in this topic |
Connection Settings | Tolerate Newlines | sections in this topic |
Additional Settings | Search Table Class | Settings for Business Services |
Reply Target Config Names (FTP) | section in this topic | |
Local Application ID, Default Char Encoding, | sections in this topic |
The remaining settings are either common to all business services or are determined by the type of adapter. For information, see the following sections:
-
Settings for the FTP Inbound Adapter
EnsLib.EDI.X12.Adapter.TCPInboundAdapterOpens in a new tab has Job Per Connection set to False, which is usually appropriate for X12.
Add Nack Error Text
Add extra error-text field to TA1 & 997/999 AKx segments when generating error-status reply messages; otherwise do not embed internal error state information in the Acknowledgement messages.
Bad Message Handler
If a document fails validation, it will be sent to the Bad Message Handler specified by this setting. If the document is part of a batch, the Batch Error Action determines how the batch is handled. This setting acts in combination with the Validation Mode, Validation, SNIP Level, and Batch Error Action
Batch Error Action
Specifies what the service does when it detects a validation error in a batch Interchange document. The options are as follows:
If the service encounters an error in a document within the batch, it validates the remainder of the batch, and then rejects the whole batch.
Additionally, if the Batch Reply Type allows, the reply document enumerates all the errors and shows an acknowledgement code of either A (accepted) or R (rejected) in each Functional Group Response Trailer (AK9) segment and Transaction Set Response Trailer (AK5) segment, as appropriate.
The service does not forward the batch or any part of the batch to the target business host.
If the service encounters an error in a document within the batch, it rejects the whole batch immediately. The service does not check for additional errors or parse the remainder of the batch.
Additionally, if the Batch Reply Type allows, the reply document enumerates the error and shows an acknowledgement code of either A (accepted) or R (rejected) in each validated Functional Group Response Trailer (AK9) segment and Transaction Set Response Trailer (AK5) segment, as appropriate. No Transaction Set Response Header (AK2) segments appear after the AK5 segment marked with R, which corresponds to the transaction set that generated the error.
The service does not forward the batch or any part of the batch to the target business host.
The service forwards any documents in the batch that pass validation to the target business host.
The service does not send transaction sets that include errors to the target business host and removes invalid transaction sets from any functional groups it sends. If all the transaction sets in a functional group include errors, the service does not send the functional group. Similarly, if all the transaction sets in all the functional groups in an interchange include errors, the service does not send the interchange.
Additionally, if the Batch Reply Type allows, the reply document enumerates the errors, shows an acknowledgement code of either A (accepted), P (partially accepted), or R (rejected) in each Functional Group Response Trailer (AK9) segment, and shows an acknowledgement code of either A or R in each Transaction Set Response Trailer (AK5) segment, as appropriate.
Reject Individual Errors is the default value.
The service forwards all documents in the batch.
Additionally, if the Batch Reply Type allows, the reply document enumerates the errors and shows an acknowledgement code of either A (accepted) or E (accepted but errors were noted) in each Functional Group Response Trailer (AK9) segment and Transaction Set Response Trailer (AK5) segment, as appropriate.
If Reply Mode is Application and Batch Handling is not Individual, InterSystems IRIS® may forward some of the documents in a batch before rejecting the whole batch upon encountering an error.
When the service does not forward a document due to a validation error, the document is deleted. Additionally, if the Batch Handling value is Individual, persisted parent documents are deleted if none of their corresponding children are forwarded.
Batch Handling
X12 Transaction Set documents are often packaged in a batch document called an Interchange, which contains nested sub-batches called Functional Groups. The Batch Handling setting specifies how InterSystems IRIS treats received document batches. The options are as follows:
-
Whole Batch—Do not process child documents individually; accumulate and send the whole batch as one composite document.
-
Single-Session Batch—Forward all documents in the batch together in one session; the session includes objects representing the parent document header and trailer segments. This is the default.
-
Multi-Session Batch—Forward each document in the batch in its own session, including the objects representing the batch header and trailer segments.
-
Individual—Forward each child document in the batch in its own session; do not forward objects representing the parent batch document’s header and trailer segments.
Batch Reply Type
Specifies the type of batch reply to create for an Interchange batch that has been received. The following table lists the possible choices:
Value | Meaning |
---|---|
None | Do not generate a batch reply. If an error occurs, do not create any immediate notification reply to the sender. |
All | Generate a reply Interchange containing a reply notification for every Transaction Set received in the Interchange. |
All+TA1 | Generate a reply Interchange containing a TA1 segment that indicates acceptance or error status for the entire Interchange, and a reply notification for every Transaction Set received in the Interchange. |
All+ISA14TA1 | Generate a reply Interchange containing a TA1 segment and a response for each Transaction Set only if a 1 appears in the Acknowledgement Requested (ISA:14) field of the Interchange Control Header (ISA) segment or if an error appears in the Interchange Envelope. Alternatively, generate an Implementation Acknowledgement (999) document with a response for each Transaction Set. |
Errors |
Whether or not errors are found, generate a reply Interchange. If no errors are found, generate an empty reply Interchange. If errors are found, generate an Interchange that contains reply notifications only for Transaction Sets in which errors are detected. This is the default setting if no choice is specified. |
OnlyIfErrors | If errors are found, generate a reply Interchange that contains reply notifications only for Transaction Sets in which errors are detected. |
Successes | Whether or not errors are found, generate a reply Interchange. If errors are found for every Transaction Set, generate an empty reply Interchange. Otherwise, generate a reply Interchange that contains reply notifications only for Transaction Sets in which no errors are detected (successes). |
TA1 | Generate a reply Interchange containing only a TA1 segment that indicates acceptance or error status for the whole Interchange received. |
OnlyIfErrorTA1 | If errors are found, generate a reply Interchange that contains only a TA1 segment that indicates error status for the whole Interchange received. |
ISA14-TA1 | If field ISA:14 of the incoming ISA header segment is set to 1, generate a reply Interchange containing only a TA1 segment; otherwise return nothing. |
ISA14-OnlyIfErrorTA1 | If errors are found and field ISA:14 of the incoming ISA header segment is set to 1, generate a reply Interchange containing only an error TA1 segment; otherwise return nothing. |
Byte | Generate a reply consisting of a single character code: 'A' if the entire Interchange is accepted, 'R' if it is rejected due to one or more errors. |
All of the options that relate to TA1 segments are used to force a TA1 segment to be generated, often as the only body segment of the reply interchange. This convention is used to represent the presence or absence of errors in the entire inbound Interchange. However, if an error is found in the incoming ISA or IEA that can only be reported in a TA1 segment, then a TA1 is generated even if the configured setting does not force a TA1 to appear.
Default Char Encoding
Specifies the character set of the input data. InterSystems IRIS automatically translates the characters from this character encoding. Supported values are UTF-8 or any member of the Latinn family. The value Native means to use the native encoding of the InterSystems IRIS server.
Placing a @ (at sign) character at the beginning of this field means that the field identifies an internal NLS translation table instead of a logical character encoding.
The default depends on the adapter.
For information on character sets and translation tables, see Translation Tables.
Default Separators and Terminators
X12 documents typically come in batches consisting of an Interchange, which contains one or more Functional Groups, which each contain one or more Transaction Sets. The Interchange header (ISA) segment includes information about which separators and delimiters to use in parsing the document.
When an X12 Interchange is parsed, the separators are set to values found in the header, and the rest of the document is parsed using those values. When there is no Interchange header, the only obvious separator is the element separator (the character immediately following the segment name) and sometimes the segment terminator (if it is followed by CRLF). In this case, the system default separator values are used as the separators and the document is parsed based on those. The system default separators are:
-
$C(30) for the repetition separator
-
":" for the component element separator
-
and "~" for the segment terminator
It is possible to use the following settings, which appear in the Additional Settings area, to pass in different default values to use for these separators when there is no Interchange header:
-
Default Repetition Separator
-
Default Element Component Separator
-
Default Segment Terminator
There are also parameters for these values in the EnsLib.EDI.X12.DocumentOpens in a new tab methods ImportFromFile, ImportFromDevice, ImportFromLibraryStream, ImportFromString, and ImportFromIOStream.
If a source document includes an invalid or duplicated separator, the system uses the corresponding separator in the Additional Settings area when it is defined or the corresponding system default separator.
Local Application ID
Colon-separated LocalID:Qualifier code that represents the facility and application that receive X12 documents via this business service. These are used to create reply document headers. The @ (at sign) character represents using the corresponding field from the incoming document. If your ID must contain a literal @ symbol, escape it with back slash: \@
The default value is:
EnsembleX12Service:03
Reply Mode
Specifies how to issue X12 reply documents (such as TA1 and 997). Options include:
-
Never—Do not send back any reply.
-
Immediate—Send a reply from the business service immediately upon receipt of an Interchange. This is the default.
-
Application—Wait for a response from the target configuration item. When it arrives, relay the reply back to the sender. If validation fails or some other error occurs, generate an immediate reply according to the option selected for BatchReplyType.
If an incoming ISA segment includes a field that too long or too short relative to the X12 standard, then that field is padded or truncated to meet the standard when it is copied to a reply document.
Reply Target Config Names
(File and FTP only) Specifies where the reply that the Business Service constructs, based on the validation that it performs, is to be sent. Usually the list contains one item, but it can be longer. The list can include business processes or business operations, or a combination of both.
Compare to Target Config Names.
SNIP Level
Relevant only when Validation Mode is SNIP.
-
SNIP level 1—segments are valid , segment order is valid, element attributes are valid, numeric data elements have numeric values, and message conforms to X12 rules.
-
SNIP level 2—meets HIPAA requirements, such as presence of required elements, non-use of elements marked as not used, and values conforming to the code tables.
Tolerate Newlines
True or False. If True, the business service processes an incoming X12 file without error, even if new lines have been inserted into the file after (or in place of) segment terminators to enhance readability. If False, these extra new lines trigger an error in parsing the file. The default is True.
Validation Mode
Two kinds of X12 validation are available:
-
SNIP level validation—validates the X12 message according to the standards developed by the Workgroup for Electronic Data Exchange (WEDI) Strategic National Implementation Process (SNIP).
-
Flag-based validation.
SNIP validation enables you to validate that:
-
SNIP level 1—segments are valid , segment order is valid, element attributes are valid, numeric data elements have numeric values, and message conforms to X12 rules.
-
SNIP level 2—meets HIPAA requirements, such as presence of required elements, non-use of elements marked as not used, and values conforming to the code tables.
Flag-based validation enables you to validate that:
-
Required fields, including conditionally required fields, are present and that all fields are allowed by the schema.
-
Conditionally excluded fields are not present.
-
The number of fields within a segment and whether they are repeated as allowed by the schema.
-
Data types for fields and components are correct.
-
Field values conform to the code tables specified.
-
Field and component values conform to length restrictions.