We've never used Omnibus specifically, but webhooks aren't really different than a normal API except that it's event driven instead of depending on a scheduled push/pull with the API. Without using the same terminology, a publish channel in Maximo is a webhook. When something happens to the record that matches what you have defined (such as PO approval), it triggers a message to another endpoint. In Maximo the other endpoint doesn't have to be a HTTP call (it could be table/file based), but otherwise it's a webhook. 

The reason you would use something like this (over scheduled push/pull) is you want something to be near real-time and don't want to be pulling from that system on a frequent basis. Think about a status page that depends on monitoring data for example. You could pull all the metrics every minute (or more frequently), but if the monitoring system supports a webhook approach they can inform your application whenever the state changes. Your application has the information almost immediately and you're not putting overhead on the monitoring system to constantly return data that typically hasn't changed.

In most SaaS solutions, APIs are also rate limited to restrict how often (or how many records) you can pull data from the API. Webhooks help you avoid that constant pulling. 

Hello Steven- Thanks for clarifying. Do we have any article describing how to create webhooks for external systema and get the get the webhook result pushed to Maximo.

We've never used Omnibus specifically, but webhooks aren't really different than a normal API except that it's event driven instead of depending on a scheduled push/pull with the API. Without using the same terminology, a publish channel in Maximo is a webhook. When something happens to the record that matches what you have defined (such as PO approval), it triggers a message to another endpoint. In Maximo the other endpoint doesn't have to be a HTTP call (it could be table/file based), but otherwise it's a webhook. 

The reason you would use something like this (over scheduled push/pull) is you want something to be near real-time and don't want to be pulling from that system on a frequent basis. Think about a status page that depends on monitoring data for example. You could pull all the metrics every minute (or more frequently), but if the monitoring system supports a webhook approach they can inform your application whenever the state changes. Your application has the information almost immediately and you're not putting overhead on the monitoring system to constantly return data that typically hasn't changed.

In most SaaS solutions, APIs are also rate limited to restrict how often (or how many records) you can pull data from the API. Webhooks help you avoid that constant pulling.