Oracle Configurator Implementation Guide Release 12.1 for Part Number E14322-03 | ![]() Contents | ![]() Previous | ![]() Next |
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:
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.
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.
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:
What users select page by page
How users navigate from page to page
What interruptions can occur during a configuration session (for example, when a user pauses a long time to consider their choices, or turns to another task before returning to make a selection)
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:
Network data access calls made by your application
The length of time that a user requires to work through the application
The number of times a user can work through the application in an hour
How many of this type of user can use your application at the same time without interfering with other users needing to access the database (for instance, to save a configuration)
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:
The size of the application (the number of pages or screens)
The size of the Model (the number of nodes)
The number or complexity of any Configurator Extensions used by the application
The number of CPUs
The memory per CPU
The JDK uses about 16 megabytes. The JVM for each JServ uses about 45 megabytes. Oracle Configurator uses native threads.
The number of JServ instances running
The number of connections available in the connection pool (see Connection Pooling)
Consider a hypothetical deployment that includes:
6 CPUs
2 JServ instances per CPU
20 end users expected per JServ
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 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.
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.
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.
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
There are a number of network issues that can cause serious problems for your deployment if not handled correctly.
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.
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.
Your application must run in an environment that resolves domain names to allow it to communicate with other servers.
You must set up your router and server so that all users and processes have the access privileges and permissions they need in order to carry out their functions.
If you are implementing Oracle Configurator outside your firewall, then consider the following recommendations:
Have an additional firewall between the application server and the database server. This additional firewall can guard against unauthorized access to the database server. It should be configured to open only designated ports for application server access to the database.
Additional servers intended for internal use should also be behind this firewall.
Use hardware routers and front-door products like Oracle’s WebCache to provide an additional level of security.
Use separate computers or clusters for the application server and the database server. This is always recommended for performance reasons, but in the context of security it also provides the benefit of preventing a denial-of service attack from disabling the database server.
Some risks still remain in that a malicious user could gain access to the application server. Oracle recommends the following:
Dedicate a computer or cluster to the public Web site’s application server. This will minimize the functionality to which a malicious user would have access. This server should not mount sensitive file systems and should be isolated from the internal servers by a firewall.
Do not store database connection parameters (for example, .dbc files) that provide extensive database access on the same application server that is used for public Web site access. For more information on database connections, see Server Considerations and Internet User Access .
Disable default database account and Oracle Applications users that ship with Oracle products.
There is no direct database connection from non-authenticated Internet users to your production database because:
The database connection is established by the Configurator middle tier that is running on the application server. The connection is not established by any software running on the client’s computer.
Database connection parameters are secured on the application server using AOL/J functionality based on Oracle Applications FND authentication. For more information, see the About Oracle Application Object Library document on MetaLink.
Database connection information is not transmitted over the Internet. An encrypted ICX session ticket that is valid just for a single application server session is transmitted. For more information on an ICX session ticket see Configurator Architecture, and the Oracle Configurator Extensions and Interface Object Developer’s Guide.
Application server sessions for a public Web site logs into Oracle Applications with an Oracle Applications user ID assigned for walk-in users. The walk-in user is defined to have a valid Oracle Applications responsibility that provides access only to the necessary functions. The walk-in user will not have database login privileges. For additional access, see Establishing End User Access.
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:
Use a second Oracle Applications instance to host the implementation of the runtime Oracle Configurator if the runtime Oracle Configurator does not require data from any part of Oracle Applications other than the CZ schema.
Application server sessions for the public Web site connect to the runtime Oracle Configurator database instance, not the production database instance. Database access from the public application server to the production database instance is not available.
Create and maintain configuration models in the production database instance, and then publish the Models to the runtime Oracle Configurator database instance. Any custom data that is needed for the public Web site would need to be stored or duplicated on the runtime Oracle Configurator instance.
If there are any transactions that a consumer could start through the public Web site, then you would have to implement a procedure to extract the transactional data from the runtime Oracle Configurator database instance and import it to the production database instance for processing. This extraction is not necessary if the only output of the public Web site is information for the consumer.
If feedback on the state of transactions in the production database instance must be provided to end users on the public Web site, then you have to implement a procedure to extract this data from the production database instance and import it into the runtime Oracle Configurator database instance. This data would only be as current as of the most recent extraction.
If you are implementing Multiple Language Support (MLS), see Multiple Language Support.
For information about improving the performance of your runtime Oracle Configurator, see the Oracle Configurator Performance Guide.
To improve performance and reduce memory usage, you can route specific Models at runtime to specific JVMs.
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:
Changes in your LBR routing rules to read a new pool token cookie, czPoolToken, from the incoming cookies for each HTTP request and accordingly route the request to a specified JVM pool.
Creation of mappings between JVM pools and Oracle Configurator Models, which you insert in the table CZ_MODEL_POOL_MAPPINGS using the procedure CZ_CF_API .REGISTER_MODEL_TO_POOL, to specify the Models to be routed to specified pools. The table includes the rows MODEL_PRODUCT_KEY and POOL_IDENTIFIER to store the mappings.
Efficient routing rules and mappings can improve performance and reduce the memory footprint in each JVM.
The general processing in this solution is as follows:
The profile option CZ: Add Model Routing Cookie must be set to True for Model routing to occur.
The runtime Oracle Configurator launches a Model via the initialization message.
Oracle Configurator looks up the publication used for the Model and obtains a Product Key that identifies it.
(The Product Key for a Model appears in the General area of the Workbench in Oracle Configurator Developer. For BOM Models, its value is a combination of the Inventory Item ID and Inventory Organization ID, such as 204:143. See the Oracle Configurator Developer User's Guide for more details about Product Key. The Product Key is the same as the Product ID used when publishing Models.
Oracle Configurator uses the Product Key to obtain the name of the intended JVM pool for the Model from the table CZ_MODEL_POOL_MAPPINGS.
Oracle Configurator adds an HTTP cookie named czPoolToken to the HTTP response message from the server. The cookie contains the name of the JVM pool for the Model being configured.
Subsequent HTTP requests include the pool token, which enables the LBR to route the request to the intended JVM pool. The pool token cookie is destroyed when the end user exits the configuration session by selecting Finish or Cancel.
To implement this model routing solution:
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.
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
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 }
Continue with the procedures that are specific to your LBR for putting the LBR rules into effect.
Copyright © 1999, 2010, Oracle and/or its affiliates. All rights reserved.