Autoconfig bits and pieces and how EBS services are started

I will not go through what autoconfig is. There are  number of docs available in the net.
Just wanted to brush what internally autoconfig does which helps during the troubleshooting times.

1. Report version conflict
2. Backup of the context file
3. Synchronization of file system Context file and its templates with those in the database (Establish DB Connection)
4. Check for customizations to Context template
5. Check the context file for possible updates from database
6. compare the context file stored in database with the context file sored in Database and update it accordingly
   Result                  : The two Context files are in sync

===========================================================================
Starting Updates of Context file Fri May 27 04:28:13 EDT 2016

      found context version     : 120.271.12010000.36
      available update version  : 120.271.12010000.36


7. Start Config Tool CVMHelper
  Updating local context file variables for Middle Tier

Checking file $AD_TOP/12.0.0/admin/template/adgendbc_ux.sh
FND_SECURE: $FND_SECURE
DBC FILE NAME: Instance name
File exists, getting the version
Version: 120.8.12010000.6
No updates to s_fnd_secure needed

Writing Context File back to File System
Context file updated

8. Making database connection using DBUtil
9. Check for new context variables
   No new variables found in the context file

Updated  s_dbGlnam to "instance name"

Processing existing variables with updated defaults
Updated  s_defterr to AMERICA
Updated  s_apps_version to 12.1.3

Writing Context File back to File System
Context file updated
Closing connection

10.Start synchronisation of context file

11. Start location of IANA character set
    [s_iana_cset]
    IANA Charset obtained from Database    : UTF-8
    IANA Charset present in Context file   : UTF-8
    IANA Charset based on APPL_TOP char set: UTF-8
    IANA Charset decided for Context file  : UTF-8
    Action taken : None, since the correct value exists in the Context file

12. Start context value management system
    Performs the task of validating the APPL_TOP
    Start $FND_TOP/patch/115/bin/txkSetConfig.pl (TXK Script to update the Applications configuration
    Start $AD_TOP/adgentns.pl (seeds the entries in to the data model and generates the tnsnames.ora)

13. Upload file system Context file and its templates to the database
14. Upload the Context information template to the DataBase
15. Configure templates from all of the product tops
16. AutoConfig Profile Phase--This prepares all the application TOPS
17. Start Restore Profile utility  

************************************************************************

We might have observed that in multi node install few services are started
in one server and some in another server.
During the Rapid Install, you select the above configuration via the
“Edit Services” button as follows :
•APPS1 : enable “Root Service Group”, “Batch Processing Services”
•APPS2 : enable “Root Service Group”, “Web Entry Point Services”, “Web Application Services”,
“Other Service Group”



Configuring Applications Node Services in Oracle E-Business Suite Release 12
(Doc ID 406558.1)



The logic behind these service classification is as follows :
1.Root Service Group (Runs services on AS, 10.1.3 OH) 1.Oracle Process Manager (OPM)
: adopmnctl.sh

2.Web Entry Point Services (Runs services on AS, 10.1.3 OH) 1.HTTP Server
: adapcctl.sh

3.Web Application Services (Runs services on AS, 10.1.3 OH) 1.OACORE OC4J
: adoacorectl.sh
2.FORMS OC4J : adformsctl.sh
3.OAFM OC4J : adoafmctl.sh

4.Batch Processing Services (Concurrent Managers and Apps Listener) 1.APPS TNS Listener
: adalnctl.sh
2.Concurrent Managers : adcmctl.sh, adsvcm.sh, ieoicsm.sh, ieosvicsm.sh
3.Fulfillment Server : jtffmctl.sh, jtfsvfm.sh

5.Other Service Group: (Runs services for Forms on 10.1.2) 1.Oracle Forms Server :
adformsrvctl.sh
2.Oracle MWA Service : mwactlwrpr.sh


After the installation you see that the Autoconfig XML file is generated with the following
entries for APPS1 and APPS2 :
•s_isDB=NO
•s_isAdmin=YES
•s_isForms=YES
•s_isConc=YES
•s_isWeb=YES

Why are all services enabled on the two application tier nodes instead of the configuration
that was selected via the “Edit Services” feature ?

In R12, the concept for Applications Nodes has changed.  When installing R12 with multiple nodes all the nodes are now set as ‘Y’ in FND_NODES.

This occurs because in R12, concept of unified APPL_TOP is introduced which means everything is laid down on all servers.

From the APPL_TOP perspective, all the Servers on a Multi-Node Environment will have the same files and can now potentially start any Service if needed.  In some cases, additional configuration will be required before this can be done since there can be profiles, etc associated with each Server.

For R12, the only difference between the Servers, are the Services that have been activated on each Node.
 The Services are identified by the variables on the /service_group/ section in the APPS Context File:
•Root Service Group : s_root_status
•Web Entry Point Services : s_web_entry_status
•Web Application Services : s_web_applications_status
•Batch Processing Services : s_batch_status
•Other Service Group : s_other_service_group_status

Depending on the value of these variables (enabled or disabled), adstrtal.sh / adstpall.sh will only start/stop the Services associated with them, ignoring the rest.

For example, if a node has only /s_batch_status/ “enabled” and the rest of the services are disabled, when you run adstrtall.sh on that Server and it will only start the Concurrent Managers and the TNS Listener for Apps.


With a Unified APPL_TOP, all Applications tier nodes have their corresponding context variables set to ‘Y’.
As the difference between nodes is in the services that are activated rather than the files that are present, and since there is no one-to-one match between service groups and nodes, services can easily be switched to run on a different node if desired. This provides a failover capability, whereby a service can be enabled on a node so it can take over the role of a failed node. Equally, it is possible to start a service on a node that was not specified to run that service when Rapid Install was executed.

******************************************************************

                                                      Few Important notes:

Sometimes we can face an issue where the serial number of the context file is less than the serial number present in FND_OAM_CONTEXT_FILES. In this case, autoconfig repalces the values stored in our context file with the values present in FND_OAM_CONTEXT_FILES table. This scenario can also happen when during cloning only DB is refreshed and apps tier is not.
In this case, value present in table will come from source and thus there can be anomaly.

This scenario can also happen in EBS 12.2 where due to adop phase=abort the there is a serial mismatch between file system context file and DB table values. Metalink note:adop phase=abort causes "Serial number in context file contains lower value than that of database copy." (Doc ID 1916658.1)

adpatch generally does not update the "values" of a context file directly. Patches usually update templates. After the file is updated by adpatch, the autoconfig portion automatically launched from the patch session will replicate the templates into configuration files. The same applies for the context file. Having said that, if for some reason, a patch changes the setting of a context variable (which I really don't recall any particular case) then the autoconfig portion will update it in the database first and second it will also update the context file on the node where autoconfig was executed. If that is the case for a patch, autoconfig should be executed separately on all the nodes to make sure the configuration is transported. If such a patch exists, the README should include this clarification.
Regardless of this particular use case, it is always recommended to run autoconfig on all the nodes to assure consistency.

Additionally, the template of the context file is treated as any other file in EBS. If it has a lower version than the patch, then adpatch will replace the file and run AC. If the version in the file system is higher, then all the actions are skipped including the AC phase.
Adpatch has a smart criteria to run AC. In the same way, the AC phase will not be launched from adpatch if the files included in the patch don't belong to the "autoconfig template" category. In other words if a patch includes another file type not related with AC (ie .o file for binaries) then it will not run AC because is not necessary.

For more information refer to metalink note:-Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12 (Doc ID 387859.1)