Extending loadUI - Part 2
Develop | Posted October 01, 2010
Let’s move forward with our creation of custom components in loadUI. Since the previous post on this subject, one of the eviware brain cells, Dain Nilsson, has written a reference document on the extension model of loadUI available at the loadUI Website. We’re going to put some more of this to work by creating a custom component that reads URLs from a text file and inserts them into a trigger message, allowing you to configure a Web Page or soapUI Runner accordingly while your tests are running (a feature that has been requested on our loadUI support forum; http://www.eviware.com/forum/viewtopic.php?f=10&t=4509).

Creating the Component

The component we will create will allows us to specify a text file containing URLs (one on each line) which will be read and used to "feed" a Web Page Runner randomly or sequentially. Visually the component will have
  1. One input and output terminal
  2. A file Property field for the data file
  3. A switch for selecting random or sequential mode

Let’s just start by creating the component with the terminals and properties:
createProperty( 'file', File, null )
createProperty( 'mode', String, 'Random' )

createInput( "input", "Incoming Messages" )
createOutput( "output", "Outgoing Messages" )

Save this in a file named “URLLoader.groovy” in the loaduiscript-components folder; in loadUI this component will be made available under the Misc category and render as follows when dragged onto the project canvas:

Now back to the script file to add the actual layout for the properties:

layout {
property( property:mode, label:'Mode', options:['Random','Sequential'] )
property( property:file, label:"File", constraints: 'w 200!', style: '-fx-font-size: 13pt' )

Save the file and in loadUI the component gets updated to look as follows:


Cool! We can specify a file and set the mode as desired. Next is to make this actually work; we’ll start by adding a method that reads the file into memory when it is specified (don’t use too large files!):

def values = []
addEventListener( PropertyEvent ) { event ->
if ( event.event == PropertyEvent.Event.VALUE ) {
if( event.property == file ) {
values = file.value == null ? [] : file.value.readLines()

This adds a PropertyEvent listener that handles changes to the file property by reading the lines of the file into the component.

Now all we have left is to add an eventhandler that adds a URL property to incoming messages before they are propagated to the output, but before we do that a short explanation is in order:

loadUI Components communicate by sending and receiving messages; for triggering requests, reporting results, etc. In line with this, the Web Page Runner checks the incoming trigger message for a URL property which it will use instead of the configured URL. Out component will simply add this URL property to each message that goes through it, thus controlling the URL the web page runner will use.

The event handler will delegate to two separate methods depending on the mode:

onMessage = { incoming, outgoing, message ->
if( values.size > 0 )
def url = ''
      if( mode.value == 'Random' )
url = getNextRandom()
else if( mode.value == 'Sequential' )
url = getNextSequential()
      if( url != null && url.length() > 0 )
message['URL'] = url
   send( output, message )
getNextRandom =
def index = (int)( Math.random()*(float)values.size )
return values[index]
def currentIndex = 0
getNextSequential =
if( currentIndex >= values.size )
currentIndex = 0
   return values[currentIndex++]

That’s it! Our component is done and ready to put to work; in loadUI we have the following setup:


As you can see the URLLoader has been inserted between a Fixed-Rate Generator (any Generator would work) and a Web Page Runner; it will add urls from the configured file to each trigger message passing through it. The file I have specified just contains five urls:


I’ve added a TableLog component just to visualize the result of each request; when you run the test you can see how the URL field changes for each request:


(Try changing the mode of the URLLoader to see that the order of the used URLs change)

One cool feature with File properties (as we used for the text file) in your components is that loadUI will automatically distribute the specified file to all loadUI Agents when running in distributed mode; the file will be saved to a temporary file locally on the agent and the value of the property will be changed to reflect this path.

What about soapUI?

Before leaving this subject altogether, let’s have a quick look at how the above component can be used with a soapUI Runner instead. The soapUI Runner, as you all know, is a loadUI component that allows you to run a soapUI TestCase as part of a loadUI Test, allowing you to load test all protocols supported by soapUI (SOAP, REST, Web, JDBC, AMF, etc). The possibility to parameterize these TestCases from loadUI is via the standard soapUI Property mechanism; before running a soapUI TestCase, the soapUI Runner will look for all properties defined by the TestCase in the current trigger message, just as the Web Page Runner looks for a “URL” property.

So if you want to use the above components with a soapUI TestCase, just make sure the TestCase has a “URL” property:


which you use accordingly in your TestSteps (via property expansion, property transfers, etc). Now when you run the test in loadUI via our URLLoader component, loadUI will feed different URL values into the soapUI TestCase for each execution, a sample setup could be as follows:


Wrap up!

You can download the final component from here, just unzip it to the loaduiscript-components folder and you are ready to go!
Next steps could be:
  • Make the actual name of the property added to the outgoing message part of the configuration, allowing you to read any parameter that can be fed into components from a file
  • Add display counters for the number of items in the file the current index (for sequential mode)
  • Add the support for other data sources (databases, excel files, etc)

Next up in our series is a component that dynamically adjusts the load from a generator based on the avg response time of the target service. How cool is that?

Have fun!


P.S. Be sure to use the nightly build of loadUI (avaialable at http://www.eviware.com/nightly-builds/loadui) so you have all the latest fixes and minor improvements.


By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox