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 Also known as Record Data. Submission data consists of information saved by Unqork components. View submission data by using the angular command, or in Record Collections.. You can also choose to overwrite existing data with new data. This 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. Change a value and the Debugger shows you how that change affects the rest of the application.

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

This tool is only available in non-production environments.

How the Configuration Works

For this how-to guide, your end-user End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. navigates to a front-end module in Express View Express View is how your end-user views your application. Express View also lets you preview your applications to test your configuration and view the styling. This is also the view your end-users will see when interacting with your application. After configuring a module, click Preview in the Module Builder to interact with the module in Express View.. Your end-user inputs insurance information into the module using Radio Buttons and Text Field components. When saved, the module's Plug-In component fires, calling the back-end module:

The front-end module's radioToSend Radio Buttons icon

Radio Buttons component response populates the destinationFieldForRadio icon

Hidden component in the back-end module.

The back-end module's ruleDecideCalc Decisions Component icon

Decisions component fires the appropriate calculation based on the radioToSend Radio Buttons icon

Radio Buttons response.

The calcHouse, calcCar, and calcBoat

Calculator components' result populates the insuranceRate icon

Hidden component.

The front-end module’s pluginRemoteExecutePart1 Plug-In retrieves the insuranceRate data from the back-end module.

The data populates the destinationForRateReturnedFromPart1

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. When testing API calls, you can also use the Service Logs tool to test and log each response.

To complete this how-to guide, you need:

EnablementLab_RemoteExecute1_BackEnd: This module represents the back-end functions. It also has the Module ID used by the Plug-In’s remote execute.
EnablementLab_RemoteExecute1_FrontEnd: This module represents the front-end functions. This is where the user selects the inputs for insurance cost calculations.

Copy and paste the module definitions of each lab into your UDesigner modules. To learn how to copy/paste module definitions, visit our How to: Copy and Paste Module Definitions article.

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:

Click the link to open the EnablementLab_RemoteExecute1_BackEnd module in the Module Builder: https://training.unqork.io/#/form/5d9e06f2b5871a004223b54e/edit.

At the top right of the page, click the Server Side Execution button.

You might need to enter your credentials to access the Server Side Testing Tools.

When you arrive on the page, you see the Request section and the Response and Debugger tabs. In the Request section of the page, enter the information to run your PUT API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. request. Running the Put request will upload the data from an existing module.

Server Side Execution Testing

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.

Enter the Submission ID for the submission where you want to run test data. Or, leave this field blank to create a new submission.

Under Data, select if you want to

Enter as Key-Value or

Enter as JSON. Then, enter the data that you want to test.

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

Under Flags, select your desired options.

Under Metadata, select if you want to

Enter as Key-Value or

Enter as JSON. Then, enter the metadata that you want to test.

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

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

Here's a closer look at each setting on the Server Side Execution Testing page:

Request

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. The Module ID is the only requirement for running a server-side test.
Submission ID	The submission ID of the submission data Also known as Record Data. Submission data consists of information saved by Unqork components. View submission data by using the angular command, or in Record Collections. 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.
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.
Delete	The Delete button removes the Data Key and Data Value fields from that row.
Add Row	This button adds another Data Key and Data Value field so you can enter more key/value pairs.
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

Setting	Description
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.

Advanced Settings

Setting	Description
Flags	There are three 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 setting is ☐ (unchecked).
Validate Data	This options shows errors for invalid data entries. By default, this setting is ☐ (unchecked).
Load Submission Data First	This option waits for submission data to load before executing any of the module's logic. By default, this setting is ☐ (unchecked). However, it's best practice to select this setting.
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.
Data Key	The Property ID for the metadata that you're testing.
Data Value	The metadata value you want to insert into the submission.
Delete	The Delete button removes the Metadata Key and Metadata Value fields from that row.
Add Row	This button adds another Metadata Key and Metadata Value field so you can enter in more key/value pairs.
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.

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.

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.

All data in this display window is green.

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.

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.

Queue

Shows the changes in logic happening next.

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

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

Data Key	Data Value
destinationFieldForRadio	boat
destinationFieldForNumber	20

Click Execute.

Click the Debugger tab.

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.

Service Logs Testing

If you're testing an API server side execute, you can run your tests on the Module Builder using the Service Logs pane. You can also open the Server Side Testing page from here by clicking the Open SEE Debugger button.

To open the Service Logs pane:

Open your module in the Module Builder.

Click the ··· (ellipsis) button.

Select .The Service Logs pane appears to the right of the Module Builder.

The Server Side Execute tool the Service Logs panel operates the same way as the Response tab in the Server Side Execution testing page. Click Run Now to initiate the test and view the result.

Service logs also allow you to store and render your tests in a dashboard. For more information on Service Logs, visit our Service Logs Dashboard Tool article.

Overview

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

This tool is only available in non-production environments.

How the Configuration Works

The front-end module's radioToSend Radio Buttons icon

Radio Buttons component response populates the destinationFieldForRadio icon

Hidden component in the back-end module.

The back-end module's ruleDecideCalc Decisions Component icon

Decisions component fires the appropriate calculation based on the radioToSend Radio Buttons icon

Radio Buttons response.

The calcHouse, calcCar, and calcBoat

Calculator components' result populates the insuranceRate icon

Hidden component.

The front-end module’s pluginRemoteExecutePart1 Plug-In retrieves the insuranceRate data from the back-end module.

The data populates the destinationForRateReturnedFromPart1

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.

To complete this how-to guide, you need:

EnablementLab_RemoteExecute1_BackEnd: This module represents the back-end functions. It also has the Module ID used by the Plug-In’s remote execute.
EnablementLab_RemoteExecute1_FrontEnd: This module represents the front-end functions. This is where the user selects the inputs for insurance cost calculations.

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:

Click the link to open the EnablementLab_RemoteExecute1_BackEnd module in the Module Builder: https://training.unqork.io/#/form/5d9e06f2b5871a004223b54e/edit.

At the top right of the page, click the Server Side Execution button.

You might need to enter your credentials to access the Server Side Testing Tools.

When you arrive on the page, you see three sections: Request, Response, and Debugger. In the Request section of the page, you see PUT and GET Request Methods. A PUT API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. 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. The Module ID is the only requirement for running a server-side test.
Submission ID	The submission ID of the submission data Also known as Record Data. Submission data consists of information saved by Unqork components. View submission data by using the angular command, or in Record Collections. 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 three 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 setting is ☐ (unchecked).
Validate Data	This options shows errors for invalid data entries. By default, this setting is ☐ (unchecked).
Load Submission Data First	This option waits for submission data to load before executing any of the module's logic. By default, this setting is ☐ (unchecked). 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.

Enter the Submission ID for the submission where you want to run test data. Or, leave this field blank to create a new submission.

Under Flags, select your desired options.

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

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

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

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

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

Debugger

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

All data in this display window is green.

Queue

Shows the logic happening next.

Execution

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.

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

Data Key	Data Value
destinationFieldForRadio	boat
destinationFieldForNumber	20

Click Execute.

Click Debugger.

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

The Execution section shows that calcBoat fired. Then, the insuranceRate changed from null to 60. So, 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

Let's 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 gain 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. 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 four 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.

Enter the Submission ID for the submission where you want to run test data. Or, leave this field blank to create a new submission.

Under Flags, select your desired options.

Under Data, enter the data that you want to test.

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

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

After clicking Execute, you see a Response tab

How to: Use the Server Side Execution Testing Page

Overview

How the Configuration Works

Accessing the Server Side Execution Testing Page

Server Side Execution Testing

Request

Request Info

Advanced Settings

Response

Debugger

Service Logs Testing

Overview

How the Configuration Works

Accessing the Server Side Execution Testing Page

PUT Server Side Execution Testing

Request

Response

Debugger

GET Server Side Execution Testing

Request

Response

Resources

Feedback

Sorry about that

Great!

Looking for more help?