An Oracle White Paper June 2011
Technical Best Practices
Technical Best Practices ... 5
Conventions used in this whitepaper ... 5
Introduction ... 6
Background of Oracle Utilities Application Framework ... 6
Installation Best Practices ... 8
Read the Installation Guide ... 8
Ensure the prerequisites are installed ... 8
Environment Practices ... 9
Using multiple administrators ... 10
Checking Java Installation ... 10
Checking COBOL Installation ... 11
Additional Oracle WebLogic Installation settings ... 12
COBOL License Errors in Batch ... 13
Location of Installation Logs ... 13
XML Parser Errors in installation ... 13
AppViewer cannot Co-Exist in Archive Mode ... 14
Implementing Secure Protocols (https/t3s) ... 15
General Best Practices ... 17
Limiting production Access ... 17
Regular Collection and Reporting of Performance Metrics ... 18
Respecting Record Ownership ... 18
Backup of Logs ... 19
Post Process Logs ... 19
Check Logs For Errors ... 20
Optimize Operating System Settings ... 20
Optimize connection pools ... 21
Read the available manuals ... 23
Technical Documentation Set Whitepapers available ... 25
Implementing Industry Processes ... 26
Custom Environment Variables or JAR files ... 28
Help and AppViewer can be used standalone ... 29
Re-Register only when necessary ... 29
Secure default userids ... 30
Consider different userids for different modes of access ... 30
Don’t double audit ... 31
Use Identical Machines ... 31
Regularly restart machines ... 31
Avoid using direct SQL to manipulate data ... 32
Minimize Portal Zones not used ... 32
Routine Tasks for Operations ... 33
Typical Business Day ... 33
Login Id versus Userid ... 34
Hardware Architecture Best Practices ... 35
Failover Best Practices ... 39
Online and Batch tracing and Support Utilities ... 41
General Troubleshooting Techniques ... 41
Data Management Best Practices ... 43
Respecting Data Diversity ... 43
Archiving ... 44
Data Retention Guidelines ... 46
Removal of Staging Records ... 47
Partitioning ... 49
Compression ... 50
Database Clustering ... 51
Backup and Recovery ... 51
Writing Files Greater than 4GB ... 52
Client Computer Best Practices ... 53
Make sure the machine meets at least the minimum specification 53 Internet Explorer Caching Settings ... 53
Clearing Internet Explorer Cache ... 54
Optimal Network Card Settings ... 54
Network Best Practices ... 54
Network bandwidth ... 54
Ensure legitimate Network Traffic ... 55
Regularly check network latency ... 55
Web Application Server Best Practices ... 56
Make sure that the access.log is being created ... 56
Examine Memory Footprint ... 57
Optimize Garbage Collection ... 58
Turn off Debug ... 58
Load balancers ... 58
Preload or Not? ... 59
Native or Product provided utilities? ... 60
Hardware or software proxy ... 61
What is the number of Web Application instances do I need? ... 61
Configuring the Client Thread Pool Size ... 62
Defining external LDAP to the Web Application Server ... 64
Synchronizing LDAP for security ... 66
Appropriate use of AppViewer ... 68
Fine Grained JVM Options ... 69
Customizing the server context ... 70
Clustering or Managed? ... 71
Allocate port numbers appropriately ... 73
Monitoring and Managing the Web Application Server using JMX 74 Enabling autodeployment for Oracle WebLogic console ... 76
Password Management solution for Oracle WebLogic ... 76
Error configuring Oracle WebLogic credentials ... 77
Corrupted SPLApp.war ... 78
IBM WebSphere Specific Advice ... 79
Business Application Server Best Practices ... 82
Distributed or local installation ... 82
Number of Child JVMS ... 82
COBOL Memory management ... 83
Cache Management ... 84
Monitoring and Managing the Business Application Server using JMX 85 Database Connection Management ... 88
XPath Memory Management ... 88
Database Best Practices ... 89
Regularly Calculate Database Statistics ... 90
Ensure I/O is spread evenly across available devices ... 91
Use the Correct NLS settings (Oracle) ... 91
Monitoring database connections ... 92
Consider changing Bit Map Tree parameter ... 92
OraGenSec command line Parameters ... 93
SetEnvId command line Parameters ... 93
Technical Best Practices
This white paper outlines the common and best practices used by IT groups at sites using Oracle Utilities Application Framework based products and Oracle internal studies, around the world, that have benefited sites in some positive way. This information is provided to guide other sites in implementing or maintaining the product.
While all care has been taken in providing this information, implementation of the practices outlined in this document may NOT guarantee the same level of (or any) improvement. Some of these practices may not be appropriate for your site. It is recommended that each practice be examined in light of your particular organizational policies and use of the product. If the practice is deemed beneficial to your site, then consider implementing it. If the practice is not appropriate (e.g. for cost and other reasons), then it should not be considered.
This whitepaper covers V2.x and above of the Oracle Utilities Application Framework based products. Where advice is applicable to a particular version of the product, a specific reference to that version is displayed. For V1.x customers, specific information for V1 is located in the V1 Addendum
Note: For publishing purposes, the word "product" will be used to be denote all Oracle Utilities Application Framework based products.
version of this document.
Note: Advice in this document is primarily applicable to the latest version of the Oracle Utilities Application Framework at time of publication. Some of this advice may apply to other versions of the Oracle Utilities Application Framework and may be applied at site discretion.
Note: In some sections of this document the environment variable $SPLEBASE (or %SPLEBASE%) is used. This denotes the root location of the product install. Substitute the appropriate value for the environment used at your site. Conventions used in this whitepaper
The advice in this document applies to any product based upon Oracle Utilities Application Framework versions 2.1 and above. Refer to the installation documentation to verify which version of the framework applies to your version of the product. For publishing purposes the specific facilities and instructions for specific framework versions will be indicated with icons:
Framework V2.1 based products and above.
Advice or instructions marked with this icon apply to Oracle Utilities Application Framework V2.2 based products and above.
Advice or instructions marked with this icon apply to Oracle Utilities Application Framework V4.0 based products and above.
Advice or instructions marked with this icon apply to Oracle Utilities Application Framework V4.1 based products and above.
Introduction
Implementation of the product at any site introduces new practices into the IT group to maintain the health of the system and provide the expected service levels demanded by the business. While configuration of the product is important to the success of the implementation (and subsequence maintenance), adopting new practices can help ensure that the system will operate within acceptable tolerances and support the business goals.
This white paper outlines some common practices that have been implemented at sites, around the globe, that have proven beneficial to that site. They are documented here so that other sites may consider adopting similar practices and potentially deriving benefit from them as well.
The recommendations in this document are based upon experiences from various sites and internal studies, which have benefited from implementing the practices outlined in the document.
Background of Oracle Utilities Application Framework
The Oracle Utilities Application Framework is a reusable, scalable and flexible java based framework which allows other products to be built, configured and implemented in a standard way.
When Oracle Utilities Customer Care & Billing was migrated from V1 to V2, it was decided that the technical aspects of that product be separated to allow for reuse and independence from technical issues. The idea was that all the technical aspects would be concentrated in this separate product (i.e. a framework) and allow all products using the framework to concentrate on delivering superior functionality. The product was named the Oracle Utilities Application Framework (oufw is the
product code).
The technical components are contained in the Oracle Utilities Application Framework which can be summarized as follows:
• Metadata – The Oracle Utilities Application Framework is responsible for defining and using the metadata to define the runtime behavior of the product. All the metadata definition and management is contained within the Oracle Utilities Application Framework.
• UI Management – The Oracle Utilities Application Framework is responsible for defining and rendering the pages and responsible for ensuring the pages are in the appropriate format for the locale.
• Integration – The Oracle Utilities Application Framework is responsible for providing the integration points to the architecture. Refer to the Oracle Utilities Application Framework Integration Overview for more details.
• Tools – The Oracle Utilities Application Framework provides a common set of facilities and tools that can be used across all products.
• Technology – The Oracle Utilities Application Framework is responsible for all technology standards compliance, platform support and integration.
The figure below summarizes some of the facilities that the Oracle Utilities Application Framework provides: • Layout • Personalization • Scripting • Roles • Rules • Language • Localization • Business Services • Business Objects • Maintenance Objects • DB Structure Meta Data • Zones • Portal • Language • Locale • BPA Scripting • UI Maps UI Management • XAI • Web Services • Staging Integration • Scheduler • Dictionary • Conversion • To Do • Security • Auditing • Algorithm • Scripting Tools • Multi-DB • XML Services • J2EE • AJAX • SOA Technology
Figure 1 - Overview of Oracle Utilities Application Framework components
There are a number of products from the Tax and Utilities Global Business Unit as well as from the Financial Services Global Business Unit that are built upon the Oracle Utilities Application Framework. These products require the Oracle Utilities Application Framework to be installed first and then the product itself installed onto the framework to complete the installation process.
There are a number of key benefits that the Oracle Utilities Application Framework provides to these products:
• Common facilities – The Oracle Utilities Application Framework provides a standard set of technical facilities that mean that products can concentrate in the unique aspects of their markets rather than making technical decisions.
• Common methods of configuration – The Oracle Utilities Application Framework standardizes the technical configuration process for a product. Customers can effectively reuse the configuration process across products.
• Common methods of implementation - The Oracle Utilities Application Framework standardizes the technical aspects of a product implementation. Customers can effectively reuse the technical implementation process across products.
• Quicker adoption of new technologies – As new technologies and standards are identified as being important for the product line, they can be integrated centrally benefiting multiple products.
• Multi-lingual and Multi-platform - The Oracle Utilities Application Framework allows the products to be offered in more markets and across multiple platforms for maximized flexibility
• Cross product reuse – As enhancements to the Oracle Utilities Application Framework are identified by a particular product, all products can potentially benefit from the enhancement.
Note: Use of the Oracle Utilities Application Framework does not preclude the introduction of product specific technologies or facilities to satisfy markets. The framework minimizes the need and assists in the quick integration of a new product specific piece of technology (if necessary).
Installation Best Practices
During the initial phases of an implementation, a copy of the product will need to be installed. During the implementation a number of copies of additional copies will be installed, including production. This section outlines some practices that customers have used to make this process smooth.
Read the Installation Guide
One of the most important pieces of advice in this document to implement is to read the installation guide. It provides valuable information about what needs to be installed and configured as well the order of the installation. Failure to follow the instructions can cause unnecessary delays to the installation.
If you are upgrading to a new version, read the new installation guide as well as it will contain instructions on how to upgrade to the new version as well as details of what has been changed in the new version.
Ensure the prerequisites are installed
When installing there is a number of third party prerequisite software that must be obtained (i.e. downloaded) prior to the actual installation of product software can commence. Read the Installation Guide and Quick Installation Guide to download and install the prerequisite software prior to installing product.
Note: For customers who are upgrading, the installation of product and its related third party software is designed so that more than one version of product can co-exist.
Environment Practices
Note: There is a more detailed discussion of effective Environment Management in the Environment Management
document of the Software Configuration Management series of whitepaper. Refer to that document for further advice.
When installing product at a site, each copy of product is regarded as an environment to perform a particular task or group of tasks. Typically, without planning this can lead to a larger than anticipated number of environments. This can have a possible negative flow on effect by increasing overall maintenance effort and increasing resource usage (hardware and people), which may in turn cause delays in implementations. Customers to minimize the impact of environments on their implementations have used the following advice:
• At the start of the implementation decide the number of environments to use. Keep this to a minimum and consider sharing environments between tasks. Another technique associated with this is to specify an end date for each environment. This is the date the environment can be removed from the implementation. This can force rethinks on the number of environments that are to be used at an implementation and may force sharing.
• For each environment, consider the impact on the hardware and maintenance effort including the following:
• The time and resources it takes to install the environment.
• The time and resources it takes to keep the environment up to date including application of single fixes, rollups/service packs and upgrades. Do not forget application and management of customization builds.
• The time and resources to maintain the ConfigLab and Archiving facilities for multiple environments, if used at an implementation. This includes the setup and regular migrations that will be performed.
Note: ConfigLab and Archiving only apply to certain Oracle Utilities Application Framework products
• The time and resources it takes to backup and restore environments on a regular basis. In some implementations, having different backup schemes for environments based upon tasks and update frequency for that environment, i.e. more updated = more frequent backup, may provide some savings.
• The time and resources to manage the disk space for each environment including regular cleanups.
Environments may be setup so that the database can be reduced to a single database instance with each environment having a different schema/owner. This will reduce the memory footprint of the DBMS on the machine but may reduce availability of the database instance is shut down (all environments are
affected). For non-production, most customers create a database instance, for Oracle sites, for each environment and one database subsystem, for DB2/UDB sites, customers for each environment.
Using multiple administrators
By default, when installing product a single administrator account (usually referred to as splsys) is
used to install and own the product. This is the default behavior of the installation and apart from specifying a different userid than the default splsys, it is possible to use other userids to own all or
individual environments.
For example, if the conversion team wishes to have the ability to start, stop and monitor their own environments, you can create another administrator account and install their copies of product using that userid. This allows the conversion team to control their own environments. If you did not have the ability to use multiple administrators than they may have access to all environments (as you would have to give them access to the splsys account).
One of the advantages of this approach is that you can delegate management of a copy product to other teams without compromising other environments. Another advantage is that you can quickly identify UNIX resource ownership by user rather than trying using other methods.
The only disadvantage is that to manage all copies of product you will need to logon to the additional administration accounts that own the various copies.
Checking Java Installation
Note: For Oracle Utilities Application Framework V4.1 and above , it is possible to use two differing Java
Virtual Machine versions if COBOL is used as it is possible to configure the CHILD_JVM_JAVA_HOME
separately. If this is the case then repeat this process for the CHILD_JVM_JAVA_HOME JVM.
When the product is installed one of the first perquisites to be verified is the version of Java installed and referenced using the environment variable $JAVA_HOME (or %JAVA_HOME% on Windows).
Whilst the product checks this version it can be checked manually prior to installation (and at anytime) using the following commands:
$JAVA_HOME/bin/java –version Or (on Windows): %JAVA_HOME%\bin\java –version For example: #> $JAVA_HOME/bin/java -version Linux: java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07) Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
#> $JAVA_HOME/bin/java -version AIX:
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap6460sr7ifix-20100220_01(SR7+IZ70326))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc64-64 jvmap6460sr7-20100219_54049 (JIT enabled, AOT enabled) J9VM - 20100219_054049 JIT - r9_20091123_13891 GC - 20100216_AA) JCL - 20091202_01 C:\> %JAVA_HOME%\bin\java -version Windows: java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
#> $JAVA_HOME/bin/java -version HP-UX:
java version "1.6.0.10"
Java(TM) SE Runtime Environment (build 1.6.0.10-jinteg_11_mar_2011_09_19-b00)
Java HotSpot(TM) Server VM (build 19.1-b02-jinteg:2011mar11-07:33, mixed mode)
Note: Verify the java version number and operating mode (32/64 bit) against the Quick Installation Guide provided with the product.
Checking COBOL Installation
Note: Not all products support COBOL based extensions; therefore this section may not apply. Check with your installation guide for more details.
By default, when the COBOL runtime is installed a license file is required to complete the installation as outlined in the Quick Installation Guide for the product. The license can be tracked using the process outlined in the Installation Guide or the following command:
cobsje -J $JAVA_HOME
Note: This command should be executed AFTER executing the splenviron[.sh] utility to initialize the environment variables used by the utilities and place the COBOL runtime in the PATH.
If the license is NOT installed the response should be similar to the text below:
Error - No license key detected. Application Server requires a license key in order to execute.
Well this message indicates that there is an issue dealing with the license key on the server. If this message appears to remedy the situation it is recommended that the COBOL runtime be re-installed and re-initialized the license key using apptrack as per the Installation Guide for the product.
If the license key is installed correctly the cobjse utility will return a message similar to the following:
#> cobsje -J $JAVA_HOME Java version = 1.6.0_20
Java vendor = Sun Microsystems Inc. Java OS name = SunOS
Java OS arch = sparcv9 Java OS version = 5.10
Additionally the 64 Bit version of COBOL is required to be used for 64 bit platforms as indicated in the Installation Guide for the product. To verify that the COBOL runtime is 64 bit the f
cob –v
This should return the output similar to the following:
cob64 -C nolist -CC -KPIC -A -KPIC -N PIC -v I see no work
The cob64
Additional Oracle WebLogic Installation settings
indicates the use of 64 bit COBOL.
When installing the Oracle WebLogic Server product as a prerequisite installation there are a number of additional advice that can be taken into account to optimize the installation:
• Avoid installing the Oracle WebLogic Server in the home directories of users for Linux installations. Other application Linux users, such as the Oracle Utilities Application Framework administration user, should not access the home directories or any subdirectory of the home directory.
• If the platform uses a hybrid 32/64 bit JDK, such as HP-PA, HPIA and Solaris64, then include the –d64 flag when initiating the installation of Oracle WebLogic Server to ensure that 64 bit is used. For example, if installing in graphical mode using the Package installer:
java -d64 -jar wlsversion_generic.jar HP-UX/Unix:
java -Xmx1024m -jar wlsversion_generic.jar Solaris64:
java -D64 -jar wlsversion_generic.jar
COBOL License Errors in Batch
If the product has COBOL based background processes and the COBOL license is not installed correctly (see Checking COBOL Installation for more details) then an error message similar to the example below will be displayed:
…cobjrun64: com.splwg.base.api.batch.ThreadPoolWorker.main ended due to an exception
Exception in thread "main"
com.splwg.shared.common.LoggedException:
The following stacked messages were reported as the LoggedException was rethrown:
com.splwg.base.support.context.ContextFactory.createDefaultCo ntext(ContextFactory.java:569): error initializing test context
To resolve this issue refer to the instructions in the Quick Installation Guide about installing the COBOL license.
Location of Installation Logs
When installing the product a log file is written for each component installed (Oracle Utilities Application Framework is a component of the installation, the product install is a separate installation component).
The log contains all the messages pertaining to the installation process including any error messages for installation errors encountered. The log is located in the directory the installation was initiated from and the name is in the format:
install_
<product>
_<environment>
.log Where:<product>
Product code of the product component you are installing. For example, FW = Oracle Utilities Application Framework<environment>
Name of the environment that is being installed. Check this log for any error messages during the installation process.XML Parser Errors in installation
The Oracle Client is used by the installers and utilities to provide access to the Perl runtime and associated libraries used by the installer and utilities. This is the first configuration question in the installation process.
The Oracle Client can be installed (if the product is not installed on a machine containing the Oracle Database software) or an existing ORACLE_HOME can be specified if the Oracle Database software is
installed already on the machine (as it contains the Oracle Client in the installation). The value is stored in the ENVIRON.INI as the value for parameter ORACLE_CLIENT_HOME.
Note: For Windows Server environments, both 32 bit client MUST be installed for use with the installation utilities. This is even if the 64 Bit Oracle Database software is installed on the same machine.
If the Oracle Client or ORACLE_HOME is invalid then the following error will be returned by the installation utilities (and other installs):
Can't locate XML/Parser.pm in @INC (@INC contains: … BEGIN failed--compilation aborted at
data/bin/perllib/SPL/splXMLParser.pm line 3. Compilation failed in require at
data/bin/perllib/SPL/splExternal.pm line 10. BEGIN failed--compilation aborted at
data/bin/perllib/SPL/splExternal.pm line 10.
Compilation failed in require at install.plx line 25. BEGIN failed--compilation aborted at install.plx line 25. Error: install.plx didn't finish successfully. Exiting. Ensure that the ORACLE_CLIENT_HOME includes the perl subdirectory to rectify this issue. AppViewer cannot Co-Exist in Archive Mode
The Application Viewer is an optional component that provides a meta data viewer for data dictionary, batch controls, to do types, javadoc etc.. It is primarily designed for use by the developers and key architects at your site1
If the site decides to move between expanded mode .
2
AppViewer.war cannot co exist with AppViewer directory
to archive mode (or visa versa) on Oracle WebLogic installations then when executing initialSetup[.sh] the product may report the
following error:
For archive mode the AppViewer.war is required and for expanded mode the AppViewer
directory is used. The error message indicates both exist. This can occur when the expanded mode is changed and the initialSetup[.sh] utility. To resolve this issue, depended on the value of WEB_ISEXPANDED parameter, the following recommended:
TABLE 1 – APPVIEWER CO-EXIST ERROR RESOLUTION WEB_ISEXPANDED VALUE COMMENTS
1 Generally customers do not implement the AppViewer in production.
2 Expanded mode is only available for Oracle WebLogic and Oracle Utilities Application Framework V4.0
WEB_ISEXPANDED VALUE COMMENTS
true Remove or rename AppViewer.war
false Remove or rename AppViewer directory.
Implementing Secure Protocols (https/t3s)
Note: For customers using Oracle Utilities Application Framework V4.1 and above the use of secure protocol can be enabled by specifying a HTTPS port using the configureEnv[.sh]–a utility and specifying a port
number under WebLogic SSL Port Number.
Note: The instructions below are designed for Oracle WebLogic installations only. Additional steps are required in IBM WebSphere to enable secure transmission of data. Refer to the appropriate documentation for additional advice.
Note: Some of the instructions below recommend changes to individual configuration files. These manual changes may be overridden by executions of the initialSetup[.sh] utility back to the product defaults. To retain the changes across invocations of the initialSetup[.sh] utility it is recommended to use custom templates and/or configuration file user exits. Refer to the Server Administration or Configuration and Operations Guide
By default, all transmission of data is using the http and/or t3
for more details of implementing custom templates and/or configuration file user exits.
3
Note: Enabling https or t3s may result in higher resource usage due to the resource requirements to encrypt and decrypt data. The extent of the resource usage will vary from platform to platform. It is advised that customer compare performance between secure and non-secure protocols before committing to secure protocols.
protocol between the various tiers of the product. Whilst this default situation is sufficient for the vast majority of customers, some sites wish to implement the secure versions of these protocols for use with the product. The reason for their use is typically to encrypt all transmission of data from the client to the server and within the server tiers themselves.
To implement the more secure protocol requires a number of changes and additional facilities to be enabled. The process below outlines the generic process for implementing the secure protocol:
• Obtain a digital certificate or generate a certificate from keytool for your organization from
a trusted certificate authority. This is used for the encryption/decryption of data using the protocol.
Note: The certificate provided with the J2EE Web Application Server installation is to be used for demonstration purposes only. It is highly recommended that alternative certificate be used for production environments.
3 The t3 protocol is only used for sites that have separated the Web Application and Business Application
tiers using the Oracle WebLogic platform on selected versions of the Oracle Utilities Application Framework. The iiop protocol is used for the same scenario but for IBM WebSphere platforms.
• Configure J2EE Web Application Server SSL support to use the certificate as outlined in the documentation sites outlined below4
TABLE 2 – J2EE SSL CONFIGURATION
: WEB APPLICATION SERVER REFERENCE
Oracle WebLogic 10 MP2 http://download.oracle.com/docs/cd/E13222_01/wls/docs100/secmanage/ssl.html Oracle WebLogic 10.3.x http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secmanage/ssl.html
Oracle WebLogic 10.3.3 http://download.oracle.com/docs/cd/E14571_01/web.1111/e13707/ssl.htm IBM WebSphere 6.1 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
IBM WebSphere 7.x http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp
• Enable the HTTPS port on your environment using the console provided with your J2EE Web Application Server. Remember to reference the certificate you processed in the previous step.
Note: For customers using Oracle WebLogic on Oracle Utilities Application Framework V4.1 and above the setting for WebLogic SSL Port Number will enable this facility without the need of the console.
Note: If changes are made to the console then to retain the change across upgrades and service packs it is recommended to use custom templates or user exits to retain the setting. Refer to the Server Administration or
Configuration and Operations Guide
• Examine the $SPLEBASE/etc/conf directory (or %SPLEBASE%\etc\conf on
Windows), unless otherwise indicated, for configuration files that use the protocol:
for more details of implementing custom templates. For Oracle WebLogic customers the config.xml templates may require changes.
TABLE 3 – SSL CONFIGURATION FILES CONFIGURATION FILE CHANGES
spl.properties Change references to the t3 protocol to t3s, if exists
Change references to the http protocol to https with the SSL port replacing the HTTP ports
web.xml Change references to the http protocol to https with the SSL port replacing the HTTP ports
web.xml.XAIApp Change references to the http protocol to https with the SSL port replacing the HTTP ports
ejb-jar.xml Change references to the http protocol to https with the SSL port replacing the HTTP ports. This file is located under $SPLEBASE/splapp/businessapp/config/META-INF (or
%SPLEBASE%\splapp\businessapp\config\META-INF on Windows)
Note: If these files are changed they may revert to the product template versions across service packs and upgrades. To retain change across service packs and upgrades it is advised to use custom templates and/or user exits. Refer to the Server Administration or Configuration and Operations Guide
4 For Oracle WebLogic customers, refer to the section Configuring Identity and Trust for the additional steps.
• Shutdown the J2EE Web Application Server to prepare to reflect the changes.
• Run the initialSetup[.sh] –w command to reflect the changes into the server files
• Restart the J2EE Web Application Server.
• Ensure that any Feature Configuration options using the product browser that use the HTTP protocol as part of their options are also converted to HTTPS and the appropriate port number. Use the Admin F Feature Configuration menu option to check each of them. The
Features will vary from product to product and version to version.
• Ensure that any XAI JNDI Server provider URLS using the product browser that use the http/t3 protocol as part of their options are also converted to https/t3s and the appropriate port number. Use the Admin X XAI JNDI Server menu option to maintain the JNDI
server.
• Any customization that refers to the HTTP protocol such as custom algorithms or service scripts must also be converted from HTTP to HTTPs.
• For customers using the Multi-Purpose Listener (MPL), the use of secure protocol should alter the $JAVA_HOME\jre\lib\security\java.security (or %JAVA_HOME%/jre/lib/security/java.security on Windows) file to enable
SSL support. Modify the WLPORT entry in the
$SPLEBASE\splapp\mpl\MPLParamaterInfo.xml (or
%SPLEBASE%/splapp/mpl/MPLParamaterInfo.xml on Windows) to use the
SSL Port.
TABLE 4 – JAVA SSL CONFIGURATION
VENDOR CHANGES
Oracle WebLogic Refer to
http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html IBM WebSphere ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl
ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl
General Best Practices
This section outlines some general practices that have been successfully implemented at various product sites.
Limiting production Access
One of the guiding principles at successful sites is that production access is restricted to the processing necessary to run their business. This means that other non-mainstream work, such as ad-hoc queries, are either very limited or NOT performed on production at all. This may sound logical but a few sites
have allowed access to production from inappropriate sources, which has had an adverse impact on performance.
For example, it is not appropriate to allow people access to the production database through ad-hoc query tools (i.e. such as DB2 Control Center, SQL Developer, SQL*Plus etc). The freestyle nature of these tools can allow a single user to wreak havoc on performance with a single inefficient SQL statement.
The database is not optimized for such unexpected traffic. Removal of this potentially inefficient access can typically, improve performance.
Regular Collection and Reporting of Performance Metrics
One of the major practices that successful customers perform is the regular collection of performance statistics, analysis of the statistics and reporting pertinent information to relevant parties within the organization as well as Oracle. Collection of such information can help identify bottlenecks and badly performing transactions, as well as help understand how the product is being used at your site. They offer proof of both good and bad performance and typically allow sites to gauge the extent of any issue.
The product contains a number of collection points in the architecture that are useful for real time and offline collection of performance related data. Information on the collection points are documented in the whitepaper Performance Troubleshooting Guides. Using the guide, decide which statistics are important to the various stakeholders at your site, decide the frequency of collection and format of any output to be provided. Use your sites Service Level Agreement (SLA), if it exists, for guidance on what to report.
Respecting Record Ownership
In Oracle Utilities Application Framework V2.x and above, the concept of ownership of records was introduced. A data element was added to data to indicate the owner of the object and is used to protect key data supplied with the product from alteration or deletion. It is used by the online system to prevent the online users accidentally causing critical data failures. The owner is also used by the upgrade tools protect the data from deletion.
The ownership of the record determines what you can do with that record:
• Framework - If the record is owned by Framework then implementation teams cannot alter or delete the record from the database as it is deemed critical to the running of the Framework. This is usually meta-data deemed important by the Framework team. For example the user SYSUSER is owned by the Framework.
• Product - If the record is owned by the product (denoted by the product name or Base) then some changes are permitted but deletion is not permitted as the record as it is necessary for the operation of the product. The amount of change will vary according to the object definition.
• Customer Modification - If the record is owned by Customer Modification then the implementation has added the record. The implementation can change and delete the record (if it is allowed by the business rules).
Basically you can only delete records that are owned by Customer Modification.
It is possible to alter or delete the records at the database level, if permitted by database permissions, but doing this will produce unexpected results so respect the ownership of the records.
Backup of Logs
By default product removes existing log files from $SPLSYSTEMLOGS (or %SPLSYSTEMLOGS%
for Windows platforms) upon restart. This is the default behavior of the product but may not be desirable for effective analysis as the logs disappear.
To override this behavior the following needs to be done:
• A directory needs to be created to house the log files. Most sites create a common directory for all environments on a machine. The size allocation of that directory will depend on how long you wish to retain the log files. It is generally recommended that logs be retained for post analysis and then archived (according to site standards) after processing to keep this directory relevant. Typically customers create a subdirectory under <SPLAPP> to hold the files.
• Set the SPLBCKLOGDIR environment variable in the .profile (for all environments) or $SPLEBASE/scripts/cmenv.sh (for individual environments) to the location you
specified in the first step. For Windows platforms then the environment can be set in your Windows profile or using %SPLEBASE%/scripts/cmenv.cmd.
• Logs will be backed up at the location specified in the format
<datetime>.<environment>.<filename> where <datetime> is the date and
time of the restart, <environment> is the id of the environment (taken from the SPLENVIRON environment variable) and <filename> is the original filename of the log.
Once the logs have been saved you must use log retention principles to manage the logs under
SPLBCKLOGDIR to meet your sites standards. Most sites archive the logs to tape or simply compress
them after post processing the log files (See Post Process Logs for more details on post processing).
Post Process Logs
The logs written by the various components of product provide valuable performance and diagnostic information. Some sites have designed and developed methods to post process those logs to extract important information and then report on it to relevant parties.
If the logs are retained by your site (see Backup of Logs for details on this process), the consider post processing the logs on a regular basis before they are archived or deleted permanently. One approach is to extract that information from the logs and loading the extracted data into some analysis repository
Figure 2 – Post Processing Logs
Details of the logs written by the product are documented in the Performance Troubleshooting Guide. Use these guides to determine what data to extract from the logs for post processing.
Check Logs For Errors
One of the most important tasks for a site is to regularly track errors output into logs. Whenever an error occurs in product, an error record is written to the appropriate log for analysis. Some sites regularly check these logs for these errors and using the information in the log, address the error condition.
Figure 3 – Filtering Logs
Viewing and checking for errors on a regular basis to quickly reduce the amount of error that may occur can detect trends and common problems. The Performance Troubleshooting Guide outlines the logs and error conditions contained within those logs.
Optimize Operating System Settings
One of the most important configuration settings for product is the operating system itself. The Installation Guide
Typically, the optimization of the operating system is performed during the implementation and uses the following principles:
provided with your product highlights the fact that the operating system parameters MUST be set to optimal values for the product to perform optimally. Some sites have experienced large improvements in performance by heeding this advice. Sites that have decided to ignore this advice have experience bad performance till the settings were corrected.
• The value of an individual operating system setting is the maximum value of any product on that machine. For example, typically if Oracle or DB2 is contained on a machine, the values for those products are used. The settings used in this way are usually are sufficient for the other products on that machine.
• If the machine is dedicated for a particular product or tier, then refer to the documentation in the installation guide and the particular vendor's site for further advice on setting up the operating system in an optimal state.
Optimize connection pools
One of the settings that will affect performance is the size of the connection pools at each layer in the architecture. Insufficient pool sizes can cause unnecessary transaction queues that can cause unnecessary delays. Conversely setting the pool sizes too high can cause higher than usual resource usage on a machine also causing adverse performance. So a balance needs to be struck for optimization.
During the implementation the size of the connection pools is determined and configured (with relevant growth tolerances) depending on the usage patterns and expected peak/normal traffic levels. The goal, typically, is to have enough connections available at normal traffic levels to minimize queuing and also have the right tolerances to cater for any expected peak periods. Therefore, it is recommended:
• Set the number of initial connections to the normal number of connections expected. Remember this is not the number of users that are connecting but the expected number of concurrent connections under normal load.
• Set the tolerances for pool growth (usually a maximum pool size and a connection increment) to the peak load expected at any time. This tolerance will have to be tracked to determine the
optimal level. Do not be tempted to set this to a very large value as memory and network bandwidth calculations are usually dependant on the values specified and wastage of resources needs to be minimized.
The product has up to three connection pools to configure:
• Client connections and Business Server connections – These are the number of active connections supported on the Web Application Server from the client machines. Remember that in an OLTP product (such as product) the number of connections allocated is always less that the number of users on the system. It needs to be sufficient to cater for the number of actively running transactions at any given point of time. In Oracle Utilities Application Framework V2.2 and above, it is possible to separate the Web Application Server and Business Application Server. If this configuration is used then it is recommended that the Business Application Server connection pools be set to the same values as the Web Application Server connection pools. Refer to Configuring the Client Thread Pool Size for more information about pool sizing.
Note: The Client connections and Business Sever connections are managed within the J2EE Web Application Server software.
• Database connections – These are the number of pooled connections to the database. The Framework holds these connections open so that the overhead of opening and closing connections is minimized. For Version 2.x of the product, the number of connections allocated is dictated in each individual web applications hibernate.properties file
using c3p0 connection pool (In Oracle Utilities Application Framework V4.0 the connection pooling is now handled by Universal Connection Pool (UCP)).
The figure below illustrates the connection pools available for each version of the Oracle Utilities Application Framework:
Database Connections
(via Hibernate/c3p0)
Client Connections
Client Web Application Server Business Application Server Database ServerV2.x
Business Server
Connections
Database Connections
(via Hibernate/c3p0/UCP)
Client Connections
Client Web Application Server Business Application Server Database ServerV2.2 and above
Figure 4 – Connection Pools by version of the Oracle Utilities Application Framework
Refer to the whitepaper Server Administration Guides (also known as Operations and Configuration Guides) provided with your product for advice on the configuration and monitoring of the connection pools.
Read the available manuals
Note: Due to the ISV licensing of Web Application Servers, there may not be as much details as other platforms. Refer to the vendor’s site for more detailed information.
The Oracle Utilities Application Framework product includes a set of documentation that should be downloaded with the software and read as part of the implementation and support of product. The following technical documentation is available on the distribution web:
• Installation Guide – Installation documentation for the base product including supported platforms and required patches.
• Server Administration Guide/Operations And Configuration Guide – Documentation on how to configure and operate the server components of the product.
• Developer documentation – This is detailed documentation on the customization aspects of the implementation including standards for implementations. This includes:
• Application Logs - List of logs produced by the development and deployment process.
• COBOL Programming Standards - List of naming conventions and programming advice used for COBOL modules including algorithms, Maintenance Objects etc.
Note: COBOL documentation only applies to products that have support for COBOL based customizations.
• Java Programming Standards - List of naming conventions and programming advice used for java modules including algorithms, Maintenance Objects etc
• Java Annotations – Brief overview of the product annotation classes available to the java developer.
• Public API – Overview of the API available to the java programmer.
• SQL Programming Standards - Documentation of the SQL standards used in product.
• HSQL Programming standards - Documentation of the Hibernate SQL standards used in product.
• User Interface Design Standards - Documentation about the User Interface standards used by product
• Database Design Standards - Documentation of the database standards employed in product including naming conventions for tables and columns and layout advice. • System Table Guide - Documentation of the meta data tables used in the
development process.
• Development Overview - An introduction to the development process and internals of product.
• Packaging Utilities - Documentation of the tools provided to package custom builds
• Key Generation – Overview of the routines and tables used for generation of random keys in the product.
• Application Workbench Overview – An overview of the Application Workbench component of the SDK.
• User Guide – A developer’s cookbook and users guide to the SDK.
• Utilities Documentation – This is detailed guides to the various tools supplied with product including:
• Background Processing – Details of all the background processes available with the product.
• Reports – Details of the reporting interface available with the product including installation of the algorithm and configuration of the reporting interface.
• CTI/IVR Integration – An overview of the installation, capabilities and configuration of the CTI/IVR integration components delivered with the product. • Framework/System Wide Standards – An overview of the various UI standards
employed by the product.
• Application Security – An overview of the authorization security model used in the product including guidelines for configuration.
• User Interface Tools – An overview of the meta data tools available for the user interface including menus, navigation keys etc.
• Zone Configuration – An overview of how to configure the zones and portals supplied with the product.
• Database Tools – An overview of the Meta data tools available for maintenance object, table and field definition including auditing.
• Algorithms – An overview of all the algorithms supplied with the product.
• Scripting – Details of the Business Process Scripting engine supplied with the product including configuration.
• Application Viewer – Overview of the maintenance and operation of the Data Dictionary and code view supplied with the product.
• XAI – Detailed overview and configuration of the Web Services/XML Application Integration component of the product.
• LDAP Import – Detailed overview of the LDAP import function supported by the product to synchronize LDAP information with the authorization information stored in the product.
• Batch Operations and Configuration Guide - Details of the configuration settings and common operations for the batch component of product.
Technical Documentation Set Whitepapers available
Apart from the product based documentation there are a number of whitepapers that provide specialist and supplemental information for use during and post implementation. The table below lists the current available technical documentation as well as the Knowledge base Id within My Oracle Support where the documentation resides:
TABLE 5 – TECHNICAL WHITE PAPERS
DOC ID DOCUMENT TITLE CONTENTS
559880.1 ConfigLab Design Guidelines A whitepaper outlining how to design, setup and monitor a ConfigLab solution for an implementation. This is a companion document to the Software Configuration Management Series.
560382.1 Performance Troubleshooting Guideline Series
A series of whitepapers outlining the tracking points available in the architecture for performance and a troubleshooting guide based upon common problems.
560401.1 Software Configuration Management Series This series of documents outlines a set of generic processes (that can be used as part of the site processes) for managing code and data changes. This series includes documents that cover concepts, change management, defect management, release management, version management, distribution of code and data, management of environments and auditing configuration.
773473.1 Oracle Utilities Application Framework Security Overview
A whitepaper outlining the security facilities in the Oracle Utilities Application Framework.
774783.1 LDAP Integration for Oracle Utilities Application Framework based products
A whitepaper outlining the common process for integrating an external LDAP based security repository with the framework. 789060.1 Oracle Utilities Application Framework
Integration Overview
A whitepaper outlining all the various common integration techniques used with the product (with case studies). 799912.1 Single Sign On Integration for Oracle Utilities
Application Framework based products
A whitepaper outlining a generic process for integrating an SSO product with the Oracle Utilities Application Framework. 807068.1 Oracle Utilities Application Framework
Architecture Guidelines
A whitepaper outlining the different variations of architecture that can be considered. Each variation will include advice on configuration and other considerations.
836362.1 Batch Best Practices for Oracle Utilities Application Framework based products
A whitepaper outlining the common and best practices implemented by sites all over the world relating to batch. 856854.1 Technical Best Practices V1 Addendum Addendum to Technical Best Practices for Oracle Utilities
DOC ID DOCUMENT TITLE CONTENTS specific advice.
942074.1 XAI Best Practices This whitepaper outlines the common integration tasks and best practices for the Web Services Integration provided by the Oracle Utilities Application Framework.
970785.1 Oracle Identity Manager Integration Overview This whitepaper outlines the principals of the prebuilt integration between Oracle Utilities Application Framework Based Products and Oracle Identity Manager used to provision user and user group security information. 1068958.1 Production Environment Configuration
Guidelines
This whitepaper outlines common production level settings for Oracle Utilities Application Framework products.
1177265.1 What's New in Oracle Utilities Application Framework V4?
This whitepaper outlines the changes since the V2.2 release of Oracle Utilities Application Framework.
1290700.1 Database Vault Integration This whitepaper outlines the Database Vault integration available with Oracle Utilities Application Framework V4.1 and above.
1299732.1 BI Publisher Integration Guidelines This whitepaper outlines some guidelines for integration available with Oracle BI Publisher for reporting.
1308161.1 Oracle SOA Suite Integration This whitepaper outlines the integration between Oracle SOA Suite and the Oracle Utilities Application Framework. 1308165.1 MPL Best Practices Addendum to the XAI Best Practices focusing on the
Multi-purpose Listener.
1308181.1 Oracle WebLogic JMS Integration This whitepaper outlines the integration between Oracle WebLogic JMS and the Oracle Utilities Application Framework for Oracle Utilities Application Framework V4.1 and above. These features are also available for Oracle Utilities Application Framework V2.2 via patches.
This documentation is updated regularly with each release of product with new and improved information and advice. Announcements of updates to whitepapers may be tracked via http://blogs.oracle.com/theshortenspot or http://www.twitter.com/theshortenspot.
Implementing Industry Processes
Implementing a product such as product can mean that an IT has to adopt new processes in the company to cater for the new product in their portfolio of applications. This is not unique to product. Any new product that is implemented into an IT portfolio not only requires business process changes but also IT process changes.
In the IT industry at the moment most software application vendors are realizing that implementing a product is not just simply configuration, there are some change management that needs to be performed with the IT group. Luckily the industry has started to adopt some sort of standard framework that helps define an IT business and the processes necessary to run that business. This framework is called the IT Infrastructure Library.
IT Infrastructure Library (ITIL) is a set of consistent and comprehensive documentation of best practice for IT Service Management. Used by many hundreds of organizations around the world, a whole ITIL philosophy has grown up around the guidance contained within the ITIL books and the supporting professional qualification scheme. ITIL consists of a series of books giving guidance on the provision of quality IT services, and on the accommodation and environmental facilities needed to support IT. ITIL has been developed in recognition of organizations' growing dependency on IT and embodies best practices for IT Service Management.
The ethos behind the development of ITIL is the recognition that organizations are becoming increasingly dependent on IT in order to satisfy their corporate aims and meet their business needs. This leads to an increased requirement for high quality IT services. ITIL provides the foundation for quality IT Service Management. The widespread adoption of the ITIL guidance has encouraged organizations worldwide, both commercial and non-proprietary, to develop supporting products as part of a shared "ITIL Philosophy".
For more information about ITIL refer to http://www.oracle.com/itil
Using Automated Test Tools
Some of the sites around the world use third party testing tools for performance and regression testing. While product is open in terms of the standard it uses not all test tools are applicable to simulate exact expected traffic. In choosing an automated testing tool that you can use with product the following must be supported:
• Support for HTTP – The automated test tool must be able to trap HTTP traffic, as this is the traffic used by the product. If the tool supports HTTPS, and you intend to use the HTTPS protocol, be careful as support for HTTPS varies greatly with most testing tools. • JSP Support – product uses JSP coding to perform most functions. A tool that can leverage
this technology will enable screens to be recognized.
• Support simulation of IE caching – The product client utilizes the Internet Explorer cache to locally hold an image of the screen for performance reasons. The automated test tools needs to be able to simulate this behavior otherwise results will not reflect reality.
• Support Pop up screens – The product utilizes pop up windows for some lists and some searches as well as confirmation and error messages. The automated test tool needs to be able to support the use of these to adequately simulate product transactions.
• Valid calls – Ensure that the test tools simulate valid calls to the product. A valid call is a call that the browser user interface issues to the web server or a call that the XAI component will accept. An invalid call that is sent by a test tool to the product may result in unpredictable results. Check EVERY call is valid (try them with browser user interface to verify the call) and fix any invalid calls.
• Oracle Application Test Suite (http://www.oracle.com/enterprise_manager/application-quality-solutions.html )
• Borland Silk Performer (http://www.borland.com/us/products/silk/silkperformer/index.html )
• Mercury Load Runner (http://www.mercury.com/us/products/performance-center/loadrunner/ )
• IBM Rational Performance Tester (http://www-304.ibm.com/jct03002c/software/awdtools/tester/performance/index.html )
Custom Environment Variables or JAR files
Implementations of the product sometimes use third party java classes or third party tools to perform specialist functions. Sometimes these tools require additional configurations settings that can be integrated in the infrastructure provided by the product. For example, if you use a third party jar file to be called by the product then you will need to add it to the CLASSPATH to ensure it is picked up by
the runtime.
Luckily, there is a feature that allows custom environment variables settings and other commands to be run after the splenviron.sh script (or splenviron.cmd on Windows) has been executed.
To do this create a cmenv.sh script (or cmenv.cmd on Windows) in the $SPLEBASE/scripts
directory (%SPLEBASE%\scripts on Windows) with the commands you want to execute. For
example, if an implementation used AXIS2 jar files to call web services. Well you place the AXIS2 jar files in a central location (e.g. /axis/lib in this example) and create the cmenv.sh/cmenv.cmd
script with the lines:
export CLASSPATH=/axis/lib/axis.jar;$CLASSPATH or
set CLASSPATH=c:\axis\lib\axis.jar:%CLASSPATH%
When splenviron.sh script (or splenviron.cmd on Windows) runs it will look in the scripts directory for the existence of the cmenv.sh script (or cmenv.cmd on Windows) and
executes it.
Additional to this, it is possible to do this WITHOUT adding the cmenv.sh script (or cmenv.cmd on Windows). Set the CMENV environment variable to the location of a script, with the above commands
contained, BEFORE running any command and splenviron.sh script (or splenviron.cmd
on Windows).
The CMENV facility is for global changes as it applies across all environments and the cmenv.sh/cmenv.cmd solution is per environment. You can use both as CMENV is run first then cmenv.sh/cmenv.cmd.
Note: It is possible, using this technique, to manipulate any environment variable used by the product but this is not recommended.
Help and AppViewer can be used standalone
The Help and AppViewer components may be used in standalone mode (a.k.a. offline mode). This can be handy for developers, designers and architects who do wish to access up to date information without the need to connect to a live copy of the product at their site.
Under the splapp/applications directory on V2.x/V4.x or cisdomain/applications
on V1.x, there are two directories named help and appViewer. These contain the online help and
AppViewer application and data. Copy these directories to your desired target machine (such as a shared drive, web server or your laptop).
Note: On some platforms the directories are contained within WAR files named help.war and
appViewer.war, these will need to be decompressed on the target platform using an appropriate utility such as jar from the Java SDK or 7Zip (or similar).
To operate the applications in standalone mode you will need to open the following files in your web browser:
• appViewer.html – Application Viewer startup file. It is also possible to reconfigure the
behavior of the standalone copy by altering the config.xml file located in the config
subdirectory of the AppViewer.
• SPLHelp.html – Help file located in language subdirectory (ENG = English et al). Note: The AppViewer and Help applications are only supported in the browsers supported by the product. Re-Register only when necessary
Note: Not all Oracle Utilities Application Framework products have the supplied ConfigLab or Archiving functionality.
As part of the ConfigLab definition process it is necessary to register the environments to be used by ConfigLab. The registration process creates remote synonyms (the database technology used to achieve this will vary from database type to database type) and an environment reference in the database. One of the processes that must be performed is that the environments must be re-registered after
upgrades (product as well as customization upgrades) as the upgrade may remove or add a new table or view and this needs to be reflected in the synonyms.
The registration process does not need to be executed if the product upgrade or customization upgrade does not add or remove any tables or views. This will save time in the upgrade process. If there are no database changes to reflect then the re-register process will remove all synonyms and rebuild exactly the ones removed. This can be a waste of time. Basically remember only to re-register if there are any database table or view additions or deletions.
The installation procedure creates a number of default userids with default passwords. It is pertinent to reduce security risk by changing the default passwords and reflecting that change in the configuration.
Secure default userids
There are a number of default users (and associated default passwords) that are supplied with the installation of product. It is recommended that the default users and their passwords be altered according to the site security standards. The table below lists the default users supplied with the products:
TABLE 6 – COMMON SUPPLIED USER CREDENTIALS
USERID SCOPE COMMENTS
SPLADM Default Database Administrator account. Owner of the database. Database Administrators are the only valid users of this account. This account is created during the database creation process.
SPLREAD Default Reporting account This account is used by Archiving, ConfigLab and Reporting. Only available on Oracle database installations. This account is created during the database creation process.
splsys UNIX administration account Treat this user as you would treat root or an Administrator account.
SPLUSER Default Application account This account is used for all application database access. This account is created during the database creation process.
SYSUSER Default initial framework user provided with product.
This user needs to be available to add other users. This needs to be defined to the Web Application Server on install. The password will reside in the repository defined in the Web Application Server (usually LDAP).
system Default User for Web Application server console
This is for Oracle WebLogic implementations only.
WEB Web Self Service Default User See SYSUSER
XAI Default XAI userid (some versions) See SYSUSER
Note: There are other userids supplied by products used by product, refer to the documentation for the products on these users.
Consider different userids for different modes of access
Note: It is not possible to configure product to use different database accounts for access. All modes of access will share the relevant pool of database connections as a single database user (usually SPLUSER).
In Oracle Utilities Application Framework version 4.0.1 and above the actual end userid is available as the CLIENT_IDENTIFIER on Oracle database sessions.
By default the application is configured to either use SYSUSER, SPL or XAI to access the product
for online, XAI and in background processing. This means any audit or staging records are associated with a common userid. Some implementations have created additional userids to use as a filter for reporting, traceability and auditing purposes. The following guidelines may be used in this area:
• Create a different userid for XAI transactions. This allows tracking of XAI within the architecture. It is also possible to assign each transaction in XAI a different userid, as it is passed as part of the transaction but usually most customers consider this overkill.
• Create a different userid for each background interface. This allows security and traceability to be tracked at a lower level.
• Create a generic userid for mainstream background processes. This allows tracking of online versus batch initiation of processes (especially To Do, Case and Customer Contact processing).
Note: Remember that any product user must be defined to the product as well as the authentication repository. Don’t double audit
The product has an auditing facility that is soft configured. The facility can be enabled by configuring the auditing parameters (location of the audit data, audit rules etc) against the meta data definitions of the tables. This ensures that any online or XAI updates are audited according to those rules. Auditing is used to track online changes to critical entities.
The financial component of product already has a separate auditing facility, as all customers generally require it. Any changes to financial information such as payments, adjustments, bills etc are registered in the Financial Transaction tables. Therefore enabling auditing on those entities is not required and constitutes double auditing (i.e. auditing information is stored in two places).
While the impact of the double auditing may be storage related, enabling auditing on bills, for example, can have a performance hit on online bills. Customers with large numbers of bill segments per bill (i.e. several hundred) have experienced negative performance impact during online billing when double auditing is enabled on financial entities. This does not affect batch performance as auditing is not used in batch.
Use Identical Machines
The flexibility of the technology used by the product allows the ability to mix-and-match different hardware for a configuration. While this may be attractive and allow for some innovative solutions, it makes overall manageability and operations harder. Hence, it should be avoided.
Having identical hardware allows for ease of stocking spare parts, better reproducibility of problems (both software and hardware), and reduces the per platform testing cost. This cost, in many cases, will surpass the savings from reusing existing disparate hardware.
Regularly restart machines
It is generally a good practice to restart servers periodically. This recovers slow memory leaks, temporary disk space build-up, or other hidden problems that may manifest themselves only when the server is up for such a long duration. This is a simple way to avoid unexpected or unexplained failures.
