JMeter RTE Plugin v3.0
Recording & VT-420 Support
We are excited to announce the release of RTE Plugin v3.0 with support for script recording and an additional protocol: VT-420
Two years ago, we published two articles: Using JMeter's RTE Plugin and Introducing JMeter Mainframe Testing With The New RTE Plugin which introduced testing mainframe applications, remote terminal emulators, and the RTE-Plugin itself. Make sure to review these articles if you are new to our RTE Plugin.
Let’s start by covering all the new functionalities with a login flow for our newly supported protocol, VT420
RTE Plugin usage example
In the following sections, we will be working with a Login Flow, which will take us from setting the variables in the app, interacting with the emulator, and multiple new features along the way.
RTE-Plugin not installed?
- Go to JMeter Plugins to download the Plugin Manager, follow installation instructions.
- Once the Plugin Manager is installed, open JMeter and navigate to Options → Plugin Manager.
- Click on available plugins, type on the search bar for RTE-Plugin, check the belonging box, and click on "Apply Changes and Restart JMeter".
We highly recommend using the provided JMeter template in order to follow our best practices. The template contains everything you would need to record a mainframe scenario.
The RTE Template will automatically add all the components.
- Thread Group: needed to contain samplers, controllers, listeners, and also for later load charge (if desired).
- Recording Controller: component in charge of sampler storage during recording. Additionally, if we need to delete samplers (because of a wrong flow while recording or any other issue) you can just click on Clear all the recorded samples
- View Result Tree:
- Embedded in Thread Group: useful to visualize all requests while Test Plan is running
- Embedded in RTE Recorder: useful to visualize requests made while recording
Since version 2.0, this component was introduced as part of several features which allow you to interact with mainframe applications through a terminal emulator. It supports tn3270, tn5250, VT420 protocols, and, while interacting with it, every step you make will automatically be recorded into your Test Plan, allowing you to run functional and load tests later on.
The RTE-Recorder contains 3 buttons to switch between states:
- Start: will display the terminal emulator when the connection is established.
- Stop: will close the terminal emulator, stop the recording, and add a disconnect sampler to indicate the end of the flow. Additionally, if the emulator window is closed manually, the plugin will behave as if the stop button was pressed.
- Restart: only if the emulator is running, this button will be clickable. It is used to restart the flow again (restart recording).
The recorder provides the following set of parameters to establish the connection to the server:
- Server: URL or server IP (required)
- Port: Open port on the server. If unspecified, 23 will be used by default.
- Protocol: The protocol to use in communication. If the server is an iSeries it typically uses TN5250, if its a zSeries then tn3270, in other cases (like unix servers) you can use VT420.
- Terminal Type: The terminal type to emulate from the client. If the server does not support the chosen one, it will use the default value for the protocol.
- SSL Type: The SSL protocol to use if it's required by the server. Select the desired one, and read this article if you want to get a better understanding of Keystore files and where to reference them.
- Timeout: the maximum time to wait to establish the connection.
- Timeout threshold: this threshold is used to have a time base for wait conditions.
Let's press Start in order to start the recording, and be able to interact with the emulator.
Once we press start on the recorder, a frame will pop up, this frame is called Terminal Emulator. The Terminal Emulator allows the user to interact with the mainframe application, as we usually do with other emulators.
Let’s give a quick overview of the Terminal Emulator features:
- When clicking a pop-up window will be displayed with general help information on the emulator: shortcuts, explanation about indicators on the screen, etc.
- Press to copy a selected area on the screen. Usual keyboard shortcut for copy is supported.
- Press to paste on the terminal clipboard content on the current cursor position. Special characters are not supported. E.g: \t (escape code for a tabulation), users will visualize where they appear on the clipboard content in order to modify it. Additionally, the usual paste keyboard shortcut is supported.
- Select a screen area to be used as Wait for Text, then press and a new Text Wait Condition will be added to your sampler.
- Press to create a Response Assertion from selected screen area text.
- As part of good practices while making scripts with JMeter, it is always recommended to rename the default sample name to a meaningful one for the screen you currently see. This will result in a cleaner and more understandable script.
- row: 12 / column: 27 indicates the current cursor position.
- If you see , it is because you are using the emulator with a VT protocol which does not support moving the cursor position by clicking on the emulator screen.
- Clicking on / will show/hide credentials in the terminal emulator. This is currently not supported for VT protocol.
- When is displayed in the status bar, the keyboard is unlocked, which means that we can type and interact with the emulator. On the other hand, if is displayed, then the keyboard is locked, which means that the server is processing our previous request or the server is not ready to receive interactions from the user.
Now it's time to navigate through the flow and make sure that if something changes on the mainframe application (screens, inputs), you can be sure that your test will be robust enough to detect any inconsistencies.
In order to gain that robustness, the plugin contains two options to validate that a certain screen contains a specified text; Response Assertion, Wait For Text.
Creating an assertion using the recorder
Let’s create a Response Assertion on the first screen
As expected, a response assertion will be added to the current sampler. That assertion contains a pattern with the text previously selected on the emulator. In the end, we are going to be looking at the response body (which contains the screen) of the request made to the mainframe application for the specified text.
This functionality is very useful to validate that we get the desired screen after an interaction with the mainframe application.
How to create a wait for text using the recorder
A Wait for Text makes sure that a given text appears on the screen.
You may be wondering, the Response Assertion from the previous section does the same validation, right? We’ll answer that in the next section. But first, let’s create this Wait for Text.
"Wait for text could be useful to check for a specific message before continuing the execution. For example, it could be used to wait for a message with the confirmation that a specific process ended correctly or to check if a search returned any result before continuing."
Wait for text or Response Assertion?
As you might be guessing, Wait for Text is quite similar to the Assertion described in the previous section, but there is a slight, yet important difference between them.
Wait for text, as the name describes, will wait until a specified text appears on the screen for at least one second (Stable period).
The assertion will assert/check that some text appears on the response body. The response body on RTE is the final screen-captured after waits like Sync, Cursor Position, Silent confirm that the request has ended.
It is highly recommended to use Wait for text, because of its customizable timeout and its robustness. If you use an assertion, it may fail depending on how good are the already configured waits on the sampler. On the other hand, the wait for text will wait until the text appears for a certain period of time, and even if it momentarily disappears, the wait will not fail.
As you may have seen in previous sections, we always end every screen with an Attention Key and, in some cases, we have also introduced data, like in the Wait for Text section. To enter this data via emulator, you just have to type the desired information. To emulate Attention Keys please review the proper key mapping in helper .
You may notice that recorded samplers specify such interactions via inputs and attention keys which are automatically populated by the recorder while you use the provided emulator.
But before getting into more details on this, let’s clarify some differences between protocols:
- when using the VT420 protocol, every single character typed on the screen will be sent to the server one at a time. Not only actual data fields or attention keys are sent to the server for processing, but also navigation keys like arrow keys & tabs.
In this scenario, RTE-Recorder records every single interaction in the sampler for later playback when running a recorded test plan. This means that if you move across the whole screen with arrow keys (as shown in below example) in order to type something, the recorder will record those movements and will create Inputs for that, more precisely Input by Navigation (explained below).
- For TN3270 and TN5250, the navigation is handled on the client side, and only field data and attention keys are sent, which makes samplers simpler and more robust.
Let's talk a little bit about the new types of inputs that are supported on the sampler in the latest releases of the plugin:
Input by Navigation
This input allows you to navigate the screen before placing the input value (String). There are five types of navigation actions: Arrows (UP, DOWN, LEFT, RIGHT), and TABULATOR.
In all cases, you can specify the number of times that the navigation key is sent before sending the data. If the repetition is zero, it means that it will try to place the data on the current cursor position.
Input by Label
This input depends on a Label, the label will be a word or text used as reference close to the field to fill. This type of input makes the test robust by adapting to changes of position and even the order of fields on the screen. This type of input is currently not supported for VT (the same applies to input by coordinates which were used on previous posts)
Review this link for case usage and a better understanding of this input.
During this quick introduction of the VT420 protocol and all the new functionalities, we have done a basic scenario.
Let's visualize what has been recorded and run the Test Plan, to make sure everything works as expected.
The reproduction of the flow works successfully, and now you can use it either to run functional or load tests against the mainframe application!
During this blog post we have included most of the new functionalities added to the plugin, as well as the newly supported protocol.
For more documentation please visit the plugin repository. Additionally, in the repository, we are open to receiving ideas for new functionalities and you can spark your interest in new protocols.