The Solution Alert Trigger
In order to be alerted about any errors that are occurring with Solution Instances / Solutions / Workflows it is possible to build an Alerting Workflow which makes use of the Solution Alert Trigger.
This is useful in terms of a 'helicopter view' of the overall health of your projects - which solutions and solution instances are causing problems.
There are two steps to setting up Error Alerting:
Create the Solution Alerting Workflow (multiple alerting workflows can be created)
In your Embedded account, set the Solution Alerting Workflow which will be notified when there are any errors occuring within your Projects
Note in Tray it is also possible to specify the Alerting Workflow to notify for each individual workflow you create. In order to receive Alerts at Team level you should not do this. You should set it in your Embedded Account, as will be illustrated below.
Create a Solution Alerting Workflow
First of all, create a new workflow and select the Solution Alert Trigger:
From the above screenshot you will see that one way of creating an alerting workflow is to parse the error output data from the trigger step into a Slack message (you could also, for example, set up an email alert to receive the information). You can manipulate and use the output data in any way you wish, using the Tray connectors and helpers you have at your disposal.
The trigger output can be picked up with the following jsonpath structure:
Note that the above example shows how you can parse the data into a plain text 'Message' box.
To see what output is available from the trigger, you can select the Solution Alert trigger and click on the Output data tab:
The following table gives a breakdown of the output data which is returned by the Solution Alert Trigger:
|workflow_uuid||The UUID of the instance workflow which sent the error|
|workflow_url||The URL of the instance workflow which sent the error|
|workflow_title||The title of the instance workflow which sent the error|
|step_name||The name of the specific step which was the cause of the error. Note that this is not the user-configured name but the unique name given by Tray|
|step_log_url||This URL can be used to go directly to the point in the logs at which this error occurred|
|connector||The type of connector (and version) that caused the error|
|user_id||The unique User ID assigned by Tray.io when an End User is created|
|user_external_id||The ID created by you to link and End User to their entry in your external database|
|solution_id||The ID of the Solution which sent the error|
|solution_instance_id||The ID of the Solution Instance|
|source_workflow_uuid||The UUID of the source workflow which sent the error|
|message||The internal Tray-generated error message|
|created||A timestamp of when the error occurred|
Your alerting workflow can make use of these fields to provide useful information for debugging.
Workflows with an alerting trigger behave just like any other workflow. You can build any logic you like into your workflow to handle the incoming errors.
Specify the Solution Alerting Workflow in your account
In your account you can go to profile settings to set the alerting workflow which will be handling any errors associated with your Projects, Solutions and Workflows:
Note that only Workflows with a Solution Alert Trigger will appear in this list.