Webhook / Interlock Configuration

Overview

Occasionally it can be desirable to trigger remote actions in response to actions that occur in the resource system. Use cases include remote logging or instrument interlock control. To support these remote actions the resource system provides HTTP webhooks for the following actions:

• Order Creation
• Order Updates
• Order Deletion
• Event Creation
• Event Updates
• Event Deletion
• Interlock Unlock Request
• Interlock Status Request
• Interlock Lock Request

Using the Service Webhook Manager facility staff can configure single or multiple webhooks to be triggered when any of the above events occur. 

Configurations can be specified for HTTP Headers, HTTP Auth, request HTTP Verb/Type and request body data.

Note: all request bodies will be encoded as "application/json"

HTTP Verb/Type settings can be set to standard or "insecure". Insecure requests will ignore all TLS certificate errors and are not recommended.

Payload

By default the payload for requests will include the following in the request body: 

• Order ID (order_id)
• Line Item or Event ID (line_id / event_id)

Any additional data elements as configured by the webhook settings will be attached to the data object.

Data keyed with the same key as any of the above will be OVERWRITTEN by the system provided value

Multiple Webhooks

Multiple webhooks on the same event can be configured. Order of execution is NOT guaranteed.

Interlock Configuration

Interlocks are a special use case for webhooks. Scheduled instruments/services can be configured to display an interlock control UI element by attaching the has_interlock tag to the service in question under the "Service Tags" configuration using the "Manual Tag Wizard"

After event creation / during event viewing services with this tag will display a set of interlock controls

Facility Staff and System Administrators will see interlock controls at all times and on all events. Instrument Users will only see the interlock controls between 5 minutes before the scheduled start of the event and 30 minutes after the scheduled end of the event.

The 3 actions correspond to the "interlock" action type and subtype.

The lock and unlock actions are "push-only" webhooks. Any response traffic to these calls is discarded. Valid HTTP Error codes will generate an error message with the reason for the error displayed.

The "Query Lock Status" action will parse the response from the target and expects an "application/json" body with a "status" key containing either a "locked" or "unlocked" value.