This page describes how HA works for integration actions based on the Listener type of triggers. If there are no Listener triggers in your integrations, you could skip that page. When you are unsure whether the Listener type of triggers is used in your integrations, you could check that by browsing through each action of the integration you have configured and checking the chosen trigger on the Source tab. It could be either "Polling" or "Listener."
Example of a Listener Trigger:
Example integrations where Listener Triggers are used OOTB:
OBM events to ServiceNow incidents (CLIP)
OBM events to Cherwell incidents (CLIP)
OBM events to BMC Remedy incidents (CLIP)
OBM events to Jira issues (CLIP)
How It Works
While the main Failover solution described on the High Availability page is applicable for any integration, when some or all of the integration actions are configured with Listener type of triggers and Failover is performed to a Backup ZigiOps server, logically, the host serving the Listener's endpoint is changed. In such cases, the 3rd party Integrated System must continue directing the HTTP requests to the active ZigiOps host.
In Integration Actions configured with Listener type of trigger, ZigiOps is the passive side of the integration, waiting to receive an HTTP request. This design allows putting a Load Balancer software before ZigiOps to direct the HTTP requests to the active instance automatically.
This way, the 3rd Party Integrated System doesn't need to know which ZigiOps host exactly is serving its requests and results in an Automatic Failover. ZigiOps acts in active/passive mode; thus, the Load Balancer will always know which server is active based on its HTTP Health monitors and direct the HTTP requests accordingly.
This scenario is an expansion of the main Failover solution described on the High Availability page. It has the same prerequisites and requires the ZigiOps servers to be configured the same way.
Equal hardware and OS used on both the Primary and the Backup ZigiOps server.
Primary and Backup servers have installed the same version of ZigiOps
Integration configuration is maintained in sync between each server - for info on how to automate this, please look at the Network Storage for Runtime Files page
External Load Balancing software
VIP for each network port used in an integration action
HTTP Health Monitors
Active licenses on each Primary and Backup ZigiOps server
Only one ZigiOps server is active at the same time
Configuring Load Balancer VIP
Determine how many VIPs you would need for your scenario - review all of the integration actions configured with Listener type of triggers and note the port number used. You would need one VIP for each unique port number used for a listener. For example, if you have 3 actions configured with a Listener trigger on HTTPS and port 9090 and 1 action configured with Listener trigger on HTTP and port 9494, you would need 2 VIPs on the Load Balancer - HTTPS 9090 and HTTP 9494.
Configuring the VIP on the Load Balancer depends on the actual Load Balancing software used, but you could consider the following general notes:
Usually, there will be a pool containing all of the ZigiOps servers included in the HA solution.
The forwarded requests need to preserve the original Host header
Forward Proxy is not supported
There are no restrictions for the load balancing method and no requirements for persistency.
Configure HTTP Health Monitor for each VIP on the Load Balancer
Type → Use the HTTP monitor type
Port → Configure the port used in an integration action, i.e., 9090
Send string → Use the GET method against a PATH used in an integration action, i.e.,/listener/omi
Receive string → The monitor should expect the successful response HTTP 200 OK
Once the LB configuration is all set, use the LB VIP in the 3rd Party Integration system instead of the direct ZigiOps hostname and port number of the listener.
The below steps explain how to move the active ZigiOps between the Primary and the Backup servers when using a Load Balancer for integration actions triggered on HTTP Listeners.
Stop the Primary ZigiOps
Start the Backup ZigiOps
There should be only 1 ZigiOps instance active at the same time.