Oracle Applications DBA Blog

Oracle Applications Tablespace Model - OATM

The Oracle Applications Tablespace Model was another long awaited feature that got introduced in 11.5.10.Prior to 11.5.10 by default each of the oracle applications product would have two dedicated tablespace holding the data element and the other for storing the index eg GLD (For General Ledger base tables) and GLX (For indexes relation to the General Ledger product).This easily resulted in some 300 odd tablespaces to manage apart from the system, temp and the rollback tablespaces.

In the new Oracle Applications Tablespace Model (OATM) all these product related tablespaces have been consolidated in two main tablespaces one for holding the base tables and the other for holding the related indexes. Apart from these two tablespace you have an additional ten tablespaces including system tablespace undo tablespace and the temporary tablespace. Thereby reducing the total number of tablespace in the OATM to twelve.

Apart from the obvious ease of management and administration with a reduced number of tablespace being involved the OATM also  provides benefits like efficient space utilization. This is achieved by supporting locally managed tablespaces as opposed to the dictionary managed tablespace in the previous model.

OATM also supports uniform extent allocation and auto allocate extent management. In uniform extent management all the extents have the same size and result in less fragmentation. Auto allocate extent management allows the system to determine the extent sizes automatically.

OATM also provides additional benefits when implementing Real Application Clusters (RAC) in Oracle Applications.

Under the OATM the following twelve tablespaces are created as a default.

• APPS_TS_TX_DATA - This tablespace hold the translational tables of all Oracle Applications products. For example the GL_JE_HEADERS will be a part of APPS_TX_DATA.
• APPS_TS_TX_IDX - All the indexes on the product tables are kept under this tablespace.
• APPS_TS_SEED - The seeded data that is setup and reference data tables and indexes form this tablespace. For example your FND_DATABASES table would reside in the APPS_TS_SEED tablespace.
• APPS_TS_INTERFACE - All the interface tables are kept in this tablespace for example the GL_INTERFACE table.
• APPS_TS_SUMMARY - All objects that record summary information are grouped under this tablespace.
• APPS_TS_NOLOGGING - This tablespace contains the materialized views that are not used for summary purposes and other temporary 
  object that do not require redo log entries.
• APPS_TS_QUEUES - With the support for advanced queuing in Oracle Applications, the advanced queue tables and related objects form a part of this tablespace.
• APPS_TS_MEDIA - This tablespace holds multimedia objects like graphics sound recordings and spital data.
• APPS_TS_ARCHIVE - Tables that are obsolete in the current release of Oracle Applications 11i are stored here. These tables are  preserved to maintain backward compatibility of custom programs or migration scripts.
• UNDO - The undo tablespace is used as automatic undo management is enabled by default in 11.5.10.This acts as a replacement to red log files.
• TEMP - The Temp tablespace is the default temporary tablespace for Oracle Applications.
• SYSTEM - This is the SYSTEM tablespace used by the Oracle Database.

For all new installation of 11.5.10 OATM is available as a default install. For prior applications system you can migrate your existing tables spaces to the oracle applications tablespace model. For this purpose you have the Tablespace Migration Utility(TMU) which is available as a patch (3381489).

The TMU is a Perl based interactive utility that helps in migrating the oracle applications schemas to implement the OATM.
For additional information refer to the Oracle Applications Tablespace Migration Utility User Documentation.

Posted by Sam at 12:53 PM | Permalink | Comments (6) | TrackBacks (0)

Concurrent Managers

Concurrent processing is at the core of every oracle applications instance. Over the years Oracle Applications has come through a number of changes but concurrent processing has retained itself and in fact got new features added on  to its self with very new version.

The request processing on Oracle Applications takes place through the implementation of concurrent Managers. These Managers allow for a concurrent processing of jobs and also scheduling and queuing of jobs.

The objective of the current post is to go through a overview of Concurrent Managers and concurrent processing in Oracle Applications.

The default installation of Oracle Applications comes with a number of pre defined concurrent managers however you can create your custom concurrent managers to spread out the load of your job processing.

Apart from taking care of the load of your jobs the concurrent managers can also be made to schedule periodic jobs and you could also have the concurrent managers run in specific workshifts thus allowing specific programs to be run with specific priority and specific times.

Concurrent managers also allows you to tweak the number of concurrent process that it can handle concurrent if the request exceed this prescribed limt they are automatically put on pending state. The processing of a request takes place based on the time of request submission and priority of the request submitted.

As mentioned there are different types of concurrent mangers in Oracle Applications among them the three important manager which are required by any oracle applications installation are stated below

• Internal Concurrent Manager (ICM) -  The Internal concurrent manager or the ICM is the 'master' concurrent manager. Its primary responsibility is to take care of the starting and stopping of all other concurrent managers that have been defined in the system and activated. However once the other managers are up and running the ICM does not play much of a role. It is for the same reason that despite your ICM being down oracle applications continues to perform as expected most of the times. That is you would be able to continue submitting requests even with the ICM down. However there are cases where you can evolve your ICM to do larger roles like acting as a conflict resolution manager or in case you have generic service management enabled your ICM can take care of starting and stopping other application services also.
  

• Standard Concurrent Manager - This the core manger and the most hard working of the three. It takes care of managing all the concurrent requests in the system. If however specific programs have been defined to use specific concurrent manager they would be taken care by that manager in all other cases the standard manager will be the default concurrent manager and will process the request. That is by default all the concurrent programs are defined to be run by the standard manager and they should not be excluded unless you have included them to run by an other manager. Though we can change a few setting of the standard concurrent manager like the number of process it can handle, most of the other definition should remain unchanged.
  

• Conflict Resolution Manager (CRM) - The conflict resolution manager of the CRM is responsible of handling any conflicts that might occur within the concurrent programmes. This conflict could be as a result of various reasons for example there might be a business requirement that two instances of a particular report should not be executed at the same time or during a particular period. In case such a scenario occurs the CRM is responsible for taking care of such request. As in the case of the standard concurrent manager the definition for the CRM should be rarely changed.
  

Apart from these three concurrent manages there is another type of concurrent manager known as the Transaction Manager also exists. The transaction manager is responsible for taking the load off the concurrent request table for pooling the request submitted by the user.The transaction manager takes care of these requests and sends it to standard manager directly.In a RAC environment the Transaction manager is required to be activated on each node of the RAC environment.
 
From the front end you could view the status of your concurrent manager by logging with the System Administration responsibility and going to the Concurrent Manager administer screen.


The concurrent managers are like other process which run on the oracle applications executable FNDLIBR. The FNDLIBR executable is located at $FND_TOP/bin.

You could also grep the FNDLIBR executable to check if any concurrent manager process are running

$ ps -ef|grep FNDLIBR

The $FND_TOP/sql/afcmstat.sql script gives you a list of concurrent managers and their respective status.

The status of concurrent managers and the nodes on which they are configured can also be known from the Oracle Applications manager.

The concurrent manager log files are a important place to check for any concurrent manager problems. The logfiles are in the .mgr format and can be located at the $APPLCSF/$APPLLOG

An oracle diagnostics test is also available to check the setup and the status of your concurrent manager under the Oracle Applications Library -> Setup -> concurrent Manager.

Posted by Sam at 10:53 PM | Permalink | Comments (11) | TrackBacks (0)

Oracle Applications Patch Types

In a continuous effort to improve applications performance, fix bugs address security vulnerabilities, perform language translations or simply add additional functionality oracle release a series of patches in addition to their base release of applications.

It goes without saying as with the case of any other applications it is recommended to be at the latest certified patch set level at most times.

The Oracle Application patches are categorized into the various types based on their purpose and the bugs they fix. This could get confusing at times to start with but once you have a understand of the oracle naming conventions, it will make your life  as an APPS DBA a whole lot easier.

Below are categories under which Oracle Application patches are divided.

• Standalone or Individual Patches - These kind of patches are delivered to fix a one off bug or introduce a new feature in any  of the oracle applications products. Mostly these patches would be independent and unrelated though they might require certain 
  pre requisite patches to be applied.
  
• Mini Packs - These are a consolidation of various standalone patches for a particular product in oracle applications like  AD,GL etc. The naming convention for mini packs would be in the form of 11i.<product>.<minipack letter> such as 11i.AD.I.Mini packs are cumulative in nature that is AD.I would include all the bug fixes that were included in AD.H and so on. Prior to release 11 the mini packs were referred as patch sets.
  
• Family Packs - A family pack is a consolidation of all the mini packs and various stand alone patches for a particular oracle 
  applications product family. The functional grouping of application products forms a product family like financials HRMS etc. The naming convention of these family packs are in the form of 11i<productfamily_product>.<Familypack letter> like  11i.HR_PF.K.As in the case of mini packs the family packs are also cumulative in nature.
  
• Consolidated Updates - Since the time between releases of oracle applications is significant, a number of patches mini packs and family packs would have been introduced. A consolidated update as the name implies is a consolidation of the recommended 
  patches that have been released up till the date of the release of the consolidated update. A consolidated update brings the entire oracle applications system to the latest recommended patch level. The consolidated updates are in the form of  CU<Update Number> like CU2.Consolidated updates are also cumulative.
  
• Technology Stack Updates - Recently oracle has started to introduce a new type of patch know as the technology stack update, these include consolidation of patches and mini packs for the underlying technology stack. As a result they do not include any  functional patches. An example of technology stack update is 11i.ATG_PF.H.Technology stack updates are cumulative.
  
• Maintenance Packs - A maintenance pack is a consolidation of all the mini packs for all products and all the family packs for the entire oracle applications. Maintenance packs upgrade the system from on release to a higher release for example when you apply the 11.5.10.2 maintenance pack to a 11.5.9 system you upgrade your entire oracle applications to a higher version.
  
• Critical Patch updates (CPU) - Every quarter oracle releases critical patch update that addresses the security vulnerabilities and alerts that have been identified. The critical patch updates were introduced in 2005 prior to which security alert were used address the security fixes for oracle products.
  
• Translation Patches - In a multilingual environment the patches are first applied in the base language. After that a translation patch is required to be applied for each of the additional language installed. The translation patches would be in the form of <patch number>_<Language code> like 3460000_FRC implies the Canadian French translation patch for 3460000  (consolidated update 2).
  
• Recommended Patch List (RPL) - A recommend patch list is a list of patches for a particular oracle applications product. The RPL is not a patch but just a list of recommendations. In fact the consolidated updates are built up on the RPL based on the cut off dates for inclusion.

 

Posted by Sam at 04:28 PM | Permalink | Comments (9) | TrackBacks (0)

JVM

JVM or the Java Virtual Machine in Oracle Applications is the core where all java requests are handled. These request can be generated either from the self service web application page, from the Oracle Applications manager console or through a java based concurrent request.

The default version of JDK that comes with the latest release of Applications 11.5.10.2 is JDK 1.4.2, although JDK 1.5 has also been certified with 11.5.10 now.

The mod_jserv component of the Oracle Applications Server is responsible for processing all java requests.

The mod_jserv automatically creates a JVM during the startup of Oracle HTTP server (OHS),this JVM will handle all the servlets coming from within a browser.This is done using $IAS_ORACLE_HOME/Apache/Apache/bin/java.sh file.

mod_jserv uses the Apache JServ Protocol (AJP) to communicate between the HTTPD process and the JVM for processing the Java requests.

The jserv.conf file and the jserv.properties file control the behavior of the mod_jserv process and the JVM.

Some of the significant parameters which influence jservr performance are

The ApJServManual parameter in the jserv.conf file is used here to specify if the JVM will be allocated automatically at the startup of the OHS.

The wrapper.bin.parameters=-verbose:gc –Xmx2048M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB in the jserv.properties

Verbose:gc means JVM is configured to print output when garbage collector runs
–Xmx2048M specifies the maximum memory heap size
-Xms128M specifies the minimum amount of memory required

According to Oracle, we can increase the maximum heap memory to over 4GB based on the available RAM.

The ApJServVMTimeout in jserv.conf is used to specify the amount of time allocated for the JVM to startup or shutdown ,this value should be sufficient to ensure thata garbage collector finishs its job.

An improper of an insufficient JVM allocation often results in java errors like the  

java.lang.OutOfMemoryError and java.lang.NoClassDefFoundError

In autoconfig enabled Oracle Applications systems the configuration and behavior of JVM can be maintained thought the context file. These can be changed though the Oracle Applications Manager or by using the context editor.

You can also get a summary of the Jserv usage from OAM by using the Jserv Usage Summary screen from OAM.

You can also use JConsole a utility provided by Sun Microsystems to have a graphical real time monitoring of your JVM usage.

The following article provides details on using jconsole.

http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

Additionally in oracle applications the JVM usage is catorgorised in the following groups

OACoreGroup This is the core group for handeling Java requests
DiscoGroup Ths is the JVM groups reserverd for your Discoverer requests
FormsGroup This is the JVM that is used in case you have configured your forms server to run in servlet mode
XmlSvcsGroup This is the JVM that is used for your XML services like XML gateway.

You can increase the number of JVMs for each of these groups through OAM. Each of these JVM will listen on a TCP port from the port range specified in the java.sh file.

You can check the status of your jvm though

http://<host><domain>:<port>/servlets/IsItWorking or by using Oracle Diagnostics

Posted by Sam at 05:47 PM | Permalink | Comments (0) | TrackBacks (0)

Oracle Applications File System

A proper understanding of the file system that Oracle Applications implements is critical for efficiently working with and managing Oracle Applications.

The below discussion only a brief overview of the Applications file system and directory structures and does not include shared application tier file system.

The final structure your application file system takes depends upon the input parameters that you give while executing rapidinstall, it is carried across multiple nodes with the help of the config.txt which stores these parameters.

The [dbname] in this blog refer to your database name and generally the SID of your database which is also specified at the time of executing rapidinstall for installing oracle applications.

Since the installation start with the DB node first we will first talk about the DB Tier.

On the DB tier there two main top level directories which are [dbname]DATA and [dbname]DB.

The [dbname]DATA is also reffred as the DATA_TOP contains all the datafiles (.dbf) for the various tablespaces of your database. These include your System tablespace, Applications Tablespace, Temporary table Space etc. All the datafiles must reside within the DATA_TOP.It is however possible to have multiple DATA_TOPs within a Oracle Applications Instance, this is
particularly useful for spreading across your datafiles across multiple mount points or disks.

The second important top level directory of the database tier is [dbname]DB. This contains your 9i ORACLE_HOME (as in the case of 11.5.10).That is under this directory all the files need to run and maintain you database reside.any database upgrade like upgrading your applications database to 10g would involve upgrading this ORACLE_HOME.

Coming to the Applications Tier there are three important top level directories.

[dbname]APPL,[dbname]COMN and [dbname]ORA

The [dbname]APPL is also know as your APPL_TOP. The APPL_TOP contains the core technology files required for Oracle Applications it also contains individual subdirectories for all oracle applications products. For eg under the [dbname]APPL or the APPL_TOP you would find directories for AD,FND,GL etc. These product directories are also know as PRODUCT_TOPs like AD_TOP,GL_TOP etc. Each of the product directories have the sub directories like admin, driver, import, odf, sql, bin, forms,reports etc.

The second TOP level directory under the applications tier is the [dbname]COMN. This is also referred to as your COMMON_TOP.The COMMON_TOP contains files that are commonly used by different Oracle applications products as well as any third party applications that may have been integrated with Oracle applications.

The COMMON_TOP contains sub following sub directories.

admin which holds the place for concurrent manager log and out files in the log and out sub directories respectively. Also it contains a scripts subdirectory.
html which is also referred by the environment variable OA_HTML contains the HTML files, JSP,CSS and Java scripts that are used by Oracle Applications.
java subdirectory which holds the jar files, this is also referred to as the JAVA_TOP.
scripts subdirectory that contains the machine admin scripts like the adstpall.sh
util subdirectory contains third party utilities that are used in oracle applications like JRE from sun microsystems
Temp subdirectory used for caching
Portal subdirectory used to delivery rapid install portal pages.

The third top level directory under application tier is the [dbname]ORA directory.This contains the IAS ORACLE HOME and the 8.0.6 ORACLE HOME.

Apart from the Database ORACLE_HOME 11i uses two other ORACLE_HOMES.The first is the 8.0.6 ORACLE HOME.This is used for developer 6i products which are forms reports and graphics. The applications executables also link with the 8.0.6 libraries.

IAS ORACLE HOME is the ORACLE HOME used by the 9iAS application server which is the primary web server for Oracle Applications.

Posted by Sam at 03:46 PM | Permalink | Comments (0) | TrackBacks (0)

Oracle Applications File System

A proper understanding of the file system that Oracle Applications implements is critical for efficiently working with and managing Oracle Applications.

The below discussion only a brief overview of the Applications file system and directory structures and does not include shared application tier file system.

The final structure your application file system takes depends upon the input parameters that you give while executing rapidinstall, it is carried across multiple nodes with the help of the config.txt which stores these parameters.

The [dbname] in this blog refer to your database name and generally the SID of your database which is also specified at the time of executing rapidinstall for installing oracle applications.

Since the installation start with the DB node first we will first talk about the DB Tier.

On the DB tier there two main top level directories which are [dbname]DATA and [dbname]DB.

The [dbname]DATA is also reffred as the DATA_TOP contains all the datafiles (.dbf) for the various tablespaces of your database. These include your System tablespace, Applications Tablespace, Temporary table Space etc. All the datafiles must reside within the DATA_TOP.It is however possible to have multiple DATA_TOPs within a Oracle Applications Instance, this is
particularly useful for spreading across your datafiles across multiple mount points or disks.

The second important top level directory of the database tier is [dbname]DB. This contains your 9i ORACLE_HOME (as in the case of 11.5.10).That is under this directory all the files need to run and maintain you database reside.any database upgrade like upgrading your applications database to 10g would involve upgrading this ORACLE_HOME.

Coming to the Applications Tier there are three important top level directories.

[dbname]APPL,[dbname]COMN and [dbname]ORA

The [dbname]APPL is also know as your APPL_TOP. The APPL_TOP contains the core technology files required for Oracle Applications it also contains individual subdirectories for all oracle applications products. For eg under the [dbname]APPL or the APPL_TOP you would find directories for AD,FND,GL etc. These product directories are also know as PRODUCT_TOPs like AD_TOP,GL_TOP etc. Each of the product directories have the sub directories like admin, driver, import, odf, sql, bin, forms,reports etc.

The second TOP level directory under the applications tier is the [dbname]COMN. This is also referred to as your COMMON_TOP.The COMMON_TOP contains files that are commonly used by different Oracle applications products as well as any third party applications that may have been integrated with Oracle applications.

The COMMON_TOP contains sub following sub directories.

admin which holds the place for concurrent manager log and out files in the log and out sub directories respectively. Also it contains a scripts subdirectory.
html which is also referred by the environment variable OA_HTML contains the HTML files, JSP,CSS and Java scripts that are used by Oracle Applications.
java subdirectory which holds the jar files, this is also referred to as the JAVA_TOP.
scripts subdirectory that contains the machine admin scripts like the adstpall.sh
util subdirectory contains third party utilities that are used in oracle applications like JRE from sun microsystems
Temp subdirectory used for caching
Portal subdirectory used to delivery rapid install portal pages.

The third top level directory under application tier is the [dbname]ORA directory.This contains the IAS ORACLE HOME and the 8.0.6 ORACLE HOME.

Apart from the Database ORACLE_HOME 11i uses two other ORACLE_HOMES.The first is the 8.0.6 ORACLE HOME.This is used for developer 6i products which are forms reports and graphics. The applications executables also link with the 8.0.6 libraries.

IAS ORACLE HOME is the ORACLE HOME used by the 9iAS application server which is the primary web server for Oracle Applications.

Posted by Sam at 03:46 PM | Permalink | Comments (0) | TrackBacks (0)

NLS/MLS in Oracle Applications.

With the globalization of business the NLS/MLS feature in Oracle Applications has come into use quite extensively.NLS (National Language Support) refers to the ability to run an Oracle Applications instance in any one of the supported languages other than American English.

This includes the user Interface that is the customer facing forms reports etc.
The base langue (that’s is the underlying logic for the instance)continues to remain American English, though this can also be changed.

MLS (Multi Language Support)should not be confused to be different from NLS it is infact an extension of NLS. MLS refers to the ability to run a single instance of Oracle Applications in more than one supported language apart for the American English.

MLS enabled applications store the seeded data in both the base language and the translated language.
Also most applications with Oracle Applications are MLS supported.

You can check the base and installed languages of your oracle Applications by querying the table FND_LANGUAGES.

Your base language will be represented with the 'B' flag and other installed language with 'I' Flag.

>SELECT LANGUAGE_SHORT_NAME, INSTALLED_FLAG
FROM FND_LANGUAGES

Before implementing NLS/MLS it is important to make sure that your database character set will support your additional language.

The metalink note 333785.1 contains a table of all the supported languages and the langues that are planned to be supported along with their supported database character sets.

If you are implementing multiple languages or planning to install additional languages you can choose UTF8 as your database character set.

You can install the additional language during the installation of Oracle Applications (in this case you would have to stage the NLS software along with the Oracle Applications Software) or you can add an additional language after you have setup and installed Oracle Applications. You should must however apply translations for any paths that you may have applied after the installation of Oracle Applications and before the implementation of the additional language.

If you are installing the language after the installation of Oracle Applications it includes a series of steps starting from Licensing your language, updating your multilingual tables and using auto patch to install the NLS patch.

NLS release notes for 11.5.10.2(215868.1) contains the details steps of installing additional languages.

At the database level once NLS/MLS is implemented Oracle Applications stores language specific attributes in a separate table know as the translation table, where as the language independent attributes are stored in the base table. As a result it is important to consider additional space requirements as far as the database sizing is considered before implementing NLS/MLS

Oracle Applications currently does not support the uninstalling of the languages once they are installed. You can manually update the FND_LANGUAGES table, though this method is also not supported by Oracle.

To print from Oracle Applications while using UTF8 to support NLS/MLS you must use PASTA (FNDPSTAX) utility which is shipped with Oracle Applications. This uses the pasta.cfg file for various print options.The file is located at $FND_TOP/resource.

There are various seed printer drivers that can used with PSATA printing like PASTA_LANDSCAPE, PASTA_PORTRAIT, PASTA_LANDWIDE and PASTA_DYNAMIC.

When applying patches on an NLS/MLS environment you must first apply the base language patch immediately followed by the translation patches of the other installed languages.

Posted by Sam at 10:55 AM | Permalink | Comments (0) | TrackBacks (0)

Shared APPL_TOP and Application Tier Filesystem

In the Shared APPL_TOP feature introduced by Oracle in E-Business 11i, Oracle allows multiple nodes to share a single APPL_TOP .In a shared APPL_TOP configuration, the APPL_TOP and COMN_TOP file systems can be installed on a single shared disk. The shared disk resource can then be shared via various network file protocols across multiple nodes to provide standard application tier services such as forms, web and concurrent processing. A shared APPL_TOP also significantly simplifies the patching or upgrade process since it has to be performed only once and changes made are immediately visible to all the nodes.

Here it is important to note that there is a difference between a Shared APPL_TOP and a Shared Application Tier File system. In a Shared APPL_TOP though the APPL_TOP(APPL_TOP and the COMMON_TOP ) is shared across different nodes, each nodes still have their individual ORACLE_HOME. In a Shared Application Tier FileSystem both the APPL_TOP and the ORACLE_HOME (ORA_TOP) reside on the shared disk.

The Shared APPL_TOP architecture was introduced in 2003 however with the release of 11.5.10 Oracle has extended this feature to share the entire application tier filesystem thereby further reducing disk space and bring down maintenance tasks.This is what is referred to now as the Shared Application Tier File System.

 

This feature i found to be particularly useful if your oracle applications environment uses multiple languages. Using the Shares APPL_TOP feature i do not now have to apply the translation on all the application Tier nodes but just to the Shared APPL_TOP.

In both the cases any changes on the shared TOPs like for example patch application is immediately visible to all the nodes of the application tier.

Another important factor to be kept in mind is that SHARED APPL_TOPS will not work if different nodes are on different Operating systems. So its mandatory that the different nodes of the application tier run on a same operating system or in other words the different nodes must be binary compatible.

Also as of now the SHARED APPL_TOP feature is not available for the windows version of Oracle Applications.

Apart from reducing maintenance tasks a shared APPL_TOP/Shared Application Tier Filesystem also improves scalability of the system as it less complex to bring in an additional node to improve performance.

There are various methods by with you can implement shared APPL_TOP like using Rapid Install or by merging existing APPL_TOPs.

It is mandatory for you to have implemented autoconfig before you can proceed with the implementation of a Shared APPL_TOP.

The metalink note Sharing the Application Tier File System in Oracle Applications 11i 233428.1 talks about implementing shared APPL_TOP under different Scenarios.

While patching a shared APP_TOP you can just apply the path to any of the nodes and it will become visible to all the nodes, in case of applying a patch to 8.0.6 home or IAS_HOME you need to apply the patch only once but to a primary node.

Shared APPL_TOP and Shared Application Files system concepts are different from a Staged APPL_TOP. A Staged APPL_TOP is implemented to reduce your patching related downtimes by creating a exact clone of your production system, patching that system and synchronizing your cloned at database and application level to the production system.

This approach significantly reduceds your patching downtime.

To know more about a Staged APPL_TOP refer to metalink note 242480.1

Posted by Sam at 10:47 AM | Permalink | Comments (1) | TrackBacks (0)

Oracle Applications Framework 

The Oracle Applications Framework 11.5.10 was one of the exciting features that i found in the latest release of Oracle Applications 11.5.10.

Oracle Applications Framework is also referred as OA Framework. OA Framework is a Java framework that excels at creating 3-tier web-based applications that link to an 11i Oracle Applications instance while maintaining all the security features of that 11i instance.

OA Framework makes a connection to the database using JDBC drivers.

An important significance of the OA framework model is that it facilitates the customization of existing out of box i modules as well as it allows development of new Self Service Web Application modules.

As a result the OA Framework provides with benefits of Productivity, Scalability, and Customizability etc.
Though the OA Framework is J2EE based, it also used various industry standards like HTML, XML, Java, JSP, SQL and Web Services.

 

The OA Framework Architecture is based on the J2EE MVC design pattern. The MVC architecture is a component-based design pattern with clean interfaces between the Model, View, and Controller. The Model is where the application implements its business logic. The View is where the application implements its user interface and the Controller is where the application handles user interaction and directs business flow.

Additionally OA framework also contain extensions to Oracle 9I JDeveloper called Oracle Applications Extension or the OA Extension. The Jdeveloper is a IDE client which allows you to do customizations and additions to the OA Framework.

The metalink note 275878.1 contains FAQ to use JDeveloper with the OA Framework.

There are a number of profile options which are used to configure the OA Framework behaviour.

To know mare about OAF profile options reffer to note 275876.1 .

You can test your OAF by go through a series of tests which are accessible from the following URL.

http://<hostname.domain>:<port>/OA_HTML/jsp/fnd/aoljtest.jsp

 

Note: use your hostname and port identifier.

The latest release of OA Framework is 11.5.10, if you are on 11.5.9 or any prior release you can user matalink note 275874.1 to upgrade and configure your OA Framework to 11.5.10.

You must also upgrade your JDK to 1.3 before proceeding with this, The metalink note 130091.1 will be helpful for upgrading JDK to 1.3.

Another good note which might be useful is Oracle Application Framework Troubleshooting Note:275875.1 .

Extensive literature regarding OA framework has been published in the OA Framework Developers Guide.

Posted by Sam at 10:11 AM | Permalink | Comments (2) | TrackBacks (0)