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:
| 1. | The front-end module's radioToSend Radio Buttons component response populates the destinationFieldForRadio  Hidden component in the back-end module. |
| 2. | The back-end module's ruleDecideCalc  Decisions component fires the appropriate calculation based on the radioToSend Radio Buttons response. |
| 3. | The calcHouse, calcCar, and calcBoat  Calculator components' result populates the insuranceRate Hidden component. |
| 4. | The front-end module’s pluginRemoteExecutePart1 Plug-In retrieves the insuranceRate data from the back-end module. |
| 5. | 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:
| 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. |
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.
| 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 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.
| 3. | Under Flags, select your desired options. |
| 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. |
Click Add Row 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. |
Here's a closer look at each setting on the Server Side Execution Testing page:
|
RequestWhen 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:
Request Info
Advanced Settings
ResponseThe 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:
There are three types of errors that you might see:
Here's an example of how the Response might look:
DebuggerClick 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:
Let’s look at the Debugger tool in action. For this example, you'll continue using the back-end module.
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. |
Save
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:
| 1. | Open your module in the Module Builder. |
| 2. | Click the ··· (ellipsis) button. |
| 3. | Select Service Logs.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
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:
| 1. | The front-end module's radioToSend Radio Buttons component response populates the destinationFieldForRadio Hidden component in the back-end module. |
| 2. | The back-end module's ruleDecideCalc Decisions component fires the appropriate calculation based on the radioToSend Radio Buttons response. |
| 3. | The calcHouse, calcCar, and calcBoat Calculator components' result populates the insuranceRate Hidden component. |
| 4. | The front-end module’s pluginRemoteExecutePart1 Plug-In retrieves the insuranceRate data from the back-end module. |
| 5. | 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:
| 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. |
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
|
RequestThe 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:
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.
Click Add Data Value if you need to add more data when selecting Enter as Key-Value. Or, click Delete to remove data.
Click Add Metadata Value if you need to add more data when selecting Enter as Key-Value. Or, click Delete to remove metadata.
ResponseThe 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:
There are three types of errors that you might see:
Here's an example of how the Response might look:
DebuggerClick 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:
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.
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
|
RequestLet'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:
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.
Click Add Data Value if you need to add more data. Or, click Delete if you want to remove data.
After clicking Execute, you see a Response tab ResponseThe 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:
There are three types of errors that you might see:
Here's an example of how the Response might look:
|
Resources
