In my current assignment I am tasked with coordinating the testing of the integration of several retail systems, basically making them work together logically and effectively. Part of the work is  oriented towards load and performance testing of these integrated systems.

What is being done is that SAP Retail systems need to communicate with Locus WMS, since the version of SAP currently running at the customer cannot deal with anything but IDocs a message broker has been setup in between SAP and Locus to translate the IDocs into XML and vice versa. The IDocs are served to the message broker via SAP’s default RFC port, the broker pulls the documents out of SAP, translates them and sends them off to Locus to be picked up and processed. This is a simplification of how it truly works, since it is only meant to help set the scene.

Generating IDoc load

In order to build up load in a structured, guided way from SAP there are a few ideas of what can be done. My initial hopes, were to push IDocs from a load generator to the message broker. This would be the easiest way in which to control the flow of data towards the broker and thus the easiest way to make sure we are fully in control of how busy the broker is. Alas, when talking to the guys behind the broker interfaces it turned out that this method would not work for the setup used. The only way the broker would actually do something with the IDocs was if it could pull them from the SAP RFC port, pushing to the broker would not work, since the RFC receiving end of the broker is not listening, it is pulling.

Alternatively sending data off into the message queue would fill up the MQ, but not help with getting the messages pushed through the Broker, again, due to the specific setup of the Enterprise Service Bus which contains the broker interfaces.

So alternatives needed to be found. One obvious alternative is setup a transaction in SAP which generates a boat-load of IDocs and sends the to the RFC port in one big bulk. This would generate a spike, such as shown in this image, rather than a guided load. In other words, this is not what we want for this test either. It might be a useful step for during a spike test, however the first tests to be completed are the normal, expected load tests.

The search for altneratives continued. At my customer, not a lot of automation tools were available, especially not for SAP systems. One tool however has been purchased a while ago and apparently is actively used: WinShuttle

Winshuttle seems to be able to generate the required load, based on Excel input, the main issue with Winshuttle however, was the lack of available licenses. There are two licenses available and both are single use licenses. This meant I would have to find a way to hijack one of the PC’s it was installed on, script my way through it and run the tests in a very timeboxed manner. In other words, not really a solution to the problem.

I then decided to look at this from a whole different point of view: what can I use to make SAP execute a bunch of transactions, is freely available and flexible enough to also monitor what is happening on several sides of the message broker? The answer that came to me was not quite what I had expected: AutoIt.

Starting SAP from AutoIt was simple, running through the application and manipulating SAP however was a bit less intuitive.
In this screenshot two SAP screens are put side by side, the left-hand side is what the userinterface in SAP looks like to the end user. The right-hand side is how AutoIt sees the screen, e.g. a big blob of nothingness.

To be a bit more specific, here’s what AutoIt can tell us about the SAP toolbar:

In other words, AutoIt sees the entire toolbar as one object, with one exception, the edit box for transactions. This box has a very easy and intuitive name: Class: Edit Instance: 1, making it easy to ensure the focus on this box can be easily set and thus the transaction being started to upload files.

Since the main screen of SAP is a blind box to AutoIt we had to resort to a very sloppy way of working, using the TAB button to navigate through the screen, resulting in code roughly looking like this:

Send("ZWBESTUPL{ENTER}")
 If WinWaitActive("Bestellingen (winkel) aanmaken vanuit CSV-bestand") Then
    _log('Successfully selected the Bestellingen aanmaken vanuit CSV-bestand transactie')
    Send("{TAB 3}")
    Send("{SPACE}")
    Send("+{TAB 3}")
 Else
    _log('Something went wrong. Could not get to the Bestellingen aanmaken vanuit CSV transactie')
    Exit
 EndIf

The resulting load ramp up was a linear rampup of IDocs being generated and sent to the SAP RFC port, where they were picked up by the Message Broker and subsequently tranformed and sent back to the Locus system, where the load turned out to be quite on the high side.

All in all this was a fun excercise in automating SAP to do something it is absolutely not meant to do with a tool not built nor designed to do what it did. In other words, it was wonderful to be able to abuse a bunch of tools and achieve a very clear and convincing result!