Skip to main content

Dear all,

we have the issue that in the MWO applications (Windows) the MWO is stating “Waiting for Server”. In the Logs the following is showing:

What could be the reason for IFS Applications and the MWO Group Push to fail?

Please advice.

 

T&R

Dear all,

we have the issue that in the MWO applications (Windows) the MWO is stating “Waiting for Server”. In the Logs the following is showing:

What could be the reason for IFS Applications and the MWO Group Push to fail?

Please advice.

 

T&R

In addition it would be great to have the information, where to look in more detail for errors and logs. Since the MWO and IFS are somewhat quiete about that.


I have came across two reasons for this issue to occur.

  1. If Group push user is not connected to the relevant sites.
  2. If your user is connected to more than 80 sites.

Hi @NEJANO. The issue is, that it worked already once. Do you know if security certificates for connections between MWS, TAS and IFS might cause such issues?


That is difficult to say. For me this issue was solved once I followed the above criteria. 


You can read about Grouped Push here:

Mobile Framework Synchronization Guide (ifs.com)

Synchronization Rules (ifs.com)

Grouped Push Transaction Queue (ifs.com)

Cheers

James


I have the same behavior and documentation and the things mentioned by NEJANO was checked but not helping. The Init state is present over a month and no error is thrown anywhere. I don’t find any possibility to cancel the process, restart or analyze it.

How can I proceed finding the cause of this?


Check that all DB Process and Batch Queues are active and running.

Also check that the GP User has been granted access to the Sites you want to see data for and that you haven’t just granted all sites for to the GP user


Check that all DB Process and Batch Queues are active and running.

All are running and I even restarted them. In System Parameters they are also Set to On.

Also check that the GP User has been granted access to the Sites you want to see data for and that you haven’t just granted all sites for to the GP user

GP User ist granted to two sites. When starting mWO App you can see that some of the data will be fetched (only some entries) but the synch will never finish and the GP process is stuck on Init forever.

 

Additionally we have granted the GP User all rights in IFS and also all Activities for mWO purpose.

 


GP User doesn’t need any access rights. 

Any errors shown in any of the logs?


GP User doesn’t need any access rights. 

Any errors shown in any of the logs?

No errors anywhere. I also have searched with Support for any hints but no clue why it is stuck.
Case: CS0118565

 


You could try increase the log levels of the Grouped Push process and see if anything gets reported in the Grouped Push logs


You could try increase the log levels of the Grouped Push process and see if anything gets reported in the Grouped Push logs

Support has done that and we have tried to Init a new GP. No further information was found. The only information in the system is still “Init GP” even though a new GP was triggered.

 

 


Started a new initialization and this is the outcome

 


This isn’t the correct log levels to increase to trace grouped push issues. These are Application Parameters as documented here: Application Parameters (ifs.com) and you will see the logs in Grouped Push Transaction Traces documented here: Grouped Push Transaction Traces (ifs.com)


Ok, so here are the Traces

 


Could you increase GP log level to INFO for the following GP application processes then we may see additional info when the GP process next runs:

BATCH_TRACE_LEVEL
INIT_TRACE_LEVEL

 


Hi

If you see ‘Init waiting for GP’ for longer period for device app, then it could be because of large no of data in the GP entities due to the missing data filters (permission Set Filters). 

Once you increase the log level to INFO for both (batch and Init under GP application parameters), please search for below trace lines to find what’s going on with the GP Init database process: 

  • Search for the GP trace for below text ‘INIT sub-task has been running in%’. This will tell if init transaction is stuck and the time in seconds. 
  • In case init transaction is stuck then need to kill that. You can do this after apply filters to users. Otherwise it create another init session and again goes to the same stage. Search for the GP trace for the text ‘Started background job %‘ this will give you the Oracle job id and DBA need to kill it. 

Could you increase GP log level to INFO for the following GP application processes then we may see additional info when the GP process next runs:

BATCH_TRACE_LEVEL
INIT_TRACE_LEVEL

 

Found it and I’ve set these to INFO. Let’s see what information we can fetch.


Here is the Output of the Grouped Push Transaction Traces.

 

In the file you can find this

 

INIT sub-task has been running in n5088419.009] seconds and has not finished yet. Nothing to accept.

 

But I can’t find the according background job. So I will try to set filters as you said. Never done this before though.

 

EDIT:

 

User Filter looks like this at the moment. I didn’t configure anything beforehand.
Looks that someone has already done changes.

 


Hi

As per the logs you have provided, there is a GP Init which is running days now and seems to be stuck at the database. Within the log details provided it does not shows the Db process Id. So DBA need to find this long running db process which is normally start with F1_Job% and need to kill it. But before that you need to apply the correct PS filters to the GP entities. Please make sure to keep one PS per mobile users which are granted to mobile activity. 


Hi

as the environment is hosted by IFS Managed Cloud, I don’t have access to TAS or DB directly.

I will try to set up Permission Filter with a colleague in April and will try to get the DB jobs killed.

 

Thanks for your feedback so far!

 


In the meantime the DB was cloned from PROD to TEST and the following script was now executed:

BEGIN
FNDMOB_DEPLOYMENT_SYS.Post_Db_Clone_Cleanup;
END;
/

 

After that the mWO works again.


Reply