Storing a last modified time stamp on a solution instance

Tracking a last time modified time stamp and other various information on a solution instance when it is modified can be implemented through the use of a single workflow in Tray and the Tray Embedded API.

Workflow Preparation

To store a last modified time stamp, you will first need to make a config property of type string and expose it in the Config Wizard. Then you will need to move this config property to the Hide from users section.

Be sure to take note of the External ID of this config property because you will need to use that in the GraphQL query later in the blog.

The next action you will need to take is to create an authentication using the Generic Service.

This authentication will house the master token needed to perform API calls against the Tray Embedded API.

Note: After creating this authentication and using it in the workflow you will make in the next section, you will need to move the auth slot to the Hide from users section.

The Workflow

The workflow will consist of four steps: (1) Solution Instance Trigger, (2) Retrieve User Token, (3) Get Current Time Stamp, and (4) Update Last Modified Property.

Solution Instance Trigger

The workflow needed here will be triggered by the Solution Instance trigger.

This trigger will be fired off when modifications are made to a solution instance such as:

• config or auth data of an instance is updated

• an instance is enabled (but not when it is disabled)

These events can occur when you programmatically update the solution instance via the Tray Embedded GraphQL API or when your end-user runs (or re-runs) through the Config Wizard.

The trigger provides you with a lot of handy information such as the impacted instance ID along with snapshots of the updated auth and config data and the previous auth and config data prior to the workflow being triggered.

For more information on the Solution Instance trigger, read our documentation here.

When you insert the trigger, be sure to navigate to the properties panel on the right hand of the screen and set the Updated property to true. Doing so will allow this workflow to be executed when the solution instance is updated.

Retrieve User Token

For this step, you will insert the GraphQL Client connector. You will then attach the authentication that you created earlier to this connector.

The Tray Embedded API GraphQL endpoint is https://tray.io/graphql. You will pass the master token from the authentication in the Header of the request like in the above image.

You will need to retrieve the Tray User ID to pass into the GraphQL mutation. To do so, you will reference the env property to gain access to that ID. You can read more on what is available in the env property in our documentation here.

Finally, you will need to set the query to be the above mutation. The output of this connector will be an access token that we will use in a later step to be authorized to perform an update to the solution instance.

Get Current Time Stamp

Now you will insert the Date Time Helpers connector using the Get current time stamp operation to retrieve the current execution time stamp in whatever date time format you wish to use.

Update Last Modified Property

The last step of this workflow will require you to insert the GraphQL Client connector again. Since you will not be using the master token from your Tray Embedded API authentication you made earlier, there is no need to attach the authentication to this step. Instead, you will use the access token generated from the previous GraphQL Client connector for authorizing access in the Header.

A sample mutation can look like the above. Note that you do not have to return all of this superfluous data if you choose not to do so.

The externalId will be equal to the ID you took note of in the Workflow Preparation section.

Conclusion

That's all there is to it for storing a last modified time stamp on a solution instance. Having this information can be handy in debugging erroring solution instances that suddenly stopped working. You can take this concept further and store previous state information that is available in the output schema of the Solution Instance trigger. Perhaps trigger other events whenever an instance changes!