Settings for X12 Business Processes
X12 business processes have the following settings:
|Basic Settings||Validation||section in this topic|
|Business Rule Name||“Settings for Routing Processes” in Using Virtual Documents in Productions|
|Additional Settings||Response Target Config Names||section in this topic|
|Alert On Bad Message, Bad Message Handler, Response From, Response Timeout, Force Sync Send, Act On Transform Errors, Act On Validation Errors||“Settings for Routing Processes” in Using Virtual Documents in Productions|
|Development and Debugging||Rule Logging||“Settings for Routing Processes” in Using Virtual Documents in Productions|
The remaining settings are common to all business processes. See “Settings for All Business Processes” in Configuring Productions.
Response Target Config Names
The Response Target Config Names is for forwarding responses that the router receives from its targets. It contains a comma-separated list of configured items within the production. If specified, this list identifies the destinations, in addition to the caller, to which responses are forwarded. If empty, responses are only returned to the caller. This setting takes effect only if the Response From field has a value.
The Validation setting of an X12 Document Router controls how the router validates the incoming message. If the incoming message fails the specified validation, InterSystems IRIS® reports the failure in the event log, and the X12 routing process passes the message to its bad message handler only; see the Bad Message Handler setting. If the message fails the specified validation but there is no bad message handler, an error is logged but the message is not sent to any target. If the message passes validation, the X12 routing process sends the message to the targets specified by the routing rules.
Ideally, you can use routing rules and data transformations to ensure each message is acceptable to the target system, and can, consequently, avoid using validation. This ensures that all messages are processed by the appropriate target. If you enable validation, InterSystems IRIS applies the validation tests before the routing rules. Any message that fails validation is not sent to a target based on the routing rules; it is sent only to the Bad Message Handler. However, there are some environments where X12 message validation is the preferred way to filter messages. For example, in the following situations, using X12 validation is a good choice:
You are developing or debugging an interface and want to determine the kind of message variants that your system needs to handle.
The target application cannot handle messages that have variances from the specification, and the routing rules and transformations cannot resolve those variances.
There is a regulatory or other business requirement that the messages conform to the specification.
X12 validation does add overhead to the routing process. This overhead can be significant and can reduce the maximum load of messages that your production can handle.
The Validation property allows you to specify flags that control the following:
Whether the message has a valid document type.
Whether the message structure is validated.
Whether the fields within the segments and the components within a composite structure conform to the schema.
If you specify an empty string as the Validation property value, the message router skips validation and routes all messages. When you create a new X12 routing process in the Management Portal, the Validation setting is initialized to an empty string.
A message can pass validation and not conform exactly to the schema definition depending on the Validation flags specified.
The following table lists the X12 validation flags and describes how the routing process validates the message when each is specified.
|d||Validation examines the DocType property of the document to see if it has a value.|
|m||Validation verifies that the document segment structure is well formed, and that it can be parsed using the schema identified in the DocType property of the document. This ensures that all required segments in the schema definition are included in the message and that the message does not contain any misplaced segments that are not allowed by the schema.|
|dm||Both d and m are active. This is the default for business processes (routers).|
|s||Validation enforces segment structure, which is the number and repetition of fields within a segment.|
|c||Validation enforces composite structures, which is the number of components.|
|x||Validation enforces relational conditions on segments and fields. Relational conditions indicate which fields or components are required or excluded based on the presence of other fields or components. At minimum, you must additionally specify s for segment-level validation. You can also specify c for component-level validation.
Relational conditions are present in SEF files and not in XSD files. For more information, see X12 Schema Distribution Files.
|r||Validation enforces that the required elements are present. If s is also specified, then it tests if the required fields are present in the segment. If c is also specified, then it tests if the required components are specified in a composite structure. If neither s nor c is specified, then r has no effect.|
|u||Validation tests whether any elements that are marked as “Not used” are present. It tests for the presence of fields if s is also specified and tests for the presence of components if c is also specified. If any of these elements are present, validation fails. Note that this test cannot be performed if the only schema available is the “new-style” schema because it requires information stored only in the legacy schema.|
|l||Validation tests the length of elements. It tests the length of fields if s is also specified and tests the length of components if c is also specified.|
|t||Validation tests for the correct datatype of the elements. It tests the datatype of fields if s is also specified and tests the datatype of components if c is also specified.|
|v||Validation tests that the value of elements is allowed by the code table. It tests against the code table of fields if s is also specified and tests against the code table of components if c is also specified. Note that this test cannot be performed if the only schema available is the “new-style” schema because it requires information stored only in the legacy schema.|
|n||Equivalent to dmscrlt, which are all validation that can be performed relying only on the “new-style” schema.|
|a||Equivalent to dmscrultv, which are all validations.|
|e||Validation continues through the entire document even after encountering an error. If e is not specified, validation stops after encountering the first error.|
|(empty string)||Skips validation and routes all messages. This is the default for business services and operations.|