In OEM Grid Control, each of the synthetic transactions executed to model the different business functions from various beacons in multiple locations are called service tests. A service test in OEM Grid Control represents an atomic unit of business flow, whose performance can be measured independently. These service tests are executed from different beacons deployed in various geographical locations.
There can be multiple service tests which model different aspects of the same service target. For example, the flight reservation business function can be monitored by executing three different service tests: add new flight, search flight, and book flight.
While there could be multiple attributes of a business function that are monitored by different service tests, only a subset of the configured service tests are required to define the availability of a service target. These service tests that participate in the definition of the availability of the business service are called key tests.
OEM Grid Control supports different types of service tests. Different types of service tests are described in detail in the subsequent sections within this chapter.
Each service test of a particular type requires a set of parameters that need to be configured. All service tests of the same type have similar parameters to be configured. For instance, for a service test of type FTP Ping, the FTP server host, the FTP server port, and the user name and password need to be configured. These parameters that need to be configured to execute a service test successfully are called service tests parameters. These parameters need to be configured in the Oracle Management Server as part of creation of service tests.
Chapter 5
[ 175 ]
Execution of a single service test results in various performance indicators. For instance, in the FTP Service Test described earlier, various attributes related to performance can be measured such as time taken to log in, time taken to upload and download data bytes, the status of the FTP server, and so on. Each of these performance indicators collected from execution of different service tests are called service test metrics. Different types of service tests have different metrics associated with them. As discussed, the metrics from a FTP Service Test and a Host Ping Service Test vary with each other. Each of the service tests has a status metric that determines the availability metric of the service test.
The various service tests defined for a business function and the beacons that represent the locations from where these tests are executed are related through a service target in OEM Grid Control. A service target, when actively monitored, comprises different service tests. Similarly, there could be a set of geographical locations from which the user experience of the business flows need to be gauged.
The service tests are first configured for the service target to which beacons are further associated.
Service tests are defined within the context of a service target. Even though the same beacon can be attached to multiple services, a service test is associated with one and only one service target.
Each of these configured service tests are then executed from each of such beacons associated with the service target. The performance metrics for each execution of a service test from each beacon is collected by the corresponding agents and stored against the service target in the Oracle Management Server repository. However, only the metrics of key tests executed from key beacons are used in the availability definition for the associated service target. The metrics from other service tests from other beacons are available only for monitoring and reporting purposes.
OEM Grid Control provides an option to configure the frequency of execution of service tests. Different service tests for a single service target can have different frequencies. However, for a given service test, the frequency of execution of is uniform across all beacons.
The following image is an illustration of the relationship between a service target and its associated service tests and beacons:
The previous image illustrates the various service tests and beacons configured for a service target named APAC Flight Reservation Service. As can be seen, there are three service tests associated with this service target, that is, Search Flight Test, Book Flight Test, and Add Flight Test and three beacons, that is, Tokyo Beacon, Beijing Beacon, and New York Beacon. The Search Flight and Book Flight being core functions are modeled as key service tests, while Add Flight Test being a non-core functional flow is modeled as a non-key test. Similarly, as Tokyo and Beijing are the important customer locations for the service in the APAC region, these are marked as key beacons, while the New York beacon used for additional monitoring is marked as a non-key beacon. Each of these service tests are executed by all the beacons as indicated in the previous image. However, only the metrics from key tests executed by key beacons, that is, Search Flight and Book Flight tests from Tokyo and Beijing, are considered for availability computation of the APAC Flight Reservation Service.
As discussed in Chapter 4, the availability of the service target can be defined based on an AND/OR algorithm. An AND algorithm is used when the service target is configured to be UP only if all the associated key service tests are UP. This is used when the business function is modularized into multiple key steps all of which have to be available. For example, in the travel portal the Flight Reservation Service may be considered UP only if both the Search Flight and Book Flight tests report an UP status. Similarly, an OR algorithm is used when the service target is configured to be UP if at least one of the associated service tests is UP. Such a configuration is used when the same business function is available in different formats. For example, if the Hotel Search function in the travel portal is available as a HTTP service as well as a SOAP-based web service, if even one of these is UP, the service may be considered as UP.
Chapter 5
[ 177 ]
When a service test is defined for a service target, the default status of the service test is DISABLED. This service test must be assigned to different beacons by associating the service target with the beacons and then by changing the status to ENABLED.
When the service test is enabled, all the beacons associated with the service target will execute the service test periodically. A test can be suspended by changing the status back to DISABLED. This operation suspends further execution of the service test from all the beacons of the service target. The following image is an illustration of the Service Test Life Cycle:
As can be seen from the previous image, the default state of the service test after definition is disabled. Upon enabling the service test and assigning beacons, the test execution and metric collection begins. This is continued until this is suspended by performing a disable operation on the service test.