How to test Serverless Functions

Use the serverless function editor's built-in test view to run your function against document content or status events and inspect the output and logs before deploying.

In order to speed up the deployment of a serverless function on your queue, the function editor includes a test view.

Figure 1. Function testing framework.

With such a framework, you can code your function, select a testing input, and run the function on the test input to see what the function would return.

The right-side OUTPUT section also includes a log view that captures the stdout and stderr of the code. In particular, all print statements and exception tracebacks are visible there. This output is also available during normal operations. Navigate to Extensions > Logs, and check the output key in the Details tab for the given hook event log entry.

By default, we have provided two testing inputs for the following events:

  • Document content event—Contains captured data from the document. This event can also contain the updated_datapoints key when a user updates a field value or clicks a button.
  • Document status event—Contains information about a document switching from one status to another.

Testing document content event

When testing the document content event, the scenario is usually the following:

  • Parse the content of an annotation.
  • Process the content in the function.
  • Show user messages or data updates in Rossum.
Figure 2. Testing document content event.

The output in the right box represents the output of your function. This is the data that Rossum processes to perform an action. Rossum can show the user messages on specific datapoints, replace the values of existing datapoints, or add new ones.

In this specific case, a warning message is displayed to the user on datapoint 332584071, and the value of the datapoint with ID 332573383 is replaced with ID143453775.

Testing document content event on custom input

When your queue is already set up, you might want to generate the sample input from your test document and customized schema. In the bottom-left input bar, paste the annotation URL (both app and API URLs are accepted), or enter the annotation ID. A sample event JSON automatically loads, including all the sideloads you configured.

Then, click the run button to see the output of your function based on your custom data.

For future use, you can save the test input by clicking the Save changes icon. When you open the function again, your custom input appears in the left box.

Figure 3. Saving custom input.

Testing document status event

The structure of a document status change event is always the same. You can check its values in the description of the events. Usually, the most important values are the status and previous_status keys, which you can use to filter for the statuses on which you need to perform an action.

To get the exact content sent in a document status change event, create a webhook object, assign it to a queue, and then open or postpone a specific annotation as described in Rossum webhook. This pushes a notification to webhook.site, where you can see the exact content sent to a hook.

You can ignore the messages and operations shown in the right box because Rossum does not process responses for document status change events.