Feedback Loop in EBS 12.2

EBS application layer has changed significantly in release EBS 12.2. There are two oracle homes here

1. 10.1.2-Oracle AS  tools or developer tools

2  Oracle AS 10.1.3 is now replaced by fusion middleware home

In the previous release of EBS oacore,oafm, forms and forms-c4ws was deployed in OC4J. Thus one run of autoconfig used to change all the configurations files. But in EBS 12.2 OC4J is replaced by weblogic server, thus EBS components are deployed in the managed servers. 

All properties of managed servers are managed using weblogic tools like admin console. So now to sync the context file and OHS configuration in weblogic, there is a mechanism introduced in EBS12.2 . This mechanism is known as feedback loop and it is invoked by 2 scripts.

adRegisterWLSListeners.pl is used to update the XML file listening to Weblogic parameter changes. This script is invoked automatically on the primary node every time Weblogic administrator server is started in UNIX machines.

adSyncContext.pl is for explicitly pulling the values of Weblogic server and HTTP server parameters to synchronize corresponding context variable values.

We did some changes by using Fusion middleware admin console.

These changes have to be in sync with context file. To do that

You will need to run the following steps on all application nodes:

Go to cd $AD_TOP/bin/

perl <AD_TOP>/bin/adSyncContext.pl contextfile=<CONTEXT_FILE>

This will read the WLS configuration parameter values and synchronize them with the context variables.

Run The Autoconfig on All App Nodes.

These are some of the activities which autoconfig cannot manage by itself completely.

Abandoned nodes in EBS 12.2

Think of a scenario, where EBS has a multinode environment(Not Shared application tier or Shared APPL TOP), in such case we have to patch all the application nodes. One node will be an admin node and others will fall into secondary node. In a multinode environment, adop command is invoked only in admin node and internally adop uses SSH connectivity to execute required patching activities in other secondary nodes. (Before executing, we should have ssh connectivity in place-https://www.clearos.com/resources/documentation/clearos/content:en_us:kb_o_setting_up_ssh_trust_between_two_servers)

Tip: If you change the password for the relevant operating system account on one or more nodes, you must regenerate the ssh credentials either using the $AD_TOP/patch/115/bin/txkRunSSHSetup.pl script, or your own native solution if you prefer(https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm)

The txkRunSSHSetup.pl script has a -help option that shows relevant usage options.

For example, a basic command to enable ssh would be:

$ perl $AD_TOP/patch/115/bin/txkRunSSHSetup.pl enablessh -contextfile=<CONTEXT_FILE> -hosts=h1,h2,h3$

To verify ssh operation:

$ perl $AD_TOP/patch/115/bin/txkRunSSHSetup.pl verifyssh -contextfile=<CONTEXT_FILE> -hosts=h1,h2,h3 \

-invalidnodefile=<filename to report ssh verification failures>

To disable ssh:

$ perl $AD_TOP/patch/115/bin/txkRunSSHSetup.pl disablessh \

-contextfile=<CONTEXT_FILE> -hosts=h1,h2,h3 \

-invalidnodefile=<filename to report ssh verification failures>

Now the question-what happens if adop fails in one node and complete successfully in another node.

example for this error-

prepare phase failed on node secondary node. if you choose to proceed with cutover, node will be marked as abandoned.

Do you want adop to continue with other completed nodes [y/n]

if we press n, it will exit out of this and then we have to rectify the error first and restart the prepare phase again by

adop phase=prepare allnodes=yes

The same goes for apply phase.

But for cutover phase, the situation is little different. ADOP will just continue by just skipping the problematic node(the problematic node has to be secondary) and this problematic node will be marked as abandoned after cut-over. If the abandoned node is meant for imporant ebs Services such as conc processing then skipping this will impact the availability of concurrent processing. So it is not advisable to skip any errors during patching. And also the admin node cannot have a status abandoned, so if an error occurs in admin node, it cannot be skipped and has to be corrected before proceeding with patching. The abandoned nodes has to be removed and recreated using rapid clone.