Product Description

Oracle WebLogic Server is an enterprise-class J2EE Application server. Oracle WebLogic Server is part of the BEA WebLogic platform and supports Oracle, IBM DB2, Microsoft SQL Server, MySQL and other JDBC-compliant databases.

A domain is the basic administration unit for WebLogic Server. It consists of one or more WebLogic Server instances, and logically related resources and services that are managed, collectively, as one unit.

Editions

The WebLogic Server is shipped in all the bundles listed below; each bundle is defined by licensing or extra features.

WebLogic Platform

Enables full support for WebLogic Server Premium (including WebLogic Workshop), WebLogic Portal, and WebLogic Integration functionality.

WebLogic Server Premium Edition

Enables full support for WebLogic Server functionality including the core Java 2 Enterprise Edition (J2EE) features, and WebLogic Workshop. WebLogic Server Premium Edition provides premium clustering, caching, and messaging.

WebLogic Workshop

Provides a complete development framework for easily building web services applications that automatically leverage the power, reliability, and scalability of WebLogic Server.

WebLogic Portal

Enables full support for WebLogic Portal functionality, which provides a framework for building enterprise portals leveraging campaign, commerce, and personalization services. Includes WebLogic Server Premium.

Further information with regards the identification of Weblogic Portal can be found later in this document.

WebLogic Express Basic Edition

WebLogic Express offers many services and APIs available with WebLogic Server, including WebLogic JDBC features, JavaServer Pages (JSP), servlets, Remote Method Invocation (RMI), and Web server functionality. WebLogic Express differs from WebLogic Server in that WebLogic Express does not provide Enterprise JavaBeans (EJB), Java Message Services (JMS), J2EE CA, WebLogic Workshop, or the two-phase commit protocol for transactions.

WebLogic Express Premium Edition

Enables basic WebLogic Express functionality as described above. Includes premium clustering support.

Aqualogic Service Bus

WebLogic Server is installed as part of a Aqualogic Service Bus deployment, Aqualogic makes use of the Weblogic platform to provide its functionality.

Further information with regards the identification of AquaLogic Service Bus can be found later in this document.

Known Versions

• 5.1
• 6.1
• 7.0
• 8.0
• 8.1
• 9.0
• 9.2
• 10.0
• 10.1
• 10.2
• 10.3
• 11g Release 1 (10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5)
• 12c (12.1, 12.2)

Software Pattern Summary

Platforms Supported by the Pattern

The pattern supports both the Windows and UNIX platforms

Identification

Software Instance Triggers

Software Instance type attributes created

The patterns in this module will set the following attributes:

Software Cluster type attributes created

Simple Identification Mappings

The following components are identified using simple identity mappings. Note that the component is identified by arguments and not by process name.

Obtaining key variables

Obtaining Server name

WebLogic server name is required argument for any Weblogic process and thus can easily be extracted from trigger process command line via the following regular expression:

• '-Dweblogic\.Name="?(\S+?)[\" ]

The WebLogic server name can additionally be obtained from WLS_INST_NAME, a custom command line argument which we have seen in some environments:

• (?i)-DWLS_INST_NAME=(\S+)

Obtaining Domain name

The standard way of obtaining domain name is searching in trigger process's command line for the argument "-Dweblogic.Domain". This is done by running the following regular expression against command line:

• 
  (?i)-Dweblogic\.Domain=(\S+)

The domain name can additionally be obtained from WLS_DOMAIN, a custom command line argument which we have seen in some environments:

• (?i)-DWLS_DOMAIN=(\S+)

Often this can be unsuccessful as needed argument is not found. As it was reported by SME in some environments users use so called "-d" argument for supplying domain and server name to WebLogic process. The format of this argument is the following:

• -d_<domain_name><server_name>

So if the option "Enable parsing of domain information from '-D_<domain><servername>' parameter" is enabled the pattern will try to parse Domain name from trigger process command line via the following regular expression:

• 
  (?:^| )-D_(\w+)%servername%

  where %servername% is WebLogic server name found earlier.

  
  

Obtaining Install Root

Install root is obtained from the trigger process arguments on the UNIX platform or Windows platform (when not running as a Windows service) using the following regular expression:

  (?i)-D(?:wls|weblogic)\.home=(\S+)/server (?i)-Djava\.security\.policy==?(/.*?)(?:/server)?/lib/weblogic\.policy (?i)-Dplatform\.home=(\S+)

  (?i)-Dem\.oracle\.home=(\S+)

When the WebLogic Server is running as a Windows service, the pattern first determines the process arguments by:

1. Mapping the trigger process to the service name under which it is running

2. Obtaining the WebLogic Server arguments using the following registry query: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service_name>\\Parameters\\CmdLine

The result is then parsed using the following regular expression:

• 
  (?i)-Dplatform\.home=(\S+)

Obtaining bea_home

Windows Platforms

The pattern has a privileged command for BEA_HOME extraction if the primary method fails.The command is as follows:  

• "PRIV_CAT %appserv_install%/common/bin/commEnv.sh | grep \"BEA_HOME=\""

If the pattern has triggered off a JAVA process the bea_home and wls_home variables are obtained by parsing the trigger process arguments with the following regular expressions:

• wls_home: -Dplatform\.home=(.*?)\s

• bea_home: -Dplatform\.home=(.*)\\

If the pattern has triggered off the beasvc.exe process (the BEA Windows service), the bea_home and wls_home variables are also obtained using the same regular expressions but the process arguments are obtained using the approach mentioned in the 'Obtaining Install Root' section.

As in many cases ADDM will scan a Windows shortened path, the pattern determines the corresponding full path by executing an Active Command.
Active Command Executed: cmd /c dir /x bea_home

After obtaining the full bea_home path, the pattern parses a file within that path, called registry.xml(or domain-registry.xml for WebLogic installations v12 and later). Version is extracted from that file by parsing it for an installation of WebLogic Server which matches the Installation Directory extracted from the Trigger arguments.

This method will usually return a depth of three levels.

Unix Platforms

Active versioning is performed by looking for and parsing a file called registry.xml which contains version information. It is stored in a directory defined in the variable BEA_HOME. The pattern  has a privileged command execution for BEA_HOME extraction if the primary method fails. The command is as folllows:

• "PRIV_CAT %appserv_install%/common/bin/commEnv.sh | grep \"BEA_HOME=\""

The BEA_HOME variable is obtained by one of the following methods:

• Running grep "BEA_HOME=" <install_root>/common/bin/commEnv.sh

  and parsing the output

  
  

• Parsing the trigger process arguments with regular expression (?i)-Dbea\.home=(\S+)

• Parsing the trigger process arguments with regular expression (?i)-Djava\.security\.policy==?(.*)/server/lib/weblogic\.policy

  , then checking a registry.xml file exists in the extracted directory

  
  

• Parsing the installation root with regular expression ^(.)/*, then checking a registry.xml file exists in the extracted directory

• Parsing the trigger process command with regular expression (?:^|\s|:|=)(/[^ :]*?/bea)/

• Checking standard locations (e.g. /opt/bea, /usr/local/bea) for a registry.xml(or domain-registry.xml for WebLogic installations v12 and later) file - the standard locations are listed and can be updated in the pattern configuration section via the pattern management UI in Atrium Discovery

Obtaining config.xml path

Config.xml file is very important source of information for each WebLogic Server instance. In fact almost all information populated in WebLogic SI except version sometimes and servername is based on this file. That's why the pattern employes many methods in order to get this file. Each method used returnes filename candidates which are added to candidates list to be verified afterwards.

Obtaining config.xml from parent process

Usually WebLogic admin server started by startWebLogic.sh (or startWebLogic.cmd on Windows). If the pattern gets the directory from which that script was lauched it will be possible to construct the path to config.xml file.
That's why firstly the pattern tries to get parent process node for trigger process. If this was successful it tries to parse it's command line using the following regular expressions:

• 
  (/[^ ]*)/bin

  - UNIX platforms

  
  

• 
  (?i)"?(\w:[\\|/](?:[\w\\/])*?)(?:[\\/]bin)?[\\/][^\\/]*\.(?:cmd|bat)"?

  - Windows platform
  If this wasn't successful the pattern for UNIX platform tries (if it's permitted in the pattern's configuration section) to use elevated privileges in order to use one of the following active commands (dependent on the type of OS, adding 'pargs' and/or 'ps' to your sudo configuration file as required) for obtaining "PWD" environment variable which usually holds the path to domain directory:

  
  

  Operating System	Active Command Requiring Elevated Privileges (where %parent.pid% is the PID of the parent process)
  Solaris	pargs -e %parent.pid%| grep -v "OLDPWD"| grep "PWD"
  Linux	ps xew | grep "\s*%parent.pid%"
  AIX	ps axew | grep "\s*%parent.pid%"

  Please note that enablement of elevated privileges usage can help the pattern to find needed info on this step.
  In the end if one of those methods was successful the pattern will add file paths: "<dir>/config.xml" and "<dir>/config/config.xml" to candidates list, where <dir> is the directory path returned by regexp or via environment variable.

Obtaining config.xml from domain-registry.xml

If BEA_HOME was found the pattern tries to read a file called 'domain-registry.xml' which is present in BEA_HOME on WebLogic setups starting from version 10. This file contains the list of installed domains. It is a very good spot for constructing config.xml candidates paths. Domain directories are obtained from <BEA_HOME>/domain-registry.xml file via the following XPath query running against DOM object constructed from domain-registry.xml contents:

• //domain/@location
  After this the pattern will add file paths: "<dir>/config.xml" and "<dir>/config/config.xml" to candidates list, where <dir> is the directory path returned by Xpath query above.

Obtaining config.xml from user defined domain locations Configuration setting

In rare cases WebLogic Server are started with -Dweblogic.Domain argument which tells the name of WebLogic Domain. Using this information if the pattern knows possible directory name relatively to BEA_HOME where domain could be located it would be possible to find needed config.xml. That's why there is Configuration options called "domain_locations_unix" and "domain_locations_windows" which can used for setting paths for directories where all domains are located.
If the pattern found domain name and BEA_HOME is know it will add file paths: "<BEA_HOME>/<dir>/config.xml" and "BEA_HOME>/<dir>/config/config.xml" to candidates list for each <dir> from Configuration option.

Obtaining config.xml from Root Directory

Root Directory (-Dweblogic.RootDirectory) is another argument which not always found in WebLogic command line, despice the fact it could be very helpful for config.xml obtaining. If Root directiry specified then we can try to find copy of config.xml right in it or in it's /config/ sub-directory as for admin server it is the same as config dir by default. For managed servers config.xml can be located in the following places:

• <root_dir>/config.xml
• <root_dir>/config/config.xml
• <parent_of_root_dir>/config.xml
• <parent_of_root_dir>/config/config.xml

That's why the pattern firstly fires the following regular expressions against trigger process command line:

• 
  -Dconfig\.root\.dir="?(/[^\s"]+)

• 
  -Dweblogic\.RootDirectory="?(/[^\s"]+)

  If they successfully return non-empty value the pattern will add all candidates described above to the candidates list.

  
  

Obtaining config.xml from command line

If previous methods failed the pattern will try the "last resort" method of parsing the command line of trigger WebLogic Server process by the following regular expression:

• 
  (?i)(/\S+?/(?:user_projects/)?domains/\w+)

  This method based on assumption that config file may be in dir mentioned somewhere in args which contains '/user_projects/domains/' or '/domains/' directory names. Of course, the WebLogic setup can use another directory names so this method is not very accurate.

  
  

Obtaining config.xml from user defined lists of domain directories(Configuration Options)

This is the last method and it used only in cases all other methods failed because of unusual WebLogic setups or lack of important arguments in command line. This method usually provides very good results because it uses paths that user inputs manually in Configuration section.
There are several Configuration options related to this method:

• Indicates whether user-definable list of WebLogic domain absolute directories paths is enabled - check to enable this method
• WebLogic domain absolute directories paths (UNIX) - the list of absolute WebLogic domain paths on UNIX platform
• WebLogic domain absolute directories paths (Windows) - the list of absolute WebLogic domain paths on Windows platform
• WebLogic domain absolute directories paths using <domain_name> and <server_name> masks(UNIX) - the same lists as above but with items that can be extended by using special masks for domain and servername on UNIX platform
• WebLogic domain absolute directories paths using <domain_name> and <server_name> masks(Windows) - the same lists as above but with items that can be extended by using special masks for domain and servername on Windows platform

For each fully-qualified absolute path in provided list the pattern will add file paths: "<dir>/config.xml" and "<dir>/config/config.xml" to candidates list for each fully-qualified absolute path <dir> in provided list.

In case paths with masks were added the pattern will extend such paths substituing the following masks:

• <domain_name> to domain name if it was found earlier
• <server_name> to servername of WebLogic Server
  In this way it is possible to have shorten the number of needed entries in the usual non-masked list. But please note that in case if <domain_name> mask was used and not domain name obtained - the pattern will have to skip such path.

Versioning

Version information for the product is currently collected using one of four possible methods.

The methods are tried in an order of precedence based on likely success and/or accuracy of the information that can be gathered. Once a result is obtained, the methods lower in precedence are not attempted. In order of precedence the methods are:

Active Versioning

The pattern parses the file <bea_home>/registry.xml for WebLogic versions below 12c with the following xpath:

• 
  /bea-product-information/host/product[@name='WebLogic Platform' or @name='WebLogic Portal']/release/component[@name='WebLogic Server']/@version

or with another xpath expression using the file <bea_home>/inventory/registry.xml for versions 12.2 and above:

• /registry/distributions/distribution[@status="installed" and @name="WebLogic Server" or @name="WebLogic Server for FMW"]/@version

There is a possibility that more than one version of WebLogic is installed under the same $BEA_HOME. We therefore firstly try to find WebLogic Server with install dir which the pattern obtained earlier (if it was able to do this) and get the version from that node. After this the pattern try to ensure that the installation directory parsed from the registry.xml can be matched with part of the server command-line. If this succeeds, the version (if it wasn't found in previous attempt) is looked up in registry.xml.

File Versioning

If the port information wasn't obtained using previous methods and config.xml config file was found, the version is parsed out from its content using the following XPath query:

• /domain/domain-version

This method is actual for WebLogic versions starting from 9 (due to the format of the configuration file).

Path Versioning

The pattern parses the process arguments with the following regular expressions to obtain path versioning

On UNIX:

• /oracle/product/fmw/(\d+(?:\.\d+)*)/

• (?:/bea|weblogic|wls|wlserver)[/_\.]?(\d+(?:\.\d+)*(?:[/_]?sp\d+)?)'

• /(\d+(?:\.\d+)*)[^/]/weblogic

• /products/oracle/wl(\d+)

• /apps/weblogic/\w+/(\d+(?:\.\d+)*)

On Windows

• (?i)\b(?:weblogic|wlserver_)(\d+\.\d+)

• (?i)\bweblogic[/\\]pkg[/\\](\d+(?:\.\d+)*)

• (?i)\\oracle\\product\\fmw\\(\d+(?:\.\d+)*)

The pattern also checks the following special cases on UNIX platfoms:

• If the trigger process arguments contain "/WebLogic11g" or /wlserver/11g", version is 10.3.1
• If the trigger process arguments contain "/WebLogic10/<digit>", version is 10.<digit>
• If the trigger process arguments contant "510sp<digit>", version is 5.1.0.<digit> 

Package Versioning

This method works exclusively on Unix Platoforms. Furthermore, it is only attempted if both active versioning and path regex methods fail.

The package names in the package manager have a number of regexes (i.e. "wls451", "wls452", "WLS51", "wls510", "wls600", "wls610") applied to them and the version information extracted from any that match. If two or more packages match, a Package Preference Algorithm is applied which seeks to discover the package with the lowest preference; the version of the "most trusted" package is returned.

This method has been found to occasionally work but only in some environments and with old versions of WebLogic Server

Application Model Produced by Software Pattern

Product Architecture

It is possible to run multiple instances of Weblogic on a single host. Instances are typically identified through the process argument list as each server is named in the command-line arguments or the process arguments obtained from the Windows Service via registry query and extracted using the following regular expression:

• 
  -Dweblogic\.Name=(\S+)

  - UNIX platforms

  
  

• -Dweblogic\.Name="?(\S+)"?

  - Windows platforms

  
  

Multiple WebLogic Managed Servers can be linked within a cluster. In this case they will have cluster name set for their configuration in config.xml file. Each cluster should have its own unique communication socket (either unicast or multicast).

Software Pattern Model

The trigger process used by the ApplicationServer and ServerWindows patterns in the creation of Oracle WebLogic Server Software Instances (SI) is the Java VM process with 'weblogic.Name', 'WLS_INST_NAME', 'weblogic.management.server', 'weblogic.RootDirectory' or 'weblogic.Server' in its argument list or one of the Windows services, beasvc.exe or beasvcx64.exe.

WebLogicCluster pattern uses an Oracle WebLogic Server software instance (or BEA equivalent) as a trigger. This software instance must have a cluster_communication_socket or cluster_name attribute with domain name set.

SI Depth

By default the ApplicationServer and ServerWindows  patterns produce a Deep (Instance Based) Software Instance for Oracle WebLogic Server. Each WebLogic Server instance that can be uniquely identified will generate a Software Instance in a ADDM model.
The WebLogic Server instance name is used as part of the key to generate a Software Instance and is also stored as the 'server_name' attribute on the SI node.

If value of BEA_HOME was found it is used for creation of the SI key (path is combined with installation path and shortened using an MD5 hash), in conjunction with the application server instance name.
Alternatively, if the value of BEA_HOME is not found, but the installation path has been, the SI key is created using this installation path (shortened using an MD5 hash) in conjuction with the application server instance name.
If those parameters were not found, 'grouped' Software Instance is generated with the key group being made from the following possibilities:

• application server instance name and installation path (shortened using an MD5 hash)
• full version and installation path (shortened using an MD5 hash)
• installation path (shortened using an MD5 hash)
• application server instance name

WebLogicCluster pattern creates an instance-based SoftwareCluster instance which key is based on one of the following:

• If the cluster_multicast_socket attribute exists, this is used in the key
• In second preference, the domain key and cluster name is used in the key

In all cases the key also contains the SoftwareCluster type

Protocol and Port Information

In order to get information described below the pattern needs to get config.xml file and create a DOM object from it's contents in order to run Xpath quieries against it.

The pattern attempts to add domain, cluster, listen address, listen port, ssl listen port, channels, default protocol and default secure protocol information to the Software Instance.

Domain is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/name/text()
• /Domain/@Name

Weblogic can be configured as virtual-host-based setup. Virtual Hosts can be configured in two ways: by specifying server name or server's cluster name as a target. So pattern checks virtual-host deployment targeted to server using xpath below:

• /domain/virtual-hosttarget="%appservername%"/name/text()

Cluster name is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/cluster/text()
• /Domain/Server[@Name="%appservername%"]/@Cluster

Listen address is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/listen-address/text()
• /Domain/Server[@Name="%appservername%"]/@ListenAddress

Default protocol is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/default-protocol/text()
• /Domain/Server[@Name="%appservername%"]/@DefaultProtocol

If unknown, this attribute defaults to 't3'.

Default secure protocol is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/default-secure-protocol/text()
• /Domain/Server[@Name="%appservername%"]/@DefaultSecureProtocol

If unknown, this attribute defaults to 't3s'.

Listen port is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/listen-port/text()
• /Domain/Server[@Name="%appservername%"]/@ListenPort

If unknown, this attribute defaults to '7001' but can be user-defined via the default_listen_port option in the configuration section.

SSL listen port is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/ssl/listen-port/text()
• /Domain/Server[@Name="%appservername%"]/SSL/@ListenPort

If unknown, this attribute defaults to '7002' but can be user-defined via the default_ssl_listen_port option in the configuration section.

If listen port or secure listen port attributes are extracted they are populated within listening_ports attribute.

If listening_ports and listen address are set the pattern combines all pairs of address and ports into listen_tcp_sockets attribute.

The channel names are ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point/name/text()
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint/@Name

Having obtained a list of channel names, additional information for each channel is obtained via a number of further xpath calls:

The protocol used by the channel is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point[name="%channel_name%"]/protocol/text()
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint[@Name="%channel_name%"]/@Protocol

If unknown, this attribute defaults to 't3'.

The address the channel is listening on is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point[name="%channel_name%"]/listen-address/text()
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint[@Name="%channel_name%"]/@ListenAddress

The port the channel is listening on is ascertained by executing the first, and if unsuccessful, the second xpath command below:

• /domain/server[name="%appservername%"]/network-access-point[name="%channel_name%"]/listen-port/text()
• /Domain/Server[@Name="%appservername%"]/NetworkAccessPoint[@Name="%channel_name%"]/@ListenPort

All extracted Channel details are then populated into Channel Detail which is linked to host WebLogic SI.

Cluster Messaging Mode

The cluster messaging mode - either "multicast" or "unicast" (for Oracle WebLogic 10.x+) is obtained via Xpath query executed against XML contents:

• /domain/cluster[name="%cluster%"]/cluster-messaging-mode

where %cluster% here and in examples below is a cluster name obtained earlier

The multicast address is obtained using the following Xpath queries:

• 
  /domain/cluster[name="%cluster%"]/multicast-address/text()

• /Domain/Cluster[@Name="%cluster%"]/@MulticastAddress

The multicast port is obtained using the following Xpath queries:

• /domain/cluster[name="%cluster"]/multicast-port/text()

• 
  /Domain/Cluster[@Name="%cluster%"]/@MulticastPort

Cluster communication address and port are populated as cluster_communication_socket attribute of the SI. Note that if unicast messaging mode is used the pattern obtains the socket details from the related Channel Detail which is used for the communication by the curent WebLogic Cluster.

JMX attributes

Pattern aims to determine whether the discovered Application Server is an Administration server in order to populate JMX port information which can then be used for extended discovery of WebLogic.

JMX port obtaining from trigger process arguments

The first method of obtaining JMX port value is to parse trigger process arguments with the following regular expression:

• -Dcom\.sun\.management\.jmxremote\.port=(\d+)

This value will be used in conjunction with the confirmation that this server is admin server for domain. This confirmation is obtained via config.xml file.

JMX information obtaining from config.xml file

This is performed by analyzing config.xml file from config directory obtained in Protocol and Port Information. The algorithm is as follows - the server is Admin Server when:

• its only one in its domain
• if its name is specified in <admin-server-name> node of config.xml
• it is the first one among other servers within the server list in config.xml and if version of WebLogic Server is 8 or older.

In case the pattern confirms that this instance is Admin Server for domain, it populates the jmx_enabled (with Boolean "true" value) and jmx_port (only if it wasn't not found in the previous step, in this case JMX port will be set the same as "listen_port") attributes.

Heap size

In order to find the value of heap_min_size and heap_max_size attributes pattern parses the trigger process arguments with the following regular expression:

• Xms(\d+\w)
• Xmx(\d+\w)

Weblogic Extended J2EE Discovery

In BMC Discovery (prior to v11.0) populated JMX attributes (in particular: jmx_enabled and jmx_port) are used for Weblogic Extended discovery . Starting from BMC Discovery 11.0 JMX attributes are just populated but aren't used for Extended Discovery any more. The extended J2EE discovery functionality includes approach which uses the WebLogic configuration file - config.xml and by analyzing it models J2EE Applications, Domains, JDBC and Mail Resources. This config-file-based method is fully described here.

Relationship with Oracle Jolt

The pattern checks for the Oracle Jolt Connection Pool information present in the config.xml file. The following Xpath query is used for extracting the information about the Jolt Connection Pool: /Domain/JoltConnectionPool/@PrimaryAddresses /Domain/JoltConnectionPool/@FailoverAddresses

For all the hosts mentioned in the XML, the pattern will search for the "Oracle Jolt Server" Software Instance present on the host and if found create a communication relationship between that SI and the WebLogic SI.

Product Editions and License Information

As mentioned above, WebLogic Server is shipped in a number of different editions. Many components of WebLogic Server are licensable. Editions in essence govern the functionality that has been enabled through licensing. Components may be licensed for different periods of time. If license expires on certain components, WebLogic Server edition changes and this typically degrades some of its functionality.

Parsing the license file

ADDM attempts to determine the product edition by parsing the license file of the WebLogic installation. The license file is called 'license.bea' and it is located in the same directory as registry.xml (i.e. BEA_HOME).

The license file is parsed using the following approach:

1. The pattern ensures that it is parsing the section of the license file that pertains to the installation of WebLogic Server that is running at the pattern triggered on.
2. The pattern then looks for existence of key components in the license file. Presence or absence of these key components determines the edition of the product.
3. The 'expiration' attribute of each of these components is compared with the date stamp from the scanned host to determine whether the component is still licensed. If not, the edition is updated prior to the setting of 'edition' attribute on WebLogic Server SI.

In addition to this, the 'WebLogic' component entry is parsed in detail to determine:

• The license type
• The number of CPUs the license is for
• The licensee
• The number of unique IP addresses that can connect to the server
• License expiry date - This is the expiry date for the 'WebLogic' component - once the license expires for this component the WebLogic Server is not licensed at all

The information obtained from the WebLogic component is displayed on a "License Detail" detail node, attached to the WebLogic Server Software Instance

Editions

ADDM currently identifies the following editions:

• Premium
• Advantage
• Workgroup
• Express Premium
• Express Base

These product editions are common between WebLogic Server versions 8.1, 9.0, 9.2, 10.0, 10.1, 10.2.

Product editions such as Server Process (WebLogic 8.1, 9.0, 9.2), Integration and WebLogic Platform (WebLogic 8.1) are currently identified as Premium edition which they are supersets of.

WebLogic Platform edition (called SDK in WebLogic 9 and 10) can be however deduced from the 'license_type' attribute which will be set to 'SDK'.

A Note on Date Parsing

To get the date from the host we run a command that is dependant on the host operating system, this is required for working out whether license expired:

Unix date command: date '+%Y-%m-%d'

Windows date command: date /T

The three possible formats that we have identified are US style (mm-dd-yyyy) with day name at the beginning, EU style (dd-mm-yyyy) and other (yyyy-mm-dd).

After reviewing all possible locales on a standard Windows XP system we identified that by looking for each of these styles we would cover ~97% of all possibilities.

The following Regular expressions extract the specific date formats:

US date regex: \w{3}\s+(\d+)[/\.-](\d+)[/\.-](\d+)

EU date regex: (\d{4})[/\.-](\d{2})[/\.-](\d{2})Other date regex: (\d+)[/\.-](\d+)[/\.-](\d+)

Additional Products on the WebLogic Framework

WebLogic Portal Installation Detection

WebLogic Portal is installed on top of WebLogic Server (Premium Edition) and provides a framework for building enterprise portals.
As it is not a different product per-se but a framework layer on top of WebLogic Server, the current ADDM functionality allows us to detect its installation but not whether the Portal is actually running.
Portal installation is detected through parsing of registry.xml file for a particular WebLogic Server installation.

There are therefore three possible outcomes when attempting to detect WebLogic Portal installation:

1. registry.xml file parsed, WebLogic Portal installation detected - portal_installed attribute created on the WebLogic SI and set to true.
2. registry.xml file parsed, WebLogic Portal installation not detected - portal_installed attribute created on the WebLogic SI and set to false.
3. BEA_HOME could not be determined and registry.xml file not obtained - the pattern does not create the portal_installed attribute on the WebLogic SI.

AquaLogic Service Bus Installation Detection

In a similar manner to the WebLogic Portal detection, the pattern tries to determine whether AquaLogic is also installed on the platform. It does so by parsing the registry.xml file, residing in the bea_home directory. The pattern will therefore be able to parse the xml file only when it can identify the bea_home directory.

There are therefore three possible outcomes in the identifying of an AquaLogic installation.

1. The registry.xml file is parsed, and AquaLogic is detected. An attribute called aqualogic is added to the SI and set to true.
2. The registry.xml file is parsed, and AquaLogic isn't detected. An attribute called aqualogic is added to the SI and set to false.
3. The registry.xml file isn't parsed and no further attempt at identifying AquaLogic is carried out. An attribute called aqualogic isn't created.

Finally, the pattern checks for the AquaLogic license in the license.bea file. In the event that the license expired, the pattern sets the aqualogic attribute to false.

Workshop Installation Detection

In a similar manner to the WebLogic Portal detection, the pattern tries to determine whether Workshop is also installed on the platform. It does so by parsing the registry.xml file, residing in the bea_home directory. The pattern will therefore be able to parse the xml file only when it can identify the bea_home directory.

There are therefore three possible outcomes in the identifying of a Workshop installation.

1. The registry.xml file is parsed, and Workshop is detected. An attribute called workshop_installed is added to the SI and set to true.
2. The registry.xml file is parsed, and Workshop isn't detected. An attribute called workshop_installed is added to the SI and set to false.
3. The registry.xml file isn't parsed. An attribute called workshop_installed isn't created.

Subject Matter Expertise

Initial information on detection of WebLogic Portal installations and determining WebLogic editions was provided by Andy Key (JPMC).

Testing

We tested the pattern for Oracle WebLogic Server using ADDM record data from Unix hosts (Solaris, Linux) as well as with actual installations (8.1, 9.2, 10.0, 10gR3, 11gR1, 12c) running on Solaris, Linux and Windows.

Information Sources

• WebLogic Server 8.1 License Packages
• WebLogic Server 9.0 License Packages
• WebLogic Server 9.0 License Packages
• WebLogic Server 10.0 License Packages

Open Issues

N/A

['Oracle WebLogic Server',
                                       'BEA WebLogic Application Server']