Skip to main content

We are currently running IFS Apps 10 Update 15 with TAS all on-premise.  These would take 1-2 hours to install.  In the past, we had been able to run the update deliveries ourselves without issue.

I can’t say this for certain, but we believe since IFS went evergreen with UPD’s, we started having this problem during deployments.  Our deployments now take 6-8 hours, and fail with an error.  This errors appears to only impact TAS, otherwise after deployment is finished with errors IFS appears to function.  During the update, it sits at a screen trying to update the locked files.  During the update and after, we have checked for locked objects or blocking sessions and see nothing.


Has anyone ever ran into this problem before?  We do NOT receive this when we deploy updates in our DEV environment.  Our DEV environment does not have TAS installed in it, so we thought unregistering TAS from our TEST environment and running the update would be a work around but unfortunately we still received this message.

 

We’ve had several cases open with IFS support over the years - no resolution.  Current “Active” case #CS0133041 opened 9 months ago.  We’ve had two separate vendors try and get to the bottom of this with no success, and I’ve tried the IFS support channels and account manager channels with no success.  I believe this is something only R&D can solve, but you can’t communicate with R&D for support.

 

Throwing this out to the community to see if anyone else has had this happen.  Our biggest gripes aside from the time it takes to perform an update, we are not comfortable rolling out updates that error out every time we install them and assuming everything is 100%.  We’ve been experiencing this for 2 years now, and are no closer to a resolution than we were when we first started seeing this error message.

I have to believe this post got someone’s attention.  After almost 2 years of back and forth, we finally got IFS R&D to jump on a call and look into this for us and in less than an hour, they found the issue.

One of our core IFS permission sets was modified at some point, not by our team, which caused the problem during installation.  We had to remove the FNDMOB_INSTALLATION_API permission grant from FND_TOUCHAPPS_CFG and confirm it was not added to the other permission sets below, which it wasn't

 

TOUCHAPPS_RUNTIME

TOUCHAPPS_ADMIN

FND_TOUCHAPPS_CONFIG

FND_TOUCHAPPS_SYNC_TRACE

FND_DEVELOPER

FND_ENDUSER

 

During installation, IFS installer attempts to clear and re-create the permission sets.  The installer tries to execute FNDMOB_INSTALLATION_API to clear permission sets from the list above.  Since it was granted to the one permission set that created a recursive dependency so it would just sit and re-try.

 

Our assumption is that this has always been this way, and the IFS installer recently started clearing these permission sets as part of the evergreen update or it was incorrectly modified by a vendor.

Hi @jchristy , 

Could you please clarify whether installing a UPD in the IFAPP 10 application can cause permission sets to be removed from structures? We need to understand the potential impact of UPD installations on application permission configurations.

Your prompt response would be greatly appreciated.

Reply


Terms & ConditionsCookie settings