Oracle WebLogic Server is an enterprise-class J2EE Application server. Oracle WebLogic Server is a 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 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

The platform fully supports WebLogic Server Premium (including WebLogic Workshop), WebLogic Portal, and WebLogic Integration functionality.

WebLogic Server Premium Edition

The server fully supports 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

Weblogic Workshop provides a complete development framework for quickly building web services applications that automatically leverage the power, reliability, and scalability of WebLogic Server.

WebLogic Portal

The 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 regarding identifying the Weblogic Portal is provided later in this documentation.

WebLogic Express Basic Edition

WebLogic Express offers many services and APIs 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

The Premium Edition enables basic WebLogic Express functionality, including premium clustering support.

Aqualogic Service Bus

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

Further information regarding the identification of the AquaLogic Service Bus is provided in this documentation.

WebLogic Node Manager

The Managed Servers in a production WebLogic Server environment are often distributed across multiple machines and geographic locations.

Node Manager is a Java utility that runs separately from WebLogic Server. It allows you to perform common operations tasks for a Managed Server, regardless of location concerning its Administration Server. While the use of Node Manager is optional, it provides valuable benefits if your WebLogic Server environment hosts applications with high availability requirements.

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 a required argument for any Weblogic process and thus can easily be extracted from the 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 that we have seen in some environments:

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

Obtaining domain name

We obtain the domain name from one of the following arguments in the trigger process:

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 expressions:

(?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

For Windows platforms:

The pattern finds wls_home from one of the following arguments in the trigger java process:

• -Dplatform.home
• -Djava.security.policy
• -Dweblogic.home
• -Dwls.home
• -Dem.oracle.home

The pattern finds bea_home from the -Dbea.home argument in the trigger java process. If they do not exist, it assumes bea_home is one directory up from wls_home (e.g. if wls_home is c:\foo\WebLogic then bea_home is c:\foo).

For 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 follows:

• "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 a regular expression (?i)-Djava\.security\.policy==?(.*)/server/lib/weblogic\.policy

  and 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 a significant source of information for each WebLogic Server instance. Almost all information populated in WebLogic SI except version sometimes and server name is based on this file. That's why the pattern employs many methods to get this file. Each method returns filename candidates added to the candidates list to be verified afterward.

Obtaining config.xml from parent process

Usually, the WebLogic admin server is started by startWebLogic.sh (or startWebLogic.cmd on Windows). If the pattern gets the directory from which that script was launched, it will be possible to construct the path to the config.xml file.

That's why firstly, the pattern tries to get the parent process node for the trigger process. If this is successful it tries to parse its command line using the following regular expressions:

• UNIX platforms

(/[^ ]*)/bin

• Windows platform

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

If this is not successful, the pattern for the UNIX platform tries (if permitted in the pattern's configuration section) to use elevated privileges 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:

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 is successful, the pattern will add file paths: "<dir>/config.xml" and "<dir>/config/config.xml" to the candidate's list, where <dir> is the directory path returned by regexp or via an 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 the candidates list, where <dir> is the directory path returned by Xpath query above.

Obtaining config.xml from domain home

If the trigger process arguments reference -Ddomain.home, we check the path referenced there for config.xml.

Obtaining config.xml from user-defined domain locations Configuration setting

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

Obtaining config.xml from Root Directory

Root Directory (-Dweblogic.RootDirectory) is another argument not always found in WebLogic command line, despite the fact it could be beneficial for config.xml obtaining. If the Root directory is specified, then we can try to find a copy of config.xml right in it or in its/config/ sub-directory as for the 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 the trigger process command line: -Dconfig\.root\.dir="?(/[^\s"]+) -Dweblogic\.RootDirectory="?(/[^\s"]+)

If they successfully return a non-empty value, the pattern will add all candidates described above to the candidate's list.

Obtaining config.xml from the command line

If previous methods failed, the pattern would 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 assumes that the config file may be in the dir mentioned somewhere in args which contains '/user_projects/domains/' or '/domains/' directory names. Of course, the WebLogic setup can use other directory names, so this method is inaccurate.

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

This is the last method, and it is used only in cases all other methods fail because of unusual WebLogic setups or a lack of essential arguments in the command line. This method usually provides excellent results because it uses paths that a user inputs manually in the 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 server name 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 server name on Windows platform.

For each fully-qualified absolute path in the 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 substituting 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 order of precedence based on the 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 or /registry/distributions/distribution[@status="installed"]/features/feature/components/component[@status="installed" and @name="oracle.wls.weblogic.sca"]/@version

If registry.xml cannot be found in <bea_home> or <bea_home>/inventory, the pattern checks in <bea_home>/../ and <bea_home>/../inventory

Alternatively, the version may be obtained from the result of the patch inventory command. If you have an Oracle Installer file in a custom location, you would need to add it to the list of custom locations that are available in configuration options.

There is a possibility that more than one version of WebLogic is installed under the same $BEA_HOME. We first try to find WebLogic Server with install dir, which is the pattern obtained earlier (if it could do this), and get the version from that node. After this, the pattern tries 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 the previous attempt) is looked up in registry.xml.

• java -cp /<bea_home>/wlserver/server/lib/weblogic.jar weblogic.version

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 actually for WebLogic versions starting from 9 (due to the configuration file format).

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 platforms:

• 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 Platforms. 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 occasionally worked only in some environments and with old versions of WebLogic Server.

Pattern will also try to set the version based on obtained PSU patch information if available.

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 expressions:

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

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

Multiple WebLogic Managed Servers can be linked within a cluster. In this case, they will have a cluster name set for their configuration in the config.xml file. Each cluster should have its 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 Discovery model.

The WebLogic Server instance name is part of the key to generating a Software Instance and is 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 the 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 conjunction 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

tO 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 the 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

The 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 current WebLogic Cluster.

JMX attributes

Pattern aims to determine whether the discovered Application Server is an Administration server to populate JMX port information.

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 expressions:

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

Weblogic Extended J2EE Discovery

In earlier versions of BMC Discovery, the JMX attributes (in particular: jmx_enabled and jmx_port) were used for Extended Weblogic discovery. From BMC Discovery 11.0, the JMX attributes are populated but are no longer used for Extended Discovery. The extended J2EE discovery uses an approach which analyses the WebLogic configuration file (config.xml) to model J2EE Applications, Domains, JDBC, Mail, and JMS Resources. For more information about the configuration file-based method, see WebLogic Extended J2EE Discovery using configuration file parsing.

Relationship with Oracle Jolt

The pattern checks for the Oracle Jolt Connection Pool information 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 several different editions. Many components of WebLogic Server are licensable. Editions, in essence, govern the functionality enabled through licensing. Components may be licensed for different periods. If the license expires on specific components, the WebLogic Server edition changes, typically degrading some of its functionality.

Parsing the license file

BMC Discovery 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 parses the section of the license file pertaining to the installation of the WebLogic Server that runs at the pattern triggered on.
2. The pattern then looks for key components in the license file. The presence or absence of these key components determines the edition of the product.
3. Each component's 'expiration' attribute is compared with the date stamp from the scanned host to determine whether the component is still licensed. If not, the edition is updated before setting the 'edition' attribute on WebLogic Server SI.

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

• 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

BMC Discovery 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, and 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 editions which they are supersets of.

WebLogic Platform edition (called SDK in WebLogic 9 and 10) can be 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 dependent on the host operating system. This is required for working out whether the 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 for usage but a framework layer on top of WebLogic Server, the current BMC Discovery functionality allows us to detect its installation but not whether the Portal is 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

Similarly to the WebLogic Portal detection, the pattern tries to determine whether AquaLogic is also installed on the platform. It parses 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 identification 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 is not detected. An attribute called aqualogic is added to the SI and set to false.
3. The registry.xml file is not parsed, and no further attempt at identifying AquaLogic is carried out. An attribute called aqualogic is not created.

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

Workshop Installation Detection

Similarly to the WebLogic Portal detection, the pattern tries to determine whether Workshop is also installed on the platform. It parses 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.

Therefore, there are three possible outcomes in identifying 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 is not detected. An attribute called workshop_installed is added to the SI and set to false.
3. The registry.xml file is not parsed. An attribute called workshop_installed is not created.

Information Sources

For more information about the described product, see the following official documentation:

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