Connector Error Log and Retry Walkthrough

Previously, we learned how to catch an error in a Connector and perform Connector Error Handling in a Tulip App. Now, we will touch on the specific use case of logging Connector Errors to a Tulip table and building a supervisor app which allows users to retry the failed connectors at a later time.

Log Connector Errors to a Tulip Table

Logging connector errors to a Tulip table is a useful technique to unblock users in an app and trigger later system processing.

1. Build connector error handling in an app.
2. Create a trigger to write data to a Connector Response Log table.
   a. Store the HTTP Response Code
   b. Store the HTTP Response Message
   c. Store any relevant station/user meta data needed
   d. Store any relevant API meta data needed (Example: work order number)

3. Allow users to continue with their app workflow, if the connector error is within expectations.

Example: An external ERP system is down while a work instruction app attempted to POST back flushing data. All data needed to POST is still available in Tulip and can be transacted later. The Tulip app then stores all the POST meta data (app variables + table placeholder data) to a table, then allows the player end user to continue with their work instructions.

Create a Supervisor App to Retry the Connector

While some users may now be unblocked due to the app level connector error handling, failed connector functions cannot automatically submit the data from Tulip to the external system. To perform this activity, you need to build a separate app.

In this Supervisor CRUD (Create, Read, Update, Delete) app, users with elevated privilege can read the failed connector transactions and choose to manually retry the connectors.

1. Create a new app named “Supervisor CRUD”.
2. Create a Read Error Log step, which allows the user to view all the Connector failed transactions.
   a. Embed an Interactive Table Widget
   b. Attach the Connector Response Log table to the this widget.
   c. Assign a Table Record Placeholder so that the Player end user can interact with the failed transactions.

3. Create a Update Error Log step.
   a. Display the table record placeholder and allow the user to confirm the details before retrying the Connector function.
   b. Create a Retry Connector button. Configure the trigger to call the connector POST function by leveraging the Connector Response Log table.
   

Create a condition where if the connector call issuccessful to delete the record from the Tulip Table.

Example: Later the ERP system comes back online. The supervisor then opens the Supervisor CRUD app they can read all the failed ERP POST transactions and manually retry the work order back flush activities.