Page tree
Skip to end of metadata
Go to start of metadata

Note

ExtendedWeblogicDiscovery pattern uses configuration file parsing approach only in Atrium Discovery 8.3 and later

ExtendedWeblogicDiscovery pattern for BMC Discovery 11.0 and later uses configuration file parsing approach only

Overview

Atrium Discovery starting with 8.2 version has native built-in Weblogic extended J2EE Discovery mechanism based on JMX technology. All technical details are described in product documentation.

Starting from Atrium Discovery 8.3 there is an additional method which is used after and if the main extended J2EE Discovery method fails. Usage of this method can be disabled in the Configuration Section of ExtendedWeblogicDiscovery module (it is turned on by default) via the Atrium Discovery pattern configuration UI.

This method is based on parsing of the Weblogic configuration file config.xml, the information about which is stored on the WebLogic Application Server SI by the core WebLogic Application Server pattern. Currently this method supports all version of WebLogic with two formats of config.xml files - WebLogic of version newer then 9.x and older.

Prerequisites

In order to successfully use Config-file-based method of WebLogic Extended Discovery target 'BEA WebLogic Application Server' SI must have 'jmx_enable' and 'config_file' attributes populated.
Also there is an option which helps ADDM to find remote Managed Server SIs.

All these prerequisites are described detailed below in three sub-sections.

jmx_enable

This attribute shows that Extended Discovery can be executed upon this particular WebLogic Server SI. In other words this means that this Server is Admin instance of WebLogic domain with JMX access enabled.

Extended Discovery by usage of Phurnace (in ADDM 8.3+) or EDM (ADDM 8.2) libraries is using this attribute in target SI to trigger off. Of course for further work they need the existence of 'jmx_port' to be populated in SI to connect to WebLogic via JMX directly and access to MBeans with information needed for modelling purposes. If these methods failed to obtain required information they immediately pass Extended Discovery to Config-file-based method unless special option directly forbid this (option 'Use Config-file-based approach for Extended modelling of Weblogic if Phurnace method failed' in WebLogic.ExtendedDiscovery module).

If this attribute ('jmx_enable') missed on instance which is known to be Admin instance this means that ADDM failed to obtain this server's config.xml. Details on how to make sure that this file could be discoverable are shared in the following sub section.

config_file

WebLogic Server SI's 'config_file' attribute is most important requirement for Config-based WebLogic Extended Discovery method and keeps the full absolute path to "config.xml" file which is the core configuration file for whole WebLogic Domain. This attribute is populated by regular WebLogic Server pattern (BEA.WebLogicApplicationServer module) if ADDM is successful in discovering config.xml which is related to target WebLogic Server. That pattern uses different methods to retrieve the path to this file:

  • from command line of startWebLogic.sh or startWebLogic.cmd which started trigger process
  • from argument of trigger process
  • from user-definable list of absolute paths to domain directories in Configuration section (in this case option to enable this functionality also needs to be enabled)

Even after deploying these methods there are possibility that ADDM won't be able to find related config.xml by some reason and this will result in lower refinement of created WebLogic Server model (usually - no domain information in the SI name, attributes such as listen ports and addresses).

To workaround such issue user may need to assist ADDM in finding this file by the manually entering the path to this file using the following steps:

  • Enable usage of user-definable list of WebLogic domain absolute directories paths in regular WebLogic Server pattern's Configuration section (option Indicated that user-definable list of WebLogic domain absolute directories paths is enabled)
  • Fill needed domain absolute directories paths for appropriate platform in respective option:
    • WebLogic domain absolute directories paths (Windows)
      • example: 'c:\bea\bea\user_projects\domains\MedRecServer'
    • WebLogic domain absolute directories paths (UNIX)
      • example: '/opt/bea/user_projects/domains/MedRecServer'

Managed Servers modelling prerequisites

Configuration file 'config.xml' contains Domain-level information - not only about Admin instance but about Managed Servers also. All WebLogic.ExtendedDiscovery methods tries to pull information for these servers also and populate it in them. For each found in config.xml server these methods tries to find respective WebLogic Server SI in Infrastructure and assign found information. This search is made by the following steps:

  • If name of processed server node entry equals to trigger WebLogic's server name - this means this is Admin instance itself. All further discovered information regarding this entry will be assigned to trigger SI
  • ADDM looks for WebLogic SI with server name and domain name equal to those found ones from processed config.xml entry.
  • ADDM looks for single WebLogic SI with server name equals to those found one for processed config.xml entry AND deployed on Host where trigger (Admin instance) is running. This search expects that domain is not discovered (without access to config.xml for ADDM at the time of the modelling of this Managed WebLogic Server).
  • If all these searches failed then ADDM can look for single WebLogic Server SI with corresponding server name. As this search may be heavy from performance perspective it needs to be enabled in Configuration section for WebLogic.ExtendedDiscovery module - option "Use search for WebLogic App Server SI within all infrastructure if other search queries failed".

Note

Please make sure that option "Use search for WebLogic App Server SI within all infrastructure if other search queries failed" is enabled (as by default it's set to 'False') if WebLogic has multi-host setup and/or remote Managed Servers were not linked with main Admin instance and with correspondent Domain Collection node

Domain

ExtendedWeblogicDiscovery creates Domain Collection node with type set to "J2EEDomain" and domain_name set to the name of domain which is retrieved from config.xml by using the following XPath query:


  • /domain/name/text()


  • /Domain/@Name

    (WebLogic of version 8.x and older)


J2EE Applications

The pattern parses out the list of deployed J2EE application from config.xml file with the help of the following Xpath query:

  • /domain/app-deployment/name

  • /Domain/Application/@Name (WebLogic of version 8.x and older)

Then the pattern checks each found application if it is deployed on current server in two steps:

  • checking if the currently processed server's name is among other deployment targets obtained by the following Xpath query:

    • /domain/app-deployment[name="<app>"]/target/text()


    • /Domain/Application[@Name="<app>"]/@StagedTargets

      - for WebLogic of version 8.x and older, is this node doesn't provide information, then the pattern will collect all targets of children WebAppComponent nodes using similar Xpath:



      • /Domain/Application[@Name="<app>"]/WebAppComponent/@Targets

        where app is the name of application being checked


  • checking if this application is deployed on current server's cluster by firstly querying current server's cluster name with Xpath query and checking if this cluster name - if it was found - is among targets (which is the result of the previous query). The mentioned Xpath query for obtaining current server's cluster name is the following:

    • /domain/server[name=<server_name>]/cluster/text()


    • /Domain/Server[@Name=<server_name>]/@Cluster

      - for WebLogic of version 8.x and older
      where server_name is current server's name


  • checking if this application is deployed using virtual host as target. Virtual Hosts can be configured in two ways: by specifying server name or server's cluster name as a target. Firstly the pattern checks virtual-host deployment targeted to server. Secondary the pattern checks if this is virtual-host deployment targeted to server's cluster. Please note that this order is not important as these methods can't give a false result. The Xpath queries to obtain virtual host targeted to server and to cluster (in this order) are shown below:

For WebLogic of 9.x and newer versions if this application is verified to be deployed on current server, the pattern will model a Software Component with the correspondent name and the type set accordingly to the value found by the following Xpath Query (either "WAR" which will result in "J2EE WAR module" type or "EAR" which will result in "J2EE EAR module" type):


  • //app-deployment[name="<app>"]/module-type

The same check for WebLogic 8.x and older is done by checking file-ending of Path atribute of Application for either ".ear" (J2EE EAR module) or ".war" (J2EE WAR module). For obtaining the path the following XPath query used:


  • /Domain/Application[@Name="<app>"]/@Path

There are some additional attributes are present for Software Components, like installation_path, installed_product_name and installed_product_version

The pattern extracts the installation path of each application by running the following xpath queries:


  • /Domain/app-deployment/source-path


  • /Domain/app-deployment/@Path

    - for WebLogic of version 8.x and older


Deployed product name can be found either by mapping the vendor's application names with the real names of the product or by looking for Implementation-Title tag in <INSTALLATION_PATH>/META-INF/MANIFEST.MF file or by matching '<display-name>' in <INSTALLATION_PATH>/WEB-INF/web.xml file.

Deployed product version is extracted from <INSTALLATION_PATH>/META-INF/MANIFEST.MF from Implementation-Version tag.

For BMC Discovery v11.0 onward the pattern distinguishes the clustered and standalone J2EE Applications deployment. Depending on 'deployment' tag of each Application the pattern links it to the respective host Node (SoftwareCluster or SoftwareInstance).

JDBC Resources

Weblogic 9.x and newer

The pattern parses out the list of available JDBC Resources from config.xml file with the help of the following Xpath query:

  • /domain/jdbc-system-resource/name

Then for each found JDBC Resource the pattern makes a checks:

  • the presence of the currently processed server's name in string which represents deployment targets obtained by the following Xpath query:

    • /domain/jdbc-system-resource[name="<jdbc_resource>"]/target

where jdbc_resource is the name of JDBC Resource being checked

  • and the same check for correspondent current server's cluster name found by the following Xpath query:

    • /domain/server[name=<server_name>]/cluster

      where server_name is current server's name


After confirming that this Resourse is available for currently processed server, the pattern will try to obtain the relative path to the file which contains so-called descriptor file - configuration file of this JDBC Resource (as such configurations are external) - with the help of the following Xpath query:


  • /domain/jdbc-system-resource[name="<jdbc_resource>"]/descriptor-file-name

After successful obtaining of descriptor path it's absolute path is obtained from merging Domain config directory path with found relative path. Domain config directory path is found by deploying the following regex on config.xml absolute path (stored as attribute of Weblogic SI):


  • ^(.*)[\\/]config\.xml$

The pattern then will try to read descriptor file and retrieve all necessary information from it - JDBC name using the following regular expression:


  • <jndi-name>(.*?)</jndi-name>

    and JDBC URL:



  • <url>(.*?)</url>

Using this information (JNDI name and JDBC URL) the pattern will model Detail node with type set to "JDBCResource" and name based on found JDBC Resource name and different database parameters populated with data obtained from JDBC URL using the general ADDM JDBC URL parsing function.

For BMC Discovery v11.0 onward the pattern distinguishes the clustered and standalone JDBC Resource deployment. Depending on 'deployment' tag of each JDBC Resource the pattern links it to the respective host Node (SoftwareCluster or SoftwareInstance).

Weblogic 8.x and older

For WebLogic 8.x and older version JDBC Resources in config.xml can be configured as transaction-enabled so the pattern tries two XPath queries:

  • /Domain/JDBCDataSource/@Name
  • /Domain/JDBCTxDataSource/@Name

To check each found JDBC DataStore is deployed on current Server the pattern makes the follwoing checks:

  • for each found JDBC Resource the pattern makes one from two Xpaths queries (depends on the type of JDBC Resource which it gets from previous step - transaction-enabled or regular one):

    • /Domain/JDBCDataSource[@Name="<jdbc_resource>"]/@Targets

      - for usual JDBC Resources



    • /Domain/JDBCTxDataSource[@Name="<jdbc_resource>"]/@Targets

      - for transaction-enabled JDBC Resources


where jdbc_resource is the name of JDBC Resource being checked

  • and the same check for related current server's cluster name found by the following Xpath query:

    • /Domain/Server[@Name=<server_name>]/@Cluster

      - for WebLogic of version 8.x and older
      where server_name is current server's name


After previous check which confirms that processing JDBC Resource is deployed on current server the pattern will get JDNI name from DataSource node and JDBC URL from related JDBCConnectionPool node:

  • JNDI name dependently on the type of DataSource is found by the one from following XPath queries:

    • /Domain/JDBCDataSource[@Name="<jdbc_resource>"]/@JNDIName

      - for usual JDBC Resources



    • /Domain/JDBCTxDataSource[@Name="<jdbc_resource>"]/@JNDIName

      - for transaction-enabled JDBC Resources


  • To obtain JDBC URL firstly we need to get correspondent Pool name and then to parse from that Pool:
    • The pattern obtains Pool name by using the following Xpath query (depends on type again):

      • /Domain/JDBCDataSource[@Name="<jdbc_resource>"]/@PoolName

        - for usual JDBC Resources



      • /Domain/JDBCTxDataSource[@Name="<jdbc_resource>"]/@PoolName

        - for transaction-enabled JDBC Resources


    • Knowing Pool name the pattern looks for JDBC URL by employing the following XPath:

      • /Domain/JDBCConnectionPool[@Name="<pool_name>"]/@URL

Using this information (JNDI name and JDBC URL) the pattern will model Detail node with type set to "JDBCResource" and name based on found JDBC Resource name and different database parameters populated with data obtained from JDBC URL using the general ADDM JDBC URL parsing function.

Java Mail Resources

The list of Mail Resources (Mail Sessions in Weblogic terminology)is obtained from config.xml by using the following Xpath query:


  • /domain/mail-session/name

Then the pattern verify each found Mail resource by checking:

  • if the currently processed server's name is among other deployment targets obtained by the following Xpath query:

    • /domain/mail-session[name="<mail_resource>"]/target


    • /Domain/MailSession[@Name="<mail_resource>"]/@Targets

      - for WebLogic of version 8.x and older
      where mail_session is the name of Mail Session being checked


  • and the same check for current server's cluster name found by the following Xpath query:

    • /domain/server[name=<server_name>]/cluster


    • /Domain/Server[@Name=<server_name>]/@Cluster

      - for WebLogic of version 8.x and older
      where server_name is current server's name


If this Resource's availability for current server is confirmed, the pattern will model a Detail with the correspondent name and the type set to "JavaMailResource".

For BMC Discovery v11.0 onward the pattern distinguishes the clustered and standalone Mail Resource deployment. Depending on 'deployment' tag of each Mail Resource the pattern links it to the respective host Node (SoftwareCluster or SoftwareInstance).

JMS Resources

The list of JMS Resources (Java Message Service in Weblogic terminology) is obtained from config.xml by using the following Xpath query:

  • /domain/jms-system-resource/name

Then the pattern verify each found JMS resource by checking the following Xpath query:

  • /domain/jms-system-resource[name="jms_resource"]/target

and

  • /domain/jms-system-resource[name="jms_resource"]/descriptor-file-name

for JMS Resource descriptor file.

In descriptor files for "connection-factory" and "queue" resources checking the following Xpath query:

  • /weblogic-jms/<resource>/@name

  • /weblogic-jms/<resource>[@name="resource_name"]/sub-deployment-name

  • /weblogic-jms/<resource>[@name="resource_name"]/jndi-name

to get name, sub-deployment-name and jndi-name.

If this Resource's availability for current server is confirmed, the pattern will model a Detail with the correspondent name and the type set to "JMSResource".