3 of 3 people found this helpful
With event integrations, there are always two options: push or pull. The method Roland suggests is a pull, meaning your third-party tool would poll (request) events from TSOM on a schedule using the TSOM REST API. This approach makes sense if your third-party tool is programmable enough that it can map the TSOM event slots to its native event format. The disadvantage of the pull method is that it introduces latency (delay). If the third-party tool requests events from TSOM every 60 seconds, events may wait in TSOM for a full minute before the third-party tool receives them. It is up to you to decide if that delay is acceptable.
TSOM also offers a push method of forwarding events to third-party tools with its Publish-Subscribe REST API. This API allows you to create a subscription which will cause TSOM to send selected events to a third-party REST endpoint using the HTTP POST method. The advantage of this approach is that events are sent immediately. The third-party tool doesn't have to request them. The disadvantage is that the third-party tool has to translate the TSOM event attributes to its native format. TSOM's Publish-Subscribe facility does not provide a data mapping function.
One solution to the data mapping problem with the Publish-Subscribe approach is to create a shim, a software server that sits between TSOM and your third-party tool. The shim would receive events from TSOM, translate the event attributes to the format required by the third-party tool and then forward the re-mapped event to the tool. The main disadvantage of this approach is that someone has to write the shim. It would require some custom code. It's not a big job, but it requires someone with development skills.