Question

Unable to connect to IFS 10 - Due to Error 500


Userlevel 2
Badge +4

Hi,

After a database cloning process,  I was trying to connect to IFS10. Before getting the login dialog the error 500 is popped up as follows;

 

Below is the error;

Ifs.Fnd.FndSystemException: Unexpected error while calling server method AccessPlsql/Invoke

   at Ifs.Fnd.AccessProvider.FndConnection.InvokeInternal(Object requestBody, Object responseBody, String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Boolean forcedSync, Boolean integrationGateway)
   at Ifs.Fnd.AccessProvider.FndConnection.InvokeInternal(String intface, String operation, Object requestBody, Object responseBody, FndRequestContext requestContext, Boolean forcedSync, Boolean integrationGateway)
   at Ifs.Fnd.AccessProvider.PLSQL.FndPLSQLCommandCollection.Invoke()
   at Ifs.Fnd.AccessProvider.PLSQL.FndPLSQLCommand.ExecuteNonQuery()
   at Ifs.Fnd.AccessProvider.PLSQL.FndPLSQLSelectCommand.ExecuteReader(String recordType, Int32 fetchsize)
   at Ifs.Fnd.AccessProvider.PLSQL.FndPLSQLSelectCommand.ExecuteReader()
   at Ifs.Fnd.AccessProvider.Interactive.FndLoginDialog.checkLanguage(FndLoginCredentials loginCreds)
   at Ifs.Fnd.AccessProvider.Interactive.FndLoginDialog.AuthenticateCredentials(FndLoginCredentials loginCreds) ---> Ifs.Fnd.FndSystemException: 500
   at Ifs.Fnd.AccessProvider.FndConnection.CallGetResponse(String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Byte[] requestHeaderBytes, Byte[] requestBodyBytes, FndApfAsyncInvoke asyncInvokeHandle, Boolean integrationGateway)
   at Ifs.Fnd.AccessProvider.FndConnection.InvokeGetResponse(String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Byte[] requestHeaderBytes, Byte[] requestBodyBytes, Boolean& abandoned, Boolean forcedSync, Boolean integrationGateway)
   at Ifs.Fnd.AccessProvider.FndConnection.InvokeInternal(Object requestBody, Object responseBody, String intface, String operation, FndRequestContext requestContext, FndManualDecisionCollection decisions, Boolean forcedSync, Boolean integrationGateway)
   --- End of inner exception stack trace ---

 

I’ve logged into middleware server console and check for deployments. All of them were Active. All the servers are in the running status. This has a clustered middleware. Didn’t get any certificate warning too, When I checked all the statues from mws-svr.cmd all of them were in ‘Running State’

Could you please help me to fix this issue?

Thanks,

Thilani


This topic has been closed for comments

10 replies

Userlevel 5
Badge +7

@CedThilaI Have you already executed a reconfiguration ? If not do it 

Userlevel 2
Badge +4

Hi Renuka,

Yes, did that. But the issue is still there. This is a clustered middleware. Any specific step to run when doing reconfiguration, may be I’ve missed that.

 

Thanks,

Thilani

Userlevel 5
Badge +7

@CedThilaI Did the reconfiguration go successfully?
Can you attach the clone log?
Are there any new invalid objects?

Userlevel 7
Badge +31

Hi @CedThilaI,

Since you did a database clone, did you make sure the database connection string is pointing to the correct database? In IFSAPP10 you need to set the database connection string from IFS Middelware Server Admin Console. Please refer to the answer in this post on how to change the database connection string:

 

Please also check the data sources in both Main and Int clusters and see whether they are running.

 

 

Hope this helps!

Userlevel 2
Badge +4

Hi Charith,

Thanks for your response. I’ve checked the data sources in both Main and Int clusters from the IFS Middleware Server Admin console. They’re in the running state. Checked the database connection string too. It’s correct. I’ve validated the connection; This is the result;

According to our DBA, it was not a clone actually. Just copied the live prod system over their development system. This is a pluggable database. Reconfiguration was successful. Look forward for your advice to fix this issue.

Thanks,

Thilani

Userlevel 5
Badge +12

Hello @CedThilaI 

If everything’s in order (db up and running - :white_check_mark:, mws up and running - :white_check_mark:, data sources up and running - :white_check_mark: ) and still you’re getting this error, try adding landing page URL to IE’s trusted sites and see

Userlevel 2
Badge +4

Hi Ruchira,

Thanks. Just tried that. Still the same error.

Thanks,

Thilani

Userlevel 2
Badge +4

Hi, 

Just wanted to give you an update. This happened after copying the database from Live to DEV. Sorry for the mistake. No cloning has happened. (Just use export -→ import) 

The database is pluggable

Database is up and running. Servers are up and running as follows;

 

Reconfiguration was successful (no errors).But cannot login. From the landing page, when selecting the IEE url, this error (Error 500) comes, even before the login dialog. Restart servers. But still the same issue. Look forward for your help.

Thanks,

Thilani

 

Userlevel 7
Badge +31

Hi @CedThilaI,

Have you inspected Middleware Server log files to see if you can find anything there?

Logs can be found under “\\<IFS_HOME>\wls_domain\<InstanceID>\servers\” folder. Here you would find folders for each server and inside them you can find a folder name logs. In your case, you should focus on MainServer1 and Admin Server logs for the most part.

If you still cannot figure it out, it would be best to open a case with IFS and get some assistance. I am afraid it is a bit difficult to solve this type of issues without performing some hands on investigation on the environment where the issue exists. 

Userlevel 2
Badge +4

Hi Charith,

Thanks. I’ve investigated logs and found that there were some errors in log files as follows;

Ex: ORA-25226: dequeue failed, queue IFSAPP.BATCH_PROC_QUEUE is not enabled for dequeue The exception is : oracle.jms.AQjmsException:

Even though, we started queuing and dequeuing on those queues and reconfigured the middleware server again, we got the same error again and again. Then we’ve identified that there’re 100s of invalid objects exists.

Thanks RanukaSerasinghe for your comment to check invalid objects. After recompiling the invalid objects and reconfiguring the middleware again, we were able to solve the issue.  Thanks all for your valuable feedbacks.

 

Thanks,

Thilani