Native Install

Native Installation
Oracle Utilities Application Framework

OR ACLE WHITE P APER | APRIL 2016 (4.3.0.2.0)
Table of Contents
Introduction 3
Overview of installation 4
Installation Preparation 6
Oracle WebLogic Installation 6
Domain Creation 7
Administration Server Setup 10
Optional: Enabling console as Autodeployed 13
Product Installation Preparation 14
Altering an Embedded installation 14
Installation of Product 15
Parameters to use in Native installation 15
Native Installation Process 16
Setup Server And Machine 17
Setup Node Manager 18
Setup Machine Definition 18
Setup Server Definition 20
Setting Memory Requirements 22
Additional Parameters 24
Inbound Web Services Parameters 25
Setting COBOL Library Path 25
Setting Additional Java Classes 26
Set SPLEBASE Location 28
1 | Native Installation - Oracle Utilities Application Framework

Create XML Registry 29
XML Registry for AIX Platforms 31
Using the setUserOverrides facility 32
Optional: Creating a Data Source 33
Create Security Definitions 33
Altering the Security Domain 35
Optional: Alter Password Validation routine 37
Create JNDI User 38
Create SYSUSER User 42
Product Deployment 45
Deploy SPLService 45
Deploy SPLWeb 51
Deploy Inbound Web Services 57
Operations in Native Mode 57
Starting/Stopping the Server 57
Redeployment of EAR files 59
Appendices 61
SPLWeb JTA Timeout 61
Creating boot.properties 62

Introduction
This whitepaper outlines the process to install and deploy Oracle Utilities Application Framework product natively
within Oracle WebLogic.
By default, Oracle Utilities Application Framework uses Oracle WebLogic in embedded mode. This means the
Oracle WebLogic installation is essentially pointed to the Oracle Utilities Application Framework product installation
and the executable of Oracle WebLogic are only used to execute the code. This has the advantage of being simple
and quick to implement with the Oracle Utilities Application Framework generating a simple configuration for Oracle
WebLogic to use. The disadvantages of this approach is that if you wish to use advanced facilities of Oracle
WebLogic then you will have to manually edit configuration files (to create user exits) and using clustering is much
harder.
To take full advantage of Oracle WebLogic it is best to use the Oracle Utilities Application Framework in native mode
within Oracle WebLogic. This deploys the Oracle Utilities Application Framework J2EE components within Oracle
WebLogic, as you would with other J2EE applications, to allow Oracle WebLogic to manage the product natively.
Note:
For publishing purposes, the word "product" will be used to be denote all Oracle Utilities Application
Framework based products.
Note:
This whitepaper applies to Oracle Utilities Application Framework V2.2 and above with instructions for specific
versions of Oracle Utilities Application Framework.
Note:
This whitepaper uses Oracle WebLogic Enterprise Edition 10.3.6 as its minimum version. Older versions of
Oracle WebLogic may require additional effort.
Note:
This whitepaper will outline the minimum steps required to install the product within Oracle WebLogic.
Additional steps can be performed if additional settings are required to support your site preferences.
Note:
The examples in the whitepaper are for illustrative purposes only and should not be used as the only settings
to use in your installation.
Note:
For customers wishing to use the clustering aspects of Oracle WebLogic refer to the Implementing Oracle

ExaLogic and/or Oracle WebLogic Clustering (Doc Id: 1334558.1) whitepaper available from My Oracle
Support.
Note:
This whitepaper will use the native facilities of Oracle WebLogic but the same process can be performed
using Oracle Enterprise Manager or Oracle Fusion Middleware Control.
Overview of installation
To use the native facilities of Oracle WebLogic from an Oracle Utilities Application Framework based product,
requires the product to deployed within Oracle WebLogic. By default, Oracle WebLogic is used in embedded mode
which has limitations such as:
» The product is deployed with the Administration Server which is typically not recommended by most Oracle
WebLogic Administrators.
» The templates generated by the installation of the embedded mode recreate the Oracle WebLogic configuration
files and any changes to these file require user exits or manipulation of templates to retain changes across
upgrades.
» Implementation of clustering and managed servers requires manual changes to configuration files which can be
complex and can cause issues if incorrectly specified.
» Certain parameters within the domain are hardcoded for quick installation which can sometimes conflict with site
standards. For example, the domain name is set to splapp.
The implementation of the product in native mode removes these restrictions.
Note:
Whilst these limitations exist, they are typically not issues for non-production environments. The embedded
mode of Oracle Utilities Application Framework can be used for non-production. The use of embedded mode
is recommended for environments where expanded mode is required for development purposes to reduce the
need for EAR file builds.
Note:
Variables in this document refer to the settings specified in the ENVIRON.INI for the environment.
To use the Oracle Utilities Application Framework product in native mode within Oracle WebLogic the following
process typically needs to be performed:
» Oracle WebLogic needs to be installed. This can be the default installation as documented in the Oracle
WebLogic installation documentation.
» The Oracle Utilities Application Framework based product needs to be installed in a basic format (or a full
embedded install) with specific settings to enable native mode.
» Some infrastructure needs to be setup within Oracle WebLogic to accept the product. Typically this was done by
the installer in embedded mode but must be performed manually to prepare Oracle WebLogic for the installation.
This process requires a minimum number of steps to setup Oracle WebLogic for the product.

» The Oracle Utilities Application Framework based product must be deployed using the Oracle WebLogic console,
Oracle Fusion Middleware console or Oracle Enterprise Manager.
A figure of the whole process is shown below:
Native Installation
Oracle WebLogic Installation
Install Oracle WebLogic
Create Domain
Create AdminServer
Product Installation
Install OUAF
Install Product
Native Installation
Setup Server/Machine
Set SPLEBASE location
Create XML Registry
Create Security
Deploy Product
Figure 1 – Native Installation process
The process can be summarized as follows:
» Install Oracle WebLogic as per the Oracle WebLogic Installation Guide according to your sites preferences.
» Create a Domain using the Domain Wizard or Oracle Enterprise Manager.
» Create an Administration Server to perform the configuration and deployment activities from.
» Install the product (or alter an existing installation) using the standard installation process outlined in the product
installation documentation with a few key parameters set to prepare the installation for deployment. During this

process a number of key parameters must be noted to specify in the configuration of servers and settings within
Oracle WebLogic.
» Configure Oracle WebLogic using the Administration console to prepare for the product deployment.
» Setup a Server to hold the product with an associated machine within Oracle.
» Set the location of the base software install to be used at runtime.
» Setup the XML Registry to be used by the product for XML processing.
» Setup the security parameters for the product. This includes the security group, JNDI user and initial user to
access the product.
Note:
The above steps are also available via the Domain templates available with Oracle Utilities Application
Framework V4.3.0.2.0 and above.
» Deploy the product to Oracle WebLogic using the Administration console.
» Deploy the Business Application Server to Oracle WebLogic.

» Deploy the Web Application Server to Oracle WebLogic.
» Deploy the Inbound Web Services deployment to Oracle WebLogic.
Installation Preparation
Before performing the native installation the Oracle WebLogic software must be installed, a domain created and an
administration server configured to complete the rest of the installation. The installation of these elements is as per
the Oracle WebLogic installation documentation.
Oracle WebLogic Installation
Note:
Oracle Coherence is not required for Oracle Utilities Application Framework online as it is already bundled for
the batch component. The examples in this document include Oracle Coherence for the default installation.
To install Oracle WebLogic you must ensure the software is downloaded and the appropriate version of java is
installed to start the installation process. For example:

Figure 2 – Oracle WebLogic Installation options
Note:
The options above outline the default installation for Oracle WebLogic. For the minimum installation
requirements refer to the product installation guides.
Domain Creation
The step after the Oracle WebLogic software is installed on the server is to create a domain to house the product
and at least one administration server per domain. This can be achieved using the WebLogic Configuration Wizard
(config.cmd/config.sh) in WL_HOME/common/bin. For example:
Figure 3 – Create Oracle WebLogic domain
Select the Basic WebLogic Server domain to support the deployment of the Administration Server and the product.
For example:

Figure 4 – Basic Oracle WebLogic domain
Note:
Customers using Oracle Utilities Application Framework V4.3.0.2.0 and above may use the Domain templates
provided in the installation to shortcut our domain configuration.
Choose a name for the domain and specify the location of the domain (usually the default is sufficient) according to
your site requirements. The example below uses ouaf_domain as the domain name but the name can be any valid
domain name (according to the Oracle WebLogic domain naming conventions). For example:
Figure 5 – Oracle WebLogic domain name

Specify the default user you wish to use for administration of the domain. This user is used to initially create and
load the domain and is used as credentials for the starting and stopping the domain1. For example:
Figure 6 – Oracle WebLogic domain Administration account.
The next step is to specify the startup mode of deployment and the JDK to use for the runtime of the servers. There
are a number of recommendations on this screen to consider:
» Oracle WebLogic ships with its own JDK but that can be overridden by setting the JAVA_HOME environment
variable prior to running the wizard. You can also manually specify a newer JDK using the Other JDK
functionality.
» The mode defaults to Development which allows deployment and has simple startup facility. This is
recommended for the majority of product environments. Refer to Oracle WebLogic documentation for a
discussion about Server modes.
Note:
If using Production Mode, instructions on creating a Boot Identity File is contained in the Appendix of this
document.
For example:
1 It is possible to change this value post release. Refer to the Oracle WebLogic documentation for more details of this process.

Figure 7 – Oracle WebLogic domain Server Startup Modes.
The next step is to create an Administration Server using the Wizard.
Administration Server Setup
Administration of the domain is typically performed via the Administration Server2 which needs to be deployed to the
domain. The Configuration Wizard can create and deploy the Administration Server to the domain. This can be
done as part of the domain creation or after the domain creation by extending the domain. To create and deploy the
Administration Server select the Modify Settings Administration Server option. For example:
2 It is possible to use WLST to manage the domain but the Administration Server is the most common method.

Figure 8 – Create Administration Server
Specify the Server Name, Listen Address and Listen Port. If you are using SSL then the SSL basic configuration is
performed at this time.
Note: Do not specify the WEB_WLPORT or WEB_WLSSLPORT from the product installtion in the Listen Port or SSL
Listen Port respectively. These will be used later in the server creation. Ideally this should be set to
WLS_ADMIN_PORT.
For example:
Figure 9 – Configure Administration Server
A confirmation screen will be shown to display the values specified. For example:

Figure 10 – Summary of domain and Administration Server
The domain and Administration Server are created. After the process is completed the product summary with
relevant URL's is displayed. For example:

Figure 11 – Completion of Domain Creation and Administration Server deployment
Optional: Enabling console as Autodeployed
The default installation of Oracle WebLogic will only deploy the console on demand when it is requested by the first
user. Whilst this saves on startup time, it can delay administration tasks. If this is an issue it is recommended to
configure the Administration Server to autodeploy the console (and other internal applications) as part of the server
startup.
This can be achieved using the following process:
» Open the Oracle WebLogic console using an Administration account.

» Navigate to the domain in the Domain Structure.
» Navigate to the Configuration  General tab.
» Uncheck the Enable on-demand deployment of internal applications to autodeploy the console and other internal
applications used by Oracle WebLogic. For example:

Figure 12 – Auto-deployment of console
» Save the changes to the Domain.

» Optionally, restart the Domain to test the change.
Everytime the server or domain is started the console will be available immediately rather than waiting for
deployment to be completed.
Product Installation Preparation

Prior to deploying the product to Oracle WebLogic the Oracle Utilities Application Framework and the Oracle Utilities
Application Framework based product must be installed in a location that will be able to be deployed from and
execute the product.
Note:
For licensing reasons, Oracle Utilities Application Framework and Oracle Utilities Application Framework
based products MUST be installed on ALL servers that it will be executed against. For details of additional
step involved in using clustering features, refer to the Implementing Oracle ExaLogic and/or Oracle WebLogic
Clustering (Doc Id: 1334558.1) or IBM WebSphere Clustering (Doc Id: 1359369.1) available from My Oracle
Support for more details.
Altering an Embedded installation
It is possible to convert an embedded installation to a native installation as a technique for migrating to the native
installation. It is not possible to run both the embedded and native installation as they will share port numbers.
To convert an embedded installation the following configuration parameters should be altered in an embedded
installation:
» Host Names – To avoid additional configuration steps, specify localhost for all host names.

» Port Numbers – Port numbers for the environment must be unique for the host. You cannot have two
environments with the same port numbers on the same host active at the same time.
» Local installation – Avoid using the distributed installation where the Web Application Server is separated from
the Business Application Server. Whilst it is possible to convert such setups it requires intervening changes prior
to deployment which complicate the process.
» EAR File installation – The native mode migration process in this whitepaper is not designed for development
environments where either WEB_ISEXPANDED or WEB_ISDEVELOPMENT are set to true. It is recommended to
use embedded mode for those environments.
Once these conditions are set then the environment can be migrated to native mode.
Installation of Product
Install the product according to the product installation documentation with the following additional setting:
» Hostnames should be set to localhost to use the environment independence features of the Oracle Utilities
Application Framework.
» Port Numbers should be unique for the host and not conflict with port numbers to be used for Administration
Servers or Node Managers.
» Ensure that the Web Application Server and Business Application are installed together in the environment. This
is the default installation and is typically the case.
» The Web Context Root (WEB_CONTEXT_ROOT) should be unique per domain.

» Ensure that Expanded mode is set to false (the default) to build and use EAR files for deployment.
Note:
To speed up deployment activities it is recommended not to install the AppViewer component unless
necessary.
Parameters to use in Native installation
One the product has been installed the following configuration settings, with their associated menu items, would be
noted to use used in the deployment process:
TABLE 1 – ENVIRONMENT SEETTINGS NEEDED TO BE USED IN DEPLOYMENT
Variable Menu Item (option)3 Comments
BSN_APP Business Server Application Name (2) Business Application Server Name
DBNAME Database Name (4) Optional: Used for Data Source (if used)
DBPASS Application Server Database Password (4) Optional: Used for Data Source (if used)
DBPORT Database Port (4) Optional: Used for Data Source (if used)
DBSERVER Database Server (4) Optional: Used for Data Source (if used)
DBUSER Application Server Database User ID (4) Optional: Used for Data Source (if used)
3 If the menu option number is greater than 50 then use the –a option on the configureEnv utility.

Variable Menu Item (option)3 Comments
SPLEBASE Not Applicable4 Location of the software installation
WEB_ADDITIONAL_OPT Web Application Additional Options (51) Additional JDK options
WEB_APP Web Server Application Name (3) Web Application Server Name
WEB_CONTEXT_ROOT Web Context Root (3) URL Root location of applications
WEB_MEMORY_OPT_MAX Web Application Java Max Heap Size (51) Maximum Online Memory in megabytes
WEB_MEMORY_OPT_MAXPERMSIZE Web Application Java Max Perm Size (51) Maximum Online Permgen Size in megabytes
(non-Jrockit JDK only)
WEB_MEMORY_OPT_MIN Web Application Java Initial Heap Size (51) Minimum Online Memory in megabytes
WEB_PRINCIPAL_NAME Web Principal Name (52) Group used for Authentication
WEB_ROLE_NAME Web Security Role (52) Role used for Authentication
WEB_SPLPASS WebLogic Admin System Password (3) Password for WEB_SPLUSER
WEB_SPLUSER WebLogic Admin System User ID (3) Initial Online User (e.g. SYSUSER)
WEB_WLHOST Web Server Host (3) Host Name for Web Application Server
WEB_WLPORT Web Server Port Number (3) Port number for product
WEB_WLSSLPORT WebLogic SSL Port Number (52) SSL Port number for product
WEB_WLSYSPASS WebLogic JNDI Password (3) JNDI User Password
WEB_WLSYSUSER WebLogic JNDI User ID (3) JNDI User (e.g. system)
WLS_ADMIN_PORT WebLogic Console Port Number (52) Administration Port.
These variables will be referred to in this whitepaper where applicable. Ensure the values match the values specified
in the installation. Failure to do so will not result in a successful deployment.
Native Installation Process
Note:
During this process Oracle WebLogic may ask you to restart the server after certain changes. It is
recommended to comply to ensure the configuration is applied correctly.
To install the product in a native installation of Oracle WebLogic the following process needs to be completed, after
Oracle WebLogic has been installed, a domain created and the Administration Server deployed to the domain:
4 This is specified in the initial installation and is not a menu item. The value is derived from the cistab file.

Native Installation
Setup Server/Machine
Setup Node Manager
Setup Machine
Setup Server
Set SPLEBASE location
Create XML Registry
Create Security
Setup Group
Alter Domain Security
Setup system user
Setup SYSUSER user
Deploy Product
Deploy SPLService
Deploy SPLWeb
Figure 13 – Native Installation Process
The following sections of this document will outline the above process in detail.
Setup Server And Machine
The first step in the process is setup the prerequisites within the Oracle WebLogic console to support the
deployment of the product. This process includes ensuring Node Manager is running on the host and creating the
necessary server objects using the Oracle WebLogic Administration console.
Note:
The process in this document primarily uses the Administration console but the process can also use Oracle
Enterprise Manager and the WebLogic Scripting Tool (wlst) as alternative means..

Setup Node Manager
Every machine that Oracle WebLogic is deployed on must have a Node Manager configured and executing. This
process is used by the Administration Server to remotely start and manage servers and resources on that machine.
To configure and operate Node Manager, refer to the Oracle Fusion Middleware Node Manager Administrators
Guide for Oracle WebLogic Server.
Note:
It is recommended to set the startScriptEnabled to true in the nodemanager.properties file

located in WL_HOME/common/nodemanager subdirectory. This supports the setting of variables as outlined
in Set SPLEBASE Location. If this file does not exist then node manager has not been started yet. It can be
generated by running startNodeManager.cmd/startNodeManager.sh in WL_HOME/server/bin.
Setup Machine Definition
Note:
This step can also be performed using the Oracle WebLogic Configuration Wizard or Oracle Enterprise
Manager.
Prior to setting up the server definition with Oracle WebLogic the host must be defined as a machine to configure the
Node Manager definitions. To do this select the Machines option from the Domain Structure and select the New
option within the Administration console. For example:
Figure 14 – Machine Creation

Specify the host name (the entry name not the actual host name) and the Machine OS for the server. This will
ensure the optimized libraries for that operating system are used. If your platform is not listed then use Other as the
setting. For example:
Figure 15 – New Machine configuration
Configure the communication type, physical host name (WEB_WLHOST) and port number allocated to the Node
Manager running on that host and Press Finish to save. For example:
Figure 16 – Defining the Node Manager

Setup Server Definition
Note:
This step can also be performed using the Oracle WebLogic Configuration Wizard or Oracle Enterprise
Manager.
The next step is to define the server (i.e. a JVM) to house the product within Oracle WebLogic. To create or maintain
the server use the Administration console. Navigate to the Servers option under the Domain Structure and use the
New option to create a new server definition. For example:
Note:
The Administration Server should be listed on the domain as the initial server on the domain.
Figure 17 – Creating a Server
Specify the following for the server:
» A name for the server. This is not a physical name it is just used by the Oracle WebLogic to identify the server.
Use your site preferences for the name.
» Allocate the machine you created earlier. This process may require the server to be saved prior to allocating the
machine. For example:

Figure 18 – Allocating a machine to the server
» Specify the Listen Port the same value as WEB_WLPORT to align with the configuration files allocated to the
product. Ensure the Listen Port Enabled is selected to enable the port.
Note:
If you do not specify the correct value the SPLWeb application will not connect to the SPLBusiness
application correctly. This will result in EJB connection errors in the domain.
Note:
It is possible to specify the Listen Address as well but that may limit the connections to the server.
If SSL is used, then the value for the SSL Listen port must be the same value as WEB_WLSSLPORT to align with the
configuration files allocated to the product. Ensure the SSL Listen Port Enabled is selected to enable the port.
» Save the Server definition.

For example:

Figure 19 – Configuring a Server
You may start the Server using the Control functionality of the Administratrion Server to verify your definition.
Setting Memory Requirements
Note:
Customers on Oracle WebLogic 12.x and above should consider placing all these settings in the
setUserOverrides file used by Oracle WebLogic to save. Refer to the Using the setUserOverrides facility
for more advice.
One of the settings that must be changed for the server is the memory requirements for the server. The default
settings on java are typically not applcable to the product.
The setting for memory are typically set on the java command line or in the ENVIRON.INI in a number of settings.
To reflect these settings on the Server definition, edit the server definition in the Administration console and under
the Server Start tab under Configuration specify the following command line arguments in the format to set memory
requirements:
-Xms<WEB_MEMORY_OPT_MIN>m –Xmx<WEB_MEMORY_OPT_MAX>m –
XX:PermSize=<WEB_MEMORY_OPT_MAXPERMSIZE>m
For example:
-Xms1024m -Xmx1024m -XX:PermSize=300m

For example:

Figure 20 – Configuring memory requirements for the server
Note:
The values above represent the minimum values for non-Production. For Production systems refer to the
Production Environment Configuration Guidelines (Doc Id: 1068958.1) whitepaper available from My Oracle
Support.
Note:
For customers using Oracle JRockit, the –XX:Permsize parameter is not supported so should not be
included in the Arguments. Oracle JRockit is not supported for newer versions of products. Refer to your
installation guides for clarification.
Note:
If the WEB_ADDITIONAL_OPT is set with any additional options, they can be added to the Arguments field.

Note:
Java options used in the Arguments field must be compatible with the JDK used.
For customers using the JMX capabilities of the Oracle Utilities Application Framework then the configuration file for
the JMX realm must be added to the command line by adding –
Djava.security.auth.login.config=<SPLEBASE>/splapp/config/java.login.config option where
<SPLEBASE> is the full path used for the installation. For example:
Figure 21 – Example JMX configuration setting
To verify the changes have been applied, after a server restart, use the Performance tab from the Monitoring funtion
for the server. For example:
Figure 22 – Verifying memory requirements for the server
Additional Parameters
Note:
for more advice.
The following additional parameters can be appended to the Arguments section of the server setup:
-Dfile.encoding=ISO8859_1 -
Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0

Note:
For customers using UTF8 character sets should set the file.encoding to UTF-8.
Note:
For IBM AIX customers using the IBM JDK, the equivalent classes should be used. Refer to the IBM JDK
documentation for more details.
For customers wishing to use Java Flight Control refer to the Using WLDF with Java Flight Recorder section of the
Oracle Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server
documentation.
Inbound Web Services Parameters
Note:
for more advice.
Note:
For IBM AIX customers using the IBM JDK, the equivalent parameters should be used. Refer to the IBM JDK
documentation for more details.
If you are using Oracle Utilities Application Framework V4.2.0.2.0 and above, the Inbound Web Services capability
must add the following additional java parameters:
-Djavax.xml.soap.MessageFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl -
Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl -
Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false
This will allow the SOAP support to integrate with the native web services capabilities of the container.
Setting COBOL Library Path
Note:
This section only applies to products that use COBOL based objects. In Oracle Utilities Application
Framework V4.3.x and above, COBOL is no longer supported, please ignore this section for those versions.
For COBOL to work with native servers, the following additional setting must be appended to the Server Start
Arguments for COBOL sockets to be used:
Linux/Unix
-Djava.library.path=<SPLEBASE>/runtime
Windows

-Djava.library.path=<SPLEBASE>\runtime
where <SPLEBASE> is the fully qualified path for the installation. This setting does not support environment
variables.
Setting Additional Java Classes
Note:
for more advice.
Note:
The settings in this section represent the minimum settings. If additional libraries are used they must be also
added as outlined.
Note:
The versions indicated in the file names in the examples represent the valid versions for the latest version of
the Oracle Utilities Application Framework at time of publication and may need to be altered to different
versions depending on the version of Oracle Utilities Application Framework.
The Oracle Utilities Application Framework uses a number of additional java classes to process the information on
the screens and parse schemas. To use these additional java classes there are a number of techniques that can be
used:
Alter the Server definition used for the product to add the new libraries in the Class Path setting under Configuration
 Server Start tab. For example:

Figure 23 – Custom Class Path for product
For the Class Path, specify the following (the values of <SPLEBASE> and <WL_HOME> need to be fully specified for
your platform, use of environment variables is not supported by the Node Manager):
Windows:
<SPLEBASE>\splapp\standalone\lib\xalan-mod-2.7.1.jar;
<SPLEBASE>\splapp\standalone\lib\serializer-
2.7.1.jar;<SPLEBASE>\splapp\standalone\lib\antlr-
2.7.6.jar;<WL_HOME>\server\lib\weblogic_sp.jar;
<WL_HOME>\server\lib\weblogic.jar
Linux/Unix:
<SPLEBASE>/splapp/standalone/lib/xalan-mod-2.7.1.jar:
<SPLEBASE>/splapp/standalone/lib/serializer-
2.7.1.jar:<SPLEBASE>/splapp/standalone/lib/antlr-2.7.6.jar:
<WL_HOME>/server/lib/weblogic_sp.jar:
<WL_HOME>/server/lib/weblogic.jar
Note:.
Note:
If this option is used then the Oracle WebLogic jar files must also be added to ensure Oracle WebLogic starts
correctly as indicated per the online help for the Class Path setting.
Alternatively, alter the startWebLogic[.sh] or startManagedWebLogic[.sh] utilities in the

WL_HOME/user_projects/domains/<domain_name>/bin to add the new libraries. For example add the
following lines (in italics):
Windows:
…
set CLASSPATH=%CLASSPATH%;
set
CLASSPATH=%CLASSPATH%;%SPLEBASE%\splapp\standalone\lib\xalan-
mod-2.7.1.jar;%SPLEBASE%\splapp\standalone\lib\serializer-
2.7.1.jar
set CLASSPATH=%SPLEBASE%\splapp\standalone\lib\antlr-
2.7.6.jar;%CLASSPATH%
…
Linux/Unix:
CLASSPATH=${SAVE_CLASSPATH}

CLASSPATH=${CLASSPATH}:${SPLEBASE}/splapp/standalone/lib/xalan
-mod-2.7.1.jar: ${SPLEBASE}/splapp/standalone/lib/serializer-
2.7.1.jar
CLASSPATH=${SPLEBASE}/splapp/standalone/lib/antlr-
2.7.6.jar:${CLASSPATH}
…
Set SPLEBASE Location
Note:
for more advice.
Note:
This step MUST be performed for successful execution of the product.
Before installing the product on the server just configure the location of the software to be used at deployment time
and at runtime. Typically J2EE applications do not require this step but the product requires this step for a number of
reasons:
» Configuration files have been extracted from the EAR files for runtime configuration. This reduces the need for
redeployment for every configuration change. These are located in specific directories where the software is
installed. For more information about configuration files refer to the Server Administration Guide5 supplied with
your product.
» Some of the executable objects are not bundled within the EAR files as they are used by the online and batch
components from a common location. This avoids multiple copies of the runtime objects being used.
» For products that support COBOL based objects, the COBOL runtime is not included in the EAR file and needs to
be referenced at runtime from the software installation.
The SPLEBASE environment variable must be set to the location of the software applicable for that server prior to the
deployment and execution of the product. The value of this SPLEBASE environment should match the SPLEBASE
variable in the ENVIRON.INI for the environment to execute.
To set the SPLEBASE environment variable there are a number of alternatives depending on the scope of the
domain and the use of the software. These alternatives are as follows:
» If all the environments on a host are using the same environment as a reference, such as a production clustered
system, then you can set the environment variable in the .profile (or profile in Windows platforms) for the
administration user used to start the environment within Oracle WebLogic.
» You can set the value at the domain level by altering the setDomain.sh/setDomain.cmd file in the
WL_HOME/user_projects/domains/<domain_name>/bin directory where <domain_name> is the name
of the domain used for the product.
5 For Oracle Utilities Application Framework V2.x products, the Server Administration Guide is called the Configuration and Operations Guide.

Linux:
SPLEBASE=….
export SPLEBASE
Windows:
set SPLEBASE=….
» You can set it at the individual server level (<servername> = your server name) using additional code in the
startWebLogic.sh/startWebLogic.cmd or
startManagedWebLogic.sh/startManagedWebLogic.cmd files in the
WL_HOME/user_projects/domains/<domain_name>/bin directory where <domain_name> is the name of
the domain used for the product.
Linux:
if [ "${SERVER_NAME}" = "<servername>" ] ; then

SPLEBASE=…
export SPLEBASE
else …..
SPLEBASE=…
export SPLEBASE
fi
Windows:
if "%SERVER_NAME%"=="<servername>" (
set SPLEBASE=…
) else (
set SPLEBASE=…
)
Create XML Registry
Note:
For customers on the AIX platform refer to the AIX specific instructions contained in XML Registry for AIX
Platforms.
The next step is to create a XML Registry to configure the XML parser to be used by the product at runtime. To
create an XML Registry, navigate to the XML Registries under Domain Structure within the Administration Console
and select the New button. For example:

Figure 24 – Create XML Registries
Name the registry appropriately for your site and specify the following settings for the parsers:
TABLE 2 – XML REGISTRY SETTINGS
PARAMETER SETTING
Document Builder Factory com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
SAX Parser Factory com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
Transformer Factory com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
When To Cache Specify cache-on-reference as the setting.
For example:

Figure 25 – XML Registry settings
Specify the Server created for the product to deploy the registry. For example:
Figure 26 – XML Registry server deployment
To confirm the settings view the registry configuration. For example:
Figure 27 – XML Registry settings
XML Registry for AIX Platforms
Note:
This step only applies to the IBM AIX platform.
As the IBM AIX platform uses the IBM JDK the classes specified for the XML Parser used for the XML Registry are
different to the previous sections. To set the parser to the correct value for the product the following java options
must be present in the startWLS.sh/startWebLogic.sh script, located in the domain directories used to start
Oracle WebLogic:
TABLE 3 – JAVA OPTIONS SETTINGS
PARAMETER RECOMMENDED SETTING
javax.xml.transform.TransformerFactory org.apache.xalan.processor.TransformerFactoryImpl
javax.xml.validation.SchemaFactory:http://www org.apache.xerces.jaxp.validation.XMLSchemaFactory

PARAMETER RECOMMENDED SETTING
.w3.org/2001/XMLSchema
These can be set in the startWLS.sh/startWebLogic.sh using the JAVA_OPTIONS environment variable in the
script. For example:
JAVA_OPTIONS="$JAVA_OPTIONS -
Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.T
ransformerFactoryImpl -
Djavax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema
=org.apache.xerces.jaxp.validation.XMLSchemaFactory"
Using the setUserOverrides facility
In Oracle WebLogic 12.x and above, a new facility to allow customization of the server start settings at a global level
was introduced in the form of the script setUserOverrides.sh which is located in the $DOMAIN_HOME/bin
directory.
This script can set the java arguments as well as any classpath variables for any server within the domain.
TABLE 4 – SETUSEROVERRIDES.SH VARIABLES
VARIABLE SUGGESTIONS
SPLEBASE Set the location of the software
USER_MEM_ARGS Sets Java options to replace Arguments section of server. If Arguments is also used then they will be
added to the arguments specified here.
EXT_PRE_CLASSPATH This is classpath for any custom classes and any Classes specified for the server.
An example of a script is shown below:
#!/bin/sh
SPLEBASE="/u01/app/oracle/ouaf"
export SPLEBASE
USER_MEM_ARGS="-Xms1024m -Xmx4096m -XX:CompileThreshold=8000 -XX:PermSize=500m -
Djava.security.auth.login.config=/u01/app/oracle/ouaf/splapp/config/java.login.config
-Dfile.encoding=ISO8859_1 -
Djavax.xml.soap.MessageFactory=com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPMe
ssageFactory1_1Impl -
Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl -
Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false -
Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 -
XX:+UnlockCommercialFeatures -XX:+FlightRecorder"
export USER_MEM_ARGS
EXT_PRE_CLASSPATH="/u01/app/oracle/ouaf/splapp/standalone/lib/xalan-mod-
2.7.1.jar:/u01/app/oracle/ouaf/splapp/standalone/lib/serializer-
2.7.1.jar:/u01/app/oracle/ouaf/splapp/standalone/lib/antlr-2.7.7.jar"
export EXT_PRE_CLASSPATH

Optional: Creating a Data Source
If your site wishes to use Oracle WebLogic Data Sources for online transactions and Inbound Web Services
transactions rather than the default Universal Connection Pool connections then they must be created prior to being
used and the product configured to use them.
If you are using Oracle Utilities Application Framework V4.3.0.2.0 and above, then the approach is as follows:
» It is recommended to create separate data sources for online and Inbound Web Services. The online data source
should use the online user/password (configured in DBUSER and DBPASS respectively) and the Inbound Web
Services should use the Inbound Web Services user/password (configured in XAI_DBUSER and XAI_DBPASS
respectively).
» Specify the data source names for online and Inbound Web Services in the JDBC_NAME and IWS_JDBC_NAME
settings respectively.
» Execute initialSetup and redeploy the online and Inbound Web Services applications to reflect the changes.
For earlier versions refer to Using Oracle WebLogic datasources with OUAF products for more information on the
process of creating data sources.
Create Security Definitions
Note:
This section assumes that the site is using the inbuilt LDAP security provided by Oracle WebLogic. If this is
not the case the steps need to be performed in the external security repository configured in Oracle
WebLogic.
As with most other application security needs to be configured to execute the product securely as well as define the
security used by the application users who use the product.
The first security definition that needs to be defined is the group used to indicate the subset of users that are
authorized to use the product. By default, this is specified at configuration time in the WEB_PRINCIPAL_NAME and
WEB_ROLE_NAME as part of the installation. This value is usually defaulted to cisusers but can be changed to any
valid group name in your security repository used for the implementation. Refer to the documentation provided with
the version of the product to determine the process of setting this value.
To create the group, navigate to the security realm defined for the domain via the Security Realms option in the
Domain Structure using the Administration Console. For example:

Figure 28 – Security Realm configuration
Navigate to the Groups tab of the Users And Groups tab and if the group is not already listed, then select New to
add a new definition. For example:
Figure 29 – Adding a new Group definition
Specify the Name as the value of WEB_PRINCIPAL_NAME and/or WEB_ROLE_NAME with an appropriate
description. The provider should be set to the DefaultAuthenticator to inherit the provider from the realm,
unless other settings are appropriate for the site requirements. For example:

Figure 30 – Group Definition
After saving the definition, the group should be now listed as a group.
For example:
Figure 31 – Added Group
Altering the Security Domain

The Oracle Utilities Application Framework requires a few additional settings on the default security realm to ensure
the security settings of the individual components of the product are processed individually.
To alter the realm, navigate to the security realm defined for the domain via the Security Realms option in the
Domain Structure using the Administration Console. For example:
Figure 32 – Altering the Security Realm
Navigate to the General tab under the Configuration tab and alter the Security Model Default to Advanced and
uncheck the Combined Role Mapping option. This instructs Oracle WebLogic to use the product security
configuration in the configuration files for each component. For example:
Figure 33 – Configuring security requirements for the domain.

Save the changes.
Optional: Alter Password Validation routine
If your site is converting an embedded environment to a native environment, the default password scheme used by
the installer is not compatible with the default password algorithm used by Oracle WebLogic. This may prevent
defining users to Oracle WebLogic in subsequent steps. If this is the case it is recommended to alter the
configuration of the default password validation provider to reset the rules for the provider.
To change the Password Provider, navigate to the security realm defined for the domain via the Security Realms
option in the Domain Structure using the Administration Console. For example:
» After selecting the realm, navigate to the Password Validation tab under the Providers tab and select the
SystemPasswordValidator. For example:
Figure 35 – Configuring the System Password Validator
» On the Provider Specific tab change the Minimum Number of Non-Alphabetic Characters under Character
Policies from 1 to 0 (zero). For example:

Figure 36 – Configuring Password rule
» Save the changes.
Create JNDI User
The first credential to add is the credential used by the product to access the JNDI for the Oracle WebLogic server.
This is used for By default, this is set to WEB_WLSYSUSER as part of the installation.
To add the user, navigate to the security realm defined for the domain via the Security Realms option in the Domain
Structure using the Administration Console. For example:
» Navigate to the Users tab of the User and Groups tab and select New to add the new user. For example:

Figure 38 – Adding New Users
» Specify the following for the user record:

» Name – Specify the user specified in WEB_WLSYSUSER. The entry is case sensitive.
» Description – Specify the name or description of the user
» Provider – Select the DefaultAuthenticator to inherit the security settings from the domain
» Password - Specify the password specified in WEB_WLSYSPASS6. The entry is case sensitive. This value will
need to be provided twice for confirmation.
For example:
6 The password is encrypted in the ENVIRON.INI. Specify the decrypted password for any prompts.

Figure 39 – Adding the JNDI User record
To complete the security setup for this user, the user must be associated with the group that was created in Create
Security Definitions. To do this, select the user from the Users tab of the User and Groups tab to edit the user. For
example:

Figure 40 – Editing an application user
Select the groups the user should have access to, including the group created in Create Security Definitions. For
example:

Note:
The group used above is for illustrative purposes only.
Create SYSUSER User
Note:
The process illustrated in this section can be used to add the authentication of any application user using the
inbuilt LDAP security repository.
As part of the installation of the product, an initial application user is provided, usually SYSUSER, to allow
implementations to create the other users to access the product as well as setup key installation data within the
product initially to meet site requirements. This user needs to be created to access the product initially.
To add the user, navigate to the security realm defined for the domain via the Security Realms option in the Domain
Structure using the Administration Console. For example:
Navigate to the Users tab of the User and Groups tab and select New to add the new user. For example:

Figure 43 – Adding New Users
Specify the following for the user record:

Name – Specify the user specified in WEB_SPLUSER. The entry is case sensitive.
Description – Specify the name or description of the user
Provider – Select the DefaultAuthenticator to inherit the security settings from the domain
Password - Specify the password specified in WEB_SPLPASS7. The entry is case sensitive. This value will need to
be provided twice for confirmation.
For example:
Figure 44 – Adding the initial application user
To complete the security setup for this user, the user must be associated with the group that was created in Create
Security Definitions. To do this, select the user from the Users tab of the User and Groups tab to edit the user. For
example:
7 The password is encrypted in the ENVIRON.INI. Specify the decrypted password for any prompts.

Select the group created in Create Security Definitions to give this user authentication access to the product. For
example:

Figure 46 – Configuring groups for the user
Save the changes to implement the user.
Product Deployment
Now that Oracle WebLogic is installed and configured to prepare it for the product, the last steps are to deploy the
product using the deployment facilities provided by the Oracle WebLogic product.
Note: The sections will use the online deployment facilities in Oracle WebLogic using the Administration console.
There are alternative methods supported by Oracle WebLogic. Refer to the Oracle WebLogic documentation for
information about these alternative methods.
Deploy SPLService
Architecturally the first component to be deployed is the Business Application Server as it must be deployed and
ready when the Web Application Server is deployed.
To deploy the Business Application Server, within the Administration Console, navigate to the Control tab of the
Deployments option within the Domain Structure and use the Install option to initiate the process. For example:

Figure 47 – Initiating the deployment of the Business Application Server
Within the Application Assistant, navigate to the location of the EAR files to deploy, which are typically stored under
$SPLEBASE/splapp/applications (or %SPLEBASE%/splapp/applications in Windows), and select the
SPLService.ear file. For example:
Figure 48 – Selecting the SPLService.ear file.
Specify that the EAR file contains an applications (as opposed to a library) so should be installed as an application.
For example:

Figure 49 – Deploy SPLService as an application
Select the server created in Setup Server Definition to deploy the product to. For example:
Figure 50 – Select Server for SPLService
Specify the deployment conditions for SPLService as follows:

Name – Set the name as set in the BSN_APP variable, by default this is SPLService. This must match the value of
BSN_APP.
Security – Select Advanced to match the Advanced mode specified earlier.

Source Availability – Select Copy this application onto every target for me as the default action. Other options
available may be used but this is the most direct and also allows WebLogic to house the application files within its
domain structures.

For example:
Figure 51 – Application Settings for SPLService
Before completing the deployment process it is advised to select Yes, take me to the deployment's configuration
screen, to validate the paraneters before the deployment. For example:

Figure 52 – Confirmation of request to deploy for SPLService
Verify that the deployment settings are correct as specified and alter the Deployment Order to 100 to configure
when this deployment will be loaded relatively to other deployments8. For example:
8 This will make sense when the Web Application Server is deployed onto the same server within this domain.

Figure 53 – Setting deployment order for SPLService
Save to initiate the deployment.
Note:
Depending on the speed of the machine, initial deployment can take a few minutes.
Once the deployment is successful the deployment will appear on the deployment list. For example:

Figure 54 – Deployment confirmation for SPLService
Note:
The deployment can be tested by starting the server that houses the deployment and seeing it start
successfully. The product cannot be used till the Web Application Server is also deployed.
Deploy SPLWeb
The last component to be deployed is the Web Application Server which is deployed after the Business Application
Server has been deployed successfully.
To deploy the Web Application Server, within the Administration Console, navigate to the Control tab of the
Deployments option within the Domain Structure and use the Install option to initiate the process. For example:
Figure 55 – Initiating the deployment of the Web Application Server
Within the Application Assistant, navigate to the location of the EAR files to deploy, which are typically stored under
$SPLEBASE/splapp/applications (or %SPLEBASE%/splapp/applications in Windows), and select the
SPLWeb.ear file. For example:

Figure 56 – Selecting the SPLWeb.ear file
Specify that the EAR file contains an applications (as opposed to a library) so should be installed as an application.
For example:
Figure 57 – Deploy SPLWeb as an application
Select the server created in Setup Server Definition to deploy the product to. For example:

Figure 58 – Select Server for SPLWeb
Specify the deployment conditions for SPLWeb as follows:

Name – Set the name as set in the WEB_APP variable, by default this is SPLWeb. This must match the value of
WEB_APP.
Security – Select Advanced to match the Advanced mode specified earlier.

Source Availability – Select Copy this application onto every target for me as the default action. Other options
available may be used but this is the most direct and also allows WebLogic to house the application files within its
domain structures.
For example:

Figure 59 – Application Settings for SPLWeb
Before completing the deployment process it is advised to select Yes, take me to the deployment's configuration
screen, to validate the paraneters before the deployment. For example:

Figure 60 – Confirmation of request to deploy for SPLWeb
Verify that the deployment settings are correct as specified and alter the Deployment Order to 200 to configure
when this deployment will be loaded relatively to other deployments. This will ensure that SPLWeb will start after
SPLService (which has a Deployment Order of 100). For example:

Figure 61 – Setting deployment order for SPLWeb
Save to initiate the deployment.
Note:
Depending on the speed of the machine, initial deployment can take a few minutes. If AppViewer is included
in SPLWeb the initial deployment may take even longer.
Once the deployment is successful the deployment will appear on the deployment list. For example:

Figure 62 – Confirmation for SPLWeb
Deploy Inbound Web Services
Note:
This section only applies to Oracle Utilities Application Framework V4.2.0.2.0 and above only.
In Oracle Utilities Application Framework V4.2.0.2.0 and above, a container based web services known as Inbound
Web Services. The major feature of this capability is the deployment of web services within the J2EE container
directly. This means that the web services are generated and assembled into a J2EE application that must be
deployed into your domain.
The implementation of the Inbound Web Services depends on the version of the Oracle Utilities Application
Framework used:
» In Oracle Utilities Application Framework V4.2.x, the implementation was WAR based and should be deployed
with the online server as an application.
» In Oracle Utilities Application Framework V4.3.x, the implementation was EAR based and can be deployed with
the online server or on its own server. In non-production environments, it is highly recommended to deploy the file
in the same server as the online server.
To prepare the server, perform the following:
» Execute the iwsdeploy[.sh] utility with the -b option to build the EAR/WAR files used.
» Deploy the EAR/WAR file generated in the $SPLEBASE/iws/deploy directory with the same parameters as the
SPLWeb application with the Deployment Order of 300 to ensure it is loaded last. Additional parameters are as
defaulted or as SPLService. This may be deployed on the same server as the online or different (for production
environments).
Operations in Native Mode

The Server Administration documentation supplied with the product tends to concentrate to using the product in
embedded mode. The following sections outline differences in common operations with native mode from
embedded mode.
Starting/Stopping the Server

To start or stop the product the control mechanism in the Administration console can be used. Alternatively
command line utilities such as startWebLogic/stopWebLogic or
startManagedWebLogic/stopManagedWebLogic can be used to start/stop the product. Oracle Enterprise
Manager can also be used to stop and start the product.
To start or stop the product is achieved by starting or stopping the server the product is deployed to. For example, to
start the product using the Administration Console use the Control tab for the Servers, select the relevant server and
press the Start option. For example:
Figure 63 – Starting the Server
This will send the request to the Node Manager which will execute the start process. Logs for the startup are
indicated on the Node Manager log files.
Similarly, to stop the server using the Administration Console use the Control tab for the Servers, select the relevant
server and press the Shutdown option. You have the option to stop the server gracefully or stop immediately. For
example:

Figure 64 – Stopping the Server
One of the advantages of native mode is that administrators have full access to the various options on the server
including suspending the product for administration tasks etc. Refer to the Oracle WebLogic Administration Guide
for more details.
Redeployment of EAR files
One of the disadvantages of the native mode installation is that if the EAR file changes for any reason (patching or
configuration changes) then the EAR file must be redeployed. The redeployment process basically is the same as
the deployment process but as Oracle WebLogic already knows the deployment attributes of the product it will
update the EAR file.
To initiate redeployment, navigate to the Deployments of the domain and select the deployment to redeploy and use
the Update action to redeploy the EAR file. For example:

Figure 65 – Redeployment
The wizard will reuse the information from the deployment and re-ask for confirmation. Follow the instructions in the
Deployment sections of this document for confirmations of parameters.
Note: It is recommended that the server housing the product be shutdown or suspended to enable redeployment
activities to completed successfully.
The following conditions typically require redeployment or not:
TABLE 5 – REDEPLOYMENT CONDITIONS
CONDITION REDEPLOY COMMENTS
Patches, Service Packs, Upgrades Yes These change the EAR files
Updates to web.xml Yes Updates to any parameter in the Web.xml files for each component
Updates to weblogic.xml Yes Rare, but if the Weblogic.xml is updated then it must be redeployed
Updates to properties files No These are read from the operating system at runtime
Update to AppViewer Yes If AppViewer is rebuilt, then it must be redeployed if installed in SPLWeb
Custom JSP code Yes These are included in EAR files
Custom Java code Maybe Only if they are included in the EAR files
Batch Changes No EAR files are not used for batch
Other configuration changes No EAR files do not include most configuration files as they are read off the
operating system at runtime
Updates to scripts No

CONDITION REDEPLOY COMMENTS
Database connection changes No
MDB9 Configuration/Changes Yes These update J2EE configuration files used in the EAR files (ejb-jar.xml and,
weblogic-ejb-jar.xml)
Appendices
SPLWeb JTA Timeout
During the product startup or deployment process, the request for the SPLWeb application may timeout with a
message similar to the example below:
BEA1-0000D3606D8FD321AAE2; nested exception is:

weblogic.transaction.internal.TimedOutException: Transaction timed
out after 32 seconds
BEA1-0000D3606D8FD321AAE2
at
weblogic.ejb.container.internal.RemoteBusinessIntfProxy.unwrapRemote
Exception(RemoteBusinessIntfProxy.java:121)
at ..
This is caused as the SPLWeb application is deployed and/or prepared10. To increase the timeout, alter the JTA
timeout on the domain to give the server more time to deploy the product. The JTA timeout can be altered within the
Administration console by selecting the JTA tab of the Configuration tab for the domain. For example:
9 Refer to the Oracle WebLogic JMS Integration and Oracle Utilities Application Framework (Doc Id: 1308181.1) whitepaper from My Oracle Support for
more details.
10 If the AppViewer is included in the installation, this can increase deployment time significantly enough to cause a timeout. The deployment process
checks every component and AppViewer has a lot of components.

Figure 66 – JTA Timeout
Set the timeout appropriate to site preferences and Save the change. This will not require a restart.
Creating boot.properties
In the setup of Oracle WebLogic, the default mode illustrated was Development Mode where the Configuration
Wizard will set a number of configuration setting and also create a Boot Identity File which is used by Oracle
WebLogic at startup time. It is possible to use Production Mode, but by default Oracle WebLogic will prompt at
startup for credentials. This may not be appropriate so it is possible to manually create a Boot Identity File to be
used as credentials at startup.
Refer to the Boot Identity File section of the Oracle Fusion Middleware Managing Server Startup and Shutdown for
Oracle WebLogic Server manual.

Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200
CONNECT WITH US
blogs.oracle.com/theshortenspot Copyright © 2007 - 2016, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and
the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
facebook.com/oracle warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
twitter.com/theshortenspot means, electronic or mechanical, for any purpose, without our prior written permission.
oracle.com Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0416

Native Install

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Native Install

Загружено:

Авторское право:

Доступные форматы

Native Installation

Oracle Utilities Application Framework

Oracle WebLogic Installation 6

Administration Server Setup 10

Optional: Enabling console as Autodeployed 13

Product Installation Preparation 14

Altering an Embedded installation 14

Parameters to use in Native installation 15

Native Installation Process 16

Setup Server And Machine 17

Setup Node Manager 18

Setup Machine Definition 18

Setup Server Definition 20

Setting Memory Requirements 22

Inbound Web Services Parameters 25

Setting COBOL Library Path 25

Setting Additional Java Classes 26

Set SPLEBASE Location 28

1 | Native Installation - Oracle Utilities Application Framework

XML Registry for AIX Platforms 31

Using the setUserOverrides facility 32

Optional: Creating a Data Source 33

Create Security Definitions 33

Altering the Security Domain 35

Optional: Alter Password Validation routine 37

Create JNDI User 38

Create SYSUSER User 42

Deploy Inbound Web Services 57

Operations in Native Mode 57

Starting/Stopping the Server 57

Redeployment of EAR files 59

SPLWeb JTA Timeout 61

2 | Native Installation - Oracle Utilities Application Framework

3 | Native Installation - Oracle Utilities Application Framework

4 | Native Installation - Oracle Utilities Application Framework

Oracle WebLogic Installation

Install Oracle WebLogic

Set SPLEBASE location

Create XML Registry

Figure 1 – Native Installation process

The process can be summarized as follows:

5 | Native Installation - Oracle Utilities Application Framework

» Deploy the product to Oracle WebLogic using the Administration console.

» Deploy the Business Application Server to Oracle WebLogic.

Oracle WebLogic Installation

6 | Native Installation - Oracle Utilities Application Framework

Figure 3 – Create Oracle WebLogic domain

7 | Native Installation - Oracle Utilities Application Framework

Figure 5 – Oracle WebLogic domain name

8 | Native Installation - Oracle Utilities Application Framework

Figure 6 – Oracle WebLogic domain Administration account.

9 | Native Installation - Oracle Utilities Application Framework

The next step is to create an Administration Server using the Wizard.

Administration Server Setup

10 | Native Installation - Oracle Utilities Application Framework

Figure 9 – Configure Administration Server

11 | Native Installation - Oracle Utilities Application Framework

12 | Native Installation - Oracle Utilities Application Framework

Optional: Enabling console as Autodeployed

This can be achieved using the following process:

» Open the Oracle WebLogic console using an Administration account.

13 | Native Installation - Oracle Utilities Application Framework

» Save the changes to the Domain.