Counterparty API call from Teamogy

The following chapters will describe the Teamogy in the role of the client which calls API of the counterparty's server. Thus, if a configured event (trigger) occurs, a request (ie data in the configured form) is sent from Teamogy, which the other party receives and responds to the request. Teamogy processes the response and, depending on the configuration, saves the response data into sent entity.

Detailed description of the transaction

Trigger configuration
You can configure a trigger for each entity. Once the trigger has been positively evaluated (the entity properties have taken the desired value or the trigger has been triggered by another process), the integration transaction processing is started.
The Configuration Register in the Teamogy system for configuring the Trigger of the entity is called "CONNECTOR.RULE-{entity}"

Connector configuration
The first thing that is evaluated is whether an Integration Adapter is connected to the entity's connector. If the Adapter is not connected, the transaction is terminated. If an Adapter is connected, the transaction continues processing in the Adapter. Multiple Adapters can be connected to a single connector. In this case, the transaction is split and processed by all connected Adapters.
The Configuration Register in the Teamogy system for configuring the Connector of a given entity is called "CONNECTOR-{entity}"

Adapter configuration
The adapter has configured in it how the given transaction will be integrated with the counterparty.

request method (POST, PUT, GET ...)
request url
request header parameters
Configuration register for processing the request body (Template configuration)

Template configuration
Teamogy works with a templating system that can be used to convert the internal format of the Data Entity (INPUT RAW JSON) into the desired format required by the API of the counterparty. The output format can be JSON or XML.

Queue
Once a request is compiled into an output format it goes to the output queue where it waits to be processed. When inserted into the queue, it is set to be processed immediately.
When it is queued (usually in couple of seconds) the first attempt to send is made.
In the event that sending the request results in an error or timeout, the request is queued for another send attempt as follows:

2nd attempt to send 5 minutes after the 1st attempt
3rd attempt to send 60 minutes after the 2nd attempt
4th attempt to send 24 hours after the 3rd attempt.
If even the 4th attempt to send data results in an error or timeout, it is considered a final error and the request is removed from the queue.

If the request is sent without errors and a positive response is returned (status 200), Teamogy proceeds to process the response

Adapter configuration
The adapter is configured to handle the response from the other side. Typically, there is configured behavior for the following cases

if a positive response is returned, the properties from this response can be written back to the default data entity
if a negative response (error) is returned, the entity owner can be notified of the error and the error is also indicated in the data entity.