EBS R122: Context File shows apps_jdbc_connect_descriptor with VIP instead of SCAN

[NubeAppsDba]

We have cloned a 12.2 instance from another instance.
The source shows the apps_jdbc_connect_descriptor connect string with SCAN values where as the target shows the vip.

Apparently the fs_clone is using the vip values and failing with EBS_SYSTEM validation.
We can connect from the apps tier with sqlplus EBS_SYSTEM/<pwd> without any issue.

Any thoughts on what is going on?

We have tried to set the <DB>.dbc and adgendbc.sh as well as the context file to the desired values BUT as soon as we run autocfg all 3 places get reset to the values with vip.

So where is autocfg picking up these from?

[ErmanArslansOracleBlog]

Interesting , actually it should be other way around. (see the following blog post , there we have a different behaviour -> https://ermanarslan.blogspot.com/2021/01/ebs-122-configuring-application.html)

You may check the relevant template file and see if there is some casual connection there. (your AD & autoconfig version may also be the cause) .. Check the template and try to predict where the autoconfig takes that value.. (db parameters maybe.. Local and Remote listener parameters I mean..)

Also,  s_jdbc_connect_descriptor_generation is also important.
if we set it or leave it as is (I mean if it is set to TRUE), then the apps tier autoconfig will overwrite the jdbc url with the scan-based & load balanced one. (but you are saying the exact opposite.. But still check that value)

Autoconfig may also take that value from the old context files stored in FND_OAM_CONTEXT_FILES table.. Check that as well..

In the worst case, you may clean up the network topology and re-populate it with autoconfigs(db + app tier)

[NubeAppsDba]

Afer setting the s_jdbc_connect_descriptor_generation to TRUE it is working as desired.
Thanks for the reply.