You’ve now got the beginnings of a LoadRunner script from the SAP utility. This is likely to be several thousand lines long. It’s all been generated into a txt file of one large “Action” section along with a couple of utility functions for strings – that it never uses.
Tip: We created a function library for these utilities so that we could just delete them from the generated Action section in all subsequent scripts. We also put the variables that the converter created in this header. Paste the generated action section into a LoadRunner SAP Web or a Webservices script but DO NOT try to save it as you may well crash your Vugen.
Edit the Sub Transactions
The first things to edit, and the most important of all, are the sub transactions that have been put in your script (Some of our “refresh all” commands have generated a transaction along with 30 sub-transactions). All these sub-transactions need editing. The conversion utility uses special characters as the sub-transaction names are the URL being requested so they have slashes, question marks and ampersands liberally scattered through them, some of these are illegal characters in LoadRunner so the sub-transaction names need to be edited. Your script should now save and possibly even compile and run.
The other thing missing are think times as Fiddler doesn’t have any such concept and therefore the conversion utility knows nothing about the speed that you recorded the script at. We’re using three different think times, 7 seconds for the “normal” requests, 300 seconds after a report refresh command (to emulate a user reading the report (there must be some reason why they generated it!) and up to 600 seconds for input forms – in one of our cases the user is expected to enter 240 lines each with 12 columns, easily 10 minutes. This does mean that some of these iterations take a long time to execute, in fact one of our scripts needed over 3 hours to execute a single iteration.
The commands are also pretty unreadable as they are as the data being submitted can be several thousand characters long. I hate that so I had the team restructure a lot of the commands so that they looked like the SOAP requests that they are and so that we could read and understand their contents. Parameters can be scattered all through the requests so if you’re using parameterisation then I’d encourage a bit of reformatting.
Requests submitted through the Data Manager submit background requests do not report their completion. We constructed a small function to keep refreshing the status until the job finishes and added it to the header file created to contain the utility functions and variables . We seem to have a reasonable solution: searching on the job name and the user id with each user for a script being unique. Tip: You’ll also need to modify your script for Data Manager as the web headers are wrong as they come out of the converter.
If you get an HTTP 500 error when you rerun your script then there are generally two causes, the command has timed out (5 minutes in the standard implementation although we’ve increased it to 15 minutes so we can measure how much over the 5 some of the requests might need) or your parameterisation is wrong. The messages are not helpful! Another little function was needed to check for an HTTP 500 error on the refresh requests. This also needed “continue_on_error” to allow the interception, shame LoadRunner still fails the script even though you’ve trapped it and allowed the script to continue.