Wednesday, January 5, 2011

Siebel Loadrunner scripting issues

If you haven't scripted a siebel application before for load testing using Load Runner then you are in for some good time. I am sure you will come across different issues which you might not have encountered before. I wanted to compile a list of issues that I/colleague have encountered and how they were solved. Therefore this blog contains some of those issues and possible solution.

Following issues were encountered by my colleague:

Issue:
Sometimes the application does not function correctly when recording with Loadrunner, but works fine without recording.
Solution:
Close all browser instances, search and delete a file called Siebel High Interactivity Framework, Log into the Siebel application and agree to 'repair' the browser configuration.


Issue:
Some "web_url" requests fail during replay and the application responds with "We detected an Error which may have occurred for one or more of the following reasons: We are unable to process your request. This is most likely because you used the browser BACK or REFRESH button to get to this point.(SBL-UIF-00335)".

The following request is a sample which generated this error:

web_url("start.swe_54",
"URL=https://{Host}/{Env}/start.swe?SWECmd=GetCachedFrame&SWEC={Siebel_SWECount}&SWEFrame=top._sweclient._swecontent._sweview._swetmp&SWESP=1",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=https://{Host}/{Env}/start.swe?SWECmd=ShowPopupFrames&SWEDIC=1&SWEU=/{Env}/start.swe%3fSWECmd%3dGetCachedFrame%26SWEC%3d9%26SWEFrame 3dtop._sweclient._swecontent._sweview._swetmp%26SWESP%3d1",
"Snapshot=t62.inf",
"Mode=HTML",
LAST);

Solution:
At first glance the requested URL seems to be parametrized correctly. However, the automatically correlated SWEC={Siebel_SWECount} is actually incorrect. In most cases the Siebel_SWECount parameter is incremented correctly by Loadrunner. However, when using SWECmd=GetCachedFrame, that value for the SWEC parameter must be correlated manually from the previous request.

The response from the previous request will contain something like:

URL .../xxx/start.swe?SWECmd=GetCachedFrame&SWEC=32&.......

Normally this kind of correlation is natural and intuitive, but with the Siebel protocol SWEC is a counter which is not usually correlated and therefore easily overlooked.


If you come across different issue(s) related to Siebel application scripting, I would like to hear about them as well as how you were able to solve it. If I come across more issues, I will update this blog.

6 comments:

lorenzo said...

Sorry,
for open a getcachedframe trought SWE,
what is the order of url?

thanks

hpseera said...

Hi Lorenzo,
I am not sure I understand your question correctly. Could you elaborate bit more as to what you are trying to do or what you are looking for?

lorenzo said...

Yes, sorry... :)

I am trying to automate data entry (name, address ..) through SWE ... I send url request so : http://localhost/smc_enu/start.swe?SWECmd=InvokeMethod...SWESetMarkup=XML

I managed to do everything ...
only the address is missing.

For edit address siebel eai opens a mvg applet, but i don't know which request must send for open this applet.

hpseera said...

Hi Lorenzo,
I suggest using a tool like wireshark or fiddler to capture a real traffic that is passed between your application and server. This way you can findout how the request for your address is send to the server(how is your address request send and soforth).

Once you have this information, you can then use LR web_custom_request function to create an appropriate request.

I hope this helps.

ahkuen said...

Hi hpseera,

i facing the issue with that swecount, but if i record it without correlation, my ie will hang whenever vugen launch the site. do you have any solution on this? 2nd iteration failed. with that swecount thingi.

hseera said...

Hi Ahkuen,

I have few questions regarding your problem and they are:

1: Have you installed all the LR patches?

2: Have you correctly correlated all the parameters?

3: Are you using same kind of data in second iteration as you have used during your recording & first iteration. For example, you might have recorded your script with an agreement that had 3 sub agreements and when you are replaying the script, the agreement might have more than 3 sub agreements.

4: Are you logging out correctly from the application? You should read the LR Help documentation on how you should be logging out. Not properly logging out can cause unexpected behavior.

5: Are you running as a new user every iteration or not?