Siebel Unleashed

After you are finished with the steps mentioned above, you need to do the following things:

1. Firstly, QTP needs to be installed in the machine where LoadRunner is also installed. This is because LoadRunner will be recording the same flow that the QTP script will be executing.
2. Secondly, this is how the process goes: Both individual instances of QTP as well as LoadRunner has to be open. Start the recording in LoadRunner keeping the application URL- “about: blank”. What this will ensure is that even though the Internet Explorer will start, it will not be accessing any application since it was ensured that there is “about: blank” in the address bar.
3. Once this is done, start executing the QTP script. What QTP will do is invoke its own Internet Explorer window and the flow recorded in the QTP script will be executed.
4. When the QTP script starts executing, the LoadRunner will start recording the communication between the client and the server of the Internet Explorer which was invoked by QTP.
5. Once the execution is stopped. LoadRunner will generate the same flow executed by QTP but in its own form, the form LoadRunner recognizes i.e, in the form of C and its functions.
6. Now, ensure that the AutoGenerate tool is available on the same machine. Also make sure that AutoGenerate.exe is in the system path.
7. Open a command window and navigate to the directory where the LoadRunner script is saved. Execute AutoGenerate.exe. The results should indicate that the post processing was completed successfully to insert the transaction boundaries and rearrange the script into different actions as specified in the QTP script.

Once the script gets generated and after the Autogenerate utility (Autogenerate.exe) has been run, we still have to do a few things: Correlation and Parameterization.

Even though, before starting the recording, we have the Auto Correlation option checked, then also LoadRunner doesn’t always correlate everything automatically. There are many values which need to be correlated manually, which don’t get correlated automatically by LoadRunner since rules are not defined to correlate these values in the .cor file used for the very purpose of automatic correlation for Siebel.

We require correlation because of certain values which change dynamically. For this express reason we have options in LoadRunner by which we can capture these dynamic values and use it so that the scripts don’t fail.

Parameterization: There are values which don’t change dynamically but are required to be parameterized, i.e. certain known values which are present in a table from beforehand and LoadRunner uses them one by one for the express purpose of the script doing exactly the flow which has been recorded otherwise the script will fail. The values are taken from the table and used in the script.

Like for example, PO numbers parameterized in a script which tries to approve a PO. Once a PO gets approved, it cannot be approved again unless and until some revisions are made. But if the script which has been recorded to approve a PO and then do nothing further, we will require a good amount of PO numbers to be parameterized so that LoadRunner, while executing the script, can take a different PO each time otherwise the script will fail since it will try to Approve a PO number which is already Approved.

After reading this though the grass seems to be quite green. But the reality is totally different. Since to set up the entire infrastructure, is not cost effective. But if you have it in place then you can go ahead with it. Also there are some transactions which cannot be recorded using LoadRunner so they can use this approach.