Incorporating Multiple Roles in Single SilkPerformer script

Maker checker in single BDF

v1.01

By Swarnkar RajeshTest Engineer, Performance Testing

Table of Contents1. Maker Checker Scenario 1.1 Description 1.2 The problem with shuffling measures2. Diagnosing the issue: What went wrong? 1.2 Found solution in Cookies 3. Building a solution 3.1 Recording Cookies before each request 3.2 Parse name-value pairs in cookie field for the first time 3.3 Reset the cookie database4. Another Example5. Related Topics 5.1 HTTP Cookies6. Exercise Problem 6.1 Recurring Parsing or Causal Parameterization7. Hints and Solutions to the exercise8. References and readings

Document ID: MakerChecker_V1.01

Keywords: checker maker, multiplexing users, emulating users

Document Versioning:

Version Date Updated Description of Change Edited/Released by0.1 September 07, 2014 Document created Swarnkar Rajesh

From the author

While I was on Finacle 10 (new core banking) load testing project at Royal Bank of Scotland (RBS) at Parel, I came across maker checker problem. This problem is described in this document along with work around that I applied in BDF (benchmark description scripts).

I also discovered the importance of cookies and how to manipulate them using silk performer functions. All of these have been explained briefly.

About the author

Swarnkar Rajesh is Computer Engineering bachelor from University Of Mumbai. He is currently working at QualityKiosk Inc. as Software Performance Testing engineer. He enjoys learning about software development and testing. He likes to ponder about metaphysics and philosophies in his free time.

1. Maker Checker Scenario1.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 be described from the load test scripting perspective as follows:

1. The maker has own User ID and password with its system. The maker logs in to the finance application called Fincore via browser2. Maker is redirected to the Fincore menu3. Maker searches a menu say, HXFER (fund transfer) 4. On HXFER menu screen, maker enters debiting account id and clicks on go5. The maker fills the debiting amount on Debit page6. The maker fills the crediting (target) account id and amount on Credit page7. Maker submits these pages which generates Transaction I d and printable receipts8. Maker accepts the transaction 9. Maker logs out and closes the browser10. Checker Opens browser (may be from his machine), visits login page11. Checker logs in with its own credential 12. Checker is redirected to the Fincore menu13. Checker searches the menus screen HXFER (fund transfer)14. On HXFER menu, Checker enters the Transaction ID (as in step 7) and clicks on submit.15. The data as filled by maker in debit/credit pages is auto populated for verification16. Checker clicks on Verify to submit the verified transaction17. Checker can take prints of receipt18. Checker logs out and closes the browser.

This whole activity was recorded with silk performer as stated here sequentially (Tmain). After parameterization of appropriate fields and customization of session and dynamic fields, the script would 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 logout pages are kept in TShutdown : end so logout takes place at the ramdown of load test.

This is done as follows:Tinit // Rampup1. 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 test4. 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 ID14. Measure (Checker Debit Page)15. Measure (Checker Credit Page)16. Measure (Checker Verify Submit)17. Measure (Checker Accept Page)

Tshutdown // Rampdown9. 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 script which will verify them. This is overhead for loadtest requiring data management.

NOTE: I am assuming 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. Following is a precept from Silk Performer’s knowledge base:

There are two categories of cookies: persistent and non-persistent (transient). Persistent cookies maintain their existence and value from browser session to browser session; they

contain expiry dates (in the future). Non-persistent cookies only exist during a single browser session.

Persistent cookies 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 requiring the user to login and identify themselves. This is done through a persistent cookie on the user’s system). Non-persistent cookies are used to maintain session-specific "state" information, such as session IDs. Further, persistent cookies are physically stored on the local hard-drive while non-persistent cookies exist only 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 like the cookie database associated with a browser session - it holds all the currently valid cookies. When a cookie is set by the server, the appropriate data is saved to that virtual user’s cookie database. If an HTTP request is made to a domain that has an existing cookie associated with it then that cookie value is read from the virtual user’s cookie database and sent to the server as part of the request.

It is important to realize that each virtual user has their own cookie database - there is no overlapping between different virtual user’s cookies. Another important point is that the cookie database only "lives" for the duration of a virtual user - the DB is empty when a virtual user is first created and is destroyed once the virtual user has completed. Given this, it can be seen that virtual users will emulate new visitors to a site, since there will not be any persistent cookies in the virtual user’s cookie database at the beginning of replay. Therefore 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 you use this function to place a cookie into the virtual user’s cookie database you can successfully simulate a 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 the cookie’s value back to the client in the response header and then the cookie’s value is maintained for the life of 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 script it is generally for one of the following reasons:

1. It is a persistent cookie that already existed when you recorded - Normally a result of 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 JavaScript so document.cookie cookies are hard-coded.3. You recorded multiple transactions, in which case the cookies are essential to maintain sessions between transactions.4. If your application does something a little unusual - for example, setting the same cookies with different values or different paths, modifying cookies using JavaScript etc.

In any case, it is very important NOT to comment out cookies in your script without understanding the consequences, since they may completely define application behavior.

If you want to simulate a new user you should delete your browsers cookie database before recording the application, so that no existing persistent cookies are recorded. To record scripts for returning users it is important that you do not clear the cookie database. The importance in both cases is a result of the fact the cookies may define application behavior. For example, a site may identify new users by a lack a cookies and bring them to a registration page. Equally, it may recognize returning users by their cookies and bring them to a previously defined personalized page. In either case, recording appropriately may be important since you cannot assume that a script for a returning user would work for a new user or vice versa.

For returning users (those who already have persistent cookies), you may need to randomize cookies if the cookies contain unique IDs or individual user data - making sure that the resultant cookies are valid for the application server. SilkPerformer provides functions to retrieve the value of a cookie from a virtual user’s cookie database (WebCookieGet), write out the entire contents of a virtual user’s cookie database (WebCookieList), and to delete all of the cookies from a virtual user’s cookie database (WebCookieResetDb).

Box-2: SilkPerformer Knowledge Base on Cookie Handling Mechanism

As mentioned in Box-1 and Box-2, the script has no explicit WebCookieSet function, and that is why the replay engine mistook the checker’s request for maker’s request causing server 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 handling in Silk Performer, 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 using cookie database functions. The plan is simple:

1. Tell SP to record the custom http headers in script2. 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 variables4. Reset Cookie database one you have acquired all the session 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 originated from. You may wish to add this field too.

Once you do this setting, try recording the same scenario. After script generation, 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 recording was done as first time 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 explore the 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, parameterize forms and requests like:

Figure-5: Session Id handled explicitly

Note: 1. Usually many more fields appear than just session IDs, e.g. RT ID, view states, request id, referrer and like that. It is advised to capture them as far as possible and replace as mentioned above.2. Not only that, they may appear at any place in script, not just on first request. Have a sharp eye on response headers and request headers. Recorded true Log helps.3. Recording rules can help you 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 // Rampup1. Measure (Maker Home Page) 2. Measure (Maker Logins)// Server sends Set-Cookie. Maker SessionID is parsed3. Measure (Maker Fincore Page)

10. Measure (Checker Home Page) // will Server send Set-Cookie again? No. 11. Measure (Checker Logins)12. Measure (Checker Fincore Page)

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 cookie or somehow told that it doesn’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 the cookie 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 separate variables, it will cause no effect on server or network at all.

At this point it becomes clear why we are doing the steps mentioned in step 3.1 and 3.2!

Finally the modified script will look something like:

Tinit // Rampup 1. Measure (Maker Home Page) Parse Session_MKR 2. Measure (Maker Logins) WebHeaderAdd(Cookie : Session_MKR)3. Measure (Maker Fincore Page)

WebCookieResetDb()

Parse Session_CKR10. Measure (Checker Home Page)11. Measure (Checker Logins) WebHeaderAdd(Cookie : Session_CKR)12. Measure (Checker Fincore Page)

WebCookieResetDb()

Tmain // EXPLICITLY maintaining session info throughout test WebHeaderAdd(Cookie : Session_MKR)4. Measure (Maker HXFER Menu) WebHeaderAdd(Cookie : Session_MKR)5. Measure (Maker Debit Page) WebHeaderAdd(Cookie : Session_MKR)6. Measure (Maker Credit page) WebHeaderAdd(Cookie : Session_MKR)7. Measure (Maker Submit Page) WebHeaderAdd(Cookie : Session_MKR)8. Measure (Maker Accept Page) // Transaction ID

WebHeaderAdd(Cookie : Session_CKR)13. Measure (Checker HXFER Menu) // Transaction ID WebHeaderAdd(Cookie : Session_CKR)14. Measure (Checker Debit Page) WebHeaderAdd(Cookie : Session_CKR)15. Measure (Checker Credit Page) WebHeaderAdd(Cookie : Session_CKR)16. Measure (Checker Verify Submit) WebHeaderAdd(Cookie : Session_CKR)17. Measure (Checker Accept Page)

Tshutdown // Rampdown WebHeaderAdd(Cookie : Session_MKR)9. Measure (Maker Logout)

WebHeaderAdd(Cookie : Session_CKR)18. Measure (Checker Logout)

Box-3: Solution to maker-checkerThis script runs without causing server to throw Forged or Malicious Request 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 be done on similar follow ups.

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 login was achieved for GATE website.

4. Another Example

Consider example of GATE website. This is an online form filling website for a student who wishes to appear for GATE exam. The user can visit page, register and login only once per machine any browser. I managed to create two dummy user IDs and passwords on this site -- both with different registration data. First user A corresponded to maker and second user B corresponded to checker. The maker-checker solution was applied and I am able to login both used simultaneously, fetch registration info for both users without conflict or server error. Also both user logout worked perfectly fine. Here is a snapshot:

I chose GATE website’s example because this website is simple and is based on JSP (Java Server Pages). JSP usually have single set-cookie viz. JSESSIONID. With ASP.net we have many more fields in headers that may complicate the example. Hence while scripting with ASP.net pages the user should notice these fields and handle according to the example shown here. For ASP.net fields in Set-Cookie and cookie, one can see Flipkart’s Website. Also scripts like Google analytics add too many forms and fields in script complicating the same. The BDF script can be found on my Google 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 least 3000 cookies total. It consists of seven components:

1. Name of the cookie 2. Value of the cookie 3. Expiry of the cookie4. Path the cookie is good for 5. Domain the cookie is good for6. Need for a secure connection to use the cookie7. Whether or not the cookie can be accessed through other means than HTTP (i.e., JavaScript)

The first two components (name and value) are required to be explicitly set.

Figure-6: Cookie Viewer in Mozilla Firefox 31

More about http cookies can be read here and here.

6. Exercise Problem6.1 Recurring Parsing or Causal Parameterization:Refer following script:Tinit // Rampup // same as box-3

Tmain WebHeaderAdd(Cookie : Session_MKR)4. Measure (Maker HXFER Menu) WebHeaderAdd(Cookie : Session_MKR)5. Measure (Maker Debit Page) WebHeaderAdd(Cookie : Session_MKR)6. Measure (Maker Credit page) WebHeaderAdd(Cookie : Session_MKR)

WebParseDataBoundEx(sData1) // sData1 is generated if sData0 was valid7. Measure (Maker Submit Page + sData0) // sData0 is some previous data // which is being submit here

WebHeaderAdd(Cookie : Session_MKR) 8. Measure (Maker Accept Page) // something here

Tshutdown // Rampdown // same as box-3

At step 7, sData0 is being sent 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 parsing was right and is being sent in Maker Submit Page. Parsing is 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 confirm the causal relationship, you should record the two set of tmain actions and confirm it via truelog.To handle the issue define another variable, say sData_Nexts, and sData_Current, do something like:

Tinit // Rampup sData_Current := seed value; // same as box-3

Tmain WebHeaderAdd(Cookie : Session_MKR)4. Measure (Maker HXFER Menu) WebHeaderAdd(Cookie : Session_MKR)5. Measure (Maker Debit Page) WebHeaderAdd(Cookie : Session_MKR)6. Measure (Maker Credit page) WebHeaderAdd(Cookie : Session_MKR) WebParseDataBoundEx(sTemp) sData_Next := sTemp;7. Measure (Maker Submit Page + sData_Current) // current value depends on previous value WebHeaderAdd(Cookie : Session_MKR) 8. Measure (Maker Accept Page) // something here

// at the end sData_Current := sData_Next;

Tshutdown // Rampdown // same as box-3

I faced the similar problem while working on 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.htm3. 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.aspx5. Silk Performer’s automatically cookie handling mechanism: http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.doc%2FSILKPERF-B111149F-WHENTOUSECUSTOMIZEDSESSIONHANDLING-CON.html