Siebel application performance testing

120 views
Skip to first unread message

Sasank

unread,
Dec 4, 2010, 7:45:38 AM12/4/10
to lr-loa...@googlegroups.com
Hi, 

I am going to work on Siebel web protocol with LoadRunner and would like to know if any body can share tips and tricks to overcome the scripting challenges in Siebel.

I know Siebel Correlation library will reduce the scripting efforts to some extent, but I would also like to focus on row_ids and SWEACn and SWC correlations.

Any thoughts on this will be appreciated .

I also gone through the siebel script development in VuGen guide and ITRC forums but still am interested to know your experience with Siebel

thanks
Sasank

John Crunk

unread,
Dec 4, 2010, 3:40:01 PM12/4/10
to lr-loa...@googlegroups.com
Basically. The same as any other

Sent from my iPhone
--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

franklin inbaraj

unread,
Dec 5, 2010, 8:44:26 AM12/5/10
to lr-loa...@googlegroups.com
Sieble web is also same like Web application.

Read "Correlating Siebel-Web Scripts" in VuGen guide which will help
you to import WebSiebel77Correlation.cor file. This makes your
correlation part easier.

Regards,
Franklin Inbaraj


--
Regards,
Franklin Inbaraj

francois

unread,
Dec 6, 2010, 9:43:09 AM12/6/10
to LoadRunner
I work with the Siebel Web protocol all the time and i prefer to use
the native correlation rules over the ones provided by Siebel. Sure
the added rules help you grab more stuff but the correlations are not
always on target either. Also, you end up with so many possible
parameters to choose from it becomes confusing. But thats just me and
this opinion is highly subjective. As a matter of fact, my partner has
the Siebel rules installed and swears by them so yeah... you can try
them and see for yourself :)

To answer a little on your questions:
rowids: The single most important part of a record. You can use it to
retrieve a given record but you will also need it to perform actions
like "delete", "drilldown", "select", etc. You will also need it as a
"reference" when you want to navigate through a record's sub tabs.
This is vulgarized but maybe it'll help shed some light:
SWERowId = rowid to perform the action/method on
SWERowIds = record's parent rowid

SWEACn & SWC:
These gave me a lot of trouble at first but for two different reasons.
SWEACn doesn't always appear in the server response where you've
originally recorded it. That being said, it will always be in the
"web_url's" response right before the call where you need it.
Basically, what i'm saying is, move your web_reg_save_param from where
you originally had it recorded to one request prior to where you need
it. This has never failed me so far.

SWC is a strange one... I don't quite understand how the system
updates this value. It adds / subtracts integers like it was
calculated instead of considering as part of a response from the
server (maybe this is solved by the Siebel correlation rules but i
don't use them). Anyways, when you get a "back or refresh error",
first thing you should suspect is the Siebel_SWECount (SWC). Usually,
this will happen after the first iteration. My advice for this one,
stick a web_reg_save_param before the call prior to the problematic
URL. Look in the appropriate server response for the real SWEC value
and put the proper boundaries in the WRSP. Of course, you'll need to
put this code before the problematic URL:

Siebel_SWECount_var = atoi(lr_eval_string("{YOUR_SWEC_PARAM_NAME}"));
lr_save_int(Siebel_SWECount_var, "Siebel_SWECount");

Also, make sure the problematic URL calls a dynamic SWEC not a
hardcoded one.
SWEC={Siebel_SWECount} GOOD!
SWEC=13 BAD!

Hope this helps buddy!

Reply all
Reply to author
Forward
0 new messages