A lot of people came to me on the last few weeks asking about Oracle Apps scripts. As I’ve been noticing during the last year, Oracle Apps (Financial) is dominating the ERP business and growing in a gigantic rate.
As I like to say, “Oracle is the new thing today”. Everybody is changing to Oracle, developing new solutions on their platform and I don’t have to say that also, creating new challenges for Performance Testing. For our luck, my opinion so far is that Oracle Apps do very well regarding performance if well designed and configured.
Obviously I’m not here to talk about Oracle Apps itself, with their search queries and concurrent requests. I’m here to give a few tips based on the things I learned while testing Oracle Apps.
Before I start, I just want to point that this is only one example of how things worked for me. If you’ve been on Performance Testing for a while, you should know that there are several ways of doing the same thing. Most examples were tested using LR 9.5 and Oracle 11i. I know that most tips can also be applied to LR 8.1, 9.1 and also Oracle 10.
Tip 1: How to correlate the Login?
Login is usually the tricky part of the Oracle Apps. The way I usually do is to use a multiple protocol script, HTTP and Oracle NCA. I know that the newer versions of LR have a specific protocol for Oracle Apps, but this has worked pretty well for me.
To make things easier, let’s record the steps from the web interface first. Don’t forget to add some comments, Each click on the web interface generates several requests and sometimes the same happens inside the application too.
All very simple so far. If you done the right things so far, LR should be capturing all events, both on the web interface and the Oracle interface. Once you’ve finished and LR generated the basic script, the tricky correlations come in.
On most cases, you will be using more than one application note. This means load balancing. In order to do this, the web front-end will send you a node name, port and domain.
To capture this information, use the following lines on the first request made when selected a form. Right before the “RF.jsp” call.
web_reg_save_param("serv_name", "LB=var xsname = \"", "RB=\"", LAST); web_reg_save_param("port_num", "LB=var xsport = \"", "RB=\"", LAST); web_reg_save_param("domain_name", "LB=var xdname = \"", "RB=\"", LAST);
This will capture the required information for the load balancing. Now let’s concatenate this and create a connection string. Add this right after the “RF.jsp” call.
lr_save_string(lr_eval_string("{serv_name}{domain_name}"), "serv_name");
Now that we have the connection string, we need to capture some variables needed for the connection, like the form to be launched, some profile information, etc.
Right after the command above, add the following lines:
web_reg_save_param("nca_connect_1", "LB=<PARAM name=serverArgs value=\"", "RB= config='", LAST); web_reg_save_param("nca_connect_2", "LB=var xform_params = \"", "RB=\"\n", LAST); web_reg_save_param("nca_connect_3", "LB=var xenv = \"", "RB=\"\n", LAST);
Now that we have captured all information we need to connect, let’s change the connection line. Replace the “nca_connect_server” line to:
nca_connect_server("{serv_name}", "{port_num}", "{nca_connect_1} record=names {nca_connect_2}::{nca_connect_3}");
All done! Now you should be able to execute the Login correctly.
Tip 2: How to record the correct field names?
If you recorded a few scripts and you’re having problems with missing fields on second and subsequent interactions of your script, that’s probably because LR is not recording the filed names correctly. Oracle, depending on how it was configured, selects random field names depending on the interaction, usually plain numbers.
In order to solve that, you will have to change some configurations on your profile or default profile on Oracle. Obviously, you will need rights to change this information and usually to change the default profile, you will need the SYSADMIN user.
OK, all rights granted. Follow these steps:
- Open the Web Interface;
- Login with your user (or SYSADMIN);
- Select the role “System Administrator”. If you don’t have this role, you don’t have the rights to do this;
- Select the option “Profile: System”;
- Search for the following profile option: “ICX: Forms Launcher” (Search for a specific user to change only the settings for one user);
- Append this string to the end URL: “?play=&record=names”;
- Save and close everything;
- Try recording the script again.
ps.: Sorry if you already recorded all your scripts, you’ll have to do it again to get the field names right.
Tip 3: Other profile settings
These settings are not required, but are best practices gained though time. Change the following profile options the same way you changed the “ICX: Forms Launcher” option before:
ICX:Session Timeout: 3000s: Use this profile option to enforce an inactivity time-out. If a user performs no Oracle Applications operation for a time period longer than the time-out value (specified in minutes), the user’s session is disabled. The user is provided an opportunity to re-authenticate and re-enable a timed-out session. If re-authentication is successful, the session is re-enabled and no work is lost. Otherwise, Oracle Applications exits without saving pending work. If this profile option to 0 or NULL, then user sessions will never time out due to inactivity.
ICX: Limit time: 999h: Use this profile option to specify the absolute maximum length of time (in hours) of any user session, active or inactive.
ICX: Limit connect: 2000: Use this profile option to specify the absolute maximum number of connection requests a user can make in a single session.
Hope these tips will help you facing the “Oracle Challenge”!