Skip Headers
Oracle® Enterprise Manager Cloud Control Administrator's Guide
12c Release 3 (12.1.0.3)

E24473-27
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

21 Configuring and Using Services

This chapter provides an overview of services and describes the procedures to configure and monitor services with Enterprise Manager. It contains the following sections:

21.1 Introduction to Services

The critical and complex nature of today's business applications has made it very important for IT organizations to monitor and manage application service levels at high standards of availability. Problems faced in an enterprise include service failures and performance degradation. Since these services form an important type of business delivery, monitoring these services and quickly correcting problems before they can impact business operations is crucial in any enterprise.

Enterprise Manager provides a comprehensive monitoring solution that helps you to effectively manage services from the overview level to the individual component level. When a service fails or performs poorly, Enterprise Manager provides diagnostics tools that help to resolve problems quickly and efficiently, significantly reducing administrative costs spent on problem identification and resolution. Finally, customized reports offer a valuable mechanism to analyze the behavior of the applications over time.Enterprise Manager monitors not only individual components in the IT infrastructure, but also the applications hosted by those components, allowing you to model and monitor business functions using a top-down approach, or from an end-user perspective. If modeled correctly, services can provide an accurate measure of the availability, performance, and usage of the function or application they are modeling.

21.1.1 Defining Services in Enterprise Manager

A service is defined as an entity that provides a useful function to its users. Some examples of services include CRM applications, online banking, and e-mail services. Some simpler forms of services are business functions that are supported by protocols such as DNS, LDAP, POP, FTP or SMTP.

Enterprise Manager allows you to define one or more services that represent the business functions or applications that run in your enterprise. You can define these services by creating one or more tests that simulate common end-user functionality. You can also define services based on system targets, or on both system and service tests.

You can create service tests to proactively monitor your services. Using these tests, you can measure the performance and availability of critical business functions, receive notifications when there is a problem, identify common issues, and diagnose causes of failures.

Services can be of two types:

  • Generic Service: A Generic Service is the simple service model you can create in Enterprise Manager. You can define one or more service models by associating service tests and/or associating relevant system targets that represent a critical business function. this section should replace: defining service tests

  • Aggregate Service: A number of services can be combined together to form an Aggregate Service. Within the context of an Aggregate Service, the individual services are referred to as sub-services. An Aggregate Service can also be used as a sub-service to create other Aggregate Services

21.1.2 Modeling Services

You can define a service target type and use it to model and monitor your business applications from within Enterprise Manager. While creating a service, you can define availability, performance and usage metrics, as well as the Service Level Agreement (SLA). This section describes the following:

21.1.2.1 Availability of a Service

The availability of a service is a measure of the end users' ability to access the service at a given point in time. However, the rules of what constitutes availability may differ from one application to another. For example, for a Customer Relationship Management (CRM) application, availability may mean that a user can successfully log on to the application and access a sales report. For an online store, availability may be monitored based on whether the user can successfully log in, browse the store, and make an online purchase.

Availability of a test can be based on the following:

  • Service Tests: Choose this option if the availability of your service is determined by the availability of a critical functionality to your end users. Examples of critical functions include accessing e-mail, generating a sales report, performing online banking transactions, and so on. While defining a service test, choose the protocol that most closely matches the critical functionality of your business process, and beacon locations that match the locations of your user communities. You can define one or more service tests using standard protocols and designate one or more service tests as Key Tests. These key tests can be executed by one or more Key Beacons in different user communities. A service is considered available if one or all key tests can be executed successfully, depending on your availability definition. See Deploying and Using Beacons for details on beacons and how to create them.

  • System: The availability of a service can alternatively be based on the underlying system that hosts the service or selected components of the system. If availability is based on selected system components, you must select the components that are critical to running your service and designate one or more components as Key Components, which are used to determine the availability of the service. The service is considered available as long as at least one or all key components are up and running, depending on your availability definition.

21.1.2.2 Performance and Usage

You can define metrics to measure the performance and usage of the service. Performance indicates the response time of the service as experienced by the end user.

Usage metrics are based on user demand for the service, or load on the system. Note that usage metrics can be be collected for a service only if the service contains a system.Performance metrics are collected for service tests when the tests are run by beacons. You can calculate the minimum, maximum, and average response data collected by two or more beacons. For example, you can monitor the time required to retrieve e-mails from your e-mail service in San Francisco, Tokyo, and London, then compare results.

You can also collect performance metrics for system components, then calculate the minimum, maximum, and average values across all components. For example, you can monitor average CPU utilization, memory utilization, and disk I/O utilization across several hosts.Usage metrics are collected based on the usage of the system components on which the service is hosted. For example, if you are defining an e-mail service that depends on an IMAP server, you can use the Total Client Connections metric of the IMAP server to represent the usage of this e-mail service. You can monitor the usage of a specific component or statistically calculate the minimum, maximum, and average values from a set of components. You can also set thresholds on the above metrics and receive notifications and alerts.

21.1.2.3 Service Level Agreements (SLA)

An SLA is a contract between the service provider and the customer which defines the expected quality of service over a specified period. It describes the nature and standard of service that the service provider will be providing to the customers.

In Enterprise Manager, an SLA describes a set of Service Level Objectives (SLOs) that define the service levels to be provided. An SLA can contain multiple SLOs for different business calendars and different service periods.

SLOs define the service level objectives to be provided. An SLO is a logical grouping of individual measurable Service Level Indicators (SLIs). For example, an SLO can define the percentage of time a service is available to the user, how well the service is performing in terms of response time or volume, and so on.

Service Level Indicators (SLIs) are quantifiable performance and usage metrics that can be used to evaluate the quality of a service. For more details on configuring and setting up an SLA, see Setting Up and Using Service Level Agreements.

21.2 Creating and Configuring a Service

This section covers the following topics:

21.2.1 Creating a Generic Service

Before you create a service, you must be familiar with the concepts of service management. You must also perform the following tasks:

  • Identify the locations where the Management Agents must be available to monitor the services using the appropriate service tests and protocols. For example, if your service includes HTTP based service tests or IMAP based service tests, ensure that the location of the Management Agent within your network architecture allows these tests. You must ensure that the Management Agents are installed at appropriate locations according to the network security (firewalls) and network routing guidelines.

    Note that the beacon targets must already be created on the Management Agents before creating the service.

  • Discover all the components for your service so that they can be listed as Enterprise Manager targets.

  • Define systems on which the service is based.

To create a service, from the Targets menu, select Services. The Services main page is displayed. Select the service type, Generic or Aggregate Service from the Add drop-down list and click Go. The following screen is displayed:

Figure 21-1 Create Service - General Page

Create Service: General

Follow the steps in the wizard to create your service. This involves the following:

  • Identifying the type of service to be created. This can be a Generic Service or an Aggregate Service.

  • Specifying the name and time zone for the service. The availability of the service and the SLA computation are based on the time zone you select here. You can select any time zone in which the service has to be monitored.

    Note:

    If you select System Time Zone, you must select a system on which the service is to be hosted.
  • Selecting a system target that hosts this service, and then marking the key components of the system that are critical for running the service. These key components are used to determine the availability of the service and identify possible causes of service failure.

    Note that this step is necessary only for system-based services. It is not needed for test-based services.

  • Setting up the availability definition for the service. This can be service test-based or system-based. If you select service test, the service's availability is based on the execution of the service test by one or more key beacons, or on the system target directly. If availability is based on system, availability is determined based on the status of one or more key components of the system.

  • Adding one or more beacons to monitor service tests. Click Add to add one or more beacons for monitoring the service. It is recommended that you use beacons that are strategically located in your key user communities in order for them to proactively test the availability of the service from those locations. If no beacons exist, you must create a new beacon. See <Creating a Beacon> for details.

    Notes:

    • Only a single beacon should be added from a Management Agent to monitor service tests. Adding multiple beacons from the same Management Agent to a service test is not recommended.

      Beacons are targets that are used to monitor service tests, primarily to measure performance of the service or business function from a different geographic location. Thus, adding mutiple beacons from the same Management Agent does not add any value.

    • Beacons marked as key beacons will be used to determine the availability of the service. The service is available if one or more service tests can be successfully executed from at least one key beacon.

    • It is recommended that you create the beacons before you create the service.

  • Defining the metrics that will be used to measure the performance of the service. Performance metrics can be based on service tests or system components. After defining the metrics, you can specify the critical and warning thresholds. You can also specify the metric that is to be displayed in a graphical format on the Service Home page.

  • Defining the metrics that will be used to measure the user demand for the service. Usage metrics can be based on one or more system components. After defining the metrics, you can specify the critical and warning thresholds. You can also specify the metric that is to be displayed in a graphical format on the Service Home page.

    Note:

    You can define usage metrics for system based services only. See Creating a System Based Service for details on system based services.
  • After you have completed all the steps in the wizard, click Finish to create your service. Refer to the Enterprise Manager Online Help for more details on these pages.

21.2.2 Configuring a Service

After you have created the service, you can configure it further by selecting an option from the Monitoring Configuration page. To configure a service, select a service from the Services main page and click Configure to go to the Monitoring Configuration page. The following screen is displayed.

Figure 21-2 Monitoring Configuration Page

Monitoring Configuration

The following options are available:

21.2.2.1 Root Cause Analysis Configuration

You can use Root Cause Analysis (RCA) to filter a set of events to determine the cause of a higher level system, service, or application problem. RCA can help you to eliminate apparent performance problems that may otherwise appear to be root causes but which are only side effects or symptoms of the actual root cause of the problem, allowing you to quickly identify problem areas. You can view the RCA results on the Home page or Topology page of any service that is currently down. The Topology page gives you a graphical representation of the service, along with the system and component dependencies. Targets that have caused the service failure are highlighted in the Topology page.

Before running RCA, you can choose to:

  • Configure the tool to run automatically whenever a service fails.

  • Disable RCA by changing the default Analysis Mode to Manual.

  • Define component tests for the service and thresholds for individual tests.

To configure Root Cause Analysis, follow these steps:

  1. From the Service Home page, click Monitoring Configuration.

  2. From the Monitoring Configuration page, click Root Cause Analysis Configuration.

  3. If the current mode is set to Automatic, click Set Mode Manual to disable RCA. If you choose to perform the analysis manually, you can perform the analysis from the Service home page at anytime by choosing Perform Analysis if the service is down. If the current mode is set for Manual, click Set Mode Automatic to enable RCA when the state of the service and its components change

  4. Click the link in the Component Tests column of the table for the key component you want to manage. You can then manage the key components for the service on the Component Tests page by adding, removing, or editing component tests. When a service is down, you can drill down to the key components to verify the underlying issue. Refer to the Enterprise Manager Online Help for details on defining component tests.

    Note:

    When you disable RCA and set it back to automatic mode, RCA does not store the previous history results for you, thus providing no history for later reference.
21.2.2.1.1 Getting the Most From Root Cause Analysis

Root Cause Analysis (RCA) can provide you with great value by filtering through large amounts of data related to your services and identifying the most significant events that have occurred that are affecting your service's availability. If you are constructing your own services to manage in Enterprise Manager it is important that the services are defined with some thought and planning in order to get the most out of RCA.

The first item to consider in getting the most from RCA is the set of dependencies that your service has on other services or system components. Be sure to identify all of the system components that your service utilizes in order to accomplish its task. If you omit a key component and the service fails, RCA will not be able to identify that component as a possible cause. Conversely, if you include components in the service definition that the service does not actually depend on, RCA may erroneously identify the component as a cause of service failures.

When building service dependencies, keep in mind that you can take advantage of the aggregate service concept that is supported by Enterprise Manager. This allows you to break your service into smaller sub-services, each with its own set of dependencies. RCA considers the status of a sub-service (a service that you depend on) as well the system components or service on which the sub-service depends.

The second item to consider in getting the most from RCA is the use of component tests. As you define the system components that your service depends on, consider that there may be aspects of these components that may result in your service failure without the component itself failing. Component tests allow RCA to test the status not only of the target itself but also the status of its key aspects.

The RCA system allows you to create component tests based on any metric that is available for the key component. Remember, this includes any user-defined metrics that you have created for the component, allowing you great flexibility in how RCA tests the aspects of that component should your service fail. RCA can be configured to run in two modes. It can run automatically based on the failure of a service or can be configured to run manually. You can decide the mode based on the Expected Service Level Agreement % of the service being monitored. If the Expected Service Level Agreement % is high, you must select the automatic mode to ensure that that possible errors and the root cause of the failure is easily detected.

21.2.2.2 Service Tests and Beacons

You can add additional service tests and specify one or more beacons that will execute these service tests. To add a service test or modify an existing service test, click the Service Test and Beacons link in the Monitoring Configuration page. The Service Tests and Beacons page appears. You can select a test type from the drop down list and create a service test. For more details, see Creating a Test Based Service.

21.2.2.2.1 Deploying and Using Beacons

A beacon is a target that allows the Management Agent to remotely monitor services. A beacon can monitor one or more services at any point in time.

Note:

Before you create a beacon, you must ensure that the Oracle Beacon 12.1.0.2 plug-in has been deployed.

To create a beacon to run one or more service tests, follow these steps:

  1. From the Setup menu, select Add Targets, then select Add Targets Manually.

  2. In the Add Targets Manually page, select Add Non-Host Targets by Specifying Target Monitoring Properties option.

  3. Select Beacon from the Target Type drop down list, select a Monitoring Agent and click Add Manually.

  4. The Create Beacon page appears.

    Figure 21-3 Create Beacon Page

    Creating a Beacon
  5. Enter the following details:

    • Name: Name of the beacon being created.

    • Agent: Select the Management Agent on which the beacon will be running.

    • Proxy Information: If the beacon is accessing the service through a firewall, you must specify the proxy server settings as follows:

      • Proxy Host and Port: The name of the proxy server host and through which the beacon communicates.

      • Proxy Authentication Realm: The authentication realm (used for Basic and Digest authentication schemes) that is used to verify the credentials on the proxy server.

      • Proxy Authentication Username: The (fully qualified) username to be used for proxy server authentication.

      • Proxy Authentication Password: The accompanying password to be used for proxy server authentication.

    • Enable Message ID Request Header: Select the checkbox to include an additional header in HTTP requests issued when Web Transactions and HTTP Ping service tests are executed. This allows Real User Experience Insight (RUEI) monitoring of Web Transactions and HTTP Ping tests.

    • Web Transaction: For Windows agents, specify the account credentials to be used when launching a browser to playback a Web transaction.

    Note:

    You can launch the Create Beacon option from the Services menu. From the Services Features menu, select Beacons and click Add to launch the Create Beacon page.
  6. Click Create to create the beacon and return to the Beacon Home page. You can now use the beacon to monitor service tests.

  7. From the Generic Service menu, select Administration, then select Service Tests and Beacons. You will see a list of service tests that have been enabled along with a list of beacons.

  8. Select the service test to be monitored, then from the Beacons table, select the beacon that you have created. Indicate if it is a key beacon.

  9. Click Verify Service Test to execute the service test by the selected beacon.

21.2.2.2.2 Configuring the Beacons

This section lists additional beacon related configuration tasks.

  • Configuring SSL Certificates for the Beacon: When a beacon is used to monitor a URL over Secure Sockets Layer (SSL) HTTPS URL, the beacon must be configured to recognize the Certificate Authority that has been used by the Website where that URL resides.

    To use the SSL option with the Port Checker test, you may need to to add additional certificates to the Management Agent's monitoring wallet. To add an additonal certificate, follow these steps:

    1. Obtain the certificate, which is in Base64encoded X.509 (.CER) format, in the b64SiteCertificate.txt file. (The file name may be different in your configuration.) An example of the contents of the file is given below:

      ------BEGIN CERTIFICATE--------------
      MIIDBzCCAnCgAw...
      ...... base 64 certificate content .....
      ------END CERTIFICATE-----------------
      

      This file is stored in the Home directory of the Management Agent as agent_home/sysman/config/b64InternetCertificate.txt file.

    2. In the Oracle Home of the Management Agent monitoring the wallet, run the following commands to add the certificate to the Management Agent:

      ${ORACLE_HOME}/bin/mkwallet -i welcome
      ${ORACLE_HOME}/sysman/config/monwallet
      ${ORACLE_HOME}/sysman/config/b64SiteCertificate.txt NZDST_CLEAR_PTP
      
    3. Start the Management Agent.

  • Configuring Dedicated Beacons: Beacon functionality on an agent requires the the use of an internal Java VM. The use of a Java VM can increase the virtual memory size of the agent by several hundred megabytes. Because of memory constraints, it is preferable to create beacons only on agents that run on dedicated hosts. If you are running large numbers of tests (e.g., several hundred per minute) on a given beacon, you may also wish to install that beacon's agent on a dedicated host. To take full advantage of dedicated hardware, edit the agent's $ORACLE_HOME/sysman/config/emd.properties file. as follows:

    • Set the property, ThreadPoolModel=LARGE. This allows the agent to simultaneously run many threads.

    • Set the property, useAllCPUs=TRUE. This allows the agent to run on multiple CPUs simultaneously.

    • Append -Xms512m -Xmx1024m to the agentJavaDefines property. This increases the Java VM heap size to 1024 MB.

  • Configuring a Web Proxy for a Beacon: Depending on your network configuration, the beacon may need to be configured to use a Web proxy. To configure the Web proxy for a beacon, search for the beacon in the All Targets page. Select the beacon you wish to configure and click Configure. Enter the properties for the Web proxy. For example, to set up www-proxy.us.oracle.com as the beacon's Web proxy, specify the values as the following:

    Proxy Host: www-proxy.us.oracle.com
    Proxy Port: 80
    Don't use Proxy for: .us.oracle.com,.oraclecorp.com
    

    Note:

    You cannot play Siebel service tests and Web Transaction (Browser) service tests on the same machine.

21.2.2.3 Availability Definition

You can modify the availability definition (service test-based or system-based) for the selected service. If availability is based on service tests, you can specify whether the service should be available when:

  • All key service tests are successful (Default)

  • At least one key service test is successful

Note:

A service test is considered available if it can be executed by at least one key beacon. If there are no key beacons, the service test will have an unknown status.

If availability is based on the key system components, you can specify whether the service should be available when:

  • All key components are up (Default)

  • At least one key component is up

You can also mark one or more components as key system components that will be used to compute the availability of the service. Key system components are used to determine the possible root cause of a service failure. For more information, refer to "Root Cause Analysis Configuration".

You can also indicate whether the service test is a key test by enabling the Key Service Test checkbox. Only key service tests are used to compute the availability of the service. You can then select the beacons that will be used to execute the key tests and determine the availability of the service.

21.2.2.4 Performance Metrics

Performance metrics are used to measure the performance of the service. If a service test has been defined for this service, then the response time measurements as a result of executing that service test can be used as a basis for the service's performance metrics. Alternatively, performance metrics from the underlying system components can also be used to determine the performance of the service. You can do the following:

  • Add a performance metric for a service test. After selecting a metric, you can choose to:

    • Use the metric values from one beacon. Choose this option if you want the performance of the service to be based on the performance of one specific location.

    • Aggregate the metric across multiple beacons. Choose this option if you want to consider the performance from different locations. If you choose this option, you need to select the appropriate aggregation function:

      Table 21-1 Beacon Aggregation Functions

      Function Description

      Maximum

      The maximum value of the metric from data collected across all beacons will be used. Use this function if you want to measure the worst performance across all beacons.

      Minimum

      The minimum value of the metric from data collected across all beacons will be used. Use this function if you want to measure the best performance across all beacons.

      Average

      The average value of the metric will be used. Use this function if you want to measure the 'average performance' across all beacons.

      Sum

      The sum of the metric values will be calculated. Use this function if you want to measure the sum of all response times across each beacon.


      Note:

      If you are configuring a Web transaction, you can specify the Source which can be transaction, step group or step. Based on this selection, the metric you add will be applicable at the transaction, step group, or step level.
  • Add a performance metric for the underlying system components on which the service is hosted. After selecting a metric for a target, you can choose to:

    • Use the metric from a specific component. Choose this option if you want the performance of the service to be based on the performance of one specific system component.

    • Aggregate the metric across multiple components. Choose this option if you want to consider the performance from multiple components. If you choose this option, you need to select the appropriate aggregation function.

      Table 21-2 System Aggregation Functions

      Function Description

      Maximum

      The maximum value of the metric across all components will be used as the value of this performance metric for the service.

      Minimum

      The minimum value of the metric across all components will be used as the value of this performance metric for the service.

      Average

      The average value of the metric across all components will be used.

      Sum

      The sum of values of metrics across all components will be calculated.


      Note:

      When a system is deleted, performance metrics associated with the system will not be collected.
  • Edit a performance metric that has been defined. For service test-based performance metrics, you can modify the beacon function that should be used to calculate the metric values. For system-based performance metrics, you can modify the target type, metric, and whether the aggregation function should be used. You can also modify the Critical and Warning thresholds for the metric.

  • Delete a performance metric that has been defined.

21.2.2.5 Usage Metrics

Usage metrics are used to measure the user demand for the service. Usage metrics are collected based on the usage of the underlying system components on which the service is hosted. You can do the following:

  • Add a usage metric. After selecting a metric for a target, you can choose to:

    • Use the metric from a specific component. Use this option if you want to monitor the usage of a specific component.

    • Aggregate the metric across multiple components. Use this option if you want to statistically calculate the usage across multiple components. If you choose this option, you need select the appropriate aggregation function.

      Table 21-3 Aggregation Functions - Usage Metrics

      Function Description

      Maximum

      The maximum value of the metric across all components will be used as the value of this usage metric for the service.

      Minimum

      The minimum value of the metric across all components will be used as the value of this usage metric for the service.

      Average

      The average value of the metric across all components will be used.

      Sum

      The sum of the values of metrics across all components will be calculated.


  • Edit a usage metric that has been defined.

  • Delete a usage metric that has been defined.

Note that only metrics from system targets can be added as usage metrics. Metrics from tests are not indicative of usage, and therefore cannot be added as usage metrics.

21.2.3 Configuring an Aggregate Service

Aggregate services consist of one or more services, called subservices. A subservice is any service created in Enterprise Manager. The availability, performance, business criteria, and usage for the aggregate service depend on the availability, performance, business criteria, and usage for the individual subservices comprising the service. To create an aggregate service, navigate to the Services main page, select Aggregate Service from the Add drop-down list and click Go. The Add Aggregate Service page appears. Creating an Aggregate Service involves the following:

  • Specifying the name and time zone for the service.

  • Adding the services that make up this aggregate service.

  • Establishing the availability definition for the aggregate service. Availability of an aggregate service depends on the availability of its constituent subservices. The availability for a subservice may depend on the successful execution of a service test or on the availability of the system components on which the subservice runs, depending how the subservice was defined.

  • Defining the metrics used to measure the performance of your aggregate service. You can add performance metrics from single subservices, or based on statistical aggregations of more than one metric. Once you have selected the performance metrics, you can set the thresholds used to trigger incidents, or remove metrics you no longer want.

  • Defining the metrics used to measure the usage of your aggregate service. Usage metrics can be based on the metrics of one or more system components. You can add usage metrics from single subservices, or based on statistical aggregations of more than one metric. Once you have selected the usage metrics, you can set the thresholds used to trigger incidents, or remove metrics you no longer want.

  • Defining the metrics that are used to measure of the performance of business in the organization. These metrics are based on business indicators that can assess the business performance.You can add business metrics from single subservices, or based on statistical aggregations of more than one metric. Once you have selected the business metrics, you can set the thresholds to trigger incidents, or remove metrics you no longer want.

After you have created an aggregate service, you can add or remove its constituent subservices, modify the availability definition and add or delete performance or usage metrics. Refer to the Enterprise Manager Online Help for details on these operations.

WARNING:

If you delete or remove a subservice from an aggregate service, the aggregate service performance, usage, and business metrics may be affected if they are based on a deleted subservice's metrics.

21.3 Creating a Test Based Service

You can create different types of service tests based on the protocol and the location of the beacons. From the Service Tests and Beacons page, you can do the following:

  • Add one or more service tests for your service. Select the Test Type and click Add. Some of the test types that can be defined are ATS, FTP, Web Transaction, DNS, SOAP and others.

  • After you have created the service test, you must enable it. If your service test is not enabled, it will not be executed by any of the beacons. You can define one or more service tests as key tests. These key tests are used to monitor the availability and performance of your service. Only service tests that are enabled can be designated as key tests. To set up a service test as a key test, click the Availability Definition link at the bottom of the page.

  • Create, add, or remove a beacon. When you identify the beacon locations, select locations on your internal network or on the Internet that are important to your e-business. These are typical locations where your end users are located. For example, if your business is hosted in Canada and you have customers in the United States, use a beacon installed on a host computer in the United States to measure the availability and performance of your applications.

  • After you have created the service test, you can verify it by clicking Verify Service Test.

    Note:

    • While defining a SOAP (Simple Object Access Protocol) service test, if the WSDL URL to be accessed is outside the company's intranet, proxy settings need to be added to the $OMS_HOME/sysman/config/emoms.properties file.

      For example, to set up www-proxy.us.oracle.com as proxy, specify the values as follows:

      proxyHost=www-proxy.us.oracle.com

      proxyPort=80

      dontProxyFor=us.oracle.com,oraclecorp.com

      The proxyUser,proxyPwd,proxyRealm,and proxyPropsEncrypted properties are used to configure an authenticated proxy. After you have modified the proxy settings, you must restart all the OMSes for the changes to be effective.

    • The Forms Transaction test type has been deprecated in Enterprise Manager 12c. Forms transactions created in earlier releases can still be used but you cannot create new Forms Transaction test types. You must create a Generic Service target and create an ATS Transaction using OATS EBS/Forms Load test scripts. This ATS test type is used to monitor Oracle Forms applications.

    • The Web Transaction test type is in maintenance mode only. To monitor Web applications, we recommend that you create an ATS load script and use the ATS Transaction test type to monitor Web applications. See Creating an ATS Service Test Using OATS Load Script for details.

    The creation of different types of service tests is covered in detail in the Enterprise Manager Online Help. In this chapter, we have covered the creation of the ATS test type as an example.

21.3.1 Creating an ATS Service Test Using OATS Load Script

You can use the Oracle Application Test Suite (OATS) to define an Openscript Transaction Service Test. This test is used to enable beacon application transaction monitoring using Openscript load testing scripts. Openscript is a component of OATS and provides advanced capabilities to record and play back various types of Web transactions, such as web/HTTP, Oracle EBS/Forms, Oracle Fusion/ADF, Siebel, Adobe Flex, and so on.

By using ATS load scripts, you can:

  • Reuse ATS testing scripts for production application transaction monitoring as part of application lifecycle management.

  • Expand the beacon capabilities by:

    • Supporting complex application flows with mixed application types and protocols such as HTTP and Oracle Forms application in one flow.

    • Supporting protocol based Siebel application monitoring.

    • Providing Databank support.

    • Incorporating enhanced scripting and debugging features from Openscript.

    • Adding the latest script modules and features without updating Enterprise Manager.

Creating an ATS service test involves the following:

  • Visit http://www.oracle.com/technetwork/oem/app-test/index-084446.html to download Openscript.

  • Launch the installer and follow the steps to install Openscript.

  • Record a new ATS transaction script by following these steps:

    • Launch Openscript and from the File menu, select New.

    • Select the type of script to be created and click Next. Some of the script types you can create are Adobe Flex, Oracle Fusion / ADF, Siebel, Database, Java Code Script, Web/HTTP and so on.

    • Select the location where the script is to be stored, enter a script name, and click Finish.

    • From the View menu, select Openscript Preferences to set the recording preferences.

    • Select Record Category and then select HTTP Preferences. Change the Record Mode from Web to HTTP. This ensures that scripts are played back correctly.

    • Select Record from the Script menu. The browser automatically opens when you start recording.

    • Load the web page where you want to start recording into the browser. Navigate the web site to record page objects, actions, and navigations. When you have finished navigating pages, close the browser and click Stop.

    • Select Playback from the Script menu to verify that the script has been properly recorded. Watch the application flow being played back in the play pane. Make sure the message log pane does not have any errors or failures. Save the script.

  • After the script has been recorded, from the File menu, select Export Script.

    • Specify the location in which the script is to be saved. You can save the script in a repository or workspace.

    • Enter a name for the script and click Finish. A script bundle (.zip) is created. Make sure that the script bundle is self contained. See Creating a Self Contained Zip File.

    Note:

    If the script file is very large, uncheck the Recorded Data option.
  • Log into Enterprise Manager, upload the script bundle, and create an ATS service test. See Creating an ATS Service Test for details.

For more details on OATS, please refer to Oracle® Functional Testing OpenScript User's Guide.

21.3.1.1 Creating a Self Contained Zip File

You must ensure that the zip file is self contained and contains the following:

  • <txn name>.jwg: The archive file that contains the compiled script executable to be run by Execution Engine.

  • script.java: The actual script Java source file.

  • <script name>-descriptor.xml – Describes the step hierarchy

  • script.xml: Describes the variables in the databank.

  • modules.properties: Describes which internal modules are required for the engine.

  • Assets.xml: Describes the dependent resources used by the root scripts including databank files, sub scripts, object libraries, and so on.

  • Databank Files: The databank files used by the script while substituting different variable values.

  • Object Libraries: The libraries that contain user-defined object identification rules and names. This is only applicable for functional testing scripts

  • Dependent Scripts: A script can call out to other script.

21.3.1.2 Creating an ATS Service Test

To create an ATS service test, follow these steps:

  1. From the Targets menu, select Services.

  2. Select Generic Service from the Type drop down list and click Add.

  3. Enter a name for the service and select a time zone.

  4. Click Next. In the Create Generic Service: Availability page, select Service Test.

  5. In the Create Generic Service: Service Test, select the Test Type as ATS Transaction.

  6. Enter a name, description, and collection frequency for the service test.

  7. In the ATS Zip Archive region, click Upload. Click Browse and upload the script bundle that has been exported from Openscript. Click Continue.

  8. You will return to the ATS Service Test page where you can specify the following:

    • Usage Options: You can configure the script variable values by selecting the required usage option. You can either use the values recorded during the transaction or use the databank. A databank is an external CSV file that ATS scripts can refer to supply different input values over multiple iterations of the same script. For example, a login script can use a databank file, named login_credential.csv, to supply different login credentials during iteration.

      You can select:

      • Use Recorded Values: While playing back the transaction, the beacon uses the recorded values in the script.

      • Use Values From EM Test Property: You can specify values in the databank columns. These values are used by the beacon while playing back the script. This is useful if the same value is to be used for each variable. If variables defined as test properties, the value can be easily modified without having to modify script bundle or databank files.

      • Loop Through All Databank Records: While playing back the transaction, the beacon will go through each row in the script. For example, the first iteration will use the first rows of all the databanks. The second iteration will use the second rows of data and so on.

    • Encryption Password: If you have configured ATS Openscript to encrypt script data (using the Openscript View File > Openscript Preferences > Generic > Encryption) option, when you create the scripts, you need to enter the same encryption password as specified in the ATS openscript, so that beacon can play back the script properly.

    • Default Playback Options: The default playback options the beacon uses to play back the ATS Script.

    • Additional Playback Options: If additional playback options have to be specified, you can specify them here.

21.3.1.3 Databanking and Parameterization

You can parameterize recorded script inputs to perform data driven testing. Examples of inputs that can be parameterized include user name, password on the login page, data entered in the search field, recorded navigations or user actions, and so on.

You can use databanks as the data source for parameterizing script inputs. Databanks are one or more external comma-separated value (CSV) or text (TXT) files that provide inputs to script parameters. Multiple Databank files can be attached to a single script and users can specify how OpenScript assigns data during script playback.

You can select data input values from an external.csv file and substitute the variable values with the values from the Databank. The field names are on the first line of the file separated by commas (no spaces). The field data is on subsequent lines separated by commas (different line for each record, no spaces around commas). An example is shown below:

FirstName,LastName,Mail,Phone
John,Smith,JohnS@company.com,x993
Mary,Ellen,MaryE@company.com,x742

To use the databank records, follow these steps:

  1. Open or create a script project.

  2. Configure the Databank to use with a script in the Assets Script Properties.

  3. Select the script node where you want to use the Databank record.

  4. Select the Script menu and then select Other from the Add sub menu.

  5. Expand the General node and select Get Next Databank Record. Click OK.

  6. Select Databank avitek alias to specify the Databank file from which the records are to be retrieved.

  7. Click OK. A GetNextDatabankRecord: databank alias node will be added to the script. In the Java Code view, the getDatabank("databank alias").getNextDataBankRecord() method will be added to the script code as follows:

    getDatabank("avitek").getNextDatabankRecord();

After you have configured the databank for use with a script, you can map the databank files to specific script parameters. To map databank fields to script parameters, follow these steps:

  1. Expand the [4] Oracle WebLogic Server - Medical Record Sample Application script tree node.

  2. Right-click the usernameInput parameter and select Substitute Variable. The Substitute Variable window opens with the databank field names listed.

  3. Select the Username field and click Finish. The parameter value changes to a databank variable in double braces {{db.avitek.Username,fred#@golf.com}}

  4. Right-click the passwordInput parameter and select Substitute Variable. The Substitute Variable window opens with the databank field names listed.

  5. Select the Password field and click Finish. The parameter value changes to a databank variable in double braces {{db.avitek.Password,weblogic}}

  6. Save the script.

For more details on setting up the Databank, see the Oracle® Functional Testing OpenScript User's Guide.

21.3.1.4 Parameterizing URLs

You can create variables to use for URLs in a script. If you need to change the base URL of a script, parametrizing the URLs provides a quick way to re-baseline a script to use a new URL.

To parameterize URLs, follow these steps:

  1. After you have recorded your script, from the Tools menu, select Parameterize URLs.

  2. Select the URL to parameterize and enter a variable name to use for the URL. Click Next.

  3. Select or unselect the checkbox to specify the instances of the URL that are to be changed. Click Finish.

  4. In the Java Code view, the getVariables().set("variable name", "value",scope); method will be added to the script code in the initialize() section as follows:

    getVariables().set("myServerVar", "http://myServer.com",
    Variables.Scope.GLOBAL);
    
  5. Repeat these steps to parameterize other URLs in the script.

21.3.1.5 Success or Failure Validation

You can perform text matching from TreeView and CodeView. For example, if you enter a string "hello" in a Google search window, the text matching is as follows:

web.document("/web:window[@index='0' or @title='Google']/web:document[@index='0']").assertText("MatchText", "hello", Source.DisplayContent, TextPresence.PassIfPresent, MatchOption.Exact);

Source - enum - (Html,Display Content)

Html - Raw Html including Tags

Display Content - Html without tags

MatchOption - Not Case Sensitive

  • Exact - sensitive: Matches any part of source string. For example, if the text entered is abcdef, if you enter abc, the string will match.

  • ExactEntireString: Matches the exact source string.

  • RegEx - Not Case Sensitive: Matches source string and sub-string. For example, if the text entered is abcdef, you can enter a.*d.

  • RegExEntireString: Matches the entire source string only. For example, if the text entered is abcdef, you can enter a.*f.

  • Wildcard - wildcard pattern: Matches source string and substring. For example, if the text entered is abcdefghijklm, you can enter a?c*f.

  • WildcardEntireString: Matches the entire source string. For example, if the text entered is abcdefghijklm, you can enter a*m.

21.3.1.6 Using Beacon Override

You can use the beacon override feature to specify different variable values for a test running on a different beacon. To do so, follow these steps:

  1. Databank a script.

  2. Select Use EM Test Property option.

  3. Define beacon by specifying the sensitive and non-sensitive values as follows:

Databank_Alias>."<COLUMN_NAME>"="VALUE",<Databank_Alias>."<COLUMN_NAME>"="VALUE",...

For example:

FusionCredentials."host"="fs-aufsn4x0cxf",FusionCredentials."hostlogin"="login-aufsn4x0cxf",FusionCredentials."username"="faadmin",FusionCredentials."password"="fusionfa1"

21.3.1.7 Updating the Databank File

To update the ATS test script, follow these steps:

  1. From the Generic Service menu, select Administration, then select Service Tests and Beacons.

  2. From the Service Tests table, select ATS Transaction test type, and click Edit.

  3. In the ATS Zip Archive region, click Download. Select the location where it is to be downloaded and click OK.

  4. Edit the .csv file using a spreadsheet editor and save the changes.

  5. Log into Enterprise Manager and navigate to the ATS Transaction Test page.

  6. In the ATS Zip Archive region, click Upload to upload the updated file.

21.3.1.8 Using SLM Header for RUEI Integration

If the ATS service test data is to be monitored by RUEI, you must specify the x-oracle-slm-message-id request header in the Additional Playback Options field. The format is in the form: name1:value1;name2:value2;name3:value3.

For example, x-oracle-slm-message-id: bcn=<beacon_name>; svc=<service_name>;test=<test_name>;step={{@getTopLevelStepName())}}

21.3.2 Using the Transaction Recorder

You can record a transaction using an intuitive playback recorder that automatically records a series of user actions and navigation paths. You can play back transactions interactively, know whether it is internal or external to the data center, and understand the in-depth break-out of response times across all tiers of the Web application for quick diagnosis.

You must install the transaction recorder in your computer to record transactions. The transaction recorder is also used for playing back and tracing transactions. The transaction recorder is downloaded from the Enterprise Manager Cloud Control server the first time any of these actions is performed. The transaction recorder requires some Microsoft libraries to be installed in your computer. If these libraries are not present during installation, they are automatically downloaded and installed from the Microsoft site. Make sure that your computer has access to the Internet to download these files. After the installation has been completed, you may need to restart your computer to make the changes effective.

21.4 Creating a System Based Service

A system is the set of infrastructure components, for example hosts, databases, and application servers that work together to host your applications. Before you create a service, you must specify the system that will be used to host your service. After you have selected the system, you must mark one or more components as key components that are critical to running your service. These key components are used to determine the availability of the service and identify possible causes of service failure for root cause analysis.

To create a system based service, follow these steps:

  • Identify the type of service being created (Generic or Aggregate Service).

  • Enter a name for the service and specify the time zone.

  • In the Availability page, select System in the Define Availability based on list.

    Figure 21-4 Availability Based on System

    System based service
  • Specify whether the Availability is based on the System Target directly or Availability of selected components of the system. If you select the first option, availability is based on the system target on which the service is based. If you select the second option, availability is based on the key components of the system that you have selected.

  • Follow the rest of the steps in the wizard and create a system based service.

21.5 Setting Up and Using Service Level Agreements

A service level agreement (SLA) is a contract between a service provider and a customer on the expected quality of service for a specified business period. An SLA consists of one or more service level objectives (SLOs) which define the service levels to be provided. Whether an SLA is satisfied or not is based on the evaluation of the underlying SLOs. Service level indicators (SLIs) allow SLOs to be quantified and measured. An SLO can have one or more SLIs.

To create an SLA, follow these steps:

  1. Log in to Enterprise Manager as a user with EM_ADMINISTRATOR role.

  2. From the Targets menu, select Services.

  3. Click on a Generic Service target on the list. The Service Home page is displayed.

  4. From the Generic Service menu, select Service Level Agreement, then select Configuration. The Service Level Agreement Configuration page appears.

  5. On this page, you will see a list of all the SLAs defined for the selected service. Select an SLA from the list to view the details in the Service Level Agreement Details table. You can create an SLA or make a copy of an existing SLA (Create Like).

  6. In the Service Level Agreement region, click Create. The Configure Service Level Agreement page appears.

    Figure 21-5 Create Service Level Agreement: Configure Service Level Agreement

    Configure Service Level Agreement

    Enter the following details:

    • Name and description of the SLA.

    • Name of the customer for whom the SLA is being created.

    • The Lifecycle Status of the SLA. When an SLA is being created, it will be in the Definition Stage. For more details on the Lifecycle Status, see Lifecycle of an SLA.

    • Specify the SLA Period. This is the contractual time period for which the SLA is determined and/or evaluated for compliance. (ie. quarterly, monthly, weekly SLA). Click the Select icon and select Monthly, Weekly, or Daily. Enter the Frequency which the SLA is to be evaluated and the date from which the SLA is to be evaluated. The SLA goals are reset when the SLA is evaluated.

      For example, if you specify the SLA Evaluation Period as Monthly, Frequency as 12 and the date as 09/01/12, the SLA will be evaluated on that date followed 11 consecutive evaluations in the months of October, November, and so on.

    • Specify the SLA Agreement Period. This is the From and To Date for which the recurring SLA periods are in effect. If you do not specify the To Date here, the SLA will have an Indefinite expiry date.

    • An SLO may sometimes not be evaluated due to planned downtime or blackouts that have been scheduled for a service. In the Service Level Agreement Evaluation Options region, select the Include blackout times (planned downtimes) in Service Level Objective evaluation checkbox and specify whether the blackout times are to be included in the SLO evaluation. You can choose to:

      • Include time as met

      • Include time as not met

      • Exclude the blackout time during the overall computation of the SLO.

      For example, if the blackout or planned downtime for the week is 1 day, then the weekly availability is (7-1) / (7-1) days which is still 100% availability.

      By default, the Include blackout times (planned downtimes) in Service Level Objective evaluation option is not selected.

  7. Click Next. In the Service Level Objectives page, define one or more SLOs that are to be part of the SLA. You can select the Evaluation Condition for the SLA which can be:

    • All Service Level Objectives must be met.

    • At least one Service Level Objective must be met.

    An SLA must have at least one SLO. More than one SLO can be active at any given time. You can either specify if all SLOs or at least one SLO should be met.

  8. Click Create to define a new SLO. See Creating a Service Level Objective for details.

  9. You can add more SLOs or edit the SLO you have defined. Click Next. In the Enable Service Level Agreement page, you can specify when the SLA is to be enabled. You can select:

    • Do Not Enable: If the SLA is not enabled, it will be in the Definition state and can be modified if required.

    • Enable Now: If the SLA is enabled, it cannot be modified as it will be in an Active state.

    • Enable Later: The SLA can be enabled later on a specified date.

  10. Click Next , review details of the SLA, and click Submit. The SLA will be enabled on the specified date and you will return to the Service Level Agreement Configuration page.

21.5.1 Actionable Item Rules for SLAs

The table below shows a list of actions that can be performed on an SLA based on its status.

Status of SLA Create Like Edit Enable Disable Delete
Definition Yes Yes Yes No Yes
Scheduled Yes Yes No Yes No
Active Yes No No Yes No
Retired Yes No No No Yes

  • An SLA in a Scheduled or Active state cannot be directly deleted. You have to disable the SLA before you can delete it.

  • When you edit an SLA in a Scheduled state, the status of the SLA changes to Definition.

21.5.2 Creating a Service Level Objective

A Service Level Objective measures the service level of one or more indicators for a specified measurement window. Service Level Objectives (SLOs) define the service levels to be provided. You can specify if the SLA is considered to be satisfied if:

  • All Service Level Objectives are met.

  • At least one Service Level Objective is met.

To create an SLO, follow these steps:

  1. Click Create in the Configure Service Level Objective page. The Create Service Level Objective page appears.

    Figure 21-6 Create Service Level Objective

    Create Service Level Objective
  2. Enter the following details:

    • Name of the SLO being defined.

    • Type of SLO: The SLO can be based on Availability or Performance metrics.

    • Expected Service Level %: This indicates the percentage of time the SLO conditions are met to ensure that the SLA is satisfied.

    • Warning Alert Level %: If the SLO conditions do not meet the specified threshold, a critical alert is generated.

      For example, if the Expected Service Level% is 90% and the Actual Service Level% is in the range of 90 to 99%, a Warning Alert is generated. If the Actual Service Level% is lesser than 90%, a Critical Alert is generated. This indicates that the SLA has been breached. If the Actual Service Level% is greater than 99%, it indicates that the SLA conditions have been satisfactorily met.

    • Measurement Window: The time periods during which the SLO is in effect. A measurement window can have more than one time period assigned. For example, a measurement window can be configured as weekday peak hours which are Monday to Friday, from 9AM to 6PM and the weekend peak hours as 10AM to 2PM.

      While creating an SLO, you can choose more than one Business Calendar for an SLO. For example, suppose you want to evaluate each SLO from 8AM to 5PM except at lunch time (12PM to 1PM). You can create two measurement windows and exclude the lunch time from being measured.

      Another example of merging two measurement windows is when you want to combine weekly evaluation with calendar evaluation. If you want to evaluate an SLO every Monday and on the 15th of every month, you can create two monitoring windows and include these conditions in both the windows.

      By default, there are 3 predefined business calendars. You can also create your own calendar. See Defining Custom SLA Business Calendars for details.

  3. Click Next. In the Create Service Level Indicators page, you can add one or more SLIs or conditions that allow the SLO to be measured.

    Figure 21-7 Create Service Level Indicators

    Create Service Level Indicators

    For example, if you are adding a performance SLI, you can specify that the Page Load Time should be less than or equal to 3 seconds. If this condition is not met, the SLI is considered to be violated. Specify the Evaluation Condition for the SLI:

    • All Service Level Indicators must be met.

    • At least one Service Level Indicator must be met.

  4. Click Add to add one or more metrics and specify the value and the evaluation condition. Click Submit to return to the Configure Service Level Objective page.

21.5.3 Lifecycle of an SLA

The following diagram shows the lifecycle of an SLA.

Figure 21-8 SLA Lifecycle

SLA Lifecycle

The SLA lifecycle consists of the following phases:

  • Definition: This is the stage where the SLA is created and the SLOs are defined. You can configure or edit the SLA definition till the SLA is activated.

  • Scheduled: This stage represents the period before the SLA is scheduled to go into effect at a future date.

  • Active: This is the stage where the start date of a scheduled SLA is reached, or when the SLA is manually enabled.

  • Retired: This is the stage when the SLA reaches the Expiry Date or the SLA is manually disabled.

  • Disabled: An SLA can be manually disabled before it reaches the Expiry Date. Once an SLA is disabled, it cannot be reactivated. You must use the Create Like option to create a similar SLA and enable it.

  • Expired: This is the stage where the SLA has reached the Expiry Date and is no longer active.

  • Deleted: An SLA can be deleted if it is the Definition or Retired stage. An SLA that is an Active or Scheduled stage cannot be deleted.

21.5.4 Viewing the Status of SLAs for a Service

You can view the status of all SLAs for a service. To view the current status of the SLAs for a service, follow these steps:

  1. From the Targets menu, select Services.

  2. Click on a Generic Service target on the list. The Service Home page is displayed.

  3. From the Generic Service menu, select Service Level Agreement, then select Current Status. The Service Level Agreement Current Status page appears.

  4. This page shows a list of all the active SLAs that have been defined for this service. For each SLA, the SLA Status, SLA Evaluation Period, and the Service Level Objectives are displayed.

  5. Select an SLA to view detailed information in the SLA. The following details are displayed:

    • Tracking Status: This is the instant status of the SLI. For an Availability SLO, it is the status of the target. For a Performance SLO, it is the value of the Performance or Usage metric at a specific point in time.

    • Service Level (%) : The percentage of time (from the beginning of the current evaluation period till the current date) the SLO conditions are met or the Tracking Status is true. If the Actual Service Level % is lesser than the Expected Service Level %, or the SLO conditions are met, the Service Level % graph is green.

    • Type: This is the type of SLOs that have been defined for the SLA. This can be based on Availability or Performance metrics. An Availability SLO is based on the Response Metric [ Service Target Availability]. It is specified in terms of the amount or percentage of time when the availability objective should be met. A Performance SLO gauges how well a service is performing. It includes measurements of speed and/or volume such as throughput or workload (ie. response times, transactions/hour). A Performance SLO can either be specified in terms of a set of SLIs, SLO conditions, and the amount or percentage of time when the objective should be met.

    • SLO Violation: The violation allowances for each SLA evaluation period.

      • Total: The duration of the Evaluation Period * ( Expected Service Level).

      • Actual: The time when the SLO is not met during the Evaluation Period.

      • Remaining: The time when the SLO could not be met without breaching the SLA. If the SLO is always met during the Evaluation Period, it indicates that there are no used allowances and the value in the Actual field will be 0.

21.5.5 Defining Custom SLA Business Calendars

Business Calendars are measurement windows that define a specific window of time in which the Service Level Objectives (SLO) are being measured. Out-of-the-box predefined business calendars are available. Apart from these, you can create custom business calendars. To create a custom business calendar, from the Targets menu, select Services. From the Services Features menu, select SLA Business Calendars.

A list of business calendars that have been defined is displayed here. You can:

  • Create: Click Create to set up a business calendar. The Add / Edit Business Calendar page is appears.

  • Create Like: Select a calendar and click Create Like to make a copy of this calendar.

  • Edit: Select a calendar, click Edit and make the necessary changes in the Add / Edit Business Calendar page.

  • Delete: Select a calendar and click Delete to delete it. You cannot edit or delete a business calendar that is associated with one or more SLAs.

  • View Associated Service Level Agreements: A business calendar can be used by one or more SLAs. Select a business calendar and click View Associated Service Level Agreements to view the SLAs that are associated with this calendar.

21.6 Using the Services Dashboard

The services dashboard provides a brief summary of all service related information in a single place. It provides a consolidated view of critical aspects of a service such as availability, performance, SLAs associated with the service, status of key system components, and so on.

21.6.1 Viewing the All Dashboards Page

To view the All Dashboards page, follow these steps:

  1. From the Targets menu, select Services.

  2. From the Services Features menu, select Dashboards.

  3. The All Dashboards page appears where you can see a list of all dashboards that have been created.

  4. From the All Dashboards page, you can do the following:

    • Create Dashboard: Enter a unique name in the Dashboard Name field and a description, and click Create Dashboard. The newly added dashboard appears in the table. To create a dashboard, you must have an EM_ADMINISTRATOR role with Create Services Dashboard privilege.

    • Customize Dashboard: Select a dashboard from the list and click Customize and make the changes in the Edit Services Dashboard page. The dashboard can be customized only by the user who has created it.

    • Delete: Select a dashboard from the list and click Delete. The selected dashboard is deleted. The dashboard can be deleted only by the user who has created it.

  5. Click on a Dashboard Name link to drill down to the Dashboard Details page.

21.6.2 Viewing the Dashboard Details Page

This page displays the following details:

  • Service Name: Click on the link to drill down to the Service Details page.

  • Incidents: Any incidents that have occurred.

  • Performance / Usage Metric: The name of the performance and usage metrics available for the service and the latest value of each metric is displayed. The Trend charts show the metric trend over the last 24 hours. Click on the Trend chart to see a detailed view over the trend.

  • SLA: Shows the number of enabled SLAs that are in Active, Critical or Warning state.

  • Key Components: Shows the key targets that are up or available for this service.

  • System Incidents: Any incidents that have occurred for the underlying systems of the service are displayed.

Figure 21-9 Services Dashboard

Services Dashboard

You can filter the list of services that are listed in the dashboard. Specify a value in the Filter By field and click Filter. The filter will be applied on each row in all the services and the resulting list is displayed.

You can email a dashboard to one or more email addresses. Click Email and enter the email address and the subject of the dashboard. Click Send. This feature works only the htttp mode.

21.6.3 Customizing and Personalizing the Dashboard

You can customize a dashboard and make the changes available to all users. To customize a dashboard, select a row on the All Dashboards page and click Customize.

Note:

The following privileges are required to cr

To add one or more services to the dashboard, click the Wrench icon. The Component Properties: Services Dashboard window appears. Select the type of service that you want to add to the dashboard and click Search. A list of services is displayed in the Available Targets table. Select one or more services that you want to add, move them to the Selected Targets table and click Apply. To add metrics to the respective services click on the Metrics tab and select the respective services to add metrics and click OK. The selected services and metrics now appear in the Services Dashboard table.

To delete a service target from the dashboard, select the row and click the Wrench icon. The Component Properties: Services Dashboard window appears. Deselect the services and metrics that are to be removed from the dashboard, click Apply and then click OK. To reset the changes you have made to the dashboard, click Reset Page. Any changes that have been made to the dashboard will be removed permanently. Click Close to exit the Edit mode.

You can make specific changes to a dashboard to suit your requirements. Click the Personalize icon and add or delete one ore more services from the dashboard. The changes that you make will be visible only to you and the other users cannot see the changes.

21.6.4 Viewing the Dashboard Service Details Page

This page shows detailed information for the selected service.

Figure 21-10 Dashboard Details Page

Dashboard Details Page

It contains the following tabs:

  • Overview: This tab provides a brief overview of the selected service. Click on the Service link to drill down to the Service Home page. It contains the following regions.

    • General: This region shows the name of the service, status, date from which the service is available, availability percentage, type of service (test or system based), down time, and error time.

    • Component Availability: This region shows the status of the components in the service. It shows the status of the component and the date from which the service has been Up. Select the Show Only Key Tests check box to view only the key service tests

  • SLA: Shows a list of SLAs that have been enabled for this service. The name, status and the date from which the SLA is applicable is displayed. The SLA history over the last 7 days is also displayed.

  • Metrics: This tab shows the performance and metrics charts that have been defined for this service. It also shows the incidents that have occured for the service and the underlying systems on which the service is based.

21.7 Monitoring Settings

For each service, you can define the frequency (which determines how often the service will be triggered against your application) and the performance thresholds. When a service exceeds its performance thresholds, an alert is generated.

To define metrics and thresholds, from the Service Tests and Beacons menu, select Monitoring Settings for Tests. The Metric and Policy Settings page is displayed. Click the Monitoring Settings link. The Monitoring Settings - Thresholds page appears.

  • View By Metric, Beacon - In this view, you can click Add Beacon Overrides to override the default threshold values for one or more beacons. In this case, the default thresholds will only be used for beacons without any overrides. Any new beacons added to the service will use the default thresholds. Click Add Metric to add one or more metrics.

  • View By Beacon, Metric - In this view, you can click on the Default icon to toggle between Edit and View modes for a specific metric. In the Edit mode, you can modify the parameters of the metric. You can also modify the parameters of the metric for a specific beacon. In the View mode, the default parameters of the metric will be used.

    Apart from these procedures, you can also define metrics at the step, and step group level for Web transactions. You can choose either of the following views:

    • View By Step, Metric, Beacon: In this view, you can click Add Beacon Overrides to override the default threshold values for one or more beacons. In this case, the default thresholds will only be used for beacons without any overrides. Any new beacons added to the Web transaction will use the default thresholds. Click Add Metric to define thresholds for one or more metrics. Incidents are generated only if the value of the Data Granularity property is set to 'Transaction' for the service tests. For more information on the Web transaction properties, refer to the Create / Edit Service Test - Web Transaction help page in the Enterprise Manager Online Help.

    • View By Step, Beacon, Metric: In this view, you can click on the Default icon to toggle between Edit and View modes for a specific metric. In the Edit mode, you can modify the parameters of the metric for a specific beacon. In the View mode, the default parameters of the metric will be used. Incidents are generated only if the value of the Data Granularity property is set to ' Step'.

To define the default collection frequency and collection properties, click the Collection Settings tab on the Monitoring Settings page. You can do the following:

  • Specify the default collection frequency for all the beacons. To override the collection frequency for a specific beacon, click Add Beacon Overrides.

  • Specify the collection properties and their corresponding values for one or more beacons.

Refer to the Enterprise Manager Online Help for more details on the defining the collection intervals and performance thresholds.

21.8 Setting Up Monitoring Templates

A monitoring template for a service contains definitions of one or more service tests, as well as a list of monitoring beacons. A monitoring template can be used to create service tests on any number of service targets, and specify a list of monitoring beacons.

A monitoring template must be created from a service target. Once the template is created, the user can edit the template, create copies, or delete it. Finally, the user can apply the template to other targets, which creates the service tests on the other targets and adds the monitoring beacons.

To create a Monitoring Template, follow the steps given below:

  1. Click Setup to navigate to the main Setup page in Enterprise Manager.

  2. Click the Monitoring Templates link in the left panel.

  3. Click Create to create a monitoring template.

  4. In the target selection box, enter or select a service target and click Continue.

  5. In the Monitoring Template General Page, enter the name of the template that you wish to create.

  6. Click Tests to add / remove or configure service tests associated with the selected service target. Make the required changes to this page and click OK to save the template to the repository.

After you have created the Monitoring Template, use the Apply option to apply this template to a service test. You can click Edit to modify the template. For more details on these operations, refer to the Online Help.

21.8.1 Configuring Service Tests and Beacons for the Monitoring Template

You can configure the service tests and beacons associated with the template by using the options in the Tests page. A service test-based template contains the following elements:

  • Variables: A variable may occur at multiple locations in the service tests. The Variables table allows you to specify default values for all the variables. These default values will be stored in the template along with the variables. You can specify values other than the default while applying the template to a target. You can perform the following operations:

    • Add a variable. The variable can consist of letters, numbers and underscores only.

    • Rename a variable. When you rename a variable, all variable references in the service tests will be replaced with the new name.

    • Remove variables for properties within service tests. If you remove a non-password variable, all references to the variable in test properties will be replaced with the variable's default value

    • Replace Text in test properties with a variable definition.

  • Service Tests: You can edit the test definition and define variables for various properties. You can select the tests from the original target that are to be part of the template by clicking the Add / Remove button. You can specify whether the service test is a key test and if it should be enabled. You can also click Monitoring Settings to drill down to this page and define metrics and thresholds for the service tests.

  • Beacons: Use the Add / Remove button to specify which beacons are to be included in the template. You can also specify whether each beacon is a key beacon.

Refer to the Enterprise Manager Online Help for detailed instructions on these operations.

21.9 Configuring Service Levels

A service level rule is defined as an assessment criteria used to determine service quality. It allows you to specify availability and performance criteria that your service must meet during business hours as defined in your Service Level Agreement. For example, e-mail service must be 99.99% available between 8am and 8pm, Monday through Friday.

A service level rule specifies the percentage of time a service meets the performance and availability criteria as defined in the Service Level Rule. By default, a service is expected to meet the specified criteria 85% of the time during defined business hours. You may raise or lower this percentage level according to service expectations. A service level rule is based on the following:

  • Business Hours: Time range during which the service level should be calculated as specified in your Service Level Agreement.

  • Availability: Allows you to specify when the service should be considered available. This will only affect the service level calculations and not the actual availability state displayed in the console. You can choose a service to be considered up when it is one or more of the following states:

    • Up: By default the service is considered to be Up or available.

    • Under Blackout: This option allows you to specify service blackout time (planned activity that renders the service as technically unavailable) as available service time.

    • Unknown: This option allows you to specify time that a service is unmonitored because the Management Agent is unavailable be counted as available service time.

  • Performance Criteria: You can optionally designate poor performance of a service as a Service Level violation. For example, if your Website is up, but it takes 10 seconds to load a single page, your service may be considered unavailable.

  • Business Criteria: Business criteria are useful in determining in the health of the business processes for a particular service. You can optionally define business metrics that can affect the Service Level. A Service Level violation occurs when a critical alert is generated for a specified business metric.

    Note:

    The Business Criteria column is displayed only if one or more key business indicators are associated with the service. Refer to Oracle Enterprise Manager Integration Guide.
  • Actual Service Level: This is calculated as percentage of time during business hours that your service meets the specified availability, performance, and business criteria.

  • Expected Service Level: Denotes a minimum acceptable service level that your service must meet over any relevant evaluation period.

You can define only one service level rule for each service. The service level rule will be used to evaluate the Actual Service Level over a time period and compare it against the Expected Service Level.

21.9.1 Defining Service Level Rules

A Service Level Rule is defined as assessment criteria to measure Service quality. A Service Level Rule is based on the following:

  • Time range for which the rule is applicable.

  • Metrics that define the rule.

  • The user expectation on these metrics values

The Expected Service Level is the expected quality for the service and is defined based on the time range and metrics of the Service Level Rule. For example, the Expected Service Level can be that the service is available 99% of the time during business hours.

When you create a service, the default service rule is applied to the service. However, you must edit the service level rule for each service to accurately define the assessment criteria that is appropriate for your service. To define a service level rule:

  1. Click the Targets tab and Services subtab. The Services main page is displayed.

  2. Click the service name link to go to the Service Home page.

  3. In the Related Links section, click Edit Service Level Rule.

  4. On the Edit Service Level Rule page, specify the expected service level and the actual service level and click OK. The expected service level specifies the percentage of time a service meets the performance, usage, availability, and business criteria defined in the Service Level Rule. The actual service level defines the baseline criteria used to define service quality and includes business hours, availability, performance criteria, usage criteria, and business criteria.

Note:

Any Super Administrator, owner of the service, or Enterprise Manager administrator with OPERATOR_TARGET target privileges can define or update the Service Level Rule.

21.9.2 Viewing Service Level Details

You can view service level information directly from the either of the following:

  • Enterprise Manager Cloud Control Console -From any Service Home page, you can click on the Actual Service Level to drill down to the Service Level Details page. This page displays what Actual Service Level is achieved by the service over the last 24 hours/ 7 days / 31 days, compared to the Expected Service Level. In addition, details on service violation and time of each violation are presented in both graphical and textual formats.

  • Information Publisher - Information Publisher provides an out-of-box report definition called the Services Dashboard that provides a comprehensive view of any service. From the Report Definition page, click on the Services Monitoring Dashboard report definition to generate a comprehensive view of an existing service. By default, the availability, performance, status, usage, business, and Service Level of the service are displayed. The Information Publisher also provides service-specific report elements that allow you to create your own custom report definitions. The following report elements are available:

    • Service Level Details: Displays Actual Service Level achieved over a time-period and violations that affected it.

    • Service Level Summary: Displays service level violations that occurred over selected time-period for a set of services.

    • Services Monitoring Dashboard: Displays status, performance, usage, business, and service level information for a set of services.

    • Services Status Summary: Information on one or more services' current status, performance, usage, business, and component statuses.

      Refer to the Online Help for more details on the report elements.

21.10 Configuring a Service Using the Command Line Interface

Using the Command Line Interface, you can define service targets, templates and set up incidents. EMCLI is intended for use by enterprise or system administrators writing scripts (shell/batch file, perl, tcl, php, etc.) that provide workflow in the customer's business process. EMCLI can also be used by administrators interactively, and directly from an operating system console. Refer to Enterprise Manager Command Line Interface Guide for details.

Samples EMCLI templates to create an ATS service test and a Web transaction are shown below.

Example 21-1 ATS Service Test Template

<?xml version = '1.0' encoding = 'UTF-8'?>
<transaction-template template_type="generic_service" xmlns="template">
   <variables/>
   <transactions>
      <mgmt_bcn_transaction>
         <mgmt_bcn_txn_with_props>
            <mgmt_bcn_txn is_representative="true" name="ATS Page"
            monitoring="true" txn_type="OATS"/>
            <properties>
               <property name="Collection Interval" num_value="5.0" prop_type="2"  
             encrypt="false"/>
               <property name="scriptDescription" string_value="[1] Sign
In&#xA;[2] Welcome&#xA;[3] Single Sign-Off&#xA;[4] Sign In" prop_type="1"
encrypt="false"/>
               <property name="fileUploadTime" string_value="2012-08-09
08:47:22.0" prop_type="1" encrypt="false"/>
               <property name="OpenScriptJwgName" string_value="ATKHomepage.zip"
prop_type="1" encrypt="false"/>
               <property name="usageOptions" string_value="userDefined" 
prop_type="1" encrypt="false"/>
               <property name="fileSize" string_value="41368" prop_type="1"
encrypt="false"/>
               <property name="beaconDistributionOverride" 
string_value="AtsCredentials=1" prop_type="1" encrypt="false"/>
               <property name="FilePropertyValue" prop_type="7" encrypt="false"/>
               <property name="databankFilesJar" prop_type="7" encrypt="false"/>
               <property name="databankFiles" 
string_value="AtsCredentials,AtsCredentials.csv,3;" prop_type="1"
encrypt="false"/>
               <property name="granularity" string_value="transaction" 
prop_type="1" encrypt="false"/>
               <property name="databankValues" string
_value="AtsCredentials.&quot;test-id&quot;=&quot;ATKHomepage&quot;,AtsCredentials.
&quot;login-host&quot;=&quot;login-aufsn4x0cxf.oracleoutsourcing.com&quot;,
AtsCredentials.&quot;host&quot;=&quot;fs-aufsn4x0cxf.oracleoutsourcing.com&quot;,
AtsCredentials.&quot;username&quot;=&quot;faadmin&quot;,AtsCredentials.&quot;
password&quot;=&quot;fusionfa1&quot;" prop_type="1" encrypt="false"/>
               <property name="modules" 
string_value="oracle.oats.scripting.modules.http;version=2.6.1&#xA;
oracle.oats.scripting.modules.adfload;version=2.6.1&#xA;oracle.oats.scripting.
modules.basic;version=2.6.1" prop_type="1" encrypt="false"/>
               <property name="databankAliasMapping" 
string_value="AtsCredentials=AtsCredentials.csv" prop_type="1" encrypt="false"/>
               <property name="defaultCLIOptions" string_value="-dboptions
*:1:FIRST_RECORD_ONLY -jwg ATKHomepage.jwg -noReport true" prop_type="1"
encrypt="false"/>
            </properties>
            <per_bcn_properties/>
         </mgmt_bcn_txn_with_props>
         <steps_defn_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="1" name="[1] Sign In" 
step_type="OATS"/>               <properties>
                  <property name="url" string
_value="aHR0cHM6Ly9mcy1hdWZzbjR4MGRwZi5vcmFjbGVvdXRzb3VyY2luZy5jb20vaG9tZVBh
Z2UvZmFjZXMvQXRrSG9tZVBhZ2VXZWxjb21l" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="2" name="[2] Welcome" 
step_type="OATS"/>
               <properties>
                  <property name="url" string
_value="aHR0cHM6Ly9mcy1hdWZzbjR4MGRwZi5vcmFjbGVvdXRzb3VyY2luZy5jb20vaG9
tZVBhZ2UvZmFjZXMvQXRrSG9tZVBhZ2VXZWxjb21l" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="3" name="[3] Single Sign-Off" 
step_type="OATS"/>
               <properties>
                  <property name="url" string
_value="aHR0cHM6Ly9sb2dpbi1hdWZzbjR4MGRwZi5vcmFjbGVvdXRzb3VyY2luZy5jb20vb
2FtL3NlcnZlci9sb2dvdXQ=" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="4" name="[4] Sign In" 
step_type="OATS"/>
               <properties>
                  <property name="url" string
_value="aHR0cHM6Ly9mcy1hdWZzbjR4MGRwZi5vcmFjbGVvdXRzb3VyY2luZy5jb20vaG
9tZVBhZ2UvZmFjZXMvQXRrSG9tZVBhZ2VXZWxjb21l" prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
         </steps_defn_with_props>
         <stepgroups_defn/>
         <txn_thresholds>
            <mgmt_bcn_threshold warning_threshold="0.0" warning_operator="1"
critical_threshold="0.0" critical_operator="1" num_occurrences="1">
               <mgmt_bcn_threshold_key metric_name="openscript_response" 
metric_column="status"/>
            </mgmt_bcn_threshold>
         </txn_thresholds>
         <step_thresholds/>
         <stepgroup_thresholds/>
      </mgmt_bcn_transaction>
   </transactions>
</transaction-template>

Example 21-2 Web Transaction Service Test Template

<?xml version = '1.0' encoding = 'UTF-8'?> <transaction-template 
template_type="generic_service" xmlns="template">
   <variables>
      <variable name="HOST1" value="smpperf-linux26.us.oracle.com"/>
      <variable name="PORT1" value="5416"/>
      <variable name="PROTOCOL1" value="https"/>
   </variables>
   <transactions>
      <mgmt_bcn_transaction>
         <mgmt_bcn_txn_with_props>
            <mgmt_bcn_txn description="Test for checking the availability of 
EM Console/Website" is_representative="true" name="EM Console Service Test"
monitoring="true" txn_type="HTTP"/>
            <properties>
               <property name="readTimeout" num_value="120000.0" prop_type="2"
encrypt="false"/>
               <property name="Collection Interval" num_value="5.0" prop_type="2"
encrypt="false"/>
               <property name="certValidationMode" string_value="1" prop_type="1"
encrypt="false"/>
               <property name="maxDownloadSize" num_value="1.0E8" prop_type="2"
encrypt="false"/>
               <property name="sensitiveValuesProtection" string_value="0" 
prop_type="1" encrypt="false"/>
               <property name="failureStringModes" string_value="regularText"
prop_type="1" encrypt="false"/>
               <property name="UserAgent" string_value="Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1) OracleEMAgentURLTiming/3.0" prop_type="1"
encrypt="false"/>
               <property name="successStringModes" string_value="regularText"
prop_type="1" encrypt="false"/>
               <property name="variablesModes" string_value="urlEncode" 
prop_type="1" encrypt="false"/>
               <property name="content" string_value="0" prop_type="1"
encrypt="false"/>
               <property name="AcceptLanguage" string_value="en" 
prop_type="1" encrypt="false"/>
               <property name="connectionTimeout" num_value="120000.0" 
prop_type="2" encrypt="false"/>
               <property name="useCache" string_value="yes" prop_type="1"
encrypt="false"/>
               <property name="stringValidationMode" string_value="1" 
prop_type="1" encrypt="false"/>
               <property name="granularity" string_value="transaction" 
prop_type="1" encrypt="false"/>
               <property name="numThreads" num_value="4.0" prop_type="2"
encrypt="false"/>
               <property name="retries" num_value="1.0" prop_type="2"
encrypt="false"/>
               <property name="timeout" num_value="300000.0" prop_type="2"
encrypt="false"/>
               <property name="retryInterval" num_value="5000.0" prop_type="2"
encrypt="false"/>
            </properties>
            <per_bcn_properties/>
         </mgmt_bcn_txn_with_props>
         <steps_defn_with_props>
            <mgmt_bcn_step_with_props>
               <mgmt_bcn_step step_number="1" name="1.Access Logout page" 
step_type="HTTP"/>
               <properties>
                  <property name="req_mode" num_value="1.0" prop_type="2"
encrypt="false"/>
                  <property name="http_method" string_value="G" prop_type="1"
encrypt="false"/>
                  <property name="url" 
string_value="{PROTOCOL1}://{HOST1}:{PORT1}/em/console/logon/logoff?event=load"
prop_type="1" encrypt="false"/>
               </properties>
            </mgmt_bcn_step_with_props>
         </steps_defn_with_props>
         <stepgroups_defn/>
         <txn_thresholds>
            <mgmt_bcn_threshold warning_threshold="6000.0" warning_operator="0"
critical_threshold="12000.0" critical_operator="0" num_occurrences="1">
               <mgmt_bcn_threshold_key metric_name="http_response" 
metric_column="avg_response_time"/>
            </mgmt_bcn_threshold>
            <mgmt_bcn_threshold warning_threshold="0.0" warning_operator="1"
critical_threshold="0.0" critical_operator="1" num_occurrences="1">
               <mgmt_bcn_threshold_key metric_name="http_response" 
metric_column="status"/>
            </mgmt_bcn_threshold>
         </txn_thresholds>
         <step_thresholds/>
         <stepgroup_thresholds/>
      </mgmt_bcn_transaction>
   </transactions>
</transaction-template>

21.11 Troubleshooting Service Tests

This section lists some of the common errors you may encounter while using the Forms and the Web Transaction test type. The following topics are covered here:

21.11.1 Verifying and Troubleshooting Forms Transactions

The section covers the following:

21.11.1.1 Troubleshooting Forms Transaction Playback

This section lists some of the common errors you may encounter while playing back a Forms transaction and provides suggestions to resolve these errors.

  1. Error Message: Connection to Forms Server is lost. Possible version mismatch between agentjars and formsjars.

    Possible Cause: The transaction was recorded using an out-of-the-box Forms version.

    Solution: Verify the version of the Forms Application that you are running by checking the version number in the About Oracle Forms Online Help. If this version is not supported, follow the steps listed under Error Message 2.

  2. Error Message: Version Not Supported <forms_version>

    Possible Cause: The machine on which the beacon has been installed does not contain the necessary forms jar files.

    Solution: To resolve this error, follow these steps:

    1. Login to the system on which the Forms server has been installed. Locate the frmall.jar (if you are using Forms 10.1 or later) or f90all.jar (if are using Forms 9.0.4 or later) under the $FORMS_HOME/forms/java directory.

    2. Login to the system on which the beacon has been deployed and copy the jar file to the $ORACLE_HOME/jlib/forms/<version>/ directory. The version you specify here should be the same as the version string in the error message. Make sure that the directory is empty before you copy over the jar file.

    If you are using Oracle Applications R12 and you encounter this error, follow these steps to resolve the error:

    1. Login to the system in which the Oracle Application server has been deployed. Locate the following files:

      $JAVA_TOP/oracle/apps/fnd/jar/fndforms.jar
      $JAVA_TOP/oracle/apps/fnd/jar/fndewt.jar
      
    2. Login to the system on which the beacon has been deployed and copy these files to the $ORACLE_HOME/jlib/forms/apps/ directory. Make sure that the directory is empty before you copy over the jar files.

      Note:

      You cannot monitor two deployments of Oracle Applications from the same beacon if different versions of Oracle Applications have been used.
  3. Error Message: Forms URL is not pointing to the forms servlet.

    Possible Cause: When the Forms transaction was recorded, the location of the forms servlet could not be determined.

    Solution: Make sure that the Forms URL Parameter is pointing to the forms servlet. It should be http://<hostname>:<port>/forms/frmservlet for Forms10g or http://<hostname>:<port>/forms/f90servlet for Forms 9i. This parameter is automatically set by the Forms Transaction Recorder. But if it has not been set, you can locate the URL by following these steps:

    • Launch the Forms application.

    • View the source HTML file in the Forms launcher window.

    • Locate the xsurl variable. The URL is stored in this variable.

  4. Error Message: Could not connect to <machine name>.

    Possible Cause: The machine on which the beacon has been installed cannot access the Forms Application.

    Solution: Make sure the machine on which the beacon has been installed can access the Forms Application and firewalls have been properly configured. Support for playing back Forms transactions through proxy server is not available in this release.

  5. Error Message: Invalid module path in the initial message.

    Possible Cause: The transaction may have been incorrectly recorded or may be corrupt.

    Solution: Try to record the transaction again.

  6. Error Message: Cannot connect to login server.

    Possible Cause: This error may occur due the following reasons:

    • The Login URL that you have specified may be incorrect.

    • An invalid HTTPS certificate may have been provided for the login server.

    Solution:

    • Verify that the Login URL is correct.

    • If you are using HTTPS to connect to login server, make sure the certificate on the server is written for the login server machine itself. Make sure the SSL Certificate is imported into Agent and the CN of the certificate matches the host name of the login Server URL.

21.11.1.2 Troubleshooting Forms Transaction Recording

This section lists some troubleshooting steps that you can use when the Forms transaction cannot be recorded successfully.

  1. Make sure that all your Internet Explorer instances are closed and no java runtime programs are open.

  2. Start recording again with the java console open. You can view any exceptions or error messages displayed on the console.

  3. You should now see the text "Forms Transaction Recorder Version: <version number>" on the console. If this text is displayed, proceed to step 5. If you do not see the text, check if the formsRecorder.jar has been copied to the Forms archive directory. You can perform this check using either of the following methods:

    1. Navigate to the Forms archive directory and check if the formsRecorder.jar file is present in the directory.

    2. Navigate to the Enable Forms Transaction Monitoring page, select the corresponding Forms server target and click Configure. Enter the host credentials to see if the Forms Transaction Recorder has already been configured on this Forms server. If the formsRecorder.jar is not present in the Forms archive directory, you need to configure your Forms server for transaction monitoring. After ensuring that the formsRecorder.jar is present in the archive directory of the Forms server, go back to Step 1 and try recording again.

  4. If you see an exception related to the java .policy file displayed on the java console, check the file to ensure that it has the required content and is in the right location. If any errors are found, you must fix these errors and try recording again.

  5. If the recording still fails, check if the Enterprise Manager Certificate has been imported to the secure site.f the certificate has not been imported, you must import it and try recording again.

21.11.2 Verifying and Troubleshooting Web Transactions

This section lists some of the common errors you may encounter while recording and playing back Web Transactions.

  1. Scenario: Verify Service Test displays: Connection establishment timed out -- http://..../

    Possible Cause: The beacon can only access that URL via a proxy server and it has not been configured.

    Solution: From the All Targets page, select the beacon, click Configure and set the beacon proxy setting.

  2. Scenario: Verify Service Test displays: Authorization Required -- https://...../

    Possible Cause: The Basic Authentication information is not recorded automatically.

    Solution: To resolve this error, follow these steps:

    1. From the Service Tests and Beacons page, select the service test, click Edit.

    2. Make sure you enter all the Basic Authentication information: Username, Password, and Realm.

      Note:

      Realm usually appears above the Username label in the Browser's authorization dialog box.
  3. Scenario: Verify Service Test displays sun.security.validator.ValidatorException: No trusted certificate found -- https://....../.

    Possible Cause: The beacon does not know about this SSL Certificate.

    Possible Solution: From the Service Tests and Beacons page, select the service test, and click Edit. Under Advanced Properties, and set Authenticate SSL Certificates to No.

  4. Scenario: Verify Service Test displays: Timeout of 300000 exceeded for https://....../ Response time = 3000000

    Possible Cause: The test may be too complex to complete within the allotted time. Or, this may be an actual performance issue with the server.

    Possible Solution: From the Service Tests and Beacons page, select the service test, and click Edit. If this is not a server performance issue, under Advanced Properties, increase the Timeout Value.

  5. Scenario: The Verify Service Test option reports that the service as down, but the Web application is up and you can successfully play back the Web transaction.

    Possible Cause: The Web application is only compatible with Internet Explorer or Mozilla-based browsers.

    Possible Solution: From the Service Tests and Beacons page, select the service test, and click Edit. Under Advanced Properties, set the User Agent Header as Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) OracleEMAgentURLTiming/3.0.

    Note:

    For Enterprise Manager 10.2.0.4 and beyond, this User Agent Header is set automatically during Web transaction recording.
  6. Scenario: Test Performance Page does not show any step metrics.

    Possible Cause: By default, only transaction-level metrics are collected.

    Possible Solution: From the Service Tests and Beacons page, select the service test, click Edit, and set Data Granularity to Step.