These settings enable direct communication between the Vocera Eventing Adapter and the Vocera Platform.
Select an empty field and begin typing, or select an existing value and type over it. To keep an existing value, do not edit that field.
Configuration Field | Description |
---|---|
Component Name | Select the Component Name field to display a list of the systems and devices that the Vocera Platform currently supports. Select the name of the adapter to create. |
Reference Name | Enter a short descriptive name in the Reference Name field to uniquely identify an adapter instance. It may demonstrate the adapter function or other information; for example, Production adapter may differentiate a live adapter from a development or "sandbox" adapter. |
Enabled | Select the Enabled checkbox to allow the Vocera Platform to use the new adapter. The Vocera Platform ignores the adapter if this option is disabled. |
General Settings Configuration Field | Description |
---|---|
Sender Patterns | A list of regular expressions to be matched to the sender for incoming messages. If none are specified, then this configuration will handle any message not handled by another active configuration. |
Report Non-Matching Messages as Audit Events | Select this box to create an audit log event for messages that do not match message definition. This field is optional. |
Connection Type | Specify the type of method to retrieve the status of the
Event. The three options are:
|
Connection URL | This URL is only required if using the RESTful Callback method. Enter the URL that will receive the notification of Events. |
Message Timeout | The amount of time, in minutes, that is expected to elapse between messages. The value must be a number between 1 and 10080. An Audit Event (610) will be generated if a message is not received when expected. |
The Eventing adapter currently supports two ways of communicating between a client and the server. First, the client may perform all of operations via HTTP using RESTful endpoints. These RESTful operations directly allow for the creation and management of events, however in order to get status updates, the client is required to regularly poll various RESTful endpoints. This approach isn't particularly efficient, especially for a client that may have hundreds of devices individually polling. Considering that, support for a WebSocket connection is now an option as well. Vocera supports all operations over the WebSocket.
General Settings Configuration Field | Description |
---|---|
Authorization Type | Select from either No Authorization or Bearer
JWT. If No Authorization is chosen the remaining fields will not populate and no further action is required. If Bearer JWT is selected, then the remain fields should be completed. |
Issuer | Enter a string that represents the sender of the event when
receiving a request to the adapter. This string also
represents the receiver of the event update when receiving a
request to the adapter. As an example, the Facility name
maybe used as the string. This field is required. |
Audience | Enter a string that represents the receiver of the event when receiving a request to the adapter. This string also represents the sender of the event update when sending a request from the adapter. As an example, Vocera may be used as the string. |
Key | The secret that is used to encode the security JWT. The
secret authenticates requests to and from the Eventing
Adapter. Select the Generate Key button to generate a
random secret. This field is required. |
Timeout | The length of time, in seconds, that the JWT is valid. The minimum is 1 second and the maximum is 3600 seconds. |
A Bearer JWT is a bearer JSON Web Token. JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.
JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed by using the key that is generated, you can be sure the senders are who they say they are.
The Vocera Eventing Adapter message types include a regex mapping for the event data. Because of the nature of the response mechanism and the need to persist data across a failover, the Eventing interface must store additional information about alerts. This data will be persisted in a separate dataset, AlertMetaData, which is tied to the original alert by a locally unique identifier, referred to as the Message Key.
Because an MCR message may contain multiple responses, the adapter must be able to store each response type and have a default Accept response and a default Decline response. Each MCR type may vary in response options between interface configurations and message types, so each message type should be configured with a Regex to match the correct Accept response and separate Regex to match the correct Decline response.
Implementation specialists may add, clone, remove, or modify message types as needed. If there are multiple message types configured, one or more can be deleted. Message types can be reordered by dragging and dropping each into the preferred order. See Understanding Regular Expressions for additional information.
Message Type Configuration Field | Description |
---|---|
Reference Name | Enter a descriptive name to identify the message type. This field is required. |
Active | Select the Active checkbox to indicate whether or not the message type is active. |
Discard Message | Select the Discard Message checkbox to disregard this type of message without processing it. Discarded message types may be created for the sole purpose of filtering them from the audit log. |
Starting Dataset | Select a dataset from the dropdown box. The dataset selected should be where you want to save messages of this type. |
Message Regex | Specify the regular expression (Regex) necessary to parse the body of the incoming message into the value expressions contained in the Regex Mapping field. Specify a Regex to capture values from the Message Data of a message received from an Eventing endpoint. |
Message Mapping | Specify one or more attributes, or attribute paths, to be
filled with data from the Message Regex. One attribute or
attribute path per line. Two different types of patterns for the attribute mapping are supported: Plain Attribute and Statement of Equality. If using a Plain Attribute list, each item in the mapping is a simple attribute path. The first capture group of the matched regular expression is used as the value of the first attribute path in the list, and so on. The number of capture groups in the Regex must match the number of attribute paths in the list. The Syntax: dataset_link_attr_name.attr_name or dataset_attr_name. If using Statements of Equality, the left hand side is the attribute path, while the right-hand side is what the attribute path should be set to. The right-hand side should use numbered captured groups (e.g. $1) to reference elements matched, but may also include literal strings. Syntax: dataset_link_attr_name.attr_name=LITERAL, dataset_attribute_name=$1, or example_with_two_capture_groups=$2:$1 |
Message Key Path | Specify the location into which the "global identifier" will be stored so that responses and status updates can be sent. |
Sender ID Path | Specify the optional location into which to store the Sender ID specified in the message. |
Link for Response Options | The link to the Response options dataset where the matching response options will be stored. |
Message Types Configuration Field | Description |
---|---|
Store Location | Select the checkbox to indicate that data should be stored in the specified location. |
Location Regex | Specify a Regex to capture location values from the Place Data of a message received from an Eventing endpoint. |
Location Regex Mapping | Specify one or more attributes, or attribute paths, to be
filled with data from the Message Regex. One attribute or
attribute path per line. Two different types of patterns for the attribute mapping are supported: Plain Attribute and Statement of Equality. If using a Plain Attribute list, each item in the mapping is a simple attribute path. The first capture group of the matched regular expression is used as the value of the first attribute path in the list, and so on. The number of capture groups in the Regex must match the number of attribute paths in the list. The Syntax: dataset_link_attr_name.attr_name or dataset_attr_name. If using Statements of Equality, the left hand side is the attribute path, while the right-hand side is what the attribute path should be set to. The right-hand side should use numbered captured groups (e.g. $1) to reference elements matched, but may also include literal strings. Syntax: dataset_link_attr_name.attr_name=LITERAL, dataset_attribute_name=$1, or example_with_two_capture_groups=$2:$1 |
Advanced Configuration Field | Description |
---|---|
Escalation Key Path | Specify the path to read the information from when sending a status response. |
Link for Responses | Specify the link to the Responses dataset to read the information from when sending a status response. |
Event Type Path | Specify the location to read the infomration from when sending a status response. |
Activity State Path | Specify the location to read the information from when sending a status response. |