While the Standard API is designed to enable getting information in and out of the Equus Platform in a consistent, structured manner, the systems that are making requests against it will need to be kept up to date about events - like data changes - that happen after an initial request is made.
Using the Webhook tab on the Quick Workflow screen, a notification can be customized so that a set of identifiers can be configured to be sent to a target URL. Webhooks allow for event conditions to be defined which, when met, will trigger a message to be sent to a target URL, or listener endpoint, in another system. Webhooks are intended to be lightweight with regards to what content is provided in them, so that the receiving system has just enough information to form a request back to the system which initiated the webhook. Typically, this be should identifiers about the objects the event is related to.
In addition, when configuring a Quick Workflow to send webhooks, authentication for Webhooks can be configured by selecting a configured webhook profile.
It is possible to change the number of processor threads by specifying the number of processor threads for the Webhook Thread Processor (WEBHOKPROC) power user system preference. Contact your Equus representative for details about power user mode.
Watch-outs
There are no Equus defined Webhooks shipped as part of the 20.4 release and beyond. If interested in leveraging the feature with another system, a technical resource should be consulted to confirm the format the Body of the request should be in so that it can be accepted by the target system
Personally Identifiable Information (PII) should not be sent in Webhooks. The content included in the Body should be kept at a high level - Assignment ID, Employee ID and other identifiers used to describe an Employee, Authorization ID, and so on. The intent for Webhooks is to be as lightweight as possible
Without having an external system setup to receive Webhooks, it may be difficult to test that they are merged and sent correctly. Information about Webhooks will be logged in specific tables to support troubleshooting and research
Webhooks have built in retry logic if the target system responds with a failure. For now, this is determined by the same settings that are used for Vendor Integration:
EQVIRETDEL Retry Delay (seconds)
EQVINUMRET Number of retries