Use the following examples to implement the Incoming WCTP features.
The examples that follow illustrate the use of only a single trigger condition for determining the appropriate rule action. In practice, additional conditions would likely be necessary to ensure that only responses, status updates, and errors related to messages received through the Vocera Incoming WCTP Adapterr will trigger these rules. The recommended additional conditions are as follows:
- The correct condition for sending the given response exists. If the response is being triggered by an end user response, this may be a "Response Is Accept" or "Response Is Decline" condition on the Responses dataset.
- The appropriate response link (alert.accept_response or alert.decline_response) is non-null.
- The appropriate meta_data link (alert.meta_data.message_key) is non-null.
- Optionally, for instance if there are multiple multi-response adapter instances, there might need to be a condition to check the interface reference name stored in the metadata (alert.meta_data.interface), or some other mechanism to fire the rule for the correct adapter instance.
Sending an Accept Response
When an alert has been accepted by the recipient in one of the Vocera-supported endpoints, we can send back a corresponding response to the originating system using an Incoming WCTP Send Response Rule.
The rule should be configured on the Responses dataset with a condition which matches the affirmative response (i.e., action starts with 'accept'). The rule can then be configured to send back one of the values that was stored in the the Response Type matching section of the adapter configuration using the accept_response link.
Please note that we are sending back the response_value attribute of the ResponseOptions dataset, as opposed to the display_value, since this is the value that the source system will generally be expecting.
Sending a Decline Response
When an alert has been declined by the recipient in one of the Vocera-supported endpoints, we can send back a corresponding response to the originating system using an Incoming WCTP Send Response Rule.
The rule should be configured on the Responses dataset with a condition which matches the negative response (i.e., action starts with 'Decline'). The rule can then be configured to send back one of the values that was stored in the the Response Type matching section of the adapter configuration using the decline_response link.
Please note that we are sending back the response_value attribute of the ResponseOptions dataset, as opposed to the display_value, since this is the value that the source system will generally be expecting.
Sending a Queued Status Update
When an alert has been queued for delivery to one of the Vocera-supported endpoints, we can send back a status update to notify the originating system that we have successfully received the alert and are attempting to send the alert out to the recipient.
This can be accomplished by configuring an Incoming WCTP Send Status Update Rule on the DeliveryHistory dataset with a condition which matches when an alert is queued for delivery (i.e., status equal to 'Queued') and selecting the 'Queued' status in the dropdown for the Send Status Update Rule.
Sending a Successfully Delivered Status Update
When an alert has been successfully delivered to one of the Vocera-supported endpoints, we can send back a status update to notify the originating system that we have successfully received the alert and have delivered it to the recipient.
This can be accomplished by configuring an Incoming WCTP Send Status Update Rule on the DeliveryHistory dataset with a condition which matches when an alert is queued for delivery (i.e., status equal to 'Delivered') and selecting the 'Delivered' status in the dropdown for the Send Status Update Rule.
Sending a Delivery Failure Status Update
When an alert has failed to deliver to one of the Vocera-supported endpoints, we can send back a status update to notify the originating system that we have successfully received the alert and have failed to deliver it to the recipient.
Here we have the option to send back a custom error code and error message. This can be accomplished by configuring an Incoming WCTP Send Delivery Error Rule on the DeliveryHistory dataset with a condition which matches when an alert fails to deliver (i.e., status equal to 'Error') and providing an error code and error message.
If there are several different error codes that will be useful for the originating system, more conditions could be conceived to determine the reason for the failed delivery (likely using the link DeliveryHistory.delivery.status_text), and using an error code and error message which correspond with the reason for failure.
