128 IBM Enterprise Workload Manager
5.4.1 Identifying the transactions that request business functions
The first step of the design phase is to identify and classify the transactions.
It is difficult to identify all transactions in a distributed environment even if the EWLM
management domain consists only of a few servers like in our test environment. The easiest
way is to interview the application developer and ask the following questions:
? How do clients use this application?
? What type of applications access this middleware?
However, if you do not get answers to those questions you are in the same situation as we are
with our test environment. We therefore provide an example study for such a case, describing
how to identify transactions. It is, of course, dependent on your application environment.
To create transaction classes, you have to identify an edge application first since all work
requests are classified to service classes by EWLM by its edge application. It is the entry
point of your applications as described at 1.2, “EWLM concepts” on page 5. When we set up
our servers, operating systems, middleware, applications, and firewall in our environment, we
already know that the edge server of both Trade3 and Plants by WebSphere is the IBM HTTP
Server. In the next section we describe how to find an edge server if such reference
information is not available.
The overall process of identifying the transactions that request business functions involves
the following steps:
1. Identifying an edge server of the work request
2. Identifying transactions
3. Defining transaction classes
4. Mapping transaction classes to service class
Identifying an edge server of the work request
EWLM provides an application topology view which is a high-level view of the EWLM domain
from a business transaction perspective. We use this view and an EWLM sample domain
policy, Sample Banking Domain Policy, to identify the edge application of the work request.
While using this policy, all work requests we generate are classified to a default transaction
class in the domain policy because there is no transaction class suitable for our work request.
There are, by default, three transaction classes for each application respectively:
? Default - IBM DB2 Universal Database
? Default - IBM Webserving Plugin
? Default - WebSphere
These transaction classes have the same classification filter, (*) Equal (*), that matches
to a work request which does not match any other transaction class filters. For more
information on how filters work, refer to 4.2.1, “Classifying your workload” on page 88.
Tip: You can use EWLM default domain policy in this step, although we used Sample
Banking Domain Policy. If the EWLM domain does not have an active service policy, the
EWLM domain uses the default service policy, which consists of a discretionary goal for all
transactions, but you cannot use the default policy once you have deployed some policy to
your domain; it’s gone.