How to: Use the Server Side Execution Testing Page

Overview

The Server Side Execution Testing page simulates a submission’s remote execution. This page gives you the freedom to test data without impacting the module or submission. You can also choose to overwrite existing data with new data. The testing page is a great way to test your module while you build. It also lets you mimic a remote execute without configuring a Plug-In component.

The Debugger tool is a part of the Server Side Execution Testing page. It shows every step of your module’s remote execution. It’s simple; you change a value, and the Debugger shows how that change affects the rest of the application. 

NOTE  We use the terms server-side execute and remote execute the same way. They both mean that Unqork executes the module behind the scenes and on the server.

For this how-to guide, your end-user navigates to a front-end module in Express View. Your end-user inputs insurance information into the module using radio buttons and text fields. When saved, the module's Plug-In component fires, calling the back-end module:

1. The Radio Buttons response populates the destinationFieldForRadio Hidden component in the back-end module
2. The Decisions component fires the appropriate calculation based on the Radio Buttons response. 
3. The Calculator component's result populates the insuranceRate Hidden component.
4. The front-end module’s Plug-In pulls the insuranceRate data from the back-end module
5. The data populates the Text Field component in the front-end module.

Your end-user then receives their insurance rate.

Because you’re mimicking a remote execute, use the Debugger tool on the back-end module. The Debugger lets you see how the module behaves as you input data.

What You'll Learn

In this how-to guide, you’ll learn to use the Server Side Execution Testing page.

What You Need

To complete this how-to guide, you need:

Accessing the Server Side Execution Testing Page

To run the Debugger tool, open the Server Side Execution Testing page. 

To open the Server Side Execution Testing page:

1. Click the link to open the EnablementLab_RemoteExecute1_BackEnd module in the Module Editor: https://training.unqork.io/#/form/5d9e06f2b5871a004223b54e/edit.
2. At the top right of the page, click the Server Side Execution button.

When you arrive on the page, you see 3 sections: Request, Response, and Debugger. In the Request section of the page, you see PUT and GET Request Methods. A PUT API (application programming interface) request updates data and a GET API request retrieves data. Because the Server Side Execution Testing settings change depending on the Request Method, let's look at those settings separately.

PUT Server Side Execution Testing

Request

The PUT Request Method is the default. When you arrive on the page, the module ID automatically populates. This module ID is all you need to test data with the Debugger tool. Here's how the Server Side Execution Testing page looks:

There are a variety of ways to test your module's data. The following settings help you create your test:

Setting Description

Module ID

The ID for the module you want to run server-side.

NOTE  The Module ID is the only requirement for running a server-side test.

Submission ID

The submission ID of the submission data you want to test.

Entering a submission ID here requires an Edit Submission function from an Initializer to trigger the process. The submission ID will remote execute, and then call the submission. To avoid this issue, enter the submission ID in the Data Key or Data Value fields below. Entering the submission ID as a Data Key/Value triggers a New Submission.

Flags

There are 3 flag options for signaling a specific function on the Testing page.

Save

This option saves data to Unqork’s database.

  • If you enter a Submission ID and click Save, the data you enter overwrites that submission data.
  • If you click Save with no Submission ID, Unqork creates a new submission ID from your data.
  • Leave this box clear to test data without saving it to the database.

By default, this checkbox is clear.

Validate Data

This options shows errors for invalid data entries.

By default, this checkbox is clear.

Load Submission Data First

This option waits for submission data to load before executing any of the module's logic.

By default, this checkbox is clear. However, it's best practice to select this setting.

Data

If you choose to test specific data, you have the option to enter key/value pairs or JSON.

Enter as Key-Value

Selecting this option lets you enter a key and value to test.

Data Key

The Property ID for the data that you're testing.

Data Value

The Data value you want to insert into the submission.

Add Data Value

This button adds another Data Key and Data Value field so you can enter more key/value pairs.

Delete

The Delete button removes the Data Key and Data Value fields from that row.

Enter as JSON

You can easily handle larger calls by entering them between curly braces in the JSON field. This field is helpful if you want to test data types that aren't strings.

You can also use this field to test inputs copied from your DevTools Console, request bodies, or service logs. Copy your object from the source. Then, paste it into the JSON field and execute a test.

Metadata

If you choose to test specific metadata, you have the option to enter key/value pairs or JSON.

Enter as Key-Value

Selecting this option lets you enter a metadata key and value to test.

Metadata Key

The Property ID for the metadata that you're testing.

Metadata Value

The metadata value you want to insert into the submission.

Add Metadata Value

This button adds another Metadata Key and Metadata Value field so you can enter in more key/value pairs.

Delete

The Delete button removes the Metadata Key and Metadata Value fields from that row.

Enter as JSON

You can easily handle larger calls by entering them between curly braces in the JSON field. This field is helpful if you want to test data types that aren't strings.

You can also use this field to test inputs copied from your DevTools Console, request bodies, or service logs. Copy your object from the source. Then, paste it into the JSON field and execute a test.

Request Info

Expanding Request Info shows the Request URL and Request Body.

Request URL

The request URL from your module. It populates automatically as: /fbu/uapi/forms/{moduleId}/execute.

Request Body

The request body from your module.

When you open the Testing page, your module’s ID populates in the Module ID field. You can then customize the settings as you see fit.

1. Enter the Submission ID for the submission where you want to run test data. Or, leave this field blank to create a new submission.
2. Under Flags, select your desired options.
3. Under Data, select if you want to Enter as Key-Value or Enter as JSON. Then, enter the data that you want to test.

NOTE  Click Add Data Value if you need to add more data when selecting Enter as Key-Value. Or, click Delete to remove data.

4. Under Metadata, select if you want to Enter as Key-Value or Enter as JSON. Then, enter the metadata that you want to test.

NOTE  Click Add Metadata Value if you need to add more data when selecting Enter as Key-Value. Or, click Delete to remove metadata.

5. Click Execute. The module executes with new data based on your chosen preferences. 

Response

The Response tab has the same information that you find in the DevTools Network Panel in Express View. If there’s an error in your execution, you’ll see it here.

Let’s look at the settings in the Response:

Setting Description

Response Status

HTTP response status codes. The codes you'll see in Unqork are:

  • 200-299: Success

  • 300-399: Redirect

  • 400+: Error

Response Body

Shows details of the status code. This is the same information that you find in the Network Panel of DevTools during the flow of the application. If there’s an error in your execution, you see that here.

There are 3 types of errors that you might see:

  • Remote Execute Failed.
  • Integrator Error - plugin failed.
  • Validation Error - submission data is invalid (optional based on Validate Flag).

Here's an example of how the Response might look:

Debugger

Click the Debugger tab to see every step of your module’s remote execute. At the bottom of the page, you’ll see a slider. The slider lets you move through the details of each step of the test. Step 0 is the start of a new submission.

NOTE  If you have any issues loading the Debugger, check for an error in the Response Body under the Response tab.

Let’s look at the settings in the Debugger:

Setting Description

Step Submission

Shows the exact data at each step of the module's process. The display window changes as logic executes. Regardless of the data updated, variables remain. You can find them at the bottom of the display window.

NOTE  All data in this display window is green.

Queue

Shows the logic happening next.

Execution

Shows the logic executed during this step. If information is in red font, you can click it to see the rest of the information. This is typical for information from a Data Workflow. Clicking the link shows you everything you expect to see in the DevTools Console. You can use this display window to help find and fix issues with your module.

NOTE  If your information is too long for the window, you'll see it truncated with an ellipsis (...). You can find the full information in the Step Submission display window.

This is how your Execution window might look if you execute a Data Workflow. Clicking the red text opens a pop-up modal with the full information. You'll also notice that the SET information is too long for the window and is truncated with an ellipsis (...). Again, you can find this full information in the Step Submission window.

Let’s look at the Debugger tool in action. For this example, you'll continue using the back-end module.

1. Enter the following test data in the Data Key and Data Value fields:
Data Key Data Value

destinationFieldForRadio

boat

destinationFieldForNumber

20

2. Click Execute.
3. Click Debugger.

When you open the Debugger tool, you see the following:

The Execution section shows that calcBoat fired. Then, the insuranceRate moved from null to 60. So, here's what we know from this information. If the end-user inputs information on a boat that’s 20 years old, they’ll see $60 in the front-end as their Insurance Rate. The Debugger tool shows how the module's logic responds to the test data.

GET Server Side Execution Testing

Request

Now, look at the settings that you can configure if you select the GET Request Method. After selecting GET from the Request Method, the Module Name field displays in place of the Module ID. Here's how the Server Side Execution Testing page looks after selecting the GET Request Method:

It's important to note that the Debugger is not available for the GET request method. But, like the PUT request, there is other information you can get from your module. The following settings help you manipulate the information:

Setting Description

Module Name

The title for the module you want to run server-side.

NOTE  The Module Name is the only requirement for receiving a server-side response with the Get request method.

Submission ID

The submission ID of the submission data you want to test.

Entering a submission ID here requires an Edit Submission function from an Initializer to trigger the process. The submission ID will remote execute, and then call the submission. To avoid this issue, enter the submission ID in the Data Key or Data Value fields below. Entering the submission ID as a Data Key/Value triggers a New Submission.

Flags

There are 4 flag options for signaling a specific function on the Testing page.

Save

This option saves data to Unqork’s database.

  • If you enter a Submission ID and click Save, the data you enter overwrites that submission data.
  • If you click Save with no Submission ID, Unqork creates a new submission ID from your data.
  • Leave this box clear to test data without saving it to the database.

By default, this checkbox is clear.

Validate Data

This option shows errors for invalid data entries.

By default, this checkbox is clear.

Load Submission Data First

This option waits for submission data to load before executing any of the module's logic.

By default, this checkbox is clear. However, it's best practice to select this setting.

Show Operations

This option shows the progress of each operation that runs in your module. It creates timestamps of the starting and ending times of your operations.

By default, this checkbox is clear.

Data

If you choose to test specific data, you have the option to enter key/value pairs or JSON.

Data Key

The Property ID for the data that you're testing.

Data Value

The Data value you want to insert into the submission.

Add Data Value

This button adds another Data Key and Data Value field so you can enter more key/value pairs.

Request Info

Expanding Request Info shows the Request URL and Request Body.

Request URL

The request URL from your module. It populates automatically as: /fbu/uapi/forms/{moduleId}/execute.

When you open the Testing page, your module’s name populates in the Module Name field. You can then customize the settings as you see fit.

1. Enter the Submission ID for the submission where you want to run test data. Or, leave this field blank to create a new submission.
2. Under Flags, select your desired options.
3. Under Data, enter the data that you want to test.

NOTE  Click Add Data Value if you need to add more data. Or, click Delete if you want to remove data.

4. Click Execute. The module executes with new data based on your chosen preferences. 

After clicking Execute, you see a Response tab

Response

The Response has the same information that you find in the DevTools Network Panel in Express View. If there’s an error in your execution, you see it here.

Let’s look at the settings in the Response:

Setting Description

Response Status

HTTP response status codes. The codes you'll see in Unqork are:

  • 200-299: Success

  • 300-399: Redirect

  • 400+: Error

Response Body

Shows details of the status code. This is the same information that you find in the Network Panel of DevTools during the normal flow of the application. If there’s an error in your execution, you see that here.

There are 3 types of errors that you might see:

  • Remote Execute Failed.
  • Integrator Error - plugin failed.
  • Validation Error - submission data is invalid (optional based on Validate Flag).

Here's an example of how the Response might look:

Resources