Oracle EBS R12.2 AutoConfig Template Version Conflict After Patching: How to Preserve Customizations

Alhamdulillah, sharing another real troubleshooting session — this one from an Oracle E-Business Suite R12.2 multi-node environment. After applying a patch, AutoConfig aborted on the primary application node with a template version conflict. This post walks through the exact error, how I identified which template entries were genuine customizations versus Oracle-shipped content, and the correct way to rebase a custom template so AutoConfig completes cleanly.

Environment

• Oracle E-Business Suite R12.2.13, AD/TXK Delta 15
• Two application nodes: appsnode1 (primary/admin) and webnode1 (secondary web node)
• Database: Oracle 19c on dbnode1
• Third-party customization: More4Apps servlet registered in oacore web.xml

The Error

After patching, running AutoConfig on the run file system failed immediately:

[applmgr@appsnode1 scripts]$ sh adautocfg.sh
Enter the APPS user password:
The log file for this session is located at: .../admin/log/<timestamp>/adconfig.log
wlsDomainName: EBS_domain
WLS Domain Name is VALID.
AutoConfig is configuring the Applications environment...
AutoConfig will consider the custom templates if present.
Version Conflicts among development maintained and customized templates encountered; aborting AutoConfig run.

The log pinpointed the conflicting template:

[ FND_TOP ]

[ VERSION CONFLICTS INFORMATION ]
Template shipped by oracle is having a version different than the template lying in custom directory.
Template shipped by Oracle : $FND_TOP/admin/template/oacore_web_xml_FMW.tmp (version: 120.17.12020000.33)
Custom template            : $FND_TOP/admin/template/custom/oacore_web_xml_FMW.tmp (version: 120.17.12020000.31)
Please resolve the differences between the two templates or refer to the Oracle E-Business Suite Setup Guide for further details.

What happened is straightforward: the patch delivered a newer version of oacore_web_xml_FMW.tmp (120.17.12020000.33), but a custom copy of the older version (120.17.12020000.31) exists under $FND_TOP/admin/template/custom. AutoConfig detects the mismatch and refuses to run, because blindly using the stale custom template would silently discard whatever Oracle changed in the new version.

Root Cause Analysis: What Is Actually a Customization?

This is the critical analysis step. Before touching anything, you need to answer one question precisely: which lines in the custom template are genuine customizations, and which are just old Oracle-shipped content?

First, take a backup and diff the new shipped template against the custom one:

cd $FND_TOP/admin/template

cp -p custom/oacore_web_xml_FMW.tmp \
      custom/oacore_web_xml_FMW.tmp.pre_patch_25Jul2026

diff -u oacore_web_xml_FMW.tmp custom/oacore_web_xml_FMW.tmp

The diff showed three differences beyond the header:

1. A m4aServlet servlet and servlet-mapping (More4Apps) present only in the custom template
2. A SyncServlet servlet and servlet-mapping present only in the custom template
3. A RequestAuditReport (QP) servlet present only in the new Oracle template

At first glance it looks like there are two customizations to carry forward: m4aServlet and SyncServlet. This is where a wrong assumption would corrupt the template. To verify, I compared the old shipped template against the new shipped template. In an R12.2 dual file system this is easy — the other file system still had the previous patch level, so both shipped versions were available:

diff -u \
  <old_fs>/EBSapps/appl/fnd/12.0.0/admin/template/oacore_web_xml_FMW.tmp \
  <new_fs>/EBSapps/appl/fnd/12.0.0/admin/template/oacore_web_xml_FMW.tmp

Key excerpt from the shipped-vs-shipped diff:

-   <servlet>
-     <servlet-name>SyncServlet</servlet-name>
-     <servlet-class>oracle.apps.jtf.cac.sync.transport.SyncServlet</servlet-class>
-  </servlet>
...
+     <servlet>
+         <servlet-name>RequestAuditReport</servlet-name>
+         <servlet-class>oracle.apps.qp.servlet.RequestAuditReport</servlet-class>
+    </servlet>

This settled the question:

• SyncServlet was Oracle-shipped content in version .31 and is no longer present in the .33 shipped template. It was never a customer customization, so it should NOT be carried forward.
• RequestAuditReport is new Oracle-shipped content in .33 — it must be retained.
• m4aServlet was not present in either shipped template version compared — it exists only in the custom directory, which identifies it as the genuine site-specific customization.

If I had merged the old custom template on top of the new one, I would have reintroduced a servlet that is no longer present in Oracle’s newer shipped template. This is why “just copy your custom entries into the new template” advice found on many forums is dangerous — verify against the shipped versions first.

The Fix: Rebase the Custom Template

The correct approach: replace the custom template with the new shipped version, then re-apply only the genuine customization.

cd $FND_TOP/admin/template

# Rebase custom template on the new shipped version
cp -p oacore_web_xml_FMW.tmp custom/oacore_web_xml_FMW.tmp

# Re-insert the only genuine customization (m4aServlet)
sed -i '/<!-- FND Servlets -->/a\
\
  <servlet>\
    <servlet-name>m4aServlet</servlet-name>\
    <servlet-class>com.more4apps.r12.servlet.XmlServlet</servlet-class>\
  </servlet>\
\
  <servlet-mapping>\
    <servlet-name>m4aServlet</servlet-name>\
    <url-pattern>/m4aServlet/*</url-pattern>\
  </servlet-mapping>\
' custom/oacore_web_xml_FMW.tmp

This matches the procedure in the Oracle E-Business Suite Setup Guide: when a patch delivers a newer version of a template you have customized, copy the new Oracle template into the custom directory and reapply the still-required customizations to that copy — never the other way around.

Verify before rerunning AutoConfig — the headers must match, and the only diff must be the customization:

grep '\$Header' oacore_web_xml_FMW.tmp custom/oacore_web_xml_FMW.tmp

oacore_web_xml_FMW.tmp:        version 120.17.12020000.33
custom/oacore_web_xml_FMW.tmp: version 120.17.12020000.33

diff -u oacore_web_xml_FMW.tmp custom/oacore_web_xml_FMW.tmp
--- only the m4aServlet servlet + mapping block should appear ---

As an additional best-practice validation, Oracle recommends running the AutoConfig configuration-check utility to preview the impact of template changes before the actual AutoConfig run:

$AD_TOP/bin/adchkcfg.sh contextfile=$CONTEXT_FILE

Rerun AutoConfig:

cd $ADMIN_SCRIPTS_HOME
sh adautocfg.sh

...
Configuring templates from all of the product tops...
        Configuring AD_TOP........COMPLETED
        Configuring FND_TOP.......COMPLETED
        ...
AutoConfig completed successfully.

A Bonus Finding on the Second Node

While repeating the check on the secondary web node, the header comparison came back clean — custom template already at .33 — but something was off:

grep -n 'm4aServlet' $FND_TOP/admin/template/custom/oacore_web_xml_FMW.tmp
(no output)

grep -n 'm4aServlet' $FND_TOP/admin/template/custom/oacore_web_xml_FMW.tmp_ORIG
61:    <servlet-name>m4aServlet</servlet-name>

The current custom template matched the newer shipped version, but the m4aServlet customization was missing. Interestingly, the _ORIG backup still contained the customization. This indicated that during an earlier template update, the customization was not carried forward. AutoConfig had been running fine and web.xml was being generated — just without the third-party servlet.

I re-inserted the m4aServlet block using the same sed command, verified the diff, and ran AutoConfig on that node as well:

AutoConfig completed successfully.

This is the real lesson of the post. A template version conflict at least fails loudly. A customization that is accidentally omitted during a template rebase may not — AutoConfig can complete successfully while the generated configuration no longer contains the required customization, and you find out later when the third-party tool stops working after a bounce.

An Additional Message Observed

The AutoConfig log in this run also contained:

ECC not enabled, setting FND_ECC_ENABLED to FALSE
[ FND_ECC_ENABLED ]
INFO : Error updating/creating profile option value.

In this case Enterprise Command Center is not configured, AutoConfig continued past this message, and the run ultimately exited with status 0. Always evaluate such messages in the context of your own environment rather than assuming every INFO : Error entry can be ignored.

Post-Fix Checklist

1. Confirm the customization landed in the generated web.xml (get the target path from the adconfig log and grep for your servlet).
2. Bounce the application services (at least the oacore managed servers) so the new web.xml is deployed.
3. Test the customization end to end — for More4Apps, hit the servlet URL from the wizard.
4. If your patching cycle requires it, regenerate appsutil.zip (perl $AD_TOP/bin/admkappsutil.pl) and refresh the database tier.
5. Repeat the custom template verification on every application node — as seen above, nodes can drift.

Key Takeaways

• Never resolve this error by copying the old custom template over the new shipped one, and never blindly merge either. The Oracle-documented procedure is to copy the new shipped template into the custom directory and re-apply only verified customizations to that copy.
• Use the dual file system to your advantage: diff old-shipped vs new-shipped to separate Oracle’s changes from your customizations.
• After any template rebase, diff the shipped and custom templates — the output should contain nothing but your customizations.
• Audit custom templates on all nodes periodically. A missing customization may not trigger an AutoConfig error, allowing the generated configuration to differ from what you expect.

I hope this helps someone facing the same conflict. Feel free to leave a comment if you have questions.

---

Disclaimer: The views expressed on this blog are my own and do not reflect the views of my employer or any client. All environment names, hostnames, and identifiers used in this post are anonymized. Always test in a non-production environment before applying any change to production.