Running the Oracle WebLogic Server

3 Running the Oracle WebLogic Server

Oracle Communications MetaSolv Solution (MSS) provides several means of monitoring and maintaining the product at its intended capacity. For instance, regularly monitoring log files can assure continued high performance. Other normal maintenance tasks are required when changes or problems occur. This chapter provides detailed instructions about the following:

Starting and stopping the MetaSolv Solution application server
Managing the MetaSolv Solution log files
Monitoring the client logons
Managing the Oracle WebLogic server
Resetting the server-to-database connections

When tuning the Oracle WebLogic server, refer to "Oracle WebLogic Server Configuration Settings" for suggested settings.

When changing hardware, refer to the MetaSolv Solution Planning Guide for recommendations.

Starting and Stopping the MetaSolv Solution Application Server

The MetaSolv Solution database and servers should always be up and running, ready for access by clients. Shutdown should occur only during normal system maintenance.

Components must be started in the following order:

Database
Application server
MetaSolv Solution client

After the database is up and running, use the MetaSolv Solution start script to start the Oracle WebLogic server. The script sets values for arguments and provides the settings required to make the Oracle WebLogic server start successfully.

The start scripts are located in the domain directory. The script name includes the server name. For example, if a server is named MSLV01, it will have a start script named startMSLV01.sh in the domain directory.

Note:

If you change the HTTP port for the server process (using the Oracle WebLogic domain wizard) without reinstalling MSS, you must also change it in the start script for the server process.

To start MetaSolv Solution with a script:

MetaSolv Solution provides scripts to start a server. Use the following command depending on which type of machine you are using:

For UNIX/Linux:

./startMSLVServer.sh <server_name><host_admin_URL>

For Windows:

startMSLVServer.cmd <server_name><host_admin_URL>.

Use the following as the admin URL argument:

http://host_name:admin_port

Use the following as the admin URL argument when using SSL port:

https://host_name:admin_sslport

Note:

To start or stop the administration server and managed servers (in a cluster environment) using the SSL port, you must add an s after http in the ADMIN_URL argument in the startup/stop server scripts for the administration server and for each managed server. For example:

https://host_name:admin_sslport

If running in a cluster environment:

After managed servers are started, the Admin server can be shut down to release resources that the process would otherwise consume. However, the Admin server must be running to allow access to the Administration Console or to perform any administrative function.

To stop MetaSolv Solution with a script:

MetaSolv Solution provides scripts to shut down a server. Use the following command depending on which type of machine you are using:

For UNIX/Linux:

./stopMSLVServer.sh <server_name><host_admin_URL>

For Windows:

stopMSLVServer.cmd <server_name><host_admin_URL>.

Use the following as the admin URL argument:

http://host_name:admin_port

Use the following as the admin URL argument when using SSL port:

https://host_name:admin_sslport

Managing the Oracle WebLogic Server

The Oracle Administration Console is an administrative tool for managing resources, including such tasks as starting and stopping servers, balancing the load on servers or connection pools, tuning and monitoring the configuration of resources, detecting and correcting problems, monitoring and evaluating system performance, and making sure the application is correctly deployed to the target servers or to a cluster.

See the WebLogic Server documentation for more information.

See "Delivering File Changes" for specific configuration and tuning recommendations for MetaSolv Solution and the WebLogic Server. You can access the Oracle WebLogic server using a Web browser at:

https://host:port/console

Where:

Host is the name of the administration server machine.
Port is the administration server port number.

Note:

Oracle recommends that you access the WebLogic Server using Hypertext Transfer Protocol Secure (HTTPS).

Or you can use the MetaSolv Solution Runtime page link to the WebLogic Administration Console. This link appears on the Runtime Page drop-down. "Getting Oracle WebLogic Server Runtime Information" for details about the Runtime page.

The Administration Console manages the following WebLogic Server tasks:

Configuring the server
Tuning the Oracle WebLogic server
Debugging and monitoring
Deployments
Managing WebLogic logs
Monitoring Oracle WebLogic server performance
Executing queues
Managing database connections
Managing Oracle WebLogic security

Follow directions in the Oracle documentation to perform specific WebLogic tasks. Follow instructions in the MetaSolv Solution Installation Guide regarding basic Oracle WebLogic settings before making changes.

Getting Started with the Administration Console

The Administration Console is a web application that is used to access the management resources.

After starting the Administration server, you can start the Administration Console by using the following procedure.

To start the Administration Console:

From your browser, type the following URL:
```
http://host_name:port/console
```

The value of host_name is the DNS name or IP address of the Administration server. The value of port is the address of the port on which the Administration server is listening for requests.

When started, the Administration Console prompts for a password. The first time the Administration Console is started, you can use the user name and password under which the Administration server was started. The Administration Console appears.

Note:

The Administration server must be running before you can use the Administration Console.

Among the key tasks you will perform using the Administration Console are:

Managing WebLogic logs
Executing queues
Managing database connections
Monitoring the Oracle WebLogic server through the Runtime page

Note:

See "Delivering File Changes" before making any changes to the number of threads.

Getting Oracle WebLogic Server Runtime Information

The MetaSolv Solution Runtime page provides detailed Oracle WebLogic server information. It also provides links to important administrative tools that provide specialized information.

To view the Runtime Information page:

Enter the following in your Web browser:
```
http://host_name:port/main
```
Note:

If you start the Administration server using Secure Socket Layer (SSL), you must add an s after http. For example:
```
https://host_name:port/main
```
The Runtime Information page is displayed.

Server Details

The MetaSolv Solution Appserver Runtime page provides a detailed snapshot of an Oracle WebLogic server, providing details about the following:

Client Information
Enterprise Archive (ear) Version
Server Information
WebLogic Server instance
URL
Stored Procedures with Invalid Version (if any)
JAR file information
Classpath JARs
Java System Properties

Links to Administrative Tools

You can select Link to the Administration Console from the Runtime page drop-down list to open the WebLogic Administration Console.

You can view a runtime page for each server in your MetaSolv Solution configuration. The information in each report should be the same. If it is not, the Oracle WebLogic server in your MetaSolv Solution system are out of sync and you may need to re-install the product.

Managing MetaSolv Solution Log Files

MetaSolv Solution provides three consolidated log files for all modules. When system or user errors occur, you can review a file and discover the source of the problem.

Table 3-1 describes the log files.

Table 3-1 Log Files

File name	Purpose
appserver.log	System-wide log file.
appserverlog_misc.log	Miscellaneous catch-all log file. This file traces any activity not specified for `APPSERVERLOG`. It can also be used as an extra log file when troubleshooting, one for which you can set different specifications.
appserver_audit.log	This file contains the records of log on and log off activities, and includes successful and failed client logon attempts. Each attempt to log on is recorded, whether it is successful or not. Since, the audit log file contains the logon and logoff information only, a large archive can be maintained for longer periods of time than when using appserver.log. The appserver_audit.log configuration is independently controlled from the main log file's configuration (using the appserverAuditLog appender of loggingconfig.xml).

Table 3-2 describes each field of the appserver.log and appserverlog_misc.log log files.

Table 3-2 MetaSolv Solution Log File Fields

Field	Description
appServerName	Application server where the event occurred.
className	Name of the JAVA class logging the message. This is typically where the problem occurred. If a developer has not specified this field, it appears as an indeterminate "DEF_CLASS." Note: Provide this information if working with Oracle Global Customer Support.
debugCode	A message may simply contain a zero or an arbitrary number for this debug code.
Events	Occurrences of log messages that meet the criteria specified.
Level	Severity of the event. Severity levels are: Alert, Fatal, Error, Warning, Performance, Info, and Debug. (Performance is not currently in use.)
machineName	Identifies the hardware.
Message	Information provided about the event.
messageID	A unique ID for the message that may be useful if working with Oracle Global Customer Support.
moduleName	Specifies the product module in which the event occurred, such as PSR, Security, etc. Audit file logs occur only with the Security module.
productName	MetaSolv Solution.
thread	Debugging aid for internal development.
Time	Time the event occurred.
userName	Identifies the user associated with the event.

Archiving the Log Files

When a MetaSolv Solution log file reaches the maximum size specified in loggingconfig.xml, it is automatically archived. The default size is 10 MB. The ten newest archived log files are maintained and older files are automatically deleted. As each log file is archived, the older files are renamed.

When a log file is archived, MetaSolv Solution appends a number to the file. The lowest number is the newest file. For instance, your company's three newest archived log files are named:

appserver.log.1 (Newest archive)
appserver.log.2
appserver.log.3 (Oldest archive)

Changing the Log File Location

The main logging directory to which log files will be written is specified in the start script startMSLVmanaged.sh or startMSLVsingle.sh in the domain directory. This value is determined by the mslv.log.dir setting specified in this script. By default this value will be set to the appserver/logs directory under each server's installation directory.

You can modify the mslv.log.dir value in the startMSLVmanaged.sh or startMSLVsingle.sh script after the installation is completed.

The new value must point to a directory, where the Oracle WebLogic server has permission to create and delete log files.

Setting the Logging Configuration Parameters

When troubleshooting, you can change the settings in the logging configuration files loggingconfig.xml and mslvloggingconfig.xml so that more or less information is captured in the log file for any given module of the software.

To set the loggingconfig.xml and mslvloggingconfig.xml parameters:

Access the loggingconfig.xml file in the Oracle WebLogic server config folder.
Make a backup copy.
Make any necessary parameter changes using any text editor.

For UNIX/Linux, a vi, emacs or /usr/dt/bin/dtpad editor may be used.

On the Windows platform, Notepad or WordPad may be used for this purpose.
Repeat the steps from 1 to 3 to modify the parameters in mslvloggingconfig.xml.

Most parameters in appserver.log should not be changed, and are reserved for error situations that may require assistance from Oracle Global Customer Support. However, as you encounter system or user problems in day-to-day operations, you will want to reset some parameters so you can screen for specific information.

The logging configuration files consist of several sections, listed in "Table 3-3" and "Table 3-4".

Table 3-3 loggingconfig.xml Sections

Section	Description and parameters
Logging File specification and configuration	Describes whether log file information is appended or written over, log file size, archiving specifications. See "Table 3-5" for information about editable parameters.
Category	Modules and components for which event levels can be set. Valid levels are fatal, error, warn, info, and debug in decreasing order of severity. See "Table 3-6" for a complete list.

Table 3-4 mslvloggingconfig.xml Sections

Section	Description and parameters
Message Resourcebundles specification	Defines the resource bundle names and their locations in the JAVA library packages. This section must never be modified unless instructed by Oracle Global Customer Support.
Pluggable interface specification	Implementation classes for the logging framework. This section must never be modified unless instructed by Oracle Global Customer Support.
SQL Tracing configuration	Captures SQL debugging messages when JDBCTrace module's debug value is also set to "on." Only one parameter can be changed: <param value="off" name="debug"/>
Row Retrieval Specification	Defines the number of rows that a user is allowed to retrieve and describes the threshold for the "too-many-rows" alert. The two parameters are: <param value="32000" name="query-results-row-limit"/> <param value="20000" name="too-many-rows-alert-threshold"/>

Editable Logging File Specifications

The following table describes the editable logging file specifications that can be changed. Locate the listed keyword in the file and edit the parameters shown. Only the following log files can be edited:

appserver.log
appserverlog_misc.log
appserver_audit.log

The last section of the loggingconfig.xml file lets you specify the level at which you want to trace events for each category.

Table 3-5 lists the logging file editable specifications.

Table 3-5 Logging File Editable Specifications

Keywords to search	Editable Logging File Specifications
RollingFile name="appserverLog"	<RollingFile name="appserverLog" fileName="${sys:mslv.log.dir}/appserver.log" filePattern="${sys:mslv.log.dir}/appserver-%i.log"> <PatternLayout> <pattern>%d{MM-dd-yyyy HH:mm:ss,SSS}\|%p\|%m%n</pattern> </PatternLayout> <Policies> <SizeBasedTriggeringPolicy size="10 MB" /> </Policies> <DefaultRolloverStrategy max="10"/> </RollingFile>
RollingFile name="appserverAuditLog"	<RollingFile name="appserverAuditLog" fileName="${sys:mslv.log.dir}/appserver_audit.log" filePattern="${sys:mslv.log.dir}/appserver_audit-%i.log"> <PatternLayout> <pattern>%d{MM-dd-yyyy HH:mm:ss,SSS}\|%p\|%m%n</pattern> </PatternLayout> <Policies> <SizeBasedTriggeringPolicy size="10 MB" /> </Policies> <DefaultRolloverStrategy max="10"/> </RollingFile>
RollingFile name="appserverMiscLog"	<RollingFile name="appserverMiscLog" fileName="${sys:mslv.log.dir}/appserverlog_misc.log" filePattern="${sys:mslv.log.dir}/appserverlog_misc-%i.log"> <PatternLayout> <pattern>%d{MM-dd-yyyy HH:mm:ss,SSS}\|%p\|%m%n</pattern> </PatternLayout> <Policies> <SizeBasedTriggeringPolicy size="10 MB" /> </Policies> <DefaultRolloverStrategy max="10"/> </RollingFile>

Keywords to search

Editable Logging File Specifications

RollingFile name="appserverLog"

<RollingFile name="appserverLog" fileName="${sys:mslv.log.dir}/appserver.log" filePattern="${sys:mslv.log.dir}/appserver-%i.log">             
            <PatternLayout>
                <pattern>%d{MM-dd-yyyy HH:mm:ss,SSS}|%p|%m%n</pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="10 MB" />
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>

RollingFile name="appserverAuditLog"

<RollingFile name="appserverAuditLog" fileName="${sys:mslv.log.dir}/appserver_audit.log" filePattern="${sys:mslv.log.dir}/appserver_audit-%i.log">             
            <PatternLayout>
                <pattern>%d{MM-dd-yyyy HH:mm:ss,SSS}|%p|%m%n</pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="10 MB" />
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>

RollingFile name="appserverMiscLog"

<RollingFile name="appserverMiscLog" fileName="${sys:mslv.log.dir}/appserverlog_misc.log" filePattern="${sys:mslv.log.dir}/appserverlog_misc-%i.log">             
            <PatternLayout>
                <pattern>%d{MM-dd-yyyy HH:mm:ss,SSS}|%p|%m%n</pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="10 MB" />
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>

Table 3-6 lists the available modules for setting trace levels.

Note:

Do not keep event severity levels at Info or Debug level during normal operations. Doing so would cause all events to be logged. Logging all events can have an adverse impact on system performance.

Table 3-6 Logging Categories

Category	Description or Direction
CaCache	Custom attributes (CAs) are characteristics end users can define generically and associate with network templates, element types, connection types, connection specifications, network systems, and allocations of connections or elements within a system.
DLR	Oracle's software supports two types of design layout reports (DLRs): Internal DLRs (also known as on-net, or outbound, DLRs) External DLRs (also known an off-new, or inbound, DLRs) Internal DLRs have always existed for circuits designed in Oracle's software and have been referred to merely as DLRs. The external DLR process begins when a customer sends a service request to a provider requesting the use of part of their network for designing connections. The provider receives the service request and sends the customer a firm order confirmation (FOC) to verify the service request. See the Help for more information.
DLR_Equipment	When users edit equipment or equipment specifications, or move equipment with assigned connections, the design layout records (DLRs) for those connections are reconciled to reflect the change - including pending assignments. See the Help for more information.
DLR_NGN_Activation	References NGN activation. See the Help for more information.
DLR_Circuit	References DLR circuits. See the Help for more information.
EventServer	For MetaSolv Solution internal use only. Use the default settings.
Event2Server	For MetaSolv Solution internal use only. Use the default settings.
Framework	MSS internal framework code that is used/depended on extensively by the other modules. This consists of logging, security, and desktop portlet related logging.
Framework.Cache	MSS internal framework code that specifically deals with database query caching.
GLR	GLR is a generic term used to refer to the Graphical Layout Record. The GLR provides information about a specific virtual connection, such as administrative information, design lines, and a graphical-view of the design. The report is generated from Connection Design.
invFromPB	For MetaSolv Solution internal use only. Use the default settings.
Infrastructure	Refers to application startup settings listed on the GUI navigation bar.
Infrastructure_NetworkLocation	Refers to Network Location settings in the GUI.
INTEGRATION_CONVERSION	For MetaSolv Solution internal use only. Use the default settings.
WORK_MANAGEMENT_CONVERSION	For MetaSolv Solution internal use only. Use the default settings.
INTEGRATION_EVENT_SERVER	For MetaSolv Solution internal use only. Use the default settings.
INTEGRATION_MANAGER	For MetaSolv Solution internal use only. Use the default settings.
Integration.API	This exists to log the messages regarding Web Services.
JDBCTrace	The module which logs the SQL statements before they are run for D/B bound operations.
LSR	Local Service Requests are managed by the LSR software and referenced by MetaSolv Solution.
MSLVSessionBean	This exists to log all the entry and exit messages regarding the invocations of various methods in all Stateless Session type Enterprise Java Beans in the MSS application.
NetworkManagement	For MetaSolv Solution internal use only. Use the default settings.
NetProv	For MetaSolv Solution internal use only. Use the default settings.
NetProv_Plant	For MetaSolv Solution internal use only. Use the default settings.
NetProv_Activation	For MetaSolv Solution internal use only. Use the default settings.
NI	For MetaSolv Solution internal use only. Use the default settings.
PSR	PSR provides service request tracking and provisioning functionality for products defined in the product catalog.
E911	E911 functionality lets a user enter and maintain detailed information about a telephone number and its service location.
CNAM	Caller Name identification (CNAM) lets users view the calling name and telephone number of a caller on a caller ID display panel.
LIDB	Line Information Database (LIDB) lets users place restrictions on third-party calls.
PSRAncillary	For MetaSolv Solution internal use only. Use the default settings.
PSREUB	PSR End User Billing extracts billing information from the order to pass to an end user billing interface.
Security	For MetaSolv Solution internal use only, if requested by Global Customer care. Use the default settings.
SYSTEM	MetaSolv Solution startup and shutdown and DB initialization module related logging.
TEST	For MetaSolv Solution internal use only. Use the default settings.
TimedEventProcess	For MetaSolv Solution internal use only. Use the default settings.
TMS	For MetaSolv Solution internal use only. Use the default settings.
TroubleBatchWorkerThread	For MetaSolv Solution internal use only. Use the default settings.
KeepAliveTroubleBatch	For MetaSolv Solution internal use only. Use the default settings.
WDI	For MetaSolv Solution internal use only. Use the default settings.
WM	For MetaSolv Solution internal use only, if requested by Global Customer care. Use the default settings.
WM_TskSv	For MetaSolv Solution internal use only, if requested by Global Customer care. Use the default settings.

Sample Log File Messages

The following sample log files can be reviewed to find the source of the problem, when there is an error.

The appserver_audit.log log file contains the following information for the user login and log out:

09-28-2022 11:36:11,955|INFO|[appServerName :: DEF_APPSERVER][userName :: ASAP][machineName :: cagbu-phx-10][productName :: nur][debugCode :: 0][moduleName :: cmm.Security][messageID :: 0001][className :: DEF_CLASS]::Login detected for ASAP.::User has signed on.::None.::
09-28-2022 11:36:12,034|INFO|[appServerName :: DEF_APPSERVER][userName :: ASAP][machineName :: cagbu-phx-10][productName :: nur][debugCode :: 0][moduleName :: cmm.Security][messageID :: 0002][className :: DEF_CLASS]::Logout detected for ASAP.::Logout by user or Client disconnected.::None.::

The appserver_audit.log log file contains the following information for an incorrect password:

09-28-2022 22:03:40,673|WARN|[appServerName :: DEF_APPSERVER][userName :: ASAP][machineName :: cagbu-phx-10][productName :: nur][debugCode :: 0][moduleName :: cmm.Security][messageID :: 0003][className :: DEF_CLASS]::Login attempt failed for ASAP. Exception: ORA-01017: invalid username/password; logon denied
::Invalid username and/or incorrect password.::Please supply correct user/password.::

The appserver.log log file contains the following message if the MSS version of the client and server software are different:

09-22-2022 10:45:34,798|ERROR|[appServerName :: DEF_APPSERVER][userName :: ASAP][machineName :: cagbu-phx-10][productName :: nur][debugCode :: 0][moduleName :: cmm.invFromPB][messageID :: 10122][className :: DEF_CLASS]::The server encountered the following Error: Software versions do not match. Client=6.3.1.522 Server=6.3.1.526::The server encountered the following Error:::The server encountered the following Error:::