EBS -- Integrated SOA Gateway / ISG - 'SOA Provider Not Accessible' After Autoconfig

We have seen an interesting issue in an EBS 12.1.3 instance.
ISG was enabled and suddenly, custom web services started to end up with SOA Provider not  accessible errors.

Actually these errors were seen when the customer tried to regenerate/redeploy the problematic web services using related EBS screens.

We knew that, Apps password was changed in this environment, recently.
As a post action of this change, autoconfig was also run.

Actually, they first changed the apps password in a TEST environment. After changing it in the TEST environment, they checked all the EBS system and didn't found any problems..

The web services could be successfully used. However; when they changed the APPS password in PROD, they encountered this issue.
In order to find the cause and fix the problem, we first checked the SOA configuration in PROD and wanted to ensure that it was configured properly.
We suspected an issue with the ASADMIN password migh have caused this.. We also saw that the file($ORA_CONFIG_HOME/10.1.3/j2ee/oafm/config/system-jazn-data.xml), that contains this ASADMIN password was modified almost at the same time as the autoconfig run.

The value written in credential tag was encyrpted and we decided to reset the ASADMIN password by changing that value;

<credentials>!password</credentials>

After this change, we restarted the application and the issue dissapeared.
Note that, when the OAFM is started, the password gets encyrpted.

At the end of the day, this showed us, running autoconfig in EBS 12.1.3 may change the ASADMIN password which is stored in system-jazn-data.xml file.. So in ISG enabled EBS 12.1.3 environments, it is a good idea to backup that file before running autoconfig in Apps Tier.

As we didn't see the same problem in the TEST environment, we concluded that autoconfig changes the value of the ASADMIN credentials to the welcome.. ( in encrypted form). We think so because, the ASADMIN password of the TEST environment was set to welcome and the issue didn't appear in the TEST environment, although the same autoconfig (apps tier) were run in there.

So, in our case, our findings showed us that if the ASADMIN password is set to welcome, we don't encounter this problem :)

This is the tip of the day. Stay tuned :)