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.
NOTE 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.
IMPORTANT This tool is only available in non-production environments.
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 you 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:
| 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 retrieves 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 Need
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:
| 1. | Click the link to open the EnablementLab_RemoteExecute1_BackEnd module in the Module Builder: https://training.unqork.io/#/form/5d9e06f2b5871a004223b54e/edit. |
| 2. | At the top right of the page, click the Server Side Execution button. |
NOTE 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. NOTE 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.
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.
| 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:
|
|
Response Body |
Displays 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 three 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 four flag options for signaling a specific function on the Testing page. |
|
Save |
This option saves data to Unqork’s 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:
|
|
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
