Maker Checker -Incorporating Multiple Roles in Single SilkPerformer script

Incorporating Multiple Roles in Single SilkPerformer script
Maker checker in single BDF
v1.01
By Swarnkar Rajesh
Test Engineer, Performance Testing
Table of Contents
1. Maker Checker Scenario
1.1 Description
1.2 The problemwith shuffling measures
2. Diagnosing the issue: What went wrong?
1.2 Found solutioninCookies

3. Building a solution
3.1 RecordingCookies before each request
3.2 Parse name-value pairs incookie fieldfor the first time
3.3 Reset the cookie database
4. Another Example
5. Related Topics
5.1 HTTPCookies
6. Exercise Problem
6.1 Recurring Parsing or CausalParameterization
7. Hints and Solutions to the exercise
8. References and readings
Document ID: MakerChecker_V1.01
Keywords: checker maker, multiplexing users,emulating users
Document Versioning:
Version Date Updated Description ofChange Edited/Released by
0.1 September 07, 2014 Documentcreated Swarnkar Rajesh
From the author
WhileI was on Finacle 10 (new core banking) load testingproject at Royal Bank of Scotland (RBS) at Parel,I came
across maker checker problem. This problem is described in this document alongwith work around that I applied
in BDF (benchmark description scripts).

I also discovered the importance of cookies and how to manipulatethem usingsilk performer functions.
All of these have been explained briefly.
About the author
Swarnkar Rajesh is Computer Engineering bachelor fromUniversity Of Mumbai. He is currently workingat
QualityKiosk Inc.as SoftwarePerformance Testing engineer. He enjoys learningaboutsoftware development and
testing. He likes to ponder about metaphysics and philosophies in hisfreetime.
1. Maker Checker Scenario
1.1 Description:
Maker-checker (or Maker and Checker, or 4-Eyes) is one of the central principles of authorization in the
Information Systems of financial organizations. This principle is reflected in financial applications like Finacle,
Flexcube etc.

The principle of maker and checker means that for each transaction, there must be at least two individuals
necessary for its completion. While one individual may create a transaction, the other individual should be
involved in confirmation/authorization of the same.
For example Money transfer transaction, the bank teller creates the money transfer transaction while branch
manager may verify the same.
(This was the case with Finacle 10 at RBS, transaction scenarios like HXFER, HCRT, HXCFRSC, HTM etc. involved
maker and checker menus.)
This business activity can bedescribed from the load test scriptingperspectiveas follows:
1. The maker has own User ID and password with its system. The maker logs in to the finance application called
Fincore via browser
2. Maker is redirected to the Fincore menu
3. Maker searches a menu say,HXFER (fund transfer)
4. On HXFER menu screen, maker enters debiting accountid and clicks on go
5. The maker fillsthedebiting amount on Debit page
6. The maker fillsthecrediting(target) accountid and amount on Creditpage
7. Maker submits these pages which generates Transaction I d and printablereceipts
8. Maker accepts the transaction
9. Maker logs out and closes the browser
10. Checker Opens browser (may be from his machine),visits login page
11. Checker logs in with its own credential
12. Checker is redirected to the Fincore menu
13. Checker searches the menus screen HXFER (fund transfer)
14. On HXFER menu, Checker enters the Transaction ID (as in step 7) and clickson submit.
15. The data as filled by maker in debit/credit pages is auto populated for verification
16. Checker clickson Verify to submitthe verified transaction
17. Checker can take prints of receipt
18. Checker logs out and closes the browser.
This whole activity was recorded with silk performer as stated here sequentially (Tmain). After parameterization of
appropriatefields and customization of session and dynamic fields,thescri ptwould run successfully.
But this would lead to major resource consumption during load test since the login-logout part is in Tmain
transaction. So the page sequence should be adjusted to implement what is known as Single Login Logout. In
Single login logout the Login pages are kept in TInit : begin transaction so the login takes place during the
rampup of load test, the repeatable transactions are kept in Tmain so it keeps on executing during the load test
and the logoutpages are kept in TShutdown : end so logout takes placeat the ramdown of load test.
This is done as follows:
Tinit // Rampup
1. Measure (Maker Home Page)
2. Measure (Maker Logins)
3. Measure (Maker Fincore Page)

10. Measure (Checker Home Page)
11. Measure (Checker Logins)
12. Measure (Checker Fincore Page)
Tmain // maintain session info throughout test
4. Measure (Maker HXFER Menu)
5. Measure (Maker Debit Page)
6. Measure (Maker Credit page)
7. Measure (Maker Submit Page)
8. Measure (Maker Accept Page) // Transaction ID
13. Measure (Checker HXFER Menu) // Transaction ID
14. Measure (Checker Debit Page)
15. Measure (Checker Credit Page)
16. Measure (Checker Verify Submit)
17. Measure (Checker Accept Page)
Tshutdown // Rampdown
9. Measure (Maker Logout)
18. Measure (Checker Logout)
Box-1: Shuffled Script for SLL (Single Login Logout)
Note this script does not reflect the exact real world scenario, but this saves us from what we call, Data Creation
i.e. the lots of transaction ids must be created via separated maker script which will be then passed to separated
checker scriptwhich will verify them. This is overhead for loadtest requiring data management.
NOTE:I amassuming that all the scripts, mentioned in this document, are being recorded on browser-level (recorder settings in
silk performer). This is done to avoid the context related discrepancies faced in HTML level recorded script when measures are
shuffled.
1.2 The problem with shuffling measures:
It was found that separated script mentioned in section 1.1 did work out well for maker parts but did not worked
at all for checker part. Why? Let’s have a closer look.
The script was recorded in the sequence mentioned earlier, hence the session information (e.g. in this case was
found to be JSESSIONID,) recorded were also separate. But when the script is modified as above the state
information was only created for maker during its home page, but not for checker! These session information
(esp. JSESSIONID) were shared for requests of checker by silk performer by default. This should not happen.
Logically, the session related information should not be intermixed and separation should prevail till end of script
in each request of maker and checker. This is what we call checker maker problem. This happens because silk
performer replay engine implicitly manages the session IDs via its cookie database. We will discuss how to override
or circumvent this in following titles.
2. Diagnosing the issue: What went wrong?
2.1 Found the solution in Cookies:
As discussed previously, Silk Performer handles the cookie(hence the user state information,viz., session IDs)
implicitly. Followingis a precept from Silk Performer’s knowledge base:

There are two categories of cookies: persistent and non-persistent (transient).
 Persistentcookies maintain their existence and value from browser session to browser session;they
contain expiry dates (in the future).
 Non-persistent cookies only existduringa singlebrowser session.
Persistentcookies are often used to recognize returning visitors to web sites (amazon.com, for example, will greet
a return user with a "Hello John Smith" message instead of requiringthe user to login and identify themselves. This
is done through a persistentcookie on the user’s system). Non-persistent cookies areused to maintain session-
specific "state"information,such as session IDs.Further,persistentcookies are physically stored on the local hard-
drivewhile non-persistentcookies existonly in memory (and go away once the browser session is closed).
SilkPerformer handles cookies the same way a browser does. The virtual users cookie database behaves exactly
likethe cookiedatabaseassociated with a browser session - itholds all thecurrently valid cookies.When a cookie
is set by the server, the appropriatedata is saved to that virtual user’s cookiedatabase.If an HTTP request is made
to a domain that has an existing cookie associated with itthen that cookievalue is read from the virtual user’s
cookiedatabaseand sent to the server as partof the request.
It is importantto realizethat each virtual user has their own cookie database - there is no overlappingbetween
different virtual user’s cookies.Another important pointis that the cookie database only "lives" for the duration
of a virtual user - the DB is empty when a virtual user is firstcreated and is destroyed once the virtual user has
completed. Given this,itcan be seen that virtual users will emulatenew visitors to a site, sincethere will notbe
any persistent cookies in the virtual user’s cookiedatabaseatthe beginningof replay.Therefore if you wish to
simulatea returning user, you have to initialize the virtual user’s cookie database to contain the appropriate
cookie. This is done usingthe WebCookieSet function. This function allows you to add a cookie (or change an
existing one’s value) to the virtual user’s cookie database. If you use this function to placea cookie into the
virtual user’s cookiedatabaseyou can successfully simulatea returning user to a web site.
As an example:
WebCookieSet("Name=John Smith; expires=Tue, 16 Nov 2010 21:53:10 GMT",
"http://foo.com"/");
With non-persistent cookies the web server initially sends thecookie’s valueback to the clientin the response
header and then the cookie’s valueis maintained for the lifeof the virtual user; the cookies are not written to the
script as everything is handled automatically by the replay engine.
If you see uncommented cookies in your recorded scriptitis generally for one of the followingreasons:
1. It is a persistent cookie that already existed when you recorded - Normally a resultof not having
deleted your browser’s cookie database (cache) before recording.
2. The cookie was set by client-side scripts within the HTML code e.g. JavaScript - SilkPerformer does not
execute JavaScriptso document.cookie cookies are hard-coded.
3. You recorded multipletransactions,in which casethe cookies are essential to maintain sessions
between transactions.
4. If your application does something a littleunusual - for example, setting the same cookies with
different values or different paths, modifyingcookies using JavaScriptetc.
In any case,it is very important NOT to comment out cookies in your scriptwithout understandingthe
consequences, sincethey may completely define application behavior.
If you want to simulatea new user you should delete your browsers cookiedatabasebefore recordingthe
application,so thatno existingpersistentcookies arerecorded. To record scripts for returningusers itis important
that you do not clear the cookie database.The importance in both cases is a resultof the fact the cookies may

define application behavior. For example, a site may identify new users by a lack a cookies and bringthem to a
registration page. Equally,itmay recognize returning users by their cookies and bringthem to a previously defined
personalized page. In either case,recordingappropriately may be important sinceyou cannot assumethat a script
for a returning user would work for a new user or viceversa.
For returning users (those who already have persistentcookies),you may need to randomize cookies if the cookies
contain uniqueIDs or individual user data - makingsurethat the resultantcookies arevalid for the application
server.
SilkPerformer provides functions to retrieve the valueof a cookiefrom a virtual user’s cookiedatabase
(WebCookieGet), write out the entire contents of a virtual user’s cookiedatabase(WebCookieList),and to
delete all of the cookies from a virtual user’s cookiedatabase(WebCookieResetDb).
Box-2: SilkPerformer Knowledge Base on Cookie Handling Mechanism
As mentioned in Box-1 and Box-2, the scripthas no explicit WebCookieSet function, and that is why the replay
engine mistook the checker’s request for maker’s request causingserver to respond something like:
The request is either forged or malicious. Retry the menu option!
Sending state information of other client is of course are forged requests. Hence subsequent checker requests
failed.
In next section, a solution to this is described.
For beginners, cookie handling mechanism of Silk Performer comes almost as a quirk that they don’t usually stumble upon.
However, SP has beautifully provided the functions to manipulate the cookie database. By end of section 3 you would learn
how to control the implicit cookie handlinginSilkPerformer, explicitly.
3. Building a solution
In this section, we are going to build a solution to maker-checker problem by overriding the silk performer replay
engine behavior usingcookiedatabasefunctions. The plan is simple:

1. Tell SP to record the custom http headers in script
2. Parse all the first session info (viz. JSESSIONID) that comes from server in response header and hold them into
(global) variables.
3. Parameterize the cookies and other dynamic fields with these variables
4. Reset Cookie databaseone you have acquired all thesession related info to retrieve another cookie.
3.1 Recording Cookies before each request:
Setting up a header field cookie by WebHeaderAdd() before every request in BDF script is tedious. Thanks to
record setting this can be trivialized. As mentioned in Knowledge Base,
The cookies are not written to the script (while recording by default) as everything is handled automatically by
the replay engine.
By default, the SP’s Recorder profile is not configured to capture the cookie field of Http Headers in the recorded
script after new project is created. We can tell the recorder to capture the cookie in script by adding header fields
to be recorded in the setting. To do this, go to Profile-> Record -> Web (Protocol Level) -> Recording Tab. In the
“Record additional HTTP headers”, click Add -> Type “cookie”. Click Ok and apply this setting to profile.
Fig-1: Recording additional HTTP headers
Note: cookie is common http header field and it is handled by silk automatically. But as stated earlier, not all headers are
captured by Silk Recorder because some of them are added by client side code, for example by JavaScript or AJAX such as
XmlHttpRequest. Another common field that is not always captured by SP is Referer which tells the server about last
page where user was or from which page the request originatedfrom. You maywishto addthis fieldtoo.
Once you do this setting, try recordingthe same scenario.After scriptgeneration, you will notice:

Figure-2: Record each cookie before every request
3.2 Parse name-value pairs in cookie field for the first time:
In the figure-2 you would notice that there is no cookie being sent in foremost request, which probably indicates
that recordingwas done as firsttime user; as mentioned in KB:
If you wish to simulate a returning user, you have to initialize the virtual user’s cookie database to contain the
appropriate cookie. This is done using the WebCookieSet function. This function allows you to add a cookie (or
change an existing one’s value) to the virtual user’s cookie database.
If we explorethe recorded truelog and look at the IN-HDR tab we find:
Figure-3: Foremost response header from server showing set-cookie field
We also notice there is another name APPS whose value is APPS4 in cookie. We can parse the field Set-
Cookie and extract the values of JSESSIONID and APPS and then parameterize in the script so that next time
each request will add appropriate cookie in the request header. Parsing is trivial using the function
WebParseResponseheader() which return all the Set-Cookie name-value pairs concatenated by semi-
colon. Apply StrSearchDelimited() to extract the JSESSIONID and APPS separately.

Figure-4: Parsing JSESSIONID and APPS
Finally,parameterizeforms and requests like:
Figure-5: Session Id handled explicitly
Note:
1. Usuallymanymore fields appear than just session IDs, e.g. RT ID, viewstates, request id, referrer andlike that. It is advised to
capture themas far as possible andreplace as mentioned above.
2. Not onlythat, theymayappear at anyplace inscript, not just onfirst request. Have a sharpeye on response headers and
request headers. Recorded true Log helps.
3. Recording rules canhelpyou a lot.
3.3 Reset the cookie Database:
In above section, we now assume that every dynamic field related to session has been captured at the first
response. (In the example above were JSESSIONID and APPS). Once you insure this, look at the shuffled script
of maker checker again:
Tinit // Rampup
2. Measure (Maker Logins)// Server sends Set-Cookie. Maker SessionID is parsed
10. Measure (Checker Home Page) // will Server send Set-Cookie again? No.
Tmain
…
Tshutdown
…
We notice that once the replay engine has sent Maker Logins request, it will receive the session id in response
header in set-cookie fields which will be parsed and used to parameterize the maker session id. But server will
not send set-cookie response in Checker Home Page because server will treat this as a request from the
maker itself. In fact server will never send cookie unless the user has reset the browser or it has closed the browser
to destroy cookieor somehow told that itdoesn’t have cookie so send one for the same.

Fortunately, there is way to reset the cookie database in Silk Performer. The function
WebCookieResetDb()deletes all thecookie in Vuser’s database.
But wait. If we delete all the cookies of vuser (which is currently maker) by calling WebCookieResetDb(),
won’t it affect the Maker request in Tmain? Of course it will, but since we have already parsed and saved the
session id in separatevariables,itwill causeno effect on server or network atall.
At this point it becomes clear why we are doing the steps mentioned in step 3.1 and 3.2!
Finally themodified scriptwill look somethinglike:
Tinit // Rampup
Parse Session_MKR
2. Measure (Maker Logins)
WebHeaderAdd(Cookie : Session_MKR)
WebCookieResetDb()
Parse Session_CKR
10. Measure (Checker Home Page)
WebHeaderAdd(Cookie : Session_CKR)
WebCookieResetDb()
Tmain // EXPLICITLY maintaining session info throughout test
7. Measure (Maker Submit Page)
8. Measure (Maker Accept Page) // Transaction ID
13. Measure (Checker HXFER Menu) // Transaction ID
14. Measure (Checker Debit Page)
15. Measure (Checker Credit Page)
16. Measure (Checker Verify Submit)
17. Measure (Checker Accept Page)

9. Measure (Maker Logout)
18. Measure (Checker Logout)
Box-3: Solution to maker-checker
This scriptruns withoutcausingserver to throw Forged or MaliciousRequest error.
Thus we have solved the maker checker problem. Look closely at script you will notice that we now control the silk
performer cookie database explicitly. Also noticed we actually multiplexed or incorporated two roles in single
script which is similar to opening two browsers on two different machines with one logged in as Maker and other
as checker. This should avoid the data creation and data management overhead too.
If there were a third role, this should bedone on similarfollowups.
Note: At the time of writing this, the Finacle 10 application at the UAT at RBS, allowed opening two browser windows or tabs
with one login as maker and another as checker at the same time. However real world applications are not like this because the
browsers store persistent cookies for domains, so two logins are not allowed. However next chapter describes an example in
which two user loginwas achieved for GATE website.
4. Another Example

Consider example of GATE website. This is an onlineform fillingwebsitefor a student who wishes to appear for
GATE exam. The user can visitpage,register and login only once per machineany browser. I managed to create
two dummy user IDs and passwords on this site -- both with different registration data.Firstuser A corresponded
to maker and second user B corresponded to checker. The maker-checker solution was applied and I am ableto
login both used simultaneously,fetch registration info for both users without conflictor server error. Also both
user logoutworked perfectly fine. Here is a snapshot:
I chose GATE website’s example because thiswebsite is simple andis basedon JSP(Java Server Pages). JSPusuallyhave single
set-cookie viz. JSESSIONID. With ASP.net we have manymore fields inheaders that maycomplicate the example. Hence while
scripting withASP.net pages the user shouldnotice these fields andhandle accordingto the example shown here. For ASP.net
fields in Set-Cookie and cookie, one can see Flipkart’s Website. Alsoscripts like Google analytics add toomanyforms and
fields inscript complicating the same. The BDF script canbe found onmyGoogle drive here.
5. Related Topics

5.1 HTTP Cookies:
Cookies are small text information or files that are stored by the server via client browser on their machine to store
the clients’state information.
HTTP protocol is Stateless protocol. That means, http does not describe to the server about their clients’ previous
states of action.
Browsers are expected to support cookies where each cookie has a size of 4KB, at least 50 cookies per domain, and
at least3000 cookies total. It consists of seven components:
1. Name of the cookie
2. Value of the cookie
3. Expiry of the cookie
4. Path the cookieis good for
5. Domain the cookieis good for
6. Need for a secure connection to use the cookie
7. Whether or not the cookiecan be accessed through other means than HTTP (i.e., JavaScript)
The firsttwo components (name and value) arerequired to be explicitly set.
Figure-6: Cookie Viewer in Mozilla Firefox 31
More about http cookies can be read here and here.
6. Exercise Problem
6.1 Recurring Parsing or Causal Parameterization:

Refer followingscript:
Tinit // Rampup
// same as box-3
Tmain
WebParseDataBoundEx(sData1) // sData1 is generated if sData0 was valid
7. Measure (Maker Submit Page + sData0) // sData0 is some previous data
// which is being submit here
8. Measure (Maker Accept Page)
// something here
// same as box-3
At step 7, sData0 is beingsent to server in Maker Submit Page, which generates sData1 as parsed above. This
data is generated if and only if the sData0 was valid.Hence to generate sData2, sData1 should be valid data,to
generated valid sData3; the sData2 should be valid and so on.This is recurring parsing means the current parsing
is successful if and only if the previous parsingwas rightand is beingsent in Maker Submit Page. Parsingis
null if previous data was not sent or parsed.
How would you confirm such causal relationship on such parsing variable? How would you modify this so script
works when Tmain is, say, 10?
7. Hints and solution to exercise problem

To confirmthe causal relationship,you should record the two set of tmain actions and confirmitvia truelog.
To handlethe issuedefineanother variable,say sData_Nexts, and sData_Current, do something like:
Tinit // Rampup
sData_Current := seed value;
// same as box-3
Tmain
WebParseDataBoundEx(sTemp)
sData_Next := sTemp;
7. Measure (Maker Submit Page + sData_Current)
// current value depends on previous value
8. Measure (Maker Accept Page)
// something here
// at the end
sData_Current := sData_Next;
// same as box-3
I faced the similarproblem whileworkingon load testing project at HDFC bank Web Collections (Contact
Recording) – a Help Desk Support application.
8. References and Readings
1. http://en.wikipedia.org/wiki/Maker-checker
2. http://www.tutorialspoint.com/jsp/jsp_cookies_handling.htm

3. http://en.wikipedia.org/wiki/Emulator
4. http://community.microfocus.com/borland/test/silk_performer_-
_application_performance_testing/w/knowledge_base/9816.how-does-silkperformer-handle-cookies.aspx
5. Silk Performer’s automatically cookiehandling mechanism:
http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.doc%2FSILKPERF-
B111149F-WHENTOUSECUSTOMIZEDSESSIONHANDLING-CON.html

Maker Checker -Incorporating Multiple Roles in Single SilkPerformer script

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Maker Checker -Incorporating Multiple Roles in Single SilkPerformer script

Similar to Maker Checker -Incorporating Multiple Roles in Single SilkPerformer script (20)

Maker Checker -Incorporating Multiple Roles in Single SilkPerformer script