Using Virtual Documents in Productions
Settings for Routing Processes
Provides reference information for settings of EnsLib.MsgRouter.RoutingEngine business process, which you use to route most kinds of virtual documents.
If True, causes errors returned by a transformation to stop rule evaluation and the error to be handled by Reply Code Actions setting.
If True, causes errors returned by validation to be handled by Reply Code Actions setting.
If True, any document that fails validation automatically triggers an alert.
If the document fails validation, and if the routing process has a configured Bad Message Handler
, it sends the bad document to this business operation instead of its usual target for documents that pass validation.
The full name of the routing rule set for this routing process.
If True, make synchronous calls for all send
actions from this routing process. If False, allow these calls to be made asynchronously. This setting is intended to ensure FIFO ordering in the following case: This routing process and its target business operations all have Pool Size
set to 1, and ancillary business operations might be called asynchronously from within a data transformation or business operation called from this routing process.
If Force Sync Send
is True, this can cause deadlock if another business process is called by a target that is called synchronously from this routing process.
Note that if there are multiple send
targets, Force Sync Send
means these targets will be called one after another in serial fashion, with the next being called after the previous call completes. Also note that synchronous calls are not subject to the Response Timeout
Reply Target Config Names
Specifies a comma-separated list of configuration items within the production to which the business service should relay any reply
documents that it receives. 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.
This setting takes effect only if the Response From
setting has a value.
A comma-separated list of configured items within the production. This list identifies the targets from which a response may be forwarded back to the original caller, if the caller requested a response.
If a Response From
string is specified, the response returned to the caller is the first response that arrives back from any target in the list. If there are no responses, an empty OK response header is returned.
The Response From
string also allows special characters, as follows:
character by itself matches any target in the production, so the first response from any target is returned. If there are no responses, an empty OK response header is returned.
If the list of targets begins with a +
character, the responses from all targets return together, as a list of document header IDs in the response header. If none of the targets responds, an empty OK response header is returned.
If the list of targets begins with a -
character, only error responses will be returned, as a list of document header IDs in the response header. If none of the targets responds with an error, an empty OK response header is returned.
If this setting value is unspecified, nothing is returned.
Maximum length of time to wait for asynchronous responses before returning a timed-out error response header. A value of -1 means to wait forever. Note that a value of 0 is not useful, because every response would time out. This setting takes effect only if the Response From
field has a value.
If logging is enabled controls the level of logging in rules. You can specify the following flags:
Log errors only. All errors will be logged irrespective of other flags, so setting the value to 'e' or leaving the value empty will only log errors.
Log return values. This is the default value for the setting, and is also automatic whenever the 'd' or 'c' flags are specified.
Log details of the conditions that are evaluated in the rule. This will also include 'r'.
Log all available information. This is equivalent to 'rcd'.
If the document fails validation, the routing process forwards the document to its bad message handler, as specified by the Bad Message Handler
setting. If there is no bad message handler, the routing process does not route the document, but logs an error. Also see Alert On Bad Message