TULIP DOCS
Home/Models/M_TRIGGER

Trigger

In the Tulip system there are many types of trigger events, “When” clauses, and many types of actions “Then” clauses. Many inputs events also contain data that can be referenced in the “if” or “then” clause. For example a barcode scan event contains the scanned value. An if statement might check this value and go to a different step if it contains some substring and go to another step if it does not. Multiple If statements can be grouped together as a single check, and set to be true whether ANY or ALL of the clauses is true. If the if statement block does not evaluate to true, the Tulip system will then check in order if there is another “If else” or “else” clause. This diagram clearly shows the how the flow of execution of a trigger is defined:

Example values and outcomes:

  • "rye bread" => go to step "bake bread"
  • "strawberry ice cream" => go to step "make ice cream"
  • "ice cream grain" => go to step "welcome page"
  • "something random" => go to step "welcome page"

The Tulip system provides many logical operations according to value type. In the above example "contains", "starts with" and "ends with" are all string operations. Note, when defining logic in if and then clauses there are several types of values an application creator can utilize:

  1. Static value - the app creator checks a value against a number they have specified in the trigger before run time.
  2. Variable - the app creator can compare one variable to another variable
  3. Expression - the app creator can use the expression editor to compare one variable to a computed value on any number of other variables and static values.
  4. Last machine output - If the "when" clause is based on a device event that has a value, this value can be referenced. Throughout this document when there is reference to users working with values, "value" can refer to one of these four types.
  5. Users - the app creator checks a value against a default or custom user field of the logged in operator or a specified user.
  6. Tables - the app creator checks whether or not a table contains a record according to specific criteria. The current checks available are 'contains record with id' & 'does not create record with id'.

There are two types of triggers: those that are configured at the app level and those that are configured at the step level (which might also be the master step).

App Triggers There are three app level triggers: On app start, on app complete and on app cancel. App start fires before any other trigger type, and app cancel and complete fire after any other trigger type. Users define app triggers on the app tab of the context pane.

Step Triggers There are four types of step level triggers: On step enter, on step exit, widget triggers and device triggers.

  1. On step enter - this trigger will fire each time a user enters the step containing the trigger.
  2. On step exit - this trigger will fire each time a user exits a step containing the trigger.
  3. When a widget is clicked - Buttons and images can be assigned triggers that fire when they are clicked.
  4. When a device fires an event - There are many device types, but only certain ones can be plugged into a tablet running the Tulip Player. For more sophisticated device integrations one needs to configure a Tulip Gateway. Relevant devices:
    • Barcode scanner - the barcode scan event will contain the scanned value as a string variable.
  5. When a timer interval is passed - Users can define timer triggers that fire according to a specified interval. The options are: 10s, 30s, 1 minute, 5 minutes or
  6. On machine event - When a machine emits an event.

Available transition actions:

  1. Go to step - Users can enter the step name or select next or previous as defined in the step list panel.
  2. Cancel application execution - this will trigger saving all of the variable data, and metadata about the execution to postgres, but it will also save a boolean value to indicicate the application was CANCELLED.
  3. Complete application execution - this will trigger saving all of the variable data, and metadata about the execution to postgres. As soon as the backend record is stored the data is available in analytics.
  4. Change application The ‘cancel application’ and ‘complete application’ actions both have an option to change applications. If this action is selected the system will route to the application selected in the trigger. It will open the application to the version assigned at the station. If there is no assignment of the application at the station, then it will open the most recently published. If there is no published version then the system will error.

There are two categories of actions that triggers can cause: transitions and actions. Transitions are changes to the flow state of the app, either going to a different step or canceling or completing the app. In a trigger there can only be one transition per action section. Once a transition has been executed by the app, any triggers for that same event will not fire. For example, if a user defines two separate triggers for a barcode scan and they both contain a transition, only the first to execute will be run.

Available regular actions:

  1. Arrays
    • Clear array clears the values stored in an array
    • Concatenate array Combines a source array with a destination array
    • Get from index in array Gets the item at the specified index from an array
    • Get length of array Returns a number that corresponds to the number of items in the array.
    • Join to string Returns a string of all values combined by a specified delimiter.
    • Pop from array Returns the last item of an array and removes it from the array.
    • Push onto array Adds and item to the end of an array.
    • Set index in array Adds an item at the specified index. If there was already an item at that index it will be overwritten.
  2. Data manipulation
    • Store in Variable - users can specify a new value to save to a variable in the context of the execution.
    • Increment Variable - returns the result of .
    • Decrement Variable - users can add a value to a variable.
    • Clear Variable - the variable will be set to undefined value.
  3. Logout current user - logout the current user and cancel the current app execution.
  4. Open link - open the specified link in another window.
  5. Play sound - play a short audio snippet. Options include: Warning, Overtime, Doorbell, Three notes, Xylophone.
  6. Player menu - bring up the player menu to a specific section. 3 options are comments menu, paused, or regular menu.
  7. Print using system dialog - bring up the system print menu for the current step
  8. Run connector function - users can select from one of the connector functions defined within the system, and specify which variable to save the results to. For more information on connector functions see 17 Connector functions.
  9. Run device function - users can select from the set of device integrations available in the Tulip system.
  10. Select default button - this will cause the player to select the default button if one has been defined for that step.
  11. Send email - sends an email to the user specified with the specified message in the email body.
  12. Send SMS - sends an SMS to the user specified with the specified message as the content of the SMS.
  13. Send SMS With Image - sends an SMS to the user specified with the specified message and specified image as the content of the SMS.
  14. Show error - Brings up the error toast in the player with the specified message.
  15. Show message - Brings up the message toast in the player with the specified message.
  16. Sleep - Pauses the player for the specified number of seconds.
  17. Split string - A function that takes two strings, the 'split' string and the 'by' string, and returns an array of strings that can be saved to a variable. The resulting array splits the split string by every isntance of the by string.
  18. Table records - a collection of actions for how apps utilize table 'record placeholders. The four possible actions:
    1. Create record - This trigger takes an id for the new record, and an indication of which record placeholder to save the record into. If the id matches a record that already exists in the table this trigger will return an error. If the record is sucessfully created that record is set as the value of the record placeholder.
    2. Create or load record - This trigger takes an id for the record, and an indication of which record placeholder to save the record into. If the id matches a record that already exists in the table this record will be set as the value of the record placeholder. Otherwise a new record is created and set as the value of the record placeholder.
    3. Delete record - This trigger takes an id and an indication of which table the record is within. If the record contains a record with a matching id it is deleted, otherwise no action is taken.
    4. Load record - This trigger takes an id for the new record, and an indication of which record placeholder to save the record into. If the id matches a record that exists in the table, that record is saved to the placeholder. If no record is found an error is thrown.