VistA RPC Listener
The VistA RPC Listener parses the VistA RPC XML and executes the commands against a VistA RPC system.
On the Basic tab you can specify:
Polling Interval: the interval in which to execute the XML file. If the value is set with enhanced properties, the units are in seconds.
Input File: input file, if the transaction contents do not contain the document to evaluate.
Validate XML: if the received or loaded XML document should be validated against its schema.
Cache Schema: if the schema for validation should be cached, so it won’t be re-loaded on every execution.
On the Advanced tab you can specify:
Initialize on trigger only: If enabled, the Listener doesn’t start up until a trigger initializes it.
Allow command-line invocation: If enabled, the listener can be invoked using the CLI client application.
Restart on listening error: If enabled, the listener will be restarted after an error occurs.
FIFO Queue Name: The name of the queue to use for guaranteed FIFO – leaving unset disables this behavior.
FIFO Queue Delay: The duration to delay between polls of the queue to use for guaranteed FIFO. If the value is set with enhanced properties, the units are seconds.
Cache Type: set the type of cache used internally for storing data when the XML structure is executed (Default Cache, Memory Cache, File Cache, Segment Cache)
On the Transaction Logging you can specify:
The Transaction Logging Enable checkbox allows transaction events originating from this listener to be logged by a TransactionEventListener.
Log Transaction Data: if enabled, logs transaction data body.
Log Transaction Data Base64: if enabled, logs transaction data body as Base64.
Log Transaction Attribute: if enabled, logs transaction attributes.
Log All Attributes: If enabled, no attributes will be filtered.
Allowed Attributes: Attributes that are allowed to be logged.
On the Inactivity you can specify:
Enable Inactivity Monitor: Check this box to enable inactivity monitoring. This will throw a non-transaction exception if the specified number of transactions haven’t been processed in the specified time interval.
Min. Transactions to Expect: The number of transactions to expect to be completed per monitoring interval.
Monitoring Interval: How often to check the specified number of transactions have been processed.
Times to Monitor: If set, monitoring will be done during the defined times of day. To ignore, set start and end time equally.
Days to Exclude from Monitoring: Inactivity monitoring will not occur on the days specified.
Include Errors in Transaction Count: If checked, transactions that attempted to start but failed at the Listener stage will also be counted.
On the Throttling you can specify:
Throttling Mode: The throttling mode to use for limiting the number of transactions or messages emitted by this Listener. “Timed” will limit transactions based on time intervals, while “Concurrent” will limit based on a concurrent number of transactions. “Concurrent” mode requires a Throttling Response Processor step later in your Interface workflow to acknowledge completion.
Throttling Mechanism: The mechanism to use for throttling message. “Blocking” prevents the Listener from continuing to process and emit messages altogether, while “Queued” pushes received messages into the Interface queue (or a default, in-memory queue).
Max Concurrent Messages: How many messages can be concurrently processed, either by time-based limits (“Allow X per Second”) or synchronous (“Allow X at any Time”).
Timed Emission Interval: The interval for time-based limits (“Allow X per X Timed Emission Interval”).
Synchronous Timeout Interval: The interval to wait for a synchronous response before failing.
On the Debug tab you can specify:
Evaluation Logging: if selected, extra information about the evaluation process will be logged to help with debugging its execution. Keep in mind that, in some cases, sensitive information may be logged with this option, so it should be kept off by default. NOTE: This is separate from the Log elements in the XML structure.
On the Connection tab you can specify:
Host: the hostname of the VistARPC system.
Port: the port number of the VistA RPC system.
Access Code: the access code for the VistA RPC system.
Verify Code: the verify code for the VistA RPC system.
Context: the context to use when running a remote procedure against a VistA RPC system. This is overridden by any Context elements added in the XML.
Use Custom Context: whether or not to use a custom context for the VistA RPC call.
Custom Context: a custom context for the VistA RPC call. This is overridden by any Context elements added in the XML.