Demystifying testing of Lawson applications with IBM Rational Performance Tester

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

Chip Davis (chip.davis@us.ibm.com), Certified Technical Services Specialist, IBM
Fariz Saracevic (fariz@us.ibm.com), Senior IT Architect, IBM

04 Dec 2007

Lawson Software includes enterprise resource planning (ERP) and human resources (HR) applications that are used in many hospitals and healthcare organizations. These are critical to business, which makes performance testing crucial to both the successful deployment and the upgrades of Lawson systems. This article provides guidance and information, including specific steps, for using IBM® Rational® Performance Tester to test Lawson applications.

Prerequisites

The steps described in this article require installation of IBM®Rational® Performance Tester Version 7.0.0.2 or later. There are no additional extensions or plug-ins required to test Lawson applications. The authors assume a general knowledge of how to use Rational Performance Tester, such as recording and editing tests, adding verification and manual correlation, and basic reporting.

Overview of Lawson applications

Lawson Software is an IBM partner that provides software for enterprise performance management, supply chain management, enterprise resource planning (ERP), customer relationship management, manufacturing resource planning, enterprise asset management, and industry-tailored applications. The Lawson Web site explains the relationship with IBM:

"Lawson provides open, standards-based software solutions that fundamentally improve customers' business performance. The open architecture of Lawson's solutions gives customers superior quality, a low total cost of ownership and a path to a service-oriented architecture (SOA). Lawson's technology platform -- Lawson System Foundation 9 -- combines Lawson's newest technology with world-class middleware from IBM for a high-performance, standards-based solution that delivers comprehensive security, scalability and usability. It also preserves customers' choice of hardware platform while providing a foundation for next-generation Lawson applications designed for use within SOA environments."

Lawson has offered healthcare-focused information technology solutions for more than a decade. These applications can be found in many hospitals, healthcare organizations and facilities across the United States and worldwide.

Summary of Lawson performance testing

The Lawson System Foundation uses a standard Web-based client for simple HTTP-based performance testing. Although this is not very different from other Web-based applications, there are several relevant characteristics relevant to using Rational Performance Tester:

• Lawson consists primarily of numerous forms that are accessed directly by entering the form name or identifier, such as HR11. Every time a user enters a value in a field (by tabbing or clicking into the next field), that triggers an HTTP request and response, even though the page appears to be the same to the user. Filling out a single form may involve many requests and a great many hidden fields for every response. Aside from this, there is relatively little other communication, such as binary or other non-HTTP network traffic.

• Rational Performance Tester may group multiple fields (steps) together into a single page in the test; however, this is not ideal for reporting or identifying performance bottlenecks. Lowering the page generation threshold will produce tests that are better for reporting and easier to edit and understand. (See the "Tool settings" subsection that follows.)

• Lawson uses two-part authentication, although this can be handled automatically by Rational Performance Tester. In some cases, you may need to manually edit the authentication (see the Manual Test Modifications section that follows). Some fields, including hidden HTTP fields, may not be automatically correlated by Rational Performance Tester; therefore, you must manually correlate them. (See the "Correlating data" section that follows.)

• Many Lawson functions require today's date as an input field. That is, the date value must match the date of the test run. You can use Rational Performance Tester custom code for this, as the "Generating data during test execution (custom code)" section that follows explains.

• Content verification points (VPs) are vital to confirm Lawson functionality during test execution. (See the "Enabling verification points" section that follows.)

• One tricky aspect to developing tests for Lawson is that the application may respond with a success message even when the transaction was not successful. For example, if a change request has an invalid field value, then the correct record will not be changed, yet Lawson may still respond with a "Change Complete" notice. One way to validate a successful transaction is by looking up the record (manual or automated) to verify the change.

Examples of Lawson forms for healthcare

These are a few of the common Lawson forms that you might test:

• AP20 - Invoice Data
• HR11 - Employee Maintenance
• IC21 - Issues
• PA26 - Employee Review
• PA31 - Applicant
• PA52 - Individual Action
• PO20 - Purchase Order

Initial considerations for developing tests

Before recording test procedures in Rational Performance Tester, you must document test procedures. Be sure to specify which field values will be included in the data pool (input from a table of test data) and whether those will be random or static (the same for every test run). Given the level of effort often required to enhance a script for Lawson, it is important that you validate and confirm the test procedures first.

Careful consideration and selection of test data can be important also, because this can affect test development. For example, if you record a transaction using a test record that has no value for field values <_f93> and <_f94> and these are hidden fields, but other test data records do have values, then it will be difficult to correlate these from the recorded transaction. Ideally, the test data used for recording should have a maximum number of available values. That is, the data should fill out the forms as much as possible, yet still be realistic for testing purposes.

Tool settings

Most of the default Rational Performance Tester settings will work fine for Lawson systems with the exception of lowering the delay to generate a new page. Change this under Window > Preferences > Test > Performance Test Generation > Protocol tab > Generate new page if delay between requests > 1000 ms or less. This will ensure that Rational Performance Tester will generate tests where each page contains a single field request, facilitating the locations for test edits. Transactions can then be used for reporting on times for entire forms or user actions.

Recording a Lawson performance test

Initiating the recording of a Lawson test is no different from HTTP recording.

1. You can start either by clicking Create New Test From Record on the toolbar or by selecting it from the Test From Recoding menu (File > New > Test From Recoding).
2. For Lawson recording, select the HTTP Recording option (see Figure 1), and then click Next.

3. In the next window, select the appropriate folder within the performance test project, enter a test name, and then click Finish to continue.
4. When the recording starts, the tester performs actions against the Lawson application.
5. When the test scenario has completed, close the browser to stop recording, and generate the test. Figure 2 shows a recorded test scenario against the Lawson Requisition Self Service (RSS).

Manual test modifications

After you capture a Lawson test procedure into a test, you need to modify the test. Some of the values that were captured during the recording must be unique for the test to play back without errors. These values may come from the Lawson servers or may be calculated (for example, the current time), and these need to be correlated in the test. Other values will not be required to be different, but you will want to vary them to create a realistic test. These optional values can come from tables of test data, which need to be added to a data pool in the test. This section describes the Lawson values that must be changed, as well as how to vary other test data.

Renaming the pages

One of the first things that you can do after Rational Performance Tester finishes generating the test is to rename the pages. The Lawson Web application does not provide meaningful names that Rational Performance Tester can use to label the pages. For example, some pages will be given the name servlet_ida, rather than the actual name of the form. It is best to rename theses pages according to the form that is accessed or the specific field that is updated. This is important not only to help "read" the test in Rational Performance Tester but, more importantly, to interpret the test results and reports.

System authentication adaptations

Lawson uses Basic Authentication, which is recorded in Rational Performance Tester. This is pretty straightforward and easy to handle, but most applications use only one basic authentication. Lawson authenticates users both on the login page and when they are accessing the home page. Therefore, Rational Performance Tester creates two basic authentication folders in each test (see Figure 3). The User ID and Password values can be added to the data pool at this point:

1. Simply select userID or password, right-click, and select Substitute From > Datapool Variable (see Figure 3).

The first request on the Lawson portal home page with the basic authentication will also contain a timestamp value. Even though it might not be required, this value should reflect the current time in each test playback, so that it is unique (see Figure 4).

You can use the Rational Performance Tester built-in data sources capability to provide a unique value for the timestamp:

2. Select the timestamp value in the test data (see Figure 5) and then click the Substitute From button.
3. Select the Built-in Datasources option.
4. When the Built-in Datasource Selection wizard opens (Figure 6), select Timestamp, and then click Finish.

You could use a data pool for the user profile data. However, because Lawson applications provide this data during login in the response content from the Lawson portal home page (see Figure 7), it is best to correlate this information from the response. This ensures that you are using the correct information and saves memory that would be used by the datapool otherwise.

Substituting test data

There are many values that a Lawson user inputs into the system, such as names and quantities on a form. Initially, a test will contain only the values that you used when recording the test. Rational Performance Tester will indicate through color coding (green) values in the test that you may want to substitute; these are identified as Datapool Candidates.

You should know from the test procedure which values are intended to vary for every user in the test execution, and these values should be provided in a table of test data. In Rational Performance Tester, you can import test data from a table into a datapool through a comma-separated value (.csv) file. When you have your test data set up in data pools, you can substitute data pool values for these. For each form value that is to included in the data pool, perform these tasks:

1. Run a Test Search (Ctrl+H) on the test. Select only HTTP Requests, ensure that both URL and POST Data fields are checked, and search for the value used during recording.
2. From the Search results, expand and right-click on each instance, and select Go To to highlight the value under the Test Elements Details.
3. From the selected value in the Test Elements Details, you can right-click and substitute a data pool variable.
4. Repeat Steps 2 through 3 for every search result.

Correlating data

Although the user inputs some test data directly on a form, other data is retrieved from the Lawson database and then passed back and forth during the test procedure. For example, you enter a company code of 123, but Lawson retrieves the company name, Acme, Inc., and both values are then used in all requests. You enter only one value, but other corresponding values may not be visible.

The Lawson transactions will work only if all related values are passed together. Therefore, if you do not substitute all of the values, then the transactions will be invalid. You will need to determine what data corresponds to values that were entered directly in the forms. You may not realize these values are even there until after you investigate failures in the initial test playback. In some cases, someone who is familiar with the forms and data being used may know what these values are. If not, then you can review the POST Data content (typically after an action such as Add, Change, or Inquiry) for values that correspond to the value that you entered. For every value identified that requires manual correlation, follow these steps:

1. Record two completely different transactions (different companies, employees, and so forth).
2. Run a Test Search on the test, selecting only HTTP Responses (not Requests), ensuring that the Content field is checked, and search for the identified value.
3. From the Search results, expand and right-click on only the first found, and select Go To to highlight the value under the Test Elements Details.
4. From the selected value in the Response Content, right-click and click Create Reference.
5. Run another Test Search, selecting only HTTP Requests and search for the same value.
6. From the Search results, expand and right-click on each instance, and select Go To to highlight the value under the Test Elements Details.
7. From the selected value in the Test Elements Details, you can right-click and substitute the reference value (Substitute From > value - Content).
8. Repeat Steps 6 through 7 for every search result.
9. For any other form values that require manual correlation, repeat Step 3.

In some cases, such as the HR11 form, you can better determine variable data this way:

1. Record two completely different transactions (different companies, employees, and so on).
2. Locate the page for the primary actions performed in the test procedure, such as Inquire, Add, or Change. This will be of the form of [server]/servlet/args and will pass values in POST data.

Tip: You may also want to look at other requests, such as the Get statement preceding the final POST, to compare.

3. Select the request data and copy into a separate text file.
4. You could also use the entire trace file (*.rec), but this might be more difficult.
5. Repeat this for the other recorded test which will give you two files, each with the same request but different data.
6. Use a file comparator (a "diff" tool) to compare the requests. In addition to the obvious values you entered or saw on the screen, the diff tool will also show hidden and obscure values that must be unique for each different transaction.

Generating data during test execution (using custom code)

There is some data that your tests will use by Lawson are not provided by the system and you may not want to store them in data pools. Some examples of these are today's date or fields requiring random values. These values can be generated during test execution using custom code in Rational Performance Tester as follows:

1. Run a Test Search on the test, selecting only HTTP Requests and ensuring that both URL and POST Data fields are checked, and then search for the value used during recording.
2. From the Search results, expand and right-click on each instance, and select Go To to highlight and indicate in which request the value is passed.
3. Under Test Contents, Insert or Add a custom code class before (above) the first request that will use the value (the request indicated in Step 2). You can move the class up or down if necessary.
1. If the class requires an input value (for example, if you are parsing or manipulating data from a test value), then you must create a reference for the value. You can do this before or after you create the class.
2. Add this to the custom code, either from a reference or a data pool.
4. Create or copy the code into the class, and pass the required data back to the test with the return. One example of this is the GetDate class, which will return the current date in the format used by Lawson forms (in a U.S. English locale).
5. Return to the Search results, right-click, and select Go To for the same item that you selected in Step 2.
6. From the selected value in the Test Elements Details, substitute the value with the custom code return.
7. Repeat Steps 5 and 6 for every search result.

Enabling verification points

To ensure accurate completion of the tests, there are several verification points (VPs) available for you to use. You can enable them on the entire test or on a specific page. Two examples:

• Response Code verification points are the mostly commonly used. They verify that status code captured during the recording of the test did not change when the test ran.

• Content verification points are powerful tools to verify if a specified string does or does not appear in response content.

Always include at least one Content VP. You can do this by following these steps:

1. Locate the page for the primary actions performed in the test procedure, such as Inquire, Add, or Change. This will be of the form [server]/servlet/args and will pass values in POST data.
2. Right-click on the response content, and enable a Content VP.
3. Add a user-defined string: <MsgNubr>lt;/MsgNbr>. You will need to do this only once for each project.
4. Select Verification fails if: None of the checked strings are found.
5. You can repeat this for other responses to similar actions in the same test if needed.

Playing back a Lawson performance test

Rational Performance Tester provides accurate workload emulation by using schedules. Thus, after you finish editing your test, you need to create a schedule.

1. First, add user groups to the schedule, and then add appropriate tests to each group to emulate a task.
2. In addition, you can distribute test execution across several machines. In this scenario, we specified that User Group 4 run from the test agent called TestSrv1 (see Figure 9).

Reviewing Lawson reports

You can view the execution of a performance schedule that applies the load on the Lawson system, using several real-time reports:

• The Overall report (Figure 10) provides the percentage of successful page loads, page element loads, and verification points.

• The Response vs. Time Summary indicates how the page response behaved while the system was under load. The steady state behavior in the time range of 1500 to 3000 seconds shows page response averaging around 1.5 seconds per page and 0.1 seconds per page element (Figure 11).

• The Page Throughput reports the page hit rate over time (left side of the graph in Figure 12) and the user load (right side of the graph in Figure 12). In this example, the user load is ramped up to 1000 users, and a steady state load exists from 1500 seconds to 3000 seconds of the elapsed time.

Resources

• Learn more in the Rational Performance Tester area on IBM® developerWorks®, where you will find technical documentation, how-to articles, product information, and more.
  
  
• Check the Lawson Software Web site for more information about Lawson applications.
  
  
• Keep up by reading the developerWorks Rational zone newsletter. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
  
  
• Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
  
  
• Sign up for the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

• Get trial versions of IBM Rational software or demos.

• Participate in the Performance Testing discussion forum on developerWorks.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

		Chip Davis is a member of the IBM Rational Brand Services organization. In this role, he leads the development of service offerings and other intellectual capital that accelerates customers' business results and success achieved via their use of IBM Rational tools, methods, and solutions. He has deployed Rational solutions at various clients across the United States since 1999. Chip can be reached at chip.davis@us.ibm.com.

		Fariz Saracevic is a Senior IT Architect for IBM Rational Software Services. He has a background in quality assurance, and his primary focus is software test automation. Fariz has worked with numerous software test teams in consulting, mentoring, and training capacities. He holds a master's degree in information technology from Virginia Tech.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top