Previous | Home | Next


WebSphere dmgr consoles

The dmgr console application name is isclite, and it is a system application, which it is central to a WAS product, and is installed when the product is installed. System applications are not seen in the list of installed applications when using the dmgr console. We cannot stop or start or uninstall isclite directly.

There are multiple dmgr consoles available...


Starting and accessing the consoles

Each application server process that hosts the dmgr console has two admin ports used to access the dmgr console. These ports are:

These ports are assigned at profile creation time. To determine the the port number for the dmgr console...

Access the dmgr console using the non-SSL port:

Access the dmgr console using the SSL port:

If administrative security is enabled, you are automatically redirected to the secure port.


Administrative console in a stand-alone server environment

In a single application server installation, the dmgr console is hosted by the application server. The server must be started to access the dmgr console.

To access the dmgr console:

  1. Verify the application server is running by entering the following command:

      serverStatus.bat(sh) -all

    The serverStatus command is used to obtain the status of one or all of the servers configured on the node. We provide the server name as an argument, or use the -all argument. The default server name is server1. 

    /IBM/WAS/AppServer/profiles/MyServer02/bin$ serverstatus.sh -all
ADMU0116I: Tool information is being logged in file 
/IBM/WAS/AppServer/profiles/MyServer02/logs/serverStatus.log
ADMU0128I: Starting tool with the MyServer02 profile ADMU0503I: Retrieving server status for all servers
ADMU0505I: Servers found in configuration:
ADMU0506I: Server name: server_85_2
ADMU0509I: The Application Server "server_85_2" cannot be reached. It appears to be stopped.

  2. If the status of your server is not STARTED, start it with the following command: startServer.bat(sh) server_name

  3. Open a web browser to the URL of the dmgr console, for example:

      https://<hostname>:9050/ibm/console

    <hostname> is the host name for the machine running the application server. We can always use the IP of the machine instead of the <hostname>.

  4. The dmgr console loads and you are prompted to log in.


Administrative console in a ND environment

If you are working with a deployment manager and its managed nodes, the dmgr console is hosted by the deployment manager. Start the deployment manager to use the dmgr console. The default name for the deployment manager is dmgr.

To access the dmgr console:

  1. Verify the deployment manager (dmgr) is running by entering the following command:

      serverStatus.sh -all

  2. If the dmgr status is not STARTED, start it with the following command:

      startManager.sh

  3. Open a web browser to the URL of the dmgr console, for example:

      https://<hostname>:9050/admin

    <hostname> is the host name for the machine running the deployment manager. We can always use the IP of the machine instead of the <hostname>.

  4. The dmgr console loads and you are prompted to log in.


Accessing the job manager console

If you are working with a job manager, the dmgr console is hosted by the job manager. The default name of the job manager is jobmgr.

To access the job manager dmgr console:

  1. Verify the job manager process (jobmgr) is running...

      serverStatus.sh -all

  2. If the status of jobmgr is not STARTED, start it...

      startServer.sh jobmgr

  3. Open a web browser to the URL of the dmgr console, for example:

      http://<hostname>:9960/ibm/console

  • The dmgr console loads and you are prompted to log in.

    If you are working with an administrative agent, the dmgr console is hosted by the administrative agent. The default name of the job manager is adminagent.

    To access the administrative agent dmgr console:

      Verify the administrative agent process (adminagent) is running.

        serverStatus.sh -all

    1. If the status of adminagent process is not STARTED, start it with the following command:

        startServer.sh adminagent

    2. Open a web browser to the URL of the dmgr console, for example:

        http://<hostname>:9060/ibm/console

      If we have nodes registered with the administrative agent, you are prompted to select which node to administer (including the administrative agent).

    3. The dmgr console loads and you are prompted to log in.


    Logging into an dmgr console

    When you access the dmgr console, you need to log in by providing a user ID. If WebSphere administrative security is enabled, you also need to provide a password.

    The user ID specified during login is used to track configuration changes made by the user.

    This allows you to recover from unsaved session changes made under the same user ID, for example, when a session times out or the user closes the web browser without saving. The configuration files are copied from the master repository and cached in the temporary workspace because you navigate through different console areas. Configuration changes are stored in...

      PROFILE_HOME/wstemp

    ...temporary workspace directory until the changes are merged with the master repository during a save operation in the dmgr console. Workspaces are not removed when you log out, so they can be reused in another login session for the same login user ID.

    We cannot log into two instances of dmgr consoles that are running on the same machine from a single browser type. For example, if you use Firefox to log into the deployment manager dmgr console, we cannot also log into a job manager running on the same machine.

    There is a limitation that cookies are unique per domain rather than a combination of domain and port. Therefore, the cookies that control the session and authentication data in the first browser tab or window get overwritten when logging into the other console in a new browser tab or window. However, it is possible to log into two consoles simultaneously from two completely different browsers, for example, Firefox and Internet Explorer.

    WebSphere administrative security also affects the log in procedure. The following scenarios relate how to maneuver in either security state:

    • If WebSphere administrative security is not enabled

      We can enter any user ID, valid or not, to log in to the dmgr console. The user ID is used to track changes to the configuration but is not authenticated. We can also simply leave the User ID field blank and click the Log In button. The administrative security is not enabled, so we cannot see any password field in the dmgr console login window.

      Logging in without an ID is not a best practice, especially if we have multiple administrators.

    • If WebSphere administrative security is enabled

      You must enter a valid user ID and password that was already assigned an administrative security role.

      If you enter a user ID already in session, a message...

        Another user is currently logged in with the same User ID

      ...is displayed, and you are prompted to do one of the following actions:

      • Log out of the other user with the same user ID.

        You are allowed to recover changes that were made in the other user's session.

      • Return to the login page and specify a different user ID.

    You also get the message if a previous session ended without a logout. For example, if the user closed a web browser during a session and did not log out first or if the session timed out. Changes made in an interrupted session are recoverable.


    Recovering from an interrupted session

    Until you save the configuration changes made during a session, the changes do not become effective. During a save operation, the changes propagate and merge with the master configuration repository. If a session is closed without saving the configuration changes made during the session, these changes are remembered, and we have an opportunity to recover the changes. The changes are currently stored in the wstemp temporary workspace directory.

    When unsaved changes for the user ID exist during login, you are prompted to complete one of the following actions:

    • Work with the master configuration

      Selecting this option specifies to use the last saved administrative configuration. Changes made to the user's session since the last saving of the administrative configuration are lost.

    • Recover changes made in a prior session

      Selecting this option specifies to use the same administrative configuration last used for the user's session. It recovers all changes made by the user since the last saving of the administrative configuration for the user's session.

    As you work with the configuration, the original configuration file and the new configuration file are stored in a folder at:

    If you log out of the dmgr console and the session is correctly ended, the session directories in the wstemp folder are automatically removed. If the session is interrupted, for example, by closing the web browser instead of logging out, the directories remain in the file system. It is safe to delete the contents of the wstemp folder to free space on the file system. After deleting the contents, the deployment manager server must be stopped and restarted. Before stopping the server, verify that no one is logged in or their session will be corrupted.


    Installing and uninstallating the dmgr console application

    We can install the dmgr console during profile creation or after you create a profile.

    We can uninstall any dmgr console that you install.

    Unfederated application servers, administrative agents, deployment managers, and job managers can have their own dmgr consoles. If you plan to install the dmgr console, a profile that does not have an dmgr console installed must exist. We cannot have two dmgr consoles running in the same profile.

    To install an dmgr console after profile creation or to uninstall the dmgr console, use wsadmin to run a jython script named deployConsole.py. This script is located in the bin folder of the IBM WAS installation root and can be run in either connected or disconnected mode. The usual security restrictions for wsadmin apply to this script. In connected mode, the user must authenticate if security is enabled.

    The wsadmin command attempts to remotely connect to the deployment manager. So, start your deployment manager process before running either commands. You have to run the commands on the deployment manager node and not on a federated node. In our examples, the user name and its password are wsadmin and they are to be replaced with your values when using the commands.

    Installing the dmgr console with the Jython script deployConsole.py 

    wsadmin -lang jython
        -c AdminControl.getNode() 
        -user wsadmin 
        -password foo 
        -f "/WAS/AppServer/bin/deployConsole.py" install

    Uninstalling the dmgr console with the Jython script deployConsole.py 

    wsadmin -lang jython 
        -c AdminControl.getNode() 
        -user wsadmin 
        -password foo 
        -f "/WAS/AppServer/bin/deployConsole.py" remove


    Administrative console application logs

    In case you need the history of the dmgr console actions and events for further audits, we have the option to enable the log details for the specific components in the isclite application. Logs are useful especially in sensitive production environments. To enable the log details, select the desired log detail level for the com.ibm.isclite.* component. In case of a deployment manager profile, this component is located in the deployment manager server log and trace levels configuration. In case of another type of profile (unfederated application servers, administrative agents, or job manager), this component is located in the server log and trace levels configuration.

    To enable log details for a deployment manager profile...

    1. Click...

        Troubleshooting | Logs and trace | deployment manager server name | Change log detail levels | Configuration tab Components and Groups | *[All Components] | com.ibm.isclite.* component.

    2. Select the required log detail level for this component or its sub-components.

    3. Save the changes, and restart the deployment manager server process.

    The log entries for the isclite application are available in the JVM logs of the deployment manager process (the default names are SystemOut.log and SystemErr.log).


    Change the dmgr console session timeout

    The idle period, before the dmgr console session expires, is referred to as session timeout. The default session timeout value for the dmgr console is 15 minutes. The timeout value can be modified using a JACL script available at the information center.


    The graphical interface

    The WebSphere dmgr consoles have the same layout pattern. In each dmgr console, we can find the following main areas:

    • Banner
    • Navigation tree
    • Work area, including the messages and help display areas

    Each area can be resized as desired. The difference in the dmgr console types is noted in the Navigation tree. The options that you find there vary depending on the dmgr console type.


    Banner

    The banner is the horizontal bar near the top of the dmgr console. It includes a greeting to the user who is logged in. The banner also provides the following actions:

    • Logout logs you out of the dmgr console session and displays the login page. If you changed the administrative configuration since last saving the configuration to the master repository, the Save page displays before returning you to the login page. Click Save to save the changes. Click Discard to return to the dmgr console, or Logout to exit the session without saving changes.

    • Help opens a new web browser with detailed online help for the dmgr console.

      This is not part of the information center.

    The banner displays a user ID and it can be customized to show a unique identifier for the dmgr console. This can be helpful in cases where administrators log on to multiple dmgr consoles. Glancing at the banner lets you know which system you are logged on to. We can add a Console Identity from the dmgr console.

    To customize the banner:

    1. Click...

    2. Click Save, and log out of the dmgr console and then log back in. After you log back in, you will see the new console identity in the banner.

      In an administrative agent configuration, the changes are applied to the administrative agent and all of its registered application servers, regardless of where the changes were actually saved.


    Navigation tree

    The navigation tree on the left side of the dmgr console offers links for you to view, select, and manage components.

    Clicking a + sign beside a tree folder or item expands the tree for the folder or item. Clicking a -sign collapses the tree for the folder or item. Double-clicking an item toggles its state between expanded and collapsed.

    The content displayed on the right side of the dmgr console, the workspace, depends on the folder or item selected in the tree view.


    Guided Activities

    The navigation tree includes a category called Guided Activities containing step-by-step assistance for performing some common tasks. Each of these activities can be accomplished manually and without guidance, but using the Guided Activities option provides additional assistance when desired.


    Workspace

    The workspace, on the right side of the dmgr console, allows you to work with your administrative configuration after selecting an item from the dmgr console navigation tree.

    When you click a folder in the tree view, the workspace lists information about instances of that folder type in the collection page. For example, clicking...

      Servers | Server Types | WebSphere application servers

    ...shows all of the application servers configured in this cell. Selecting an item, an application server in this example, displays the detail page for that item.

    The detail page can contain multiple tabs. For example, you might have a Runtime tab for displaying the runtime status of the item and a Configuration tab for viewing and changing the configuration of the displayed item.


    Messages

    When you perform administrative actions, messages are shown at the top of the workspace to display the progress and results. These messages are limited in nature, so if an action fails, review the JVM process logs for more detailed information.

    When configuration changes are made, the message area contains links that we can click to review or save the changes.


    Breadcrumb trail

    As you navigate into multiple levels of a configuration page, a breadcrumb trail is displayed at the top of the workspace. It indicates how you reached the current page and provides links that allow you to go back to previous pages without starting the navigation trail over.


    Help area

    On the right side of the dmgr console, the help portlet displays the Help area. Most pages have a More information about this page link in the Help area. Clicking the link opens the online help in a separate browser. Many pages have a View administrative scripting command for last action link. Clicking this link displays an equivalent scripting command for the action you just performed.

    The visibility of the help area is controlled by console preferences.


    Setting console preferences

    The look of the dmgr console can be altered by setting console preferences. The preference you see vary slightly depending on the console type. For example, the preference to synchronize changes with nodes is only applicable to an dmgr console on a deployment manager. Console preferences for a deployment manager's dmgr console.

    To set dmgr console preferences, go to...

    ...and set...

    • Turn on WorkSpace Auto-Refresh specifies the view automatically refreshes after a configuration change. If it is not selected, re-access the page to see the changes.

    • No Confirmation on Workspace Discard specifies that a confirmation window be displayed if you elect to discard the workspace. For example, if we have unsaved changes and log out of the dmgr console, you are asked whether to save or discard the changes. If this option is not selected, and you elect to discard your changes, you are asked to confirm the discard action.

    • Use default scope (dmgr console node) sets the default scope to the node of the administration console. If we do not enable this setting, the default is all scopes.

    • Show the help portlet displays the help portlet to the right of the dmgr console.

    • Enable command assistance notifications allows you to send JMX notifications containing command data. These notifications can be monitored in a Rational Application Developer workspace, providing assistance in creating scripts.

    • Log command assistance commands specifies whether to log all of the command assistance wsadmin data for the current user.

      When you select this option, script commands matching actions you take in the dmgr console are logged to the following location:

        PROFILE_HOME/logs/<server_name>/commandAssistanceJythonCommands_<user_name>.log

    • Synchronize changes with Nodes synchronizes changes that are saved to the deployment manager profile with all the nodes that are running.

      Select the boxes to choose which preferences to enable and then click Apply.

    Using the bidirectional support options link we can specify bidirectional text preferences for the dmgr console. Text is supported in both directions for different types of alphabets.

    This means the path hierarchy is displayed left-to-right even if elements of the path have right-to-left text.We can enable Global Preferences, which enables this option for all users and also selects the Current User Preferences option | If you only want to enable this support for the current user logged into the dmgr console, enable only the Current User Preferences.


    Administrative console resources scopes

    When working with items in the dmgr console, certain resources are defined at a scope level. If applicable, we can select the scope from the drop-down menu, and we can set the preferences to specify how the information is to be displayed on the page.

    For example, to display WebSphere Variables that were defined, click Environment | WebSphere Variables.


    Selecting a scope

    The scope level determines which applications or application servers see and use that configuration. The scope setting is available for all resource types, WebSphere variables, shared libraries, and name space bindings.


    Scope levels

    Configuration information is defined at the following levels: cell, cluster, node, server, and application. Here, we list these scopes in overriding sequence. Because you see application scope first, anything defined at this scope overrides any conflicting configuration you might find in the higher-level scopes:

    • Resources and variables scoped at the application level apply only to that application. Resources and variables are scoped at the application level by defining them in an enhanced EAR.

    • Resources scoped at the server level apply only to that server. If a node and server combination is specified, the scope is set to that server. Shared libraries configured in an enhance EAR are automatically scoped at the server level.

    • Resources scoped at the node level apply to all servers on the node.

    • Resources scoped at the cluster level apply to all application servers in the cluster. New cluster members automatically have access to resources scoped at this level. If we do not have any clusters defined, you will not see this option.

    • Resources scoped at the cell level apply to all nodes and servers in the cell. Stand-alone application servers: Although the concept of cells and nodes is more relevant in a managed server environment, scope is also set when working with stand-alone application servers. Because there is only one cell, node, and application server, and no clusters, simply let the scope default to the node level.

    Configuration information is stored in the repository directory that corresponds to the scope. For example, if you scope a resource at the node level, the configuration information for that resource is in:

      <PROFILE_HOME>/config/cells/cellname/nodes/<node>/resources.xml

    If you scoped that same resource at the cell level, the configuration information for that resource is in:

      <PROFILE_HOME>/config/cells/cellname/resources.xml


    Setting scope levels in the dmgr console

    Collection pages containing items that require a scope level to be identified provide two different options for defining the scope. Setting the scope level sets the level for any resources that you create and limits what is displayed in the collection page.

    Clicking the Show scope selection drop-down list with the all scopes option provides a drop-down box with all scopes from which we can select, including the “All scopes” option. Selecting a scope from the drop-down list changes the scope automatically.

    The second option for setting the scope is to clear Show scope selection drop-down list with the all scopes. Instead of a drop-down menu, we have fields for each scope level where we can browse a list of applicable entries at that scope level. Click Apply to complete the selection.

    The scope is set to the lowest level entry you select (a red arrow to the left of the field indicates the current scope). To move to a higher scope, simply clear the lower field. For example, if you select a server as the scope level and want to change the scope to the node level, clear the server field, and click Apply.

    This option is useful in cells containing a large number of nodes, servers, or clusters. In those situations, the drop-down menu can be difficult to navigate. However, note the option to view all scopes is not available.


    Setting preferences for viewing the dmgr console page

    After selecting a task and a scope, the dmgr console page shows a collection table with all of the objects created at that particular scope. We can change the list of items you see in this table using the filter and preference settings.

    The preference settings available vary by the type of item you are displaying.

    The filter options can be displayed or set by clicking the Show Filter Function icon ( ) at the top of the table.

    When you click the Show Filter Function icon, a new area appears at the top of the table, allowing you to enter filter criteria. To filter items:

    1. Select the column to filter on for example, the display table has three columns from which to choose. Your options vary depending on the type of item you are filtering.

    2. Enter the filter criteria. The filter criteria is case sensitive and wild cards can be used. In our example, to see only providers with names starting with S, select the Name column to filter on, and enter S* as the filter.

    3. Click Go.

    4. After you set the filter, click the Show Filter icon again to remove the filter criteria from the view. You still have a visual indication the filter is set at the top of the table.

    Setting the filter is temporary and only lasts for as long as you are in that collection. To keep the filter active for that collection, select the Retain filter criteria box in the Preferences section, and click Apply. To clear the filter criteria, click the icon.


    Updating existing items

    To edit the properties of an existing item:

    1. Select the category and type in the navigation tree, for example, select...

        Servers | Server Types | WebSphere application servers

    2. A list of the items of that type, in the scope specified, are listed in a collection table in the workspace area. Click an item in the table.

      This action opens a detail page for the item.

    3. In some cases, you see a Configuration tab and a Runtime tab on this page. In others, you only see a Configuration tab.

    Updates occur under the Configuration tab. Specify new properties or edit the properties already configured for that item. The configurable properties depend on the type of item selected. For example, if you select a WAS cluster, this action opens a detail page

    A Local Topology tab is sometimes displayed and shows the topology currently in use for this administrative object.

    The detail page provides fields for configuring or viewing the more common settings and links to configuration pages for additional settings.

  • Click OK to save your changes to the workspace and exit the page. Click Apply to save the changes without exiting. The changes are still temporary. They are only saved to the workspace and not to the master configuration. Those changes still need to be done.

  • As soon as you save changes to your workspace, you will see a message in the Messages area reminding you that we have unsaved changes.

    At intervals during your configuration work and at the end, save the changes to the master configuration by clicking Save in the Messages area or by clicking...

    To discard changes, use the same options. These options simply display the changes you made and give you the opportunity to save or discard.


    Add new items

    To create new instances of most item types:

    1. Select the category, and type in the navigation tree.
    2. Click Scope. (When creating a new item, we cannot click the All option for scope.)
    3. Click the New button above the collection table in the workspace.

    When you click New to add an item, one of two things occur, depending on the type of item you are creating. A wizard guides you through the definitions, or a new details page opens allowing you to fill in the basic details. In the latter case, enter the required information, and click Apply. This action usually activates additional links to detail pages required to complete the configuration.

    In the configuration pages, we can click Apply or OK to store your changes in the workspace. If you click OK, you exit the configuration page. If you click Apply, you remain in the configuration page. As you are becoming familiar with the configuration pages, always click Apply first. If there are additional properties to configure, you will not see them if you click OK and leave the page.


    Removing items

    To remove an item:

    1. Find the item.
    2. Select the item in the collection table by selecting the box next to it.
    3. Click the Delete button above the collection table in the workspace.
    4. If asked whether to delete it, click OK.
    5. Click Save in the Messages area when you are finished.


    Start and stop items

    To start or stop an item using the dmgr console:

    1. Select the category and type in the navigation tree.
    2. Select the item in the collection table by selecting the box next to it.
    3. Click Start or Stop. The collection table shows the status of the item.

    For example, to start a specific application server in a distributed server environment, click Servers | All Servers. Select the box beside the resource you want, and click Start.

    Not all items can be started and stopped from the dmgr console. For example, the deployment manager must be started independently from the dmgr console. Also, there can be multiple options for starting and stopping an item (restart, stop immediate, and so on.)


    Using variables

    WebSphere variables are name and value pairs used to represent variables in the configuration files, which makes it easier to manage a large configuration. Predefined variables, such as JAVA_HOME, SERVER_LOG_ROOT, WAS_SERVER_NAME, can be found here using specific scope selections. It is important to set a variable to the required scope level to use it properly.

    To set a WebSphere variable:

    1. Select Environment | WebSphere variables.

    2. To add a new variable, select the desired scope and then click New, or click a variable name to update its properties.

    3. Enter a name and value and then click Apply. A detailed description might help you identify the correct variable in a large environment.


    Saving work

    As you work with the configuration, your changes are saved to temporary workspace storage. For the configuration changes to take effect, they must be saved to the master configuration.

    If we have a ND environment, a second step is required to synchronize, or send, the configuration to the nodes. Consider the following possibilities.

    If you work on a page, and click Apply or OK, the changes are saved in the workspace under the user ID. Using this action, we can recover changes under the same user ID if you exit the session without saving.

    You need to save changes to the master repository to make them permanent. You have several options:

    • Use the Save window in the Messages area. If it is open, it is the quickest method.

    • Click...

  • When you log in, if you logged out without saving the changes, you are given the option to save the changes.

    The Save window presents you with the following options:

    • Save.

    • Discard: This option reverses any changes made during the working session and reverts to the master configuration.

    • Cancel: This option does not reverse changes made during the working session. It just cancels the action of saving to the master repository for now.

    • Synchronize changes with nodes: This action distributes the new configuration to the nodes in a distributed server environment.

    Before deciding whether to save or discard changes, we can see the changed items by expanding Total changed documents in the Save window.

    All the changes made during a session are cumulative. Therefore, when you decide to save changes to the master repository, all changes are committed. There is no way to be selective about what changes are saved to the master repository.


    New options in version 8.5 deployment manager dmgr console

    The deployment manager dmgr console for IBM WAS V8.5 contains new guided activities that can help you prepare the environment:

    • Preparing the hosting environment for basic dynamic operations helps you prepare support for WebSphere dynamic operations. This task can help create an On Demand Router, create a dynamic cluster, enable email notification for runtime tasks, and save and synchronize the changes.

    • Deploying an application with defined service levels helps you to deploy an application with defined service levels into the WebSphere Extended Deployment hosting environment. It does so by installing the application, defining service levels with service policies, classifying application requests with service policy work classes, and saving and synchronizing the changes.

    • Defining policies to detect and manage health conditions helps you to plan for detecting and managing health conditions. It does so by creating policies for specific health conditions, configuring the health monitoring controller, setting email notifications for runtime tasks, and saving and synchronizing the changes.


    Servers task

    The dmgr console for IBM WAS V8.5 contains the following new features in the Servers task:

    • We can view a list of all servers by selecting Servers | All servers

    • In Server Types, there are the following new links:

        On Demand Routers View, add, delete, use templates, start, stop.
        PHP servers View, add, delete, use templates, start, stop, terminate, submit action, set mode
        WAS Community Edition servers View, add, delete, use templates, start, stop, terminate, submit action, set mode
        Apache servers View, add, delete, use templates, start, stop, terminate, submit action, set mode
        Custom HTTP servers View, add, delete, use templates, start, stop, terminate, submit action, set mode.

    • In Clusters there are the following new features:

      • On demand Router
      • Dynamic clusters

    The v5 JMS servers link is no longer available in the tasks...

      Servers | Servers Types


    Applications task

    New features:

    • We can view all the applications by selecting the linkk..

        All applications

    • Using the link...

        Install New Middleware Application

      ...we can add the following types of applications...

      • Java 2 Platform enterprise Edition
      • PHP
      • Unmanaged Web Application
      • WAS Community Edition

    • Edition Control Center enables management and operational control over application editions, including interruption free application upgrade. An application edition is a version of an application composed of distinct versions of modules and bindings. It provides a summary view of each enterprise application, its editions, and their current state. By clicking an enterprise application name, we can manage the individual editions of the selected application.

    • Using the Global deployment settings link we can manage settings that apply to all applications.


    Runtime Operations task

    Runtime operations are used to configure the dynamic operations environment and use visualization capabilities to understand the operational state of the environment.

    This task consists of several features:

    Dashboard Display a high level of the overall environment and alert about problems.
    Applications Display an operational summary of all the started applications, including status, stability, and service policy.
    Deployment Targets Operational summary of running deployment targets, such as application servers, middleware servers, clusters, and dynamic clusters.
    Service Policies Display performance data. Determine relative performance of service policies to goals.
    Component Stability Runtime information and is used to review the information for all of the on demand routers.
    Reports Customized business and performance charting. Track statistics environment. Operational Policies task

    This new task is used to define service policies, visualize service policies topology, define health policies, define custom actions, and manage autonomic managers.


    System administration task

    This task contains the following new features:

    • Extended Repository Service enables advanced management of the configuration repository. The configuration repository contains the configuration for the cell. This information is essential to the operation of the applications. We can create repository checkpoints to help save snapshots of your configuration as you make changes, so we can undo those changes if necessary. We can configure your repository to create automatic delta checkpoints each time you make a configuration change. A delta checkpoint saves a copy of the configuration documents prior to saving your changes. We can specify the number of automatic checkpoints to save. After this limit is reached, the next checkpoint replaces the oldest.

    • Middleware nodes is used to manage nodes in the application server environment. A node corresponds to a physical computer system with a distinct IP host address. We can view a table with the managed and unmanaged nodes in this cell, add new nodes to the cell and to this list by selecting the add node administrative action.

    • Middleware descriptors provides information about different middleware server platforms to the Intelligent Management runtime environment. The default middleware platforms are:

      • apacheWebServerRuntime
      • apache_server
      • application_server
      • customhttp_server
      • phpRuntime
      • wasceRuntime
      • wasce_server.

    • Visualization Data Services provides performance statistics for the managed cell.

    • Target Management | Notifications is used when sending email notifications of tasks.

    • Target Management | Runtime Tasks shows the current tasks that are generated by a runtime component within Intelligent Management. Click the Task ID to view the task target objects and corresponding monitors of a specific task. To act on a task, choose the action from the appropriate list and select the corresponding check box. Click Submit.

    We can submit multiple actions concurrently.