Using a virtual ‘Tulip Machine’ to enable event-based Trigger logic in an app.
Background
Some Tulip customers have legitimate use cases wherein an operator-centric app needs to rapidly react to some context (i.e. some event) outside of: the app or any connected device or Shop Floor machine. In service of such use cases, some customers have developed Tulip apps that use high-frequency (i.e. less than 30 seconds) Timer triggers wherein a timer may be checking for some context (e.g. in a 3rd party system via a Connector Function, or a changed value in a Tulip Table record).
Problem Statement - High-Frequency Timer Triggers
A high volume of high frequency Timer-based triggers (especially those dependent on response from a 3rd party system or machine) can accumulate in the Trigger Queue faster than they can be executed.
Solution - Event-Based Triggers via a ‘Virtual’ Tulip Machine
Rather than using high-frequency Timer-based triggers to enable app triggers that respond to events that occur outside of the Tulip app, an alternative (and more reliable and resilient) solution consists of the following:
A virtual ‘Tulip Machine’ modeled to act as an event stream.
Machine Attributes mapped to the Tulip API
Usage of the Tulip Machine Monitoring API enabling Tulip Apps (or third party systems) to POST “events”.
Machine-based triggers in the relevant Tulip apps to initiate the logic related to the ‘event’.
High-Level Solution Architecture
Below you will find a high-level diagram of the components involved in implementing such a solution. Following the diagram is an itemized explanation.
“Event”: This is very much a case-by-case definition. An ‘event’ in this context might be an updated value in a Tulip Table Record, or new content in a third-party system.
Event Source: The ‘event’ may occur in a Tulip solution (Tulip app, Automation, or Function), or even a third-party system. The remainder of this explanation assumes the event occurs within Tulip. An event outside of Tulip would still use the ‘Machine Attributes API’ and an API Token with the ‘attributes:write’ scope, but not use a Connector nor Connector Function.
Tulip Machine ‘Event Stream 1’: This Tulip Machine acts as a conduit for event signals transmitted as values on the configured Machine Attributes.
Connector: “Event Stream”: This Connector is configured similar to a Tulip Table API Connector, however note that the Connector Function “Post Machine Attribute” uses the Machine Monitoring API endpoint POST /attributes/report which requires an API Token configured with the ‘attributes:write’ scope.
Machines Trigger: When the ‘Event Source’ POSTs a new ‘event’ via the Machine Monitoring /attributes/report API, a Tulip app can then initiate a Machines trigger to perform the necessary logic.
Did you find what you were looking for?
You can also head to community.tulip.co to post your question or see if others have faced a similar question!
.gif)
.gif)