Deployment Considerations

This chapter describes the strategies you should consider when you are ready to complete the deployment of a runtime Oracle Configurator.

This chapter covers the following topics:

Overview

This chapter and User Interface Deployment describe activities required to complete deployment of a runtime Oracle Configurator embedded in a host Oracle Application such as Order Management or iStore. The activities include:

Additionally, see Database Uses for an overview of possible deployment environments and architecture.

Deployment Strategies

No single factor is likely to make your deployment succeed. A successful deployment depends on the relationship and interaction of several critical factors that are mentioned in this chapter.

This chapter describes the principles that affect a typical Oracle Configurator deployment.

Architectural Considerations

The architecture of an application often limits its operation. An inefficient configuration model design cannot overcome the limitation by simply tuning your server software of augmenting your hardware.

Model loading and data access depend on how the application was implemented. To get the information required to start tuning your servlet requires you to understand the application. You need to take the time to plan a model of what steps end users will experience and what variety of options will be presented, such as:

Server Considerations

A critical factor in deploying Oracle Configurator on your internet server is the number of instances of the servlet engine (Apache JServ) that you deploy. This number is based on the number of end users that you expect to be conducting simultaneous configuration sessions in each instance, and the kind of data access that they are going to experience.

You need to consider these factors in determining the load balance of users per JServ:

Consequently, the architecture of your application affects your ability to balance the load on your server, which determines the server resources that your application requires.

The factors that affect the number of users per JServ include:

Example

Consider a hypothetical deployment that includes:

This deployment can support 240 simultaneous user configuration sessions:

6 CPUs x 2 JServs per CPU x 20 users per JServ = 240 users

Due to the nature of the application, and the kind of data access that occurs in the application, you should consider what kind of peak events might occur when several users perform a "save" operation in the same minute.

If there are not enough database connections in the connection pool when many users save their configuration at the same time, those users will experience an unacceptable wait until enough connections are freed.

The Oracle Applications Java Caching Framework (OAJCF) is the caching mechanism for all Oracle Applications products. This mechanism stores database results and Java objects in memory for repeated usage, thus minimizing expensive object initializations and database round-trips as well as improving application performance. Consider setting up a dedicated JServ for running Oracle Configurator.

For more information, see the Oracle Configurator Performance Guide.

Connection Pooling

Connection pooling allows multiple configuration sessions in a JServ instance to make database connections. (Previous versions of Oracle Configurator were only able to use a single database connection for each JServ instance.)

When a configuration session is started by the posting of the initialization message to the OC Servlet, a connection is obtained from the pool. When the session is over, the connection is returned to the pool. Each connection requires memory.

Oracle Configurator uses AOL/J (Java classes for AOL (Applications Object Library)) to provide connection pooling. To modify the default setting for connection pooling, you use the AdminAppServer class to create or update a DBC file, setting a value for the parameter FND_MAX_JDBC_CONNECTIONS.

The parameter FND_MAX_JDBC_CONNECTIONS specifies the maximum number of open connections in the JDBC connection cache. This number is dependent on the amount of memory available, the number of processes specified in the init.ora file of the database, and the per-processor file descriptor limit.

The maximum pool size is the maximum allowed sum of the number of available connections and the number of locked connections. If the .dbc file does not have a setting for maximum pool size, the default value is used. The default value is the Java static field Integer.MAX, which normally has a value of about 2 billion. Therefore, the default value is essentially unlimited.

The parameter FND_JDBC_MAX_WAIT_TIME specifies the length of time a request waits for a connection to be established. The default value is 10 seconds, and this parameter is not configurable.

Establishing End User Access

End users ability to access the runtime Oracle Configurator are established by the Oracle Applications System Administrator. For more information, see the Oracle E-Business Suite System Administrator’s Guide. For more information about the behavior of the runtime Oracle Configurator as it affects end users, see the Oracle Configurator Developer User’s Guide.

Publication applicability parameters also affect end-user access to configuration models. For example, the effective dates and times of the configuration model publication must be valid for the time setting on the computer where the host application is running. For more information about publication applicability parameters, see Determining the Runtime User Interface, and the Oracle Configurator Developer User’s Guide.

Determining the Runtime User Interface

The settings of a Model publication’s applicability parameters, the initialization message sent by the host application, and the end user’s responsibility determine which type of user interface is displayed in a runtime Oracle Configurator. For more information, see User Interface Deployment.

For example, an end user is expecting to see a generated Configurator UI at runtime but instead sees the Generic Configurator User Interface. This can happen when the host application is not specified in the publication’s applicability parameters, or the end user’s responsibility is not valid for the host application. For details about the Generic Configurator UI, see Generic Configurator User Interfaces.

To determine what responsibilities are valid for an application, two queries can be run. By querying the local database with the specified application short name, the application ID can be retrieved and then used in a second query to determine what responsibility IDs are valid for the specified application ID.

SELECT application_id, application_short_name, description
FROM FND_APPLICATION_Vl
WHERE application_short_name=’CSS’
APPLICATION_ID      APPLICATION_SHORT_NAME    DESCRIPTION
514                 CSS                       Support

Using the returned APPLICATION_ID you can then run another query to determine the responsibilities that are allowed for that application:

SELECT application_id, responsibility_id, responsibility_name, responsibility_key
FROM fnd_responsibility_VL
WHERE application_ID = ’514’
APPLICATION_ID  RESPONSIBILITY_ID  RESPONSIBILITY_NAME     RESPONSIBILITY_KEY
     514          12345            Customer Support Test      Oracle_Support
     514          67890            Customer Support USA       Customer_Support

For information about legacy UIs, see the current release or patch information for Oracle Configurator on MetaLink, Oracle’s technical support Web site.

Load Balancing and Secure Sockets Layer

Oracle strongly recommends using Oracle Application Server 10g. This version can be set up to use a process manager that automatically load balances server processes and supports Secure Sockets Layer (SSL) for greater security when transmitting data over the Internet.

Refer to Oracle Application Server documentation. For additional SSL information, see MetaLink, Oracle’s technical support Web site.

If you are not using Oracle Application Server, refer to the following Apache Web sites for more information about load balancing and SSL:

http://java.apache.org/jserv/howto.load-balancing.html
http://www.apache-ssl.org

Network Considerations

There are a number of network issues that can cause serious problems for your deployment if not handled correctly.

Firewalls and Timeouts

If your application requires more than one server system, then it is recommended that there be separate servers for the Oracle database server and the internet server. If there are firewalls between servers, then these firewalls must allow persistent database connections between them. Persistent database connections are SQL links that do not close when the execution of your script ends.

The OC Servlet is a stateful application. A stateful application keeps its critical data in memory, rather than writing and reading it from disk storage. Oracle Configurator keeps in memory critical data, such as the Properties cache and the state of the logic engine, until a configuration is saved.

Stateful applications require a persistent connection between the database server port and the ports used by the servlet engine (in this case, Apache JServ). The default timeout for the JServ engine is 30 minutes.

Warning: If there is an idle time limit set on the TCP/IP database connection across a firewall, then this limit can prevent Oracle Configurator from operating.

See Security Considerations for firewall recommendations.

Router Timeouts

Routers have a setting referred to as "stickiness." Router stickiness connects the HTTP request made by a particular client browser (that is, the browser displaying the runtime Oracle Configurator) with a particular instance of the servlet engine (JServ).

The stickiness setting is a time limit on the total time allowed for the connection between client and servlet engine. After the time limit is exceeded by the client browser, the connection to the servlet engine instance is broken. If the end user attempts to use the browser, then it is possible that the router may connect that browser to a different, and wholly incorrect, servlet engine instance.

You must determine the appropriate length of time for your application. For instance, if you feel that your users may wish to use your application for one hour, then you must set the router stickiness to match that time.

Warning: If the "stickiness" time limit of your router is too small for the correct use of your application, this limit can prevent Oracle Configurator from operating.

See Security Considerations for router recommendations.

Miscellaneous Issues

Security Considerations

If you are implementing Oracle Configurator outside your firewall, then consider the following recommendations:

Some risks still remain in that a malicious user could gain access to the application server. Oracle recommends the following:

Internet User Access

There is no direct database connection from non-authenticated Internet users to your production database because:

Additional Security Precautions

The following security precautions may also be considered if your public Web site does not require live access to production data such as entering orders or updating account information:

Multiple Language Support Considerations

If you are implementing Multiple Language Support (MLS), see Multiple Language Support.

Performance Considerations

For information about improving the performance of your runtime Oracle Configurator, see the Oracle Configurator Performance Guide.

Routing Models to Specified JVMs

To improve performance and reduce memory usage, you can route specific Models at runtime to specific JVMs.

Solution Overview

By default, Oracle Configurator caches all Models in a session on every Java Virtual Machine (JVM) running on the web server. If you have very large Models, you may encounter performance problems related to the large memory footprint of those Models. Caching of large Models can overload the JVMs, eventually hitting the maximum heap limit, which in turn causes JVMs to die.

To circumvent this situation, you can route specific Models only to specific pools of JVMs, thus reducing the memory footprint load on the other JVMs. This solution requires the use of a Load Balancing Router (LBR), which is a hardware item that distributes HTTP requests to the servers in a server farm based on load-balancing methods such as round-robin or least-load. An LBR can read the HTTP information of the traffic to and from the web servers connected to it.

To augment the pool-routing capability of an LBR, Oracle Configurator exposes the pool-specifying information of a Model when the Model is launched at the beginning of a configuration session. The pool information for a given Model is placed in the HTTP response message, enabling the LBR to read the pool information for the Models from the HTTP traffic during a configuration session and thus route HTTP request messages to the desired JVM pool.

This routing capability requires a combination of the following elements:

Efficient routing rules and mappings can improve performance and reduce the memory footprint in each JVM.

Solution Processing

The general processing in this solution is as follows:

Solution Procedure

To implement this model routing solution:

  1. Set the profile option CZ: Add Model Routing Cookie to True.

    This enables the addition of the routing cookie to the HTTP response content. By default, the value is False. This profile option can be set only at Site level. See the Oracle Configurator Installation Guide for details.

  2. Register your Models to the JVM server pools that should serve requests to configure them. To do this, run the procedure CZ_CF_API .REGISTER_MODEL_TO_POOL.

    Example: The following simplified example registers the Model with Product Key 204:143 to the JVM pool PoolA:

    cz_cf_api .register_model_to_pool('PoolA', '204:143')

    You can examine your mappings with the following SQL query:

    select MODEL_PRODUCT_KEY, POOL_IDENTIFIER from CZ_MODEL_POOL_MAPPINGS;

    The query might produce output like the following example of mappings for several Models and pools:

    MODEL_PRODUCT_KEY  POOL_IDENTIFIER
-----------------  ------------------------
204:143            PoolA
204:137            PoolB
204:19886          PoolC

  3. Modify your LBR routing rules so that they read the new pool token in the cookie named czPoolToken and route the Configurator requests to the correct JVM pools.

    Example: The following rule for the BIG-IP LBR routes an Oracle Configurator pool token for the CZ mapping table identifier PoolA to the LBR pool identified in the LBR rules as pool_x, which must be previously defined for the LBR:

    if ( exists http_cookie ("czPoolToken") and http_cookie ("czPoolToken ") contains "PoolA") 
{ use pool pool_x } 
else { use pool pool_y }

  4. Continue with the procedures that are specific to your LBR for putting the LBR rules into effect.