IBM Enterprise Workload Manager Release 1

144 IBM Enterprise Workload Manager

5.5.2 Creating the domain policy at the EWLM Control Center

You are now ready to start the implementation of the domain policy. We assume that you

already understand how to create domain policy; therefore, this section does not describe

how to do it screen-by-screen. Refer to “Building a domain policy” on page 92 for a detailed

description of the steps to create a domain policy.

5.6 Verification

In this phase, we verify our new domain policy and defined service policy.

Before you deploy a new domain policy into your production environment, you have to verify

that there is no mistake or error in your domain policy. Possible mistakes are often found at:

򐂰 Work request classification

򐂰 Service class definition

When all the following steps are completed successfully, you can use the EWLM monitoring

and reporting functions.

5.6.1 Verifying transaction request classification filters

There may be some mistakes in your classification filter no matter how carefully you

implemented it. EWLM does not provide a tool to show what transaction request is classified

to what transaction class, thus you have to check manually using the EWLM Control Center.

Our verification steps are follows:

1. Run the workload again.

2. Review classification result using Transaction Classes monitor.

3. Redefine the classification filter.

Run the workload again

We run the workload to Trade3 and Plants by WebSphere again using WebSphere Studio

Workload Simulator for z/OS and OS/390. We use the same workload for this step that we

described in “Identifying an edge server of the work request” on page 128.

Review classification result using Transaction Classes monitor

Next, we review the Transaction Classes monitor to verify our classification filter. To see the

monitor:

1. Log in to the EWLM Control Center as the user who has monitor role. In our case we log

on as user ewlmmon.

2. Click Transaction classes on the navigation panel.

Figure 5-11 shows the classification result. We found that the Response time value for two

transaction classes, TC_Trade3_register and TC_Trade3_update_profile, shows 00.000

average, which means these transaction classes do not receive any requests. No work

Note: You have to run the workload longer than the interval specified in the EWLM Control

Center preferences in order to make EWLM detect all work requests and classify them to

transaction class successfully. Refer to 4.1, “EWLM Control Center overview” on page 78

for more information.

Chapter 5. The ITSO EWLM scenario 145

request is classified to these transaction classes, although there are work requests to

register and update_profile action. This is due to wrong classification filters.

Figure 5-11 Result of classification filter at Transaction Classes monitor

Redefine the classification filter

We can verify whether Trade3 receives the work request related to the actions or not using

the IBM HTTP Server access log file. We transfer the IBM HTTP Server access log file to our

Linux machine as we did at “Identifying transactions” on page 131.

Then, we use grep again to print lines which contain “?” and “register” or “update_profile”

to verify if the IBM HTTP Server received the work request related to these actions.

Example 5-5 and Example 5-6 show us that the work requests were coming to the application

but were not classified to the appropriate transaction class. There may be some mistakes in

our classification filter, therefore EWLM classifies these work requests to the general

transaction class, TC_Trade3_general.

Example 5-5 Access log of register action for Trade3

[root]# grep '?' access.log | grep register | head -3

9.12.4.54 - - [17/May/2004:17:01:16 -0400] "GET /trade/app?Full+Name=first%3A176

+last%3A3209&snail+mail=1925+mystreet&email=ru%253A1111960%4038.com&user+id=ru%3

A1111960&passwd=222&confirm+passwd=yyy&money=1000000&Credit+Card+Number=123-fake

-ccnum-456&action=register HTTP/1.1" 200 13413

9.12.4.54 - - [17/May/2004:17:01:39 -0400] "GET /trade/app?Full+Name=first%3A573

+last%3A2840&snail+mail=337+mystreet&email=ru%253A2135272%4057.com&user+id=ru%3A

2135272&passwd=222&confirm+passwd=yyy&money=1000000&Credit+Card+Number=123-fake-

ccnum-456&action=register HTTP/1.1" 200 13413

9.12.4.54 - - [17/May/2004:17:01:46 -0400] "GET /trade/app?Full+Name=first%3A46+

last%3A2146&snail+mail=2122+mystreet&email=ru%253A7142375%4010.com&user+id=ru%3A

7142375&passwd=222&confirm+passwd=yyy&money=1000000&Credit+Card+Number=123-fake-

ccnum-456&action=register HTTP/1.1" 200 13413

Example 5-6 Access log of update_profile action for Trade3

[root]# grep '?' access.log | grep update_profile | head -3

9.12.4.54 - - [17/May/2004:17:01:17 -0400] "GET /trade/app?userID=uid%3A20&fulln

ame=rnd5114277&password=111&address=rndAddress&cpassword=xxx&creditcard=rndCC&em

ail=rndEmail&action=update_profile HTTP/1.1" 200 13601

9.12.4.54 - - [17/May/2004:17:01:26 -0400] "GET /trade/app?userID=uid%3A15&fulln

ame=rnd7123842&password=111&address=rndAddress&cpassword=xxx&creditcard=rndCC&em