Enterprise Manager Agent application

The Enterprise Manager Agent Web application installed on every system server that communicates with the Enterprise Manager regarding any configuration changes or alarm messages for the relevant server. (EMA) application is installed as part of every managed server Server that is managed by the Enterprise Manager application.. The EMA is a Java-based Web application that runs on a Tomcat Server.

The EMA is the application on the managed server with which the Enterprise Manager communicates. The EMA application operates as an agent for the Enterprise Manager on the managed server. If the EMA is not present on a server, the Enterprise Manager cannot manage or send configuration messages to that server.

For details on the connections that occur between the EMA and Enterprise Manager, see HTTP(S) Connection to the Enterprise Manager.

The EMA connects to and communicates with the Enterprise Manager to get configuration messages (containing configuration changes) from the managed server

  1. This step occurs only for servers from releases 15.2 HFR4 and later. EMA periodically contacts Enterprise Manager as described here:

    1. EMA contacts Enterprise Manager and issues a GET request to get any new configuration messages Enterprise Manager has available. EMA also passes in the previously completed message sequence to Enterprise Manager. If there are no configuration messages, EMA sleeps for one minute and then contacts EM again to check for any new configuration messages.

    2. Enterprise Manager ensures that the server that hosts EMA is authenticated and is not blocked. Enterprise Manager returns to EMA any configuration messages that are available.

    3. EMA processes the configuration message as described below, and continues to ask Enterprise Manager for the next configuration message as described in step a.

  2. The EMA receives a configuration message XML document from Enterprise Manager. EMA receives this configuration message over the HTTP(S) connection with the Enterprise Manager.

  3. EMA uses stAX (Streaming API for XML) to parse the configuration message XML document.

    In this parsing process, EMA extracts individual XML files (for example, a server role Entity that contains a logical, predefined set of components (system software or certified third-party software) deployed in the Data Center and Site Zones that provide specific functionality for the system. instance data file) from the configuration message XML document. These individual XML files are temporarily stored in this directory:

    install directory\Data\Ema\Temp\<Sequencenumber_Timeinmillisec>\Cache

    These temporary files can be automatically zipped and saved, as described in the notes at the end of this process.

  4. EMA creates a smaller version of the original configuration message XML document. This document includes pointers to each of the individual XML files (rather than the entire contents of the XML files). These pointers point to the individual XML files stored in the temporary Cache directory described in step 2.

  5. EMA loads the smaller version of the original configuration message XML document into memory.

  6. EMA copies the individual XML files from their temporary directory into the following directories:

    • install directory\Software\Conf\Roles - Server role instance data XML files are moved into this directory. Each specific server role includes its own subdirectory under the ..\Conf\Roles subdirectory:

      For example, the server role instance data XML file for the IP Recorder server role is moved here: ..\Conf\Roles\IP_RECORDER\IP_RECORDER-conf.xml

    • install directory\Software\Conf\Alarms - Alarm configuration files are moved into this directory.

    • install directory\Software\Conf\Cache - All other non-server role configuration files are moved into this directory.

      For example: ..\Conf\Cache\enterprisesettings.xml

  7. EMA deletes the XML files from the temporary directories (unless they were zipped, as noted in subsequent steps).

  8. EMA notifies applications on the managed server that it has placed XML files with configuration changes in the directories noted in step 6.

    Specifically, EMA notifies the Recorder Manager and the Unified Configuration and Monitoring (UCM) application.

  9. If the EMA successfully notifies the Recorder Manager or the UCM application of the changed files, the EMA returns a message. The EMA returns the message to the Enterprise Manager indicating the configuration change is successful. This message appears in the Configuration Status tab on Enterprise Manager.

  10. The Recorder Manager, or the UCM application, implements the configuration changes to components on the managed server to complete the configuration change process.

Note the following points regarding the process described above:

  • This process, and the process described in Handling of Configuration Changes by the Enterprise Manager, comprise the entire configuration change process. If an error occurs anywhere in either of these processes, up to and including step 9, a message appears in the Configuration Status tab on Enterprise Manager. The message indicates that Enterprise Manager is retrying the configuration change. The Reliable Messaging architecture continues retrying the configuration change until step 8 is completed successfully. (The EMA successfully notifies the Recorder Manager or the UCM application of the changed files.)

  • An error can occur in step 10 that prevents the Recorder Manager or the UCM application from implementing changes on the managed server. In this case, an alarm is raised on the managed server indicating the reason the change cannot be implemented.

    If an error occurs in step 10, the message indicating the configuration change was successful still displays in the Configuration Status tab of the Enterprise Manager. However, the alarm must be resolved before the configuration changes are implemented on the managed server.

  • Steps 3 through 7 describe a process by which the original configuration message XML document is parsed into a smaller file before being loaded into memory. Parsing this file into a smaller file allows the EMA to process configuration messages more quickly and efficiently.

    Optionally, you can create zip files of the temporary files stored in the Cache subdirectory described in step 3. These temporary files can be useful in troubleshooting scenarios. These files are saved only if they are zipped. Otherwise, they are deleted as noted in step 7.

    If you want to zip these files automatically, set the following property in the ConfigManager.xml file to true:

    <Property name=”ZIP_TEMP_FILES_FLAG”>true</Property>