For mobile and/or desktop clients to access Applaud products, you will need to ensure the E-Business Suite DMZ/Firewall grants access to the following locations:
<protocol>://<host>:<port>/OA_HTML/a/*
<protocol>://<host>:<port>/OA_HTML/applaud/*
<protocol>://<host>:<port>/OA_HTML/xxas/*
<protocol>://<host>:<port>/OA_MEDIA/xxas/*
Additionally, the client will need Internet access to several domains to download javascript, CSS, and other assets. Please see Client Pre-requisites.
Sizing - Hardware
Applaud products integrate into Oracle E-Business Suite in a similar way to other E-Business Suite modules. In most cases, Applaud products can be deployed without any new hardware whatsoever.
New hardware may be required if going live with substantially more users and the current hardware is inadequately resourced to cope with the increased concurrency. You can use Oracle’s standard recommendations for hardware requirements to make an assessment of this. Please note the comments on the JDBC connection sizing, below.
Sizing - Disk
Applaud products use much the same technology and architecture as standard Oracle E-Business Suite applications, such as PL/SQL and Java. This allows you to enjoy Applaud products without any substantial investment in extra hardware or network infrastructure.
An Applaud patch zip file is approximately 40MB in size. The files in the patch zip will be copied (uncompressed) to each of your Application Tier file systems on each environment. For example, if you have a DEV, TEST, and PROD environment and each environment uses a shared Application Tier file system, the files in the patch will be copied to 3 different locations. If your 3 environments each had 2 Application Tier file systems, the files would be copied to 6 different locations. The installation process will also copy the patch log files to each Application Tier file system.
Most products will deliver new tables. Some of these are set-up tables, some are transactional and some are for temporary use. In general, the setup tables will remain small in size. The size of transactional and temporary tables will vary according to your existing setup and volume of transactions. Some may grow large in size (millions of rows) so it is recommended you consider additional disk allowances where this may apply. Examples: the people search creates a snapshot table and indexes large amounts of employee data; timecards create multiple rows for every log entry of time. If unsure, contact Applaud Support who can advise on likely volumes.
There are additionally audit tables. If you wish to enable audit, these will record lots of low-level information.
Other objects are also loaded into the database, such as PL/SQL objects and FNDLOAD seed data. These will consume few resources, typically equivalent to a small to medium-sized Oracle E-Business Suite patch.
Sizing – Memory
Applaud uses a similar design to standard Oracle applications and you are unlikely to notice much difference after deploying Applaud products. It’s analogous to rolling out a new Oracle HRMS module such as Self Service.
One difference is that Applaud products make use of PL/SQL RESULT CACHE (new db feature in 11g), which is used to optimize performance. This caches data in the SGA rather than in the PGA. /hc/en-us/articles/4410498178449#result-cache
Sizing – Session Pool
Unlike OA Framework pages, Applaud uses modern single-page JavaScript applications. These make extensive use of XHR requests (server-side interactivity is entirely via XHR). The number of simultaneous XHR requests depends on the client’s browser. For example, Chrome currently allows a maximum of 6 per domain; IE10 8 per domain. Please see:
http://www.browserscope.org/?category=network
Each concurrent XHR request will use a different session from the JDBC connection pool. This means the number of JDBC connections in the pool should be sized substantially higher than the estimated number of concurrent users. Further, Applaud products are specifically designed to increase adoption and drive usage – further broadening the audience through mobile access.
Applaud recommend that the session pool be re-evaluated prior to go-live. A common recommendation is: (max concurrent users × 8) + 20%.
When increasing the JDBC session pool, please adjust other parameters (processes, sessions, SGA, and PGA) as required.