
Problem
I'm currently relying on a load testing tool based on chains of HTTP requests, instead of a browser-like environment. I'd like to build load testing scripts for Appway. I can display pages and start processes – but am finding action in the pages hard to reconstruct. What messages do I need to pass to make the system execute a process action or an AJAX update area, for example?

Solution

- Component path: On which component has the event been triggered? Example: "/0/16/32/77"
- Event type: What kind of event has been triggered? Examples: "onclick" or "onchange"
- (optional) Additional event- or component-specific parameters
The "__events__" field
Every Workspace form contains a hidden field with name "__events__". This hidden field is used to submit events to the server. Initially (immediately after rendering), the field value is always empty. If the field has a value, it must have the following format:
Two example values:
Now, how do these values get into the hidden field? This is where the JavaScript function "queueEvent" comes into play. If a component has at least one server-side action attached to one of its events, the component renderer has to generate JavaScript code that is executed when this event is triggered. The JavaScript code usually contains a call to "queueEvent(...)", passing the component path of the current component and the event type as parameters.
Example: A server-side action attached to the "onclick" event of a button could generate the following HTML and JavaScript code:
The implementation of the JavaScript function "queueEvent" is trivial. It simply appends the parameters to the value of the hidden field "__events__", in the format described above. The following call to "exec()" triggers the submission of the form. The value of the hidden field is then submitted to the server together with all other values of input elements.
No matter how many server-side actions you attach to a certain event on a component, there is always only one call to "queueEvent". What is transferred to the server is only the information on what event has been triggered on which component. Appway then executes all server-side actions attached to that event for the given component.
Simulating requests
In order to simulate such requests, one first has to know the component path of the target component. Component paths are generated dynamically at runtime. The simple rule is that it is a path-like string concatenating the IDs of all parent components and the ID of the component itself.
However, several components influence the component path in different ways, for example by adding additional path elements. Includes and template screens also have a huge impact on the component paths.
It is almost impossible to deduce the component path for a certain component at design time. But parsing the HTML code for occurrences of "queueEvent" and extracting this information should be almost trivial.
- Parse the HTML code and find the HTML element representing the button or link.
- Find the JavaScript event handler code on that element
- Extract the component path, event type and potential parameters from the call to "queueEvent(...)"
- Join these values with a comma as separator
- Submit the result as value for the HTTP parameter "__events__"
Example: Simulate a click on the button with ID "NextStep".
The HTML code for this button could look like this:
The JavaScript event handler "onclick" contains a call to "queueEvent(...)" with the following values:
• Component path = /0/38/182/19
• Event type = onclick
The HTTP request sent to the server then should contain a parameter "__events__" with the following value:
AJAX Update Requests
AJAX update requests are pretty similar. From the server's perspective, such a request is almost identical to a regular form submission. If the user has triggered any server-side actions at the same time, information about the events is transported to the server in the same way as described above (as value of a parameter "__events__").
The only difference is an additional parameter, "ajaxUpdateAreaIds", containing a list of HTML IDs of areas that should get updated. Appway performs exactly the same steps as for a regular submit: update, validate, process, render. The main difference is that after generating the HTML code, Appway extracts the HTML snippets for the given areas and returns them as part of a JSON-formatted response.
So, if requests get simulated with a tool like JMeter, a request for a regular submit and an AJAX update look the same, except for the additional parameter "ajaxUpdateAreaIds".

Comments (0)