Load test scripts are difficult to create due to highly dynamic nature of Siebel applications. Load test scripts typically automate transactions at the protocol level for maximum scalability, however Siebel requests are very dynamic and if the recording tool captures hard-coded data values then they will not play back.
Manual parameterization is often required which is tedious and time-consuming, plus it requires extensive Siebel expertise. Once you get your tests running, the highly distributed Siebel architecture makes performance bottlenecks difficult to identify.
Correlation in Siebel:
Correlating standard HTML pages is not a difficult task, all you usually need to do is look for a value inside an HTML tag and match it to a regular expression, which tends to be an easy task, in the case of Siebel however, it does not send all of its information in an HTML format, instead it does so in a very difficult format to read by humans and to correlate using regular expressions, see the text below for an example.
@0`1`3`3``0`UC`1`Status`OK`SWEC`16`1`0`ResultSet`0`Return Alerts`<pre><br><font face="verdana" color="red" size=3> Executive - Transfer call to Executive Specialist Team if applicable<br>or<br>Handle with Care <br> </font></pre><br><font face="verdana" color="black" size=2>    1. Pension Eligible`0`12` Notifications `0`2`0``0`OP`bn` bc`S_BC4`7`0``0`br`0`ArgsArray`34*qrs WMT Contact Toggle FormApplet 1*1`size`1`cr`0`OP`g`bc`S_BC4`type `SWEIRowSelection`2`0``0`OP`en`bc`S_BC4`2`0``0`OP`bn`bc`S_BC2`7`0``0`br`0`ArgsArray`38*qrs WMT Contact Summary SR List pplet1*11*01*01*01*0`size`5`cr`4`OP`g`bc`S_BC2`type` SWEIRowSelection`2`0``0`OP`en`bc`S_BC2`2`0``0`OP`bn`bc `S_BC3`7`0``0`br`0`ArgsArray`29*FIN
While developing Siebel performance test scripts using load runner we need to do very few script enhancement.
SWEACn ---> Siebel Web Extension Applet count.
This value usually appears in web_url() and you can correlate @ first occurrence in the start and replace all other occurrences with the correlated variable name.
SWERowids ---> Siebel Web Extension Rowids
Kindly note this value is not same as the one mentioned earlier. This value would correspond with the SWEMethod implemented/used in the step. So the Ordinal No depends on the SWEMethod in the Server Response.
SWERowId = rowid to perform the action
SWERowIds = record's parent rowId
SWETS ---> Siebel Web Extension Time Stamp
This can be correlated by using web_reg_save_timestamp() just above the request and pass it.
SWEC ---> Siebel Web Extension Click count
This can be correlated by increment method followed in LR or using the web_reg_save_param ()
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.
Read "Correlating Siebel-Web Scripts" in VuGen guide which will help you to import WebSiebel77Correlation.cor file. This makes your correlation part easier
Dynamic Record Changing:
Problem: whenever any new record is added or existing record is modified the position of records will change. While recording we need to select a record (SR) from the list of records, but the selected record position will change whenever any new record is added/modified, this leads to a problem while replaying the script as the record position has changed.
Default: while trying to correlate the record items (each record has atleast 20 fields) the boundaries of fields are changing dynamically, and there is no specific pattern for boundaries.
Example: 1-4611378121*21HealthandWelfare10*Phone
Call1*05*Sivakota2*HW7*Inquiry0*4*TEST5*COBRA19*0
If we want to capture ---> the boundaries of SIVAKOTA are changing dynamically without any specific pattern.
Solution: To the above problem we are explicitly capturing the entire record and storing into the parameter array.
//*1-4819497423*HRO3*ODM1*15*Sivakota7*Payroll11*Transaction0*5*ALBEE12*
web_reg_save_param("Record","LB/DIG=*#-#####","RB/DIG=*#-#####","ORD=1", LAST);
The entire record is captured into array “Record”, now we are explicitly matching the field values, by writing some code logic it will take the first value, and using StringCheck function whenever the value is not matched StringCheck function will return a null pointer. Once the value is matched, the matched value will be send as field input to server.
Pros: The logic will handle dynamic record changes And Script maintenance is less.
Cons: All the field values should be statically kept into pointer array.
Ex: char* LastnameArray [] = {"ALBEE","ADKINS","TEST","ADELMUND","Sivakota1"};
Memory utilization is high.
Manual parameterization is often required which is tedious and time-consuming, plus it requires extensive Siebel expertise. Once you get your tests running, the highly distributed Siebel architecture makes performance bottlenecks difficult to identify.
Correlation in Siebel:
Correlating standard HTML pages is not a difficult task, all you usually need to do is look for a value inside an HTML tag and match it to a regular expression, which tends to be an easy task, in the case of Siebel however, it does not send all of its information in an HTML format, instead it does so in a very difficult format to read by humans and to correlate using regular expressions, see the text below for an example.
@0`1`3`3``0`UC`1`Status`OK`SWEC`16`1`0`ResultSet`0`Return Alerts`<pre><br><font face="verdana" color="red" size=3> Executive - Transfer call to Executive Specialist Team if applicable<br>or<br>Handle with Care <br> </font></pre><br><font face="verdana" color="black" size=2>    1. Pension Eligible`0`12` Notifications `0`2`0``0`OP`bn` bc`S_BC4`7`0``0`br`0`ArgsArray`34*qrs WMT Contact Toggle FormApplet 1*1`size`1`cr`0`OP`g`bc`S_BC4`type `SWEIRowSelection`2`0``0`OP`en`bc`S_BC4`2`0``0`OP`bn`bc`S_BC2`7`0``0`br`0`ArgsArray`38*qrs WMT Contact Summary SR List pplet1*11*01*01*01*0`size`5`cr`4`OP`g`bc`S_BC2`type` SWEIRowSelection`2`0``0`OP`en`bc`S_BC2`2`0``0`OP`bn`bc `S_BC3`7`0``0`br`0`ArgsArray`29*FIN
While developing Siebel performance test scripts using load runner we need to do very few script enhancement.
SWEACn ---> Siebel Web Extension Applet count.
This value usually appears in web_url() and you can correlate @ first occurrence in the start and replace all other occurrences with the correlated variable name.
SWERowids ---> Siebel Web Extension Rowids
Kindly note this value is not same as the one mentioned earlier. This value would correspond with the SWEMethod implemented/used in the step. So the Ordinal No depends on the SWEMethod in the Server Response.
SWERowId = rowid to perform the action
SWERowIds = record's parent rowId
SWETS ---> Siebel Web Extension Time Stamp
This can be correlated by using web_reg_save_timestamp() just above the request and pass it.
SWEC ---> Siebel Web Extension Click count
This can be correlated by increment method followed in LR or using the web_reg_save_param ()
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.
Read "Correlating Siebel-Web Scripts" in VuGen guide which will help you to import WebSiebel77Correlation.cor file. This makes your correlation part easier
Dynamic Record Changing:
Problem: whenever any new record is added or existing record is modified the position of records will change. While recording we need to select a record (SR) from the list of records, but the selected record position will change whenever any new record is added/modified, this leads to a problem while replaying the script as the record position has changed.
Default: while trying to correlate the record items (each record has atleast 20 fields) the boundaries of fields are changing dynamically, and there is no specific pattern for boundaries.
Example: 1-4611378121*21HealthandWelfare10*Phone
Call1*05*Sivakota2*HW7*Inquiry0*4*TEST5*COBRA19*0
If we want to capture ---> the boundaries of SIVAKOTA are changing dynamically without any specific pattern.
Solution: To the above problem we are explicitly capturing the entire record and storing into the parameter array.
//*1-4819497423*HRO3*ODM1*15*Sivakota7*Payroll11*Transaction0*5*ALBEE12*
web_reg_save_param("Record","LB/DIG=*#-#####","RB/DIG=*#-#####","ORD=1", LAST);
The entire record is captured into array “Record”, now we are explicitly matching the field values, by writing some code logic it will take the first value, and using StringCheck function whenever the value is not matched StringCheck function will return a null pointer. Once the value is matched, the matched value will be send as field input to server.
Pros: The logic will handle dynamic record changes And Script maintenance is less.
Cons: All the field values should be statically kept into pointer array.
Ex: char* LastnameArray [] = {"ALBEE","ADKINS","TEST","ADELMUND","Sivakota1"};
Memory utilization is high.
No comments:
Post a Comment