I'm trying to find out what causes long mWO initilazation time.
I've found a thread on community regarding slow initialization https://community.ifs.com/service-touch-apps-mwo-mro-43/long-delay-in-mwo-app-10-initialization-process-13158
Now, our customer reports slow initialization and also synchronization. Initialization takes up to 1.5 hour (measured in local network), synchronization also takes a lot of time and usually is unsuccesfull (done on mobile data far from work).
I did a test yesterday evening using vpn connection and in my case initialization took 20 minutes. Looking in synchronized objects tab on mobile user, the most time consuming entity was InventoryPartInStock and InventoryPart But summing time for entites it should take approx 3-4 minutes to finish.
On my iPad after downloading entities there was a longer approx 10 minutes or more period with a Waiting for Server message
After that there was another information about Processing messages for a minute or two.
And finally application loaded.
I wonder if there is a way to find out what’s takes the time in Waiting for Server phase. Is it waiting for some database task (background job) or something else? In previous test during day it took 8 minutes to fully initialize.
So the time varies - maybe application is waiting for a particular process or job and it could be fastened by setting such job to run more frequently?
According to query from above thread the results on PROD are as below
Regarding synchronization - I’ve found background job Mobile_Batch_Sys.Execute_Job_ which takes sometimes up to half an hour
Is it responsible for synchronization time and also affects initialization time?
Are there any settings which could shorten times and makes technician work without long delays?
I would appreciate any help.
Best regards,.
Hubert
Page 1 / 1
Looks like Apps 10. If so there is a Lobby Page which shows the performance timings of the Sync. It could be that one or more entities are taking the time. Look to see which entities are taking the time to sync. If its due to data then you can add a Permission Set Filter to reduce the data and speed up the sync times.
Cheers
James
Hi,
@James Ashmore - you mean this lobby? I've entered AppName as ServiceEngApp - same as on mobile user
I did a new test - disconnected and connected once again so it forced full initialization. Updating data like InventoryPart... etc. took approx. 5 minutes, then there was 35 minutes with Waiting for Server on iPad. During that time in mobile user in application there was Init waiting for GP status.
What exactly means "Waiting for Server" ? Does the iPad waits for information from server or waits for some background jobs to finish?
Looking for VPN connections stats on iPad seems like there is no data communication during first few minutes when "Waiting for Server" and very low traffic (~1kB/s) in next minutes(I'm not sure if it's only mWO, the OpenVPN stats may show other iPad networ usage).
So I can suspect 2 things: first - a local DB is being built during that time on iPad but it seems too long or second - iPad is waiting for something to be done on server.
Finally it synchronized and in logs I can see a time gap between 13:10 and 13:40 - in that time it was waiting for server.
What happened during this 30 minutes?
Best regards,
Hubert
Sounds like a potential problem with Grouped Push entities. This Sync Method is used in MWO to sync the Equipment Objects. The Grouped Push process should run overnight and collect the datasets for the end users. Once the end users connect they will be given the latest copy of the data sets they belong to. By default this is defined based on Site access. However, the first time a User ever connects with a data set not already prepared by the nightly Grouped Push process the server will start preparing this data for them. This can take some time. However, once this process completes it should be quick for subsequent users.
Indeed, there is a problem with Grouped Push. I’ve found almost 200 000 rows in mobile_transaction_offline_tab and seems like there is a problem with processing them due to ORA-00001 error in MOBILE_TRANSACTION_PUBLISH_SYS
The procedure has been recently changed in standard, so we are going to apply the change (only in the procedure below as the change was marked as grouped patch to apply with a whole UPD)
PROCEDURE Insert_Offline_Rows___ ( entity_ IN Transaction_Entity_Row, transaction_filter_id_ IN VARCHAR2, objkeys_ IN Objkey_Table, context_ IN Transaction_Context) IS tab_ Mobile_Objkeys_Type; -- Local PLSQL collections cannot bind into insert, update, delete, or merge insert_count_ NUMBER; BEGIN IF objkeys_.COUNT > 0 THEN SELECT column_value BULK COLLECT INTO tab_ FROM TABLE(objkeys_);
--Only insert missing OBJKEYs to the table INSERT INTO mobile_transaction_offline_tab(app_name, app_version, entity, transaction_filter_id, objkey, rowversion) SELECT entity_.app_name, entity_.app_version, entity_.entity, transaction_filter_id_, D.column_value, 1 FROM TABLE(tab_) D WHERE NOT EXISTS ( SELECT 1 FROM mobile_transaction_offline_tab WHERE app_name = entity_.app_name AND app_version = entity_.app_version AND entity = entity_.entity AND transaction_filter_id = transaction_filter_id_ AND objkey = column_value);
High number of record in mobile_transaction_offline_tab causes slowness each time grouped push is being executed..I expect that after the fix the initialization time will be shorter.
@James Ashmore - from your experience - is the default 10 seconds execution interval of Grouped Push in database processes proper, or should it be increased? I think it’s a default setting, not changed by anyone.
Yes, the 10 second execution interval should be fine - we have conducted lots of testing around this area to ensure the parameters are satisfactory for all installations. Please retest once the update has been applied
Cheers
James
Hi,
Indeed, there is a problem with Grouped Push. I’ve found almost 200 000 rows in mobile_transaction_offline_tab and seems like there is a problem with processing them due to ORA-00001 error in MOBILE_TRANSACTION_PUBLISH_SYS
The procedure has been recently changed in standard, so we are going to apply the change (only in the procedure below as the change was marked as grouped patch to apply with a whole UPD)
PROCEDURE Insert_Offline_Rows___ ( entity_ IN Transaction_Entity_Row, transaction_filter_id_ IN VARCHAR2, objkeys_ IN Objkey_Table, context_ IN Transaction_Context) IS tab_ Mobile_Objkeys_Type; -- Local PLSQL collections cannot bind into insert, update, delete, or merge insert_count_ NUMBER; BEGIN IF objkeys_.COUNT > 0 THEN SELECT column_value BULK COLLECT INTO tab_ FROM TABLE(objkeys_);
--Only insert missing OBJKEYs to the table INSERT INTO mobile_transaction_offline_tab(app_name, app_version, entity, transaction_filter_id, objkey, rowversion) SELECT entity_.app_name, entity_.app_version, entity_.entity, transaction_filter_id_, D.column_value, 1 FROM TABLE(tab_) D WHERE NOT EXISTS ( SELECT 1 FROM mobile_transaction_offline_tab WHERE app_name = entity_.app_name AND app_version = entity_.app_version AND entity = entity_.entity AND transaction_filter_id = transaction_filter_id_ AND objkey = column_value);
High number of record in mobile_transaction_offline_tab causes slowness each time grouped push is being executed..I expect that after the fix the initialization time will be shorter.
@James Ashmore - from your experience - is the default 10 seconds execution interval of Grouped Push in database processes proper, or should it be increased? I think it’s a default setting, not changed by anyone.
Hi @HubertZ Thanks for sharing the investigation results with reference to MWO initialization. Would you kindly advise if the above inserted procedure worked with reducing the time, as we are facing similar longer waiting times during the device initialization. We are using Application 10 UPD 9. Thanks for your kind thoughts.
Hi,
Indeed, there is a problem with Grouped Push. I’ve found almost 200 000 rows in mobile_transaction_offline_tab and seems like there is a problem with processing them due to ORA-00001 error in MOBILE_TRANSACTION_PUBLISH_SYS
The procedure has been recently changed in standard, so we are going to apply the change (only in the procedure below as the change was marked as grouped patch to apply with a whole UPD)
PROCEDURE Insert_Offline_Rows___ ( entity_ IN Transaction_Entity_Row, transaction_filter_id_ IN VARCHAR2, objkeys_ IN Objkey_Table, context_ IN Transaction_Context) IS tab_ Mobile_Objkeys_Type; -- Local PLSQL collections cannot bind into insert, update, delete, or merge insert_count_ NUMBER; BEGIN IF objkeys_.COUNT > 0 THEN SELECT column_value BULK COLLECT INTO tab_ FROM TABLE(objkeys_);
--Only insert missing OBJKEYs to the table INSERT INTO mobile_transaction_offline_tab(app_name, app_version, entity, transaction_filter_id, objkey, rowversion) SELECT entity_.app_name, entity_.app_version, entity_.entity, transaction_filter_id_, D.column_value, 1 FROM TABLE(tab_) D WHERE NOT EXISTS ( SELECT 1 FROM mobile_transaction_offline_tab WHERE app_name = entity_.app_name AND app_version = entity_.app_version AND entity = entity_.entity AND transaction_filter_id = transaction_filter_id_ AND objkey = column_value);
High number of record in mobile_transaction_offline_tab causes slowness each time grouped push is being executed..I expect that after the fix the initialization time will be shorter.
@James Ashmore - from your experience - is the default 10 seconds execution interval of Grouped Push in database processes proper, or should it be increased? I think it’s a default setting, not changed by anyone.
Hi @HubertZ Thanks for sharing the investigation results with reference to MWO initialization. Would you kindly advise if the above inserted procedure worked with reducing the time, as we are facing similar longer waiting times during the device initialization. We are using Application 10 UPD 9. Thanks for your kind thoughts.
Hi, I’m facing the same.
Any news @HubertZ ?
Tks a lot
Hi @lopespetro & @ISD
The fragment of the patch mentioned above resolved the ORA-00001error, but the synchronization time remained long. I’ll have to look into again as we have now few users facing this issue.
Best regards,
Hubert
Hi @lopespetro & @ISD
The fragment of the patch mentioned above resolved the ORA-00001error, but the synchronization time remained long. I’ll have to look into again as we have now few users facing this issue.
Best regards,
Hubert
Hi @HubertZ Thanks for your kind feedback. Would be great if you could kindly share any findings and recommendations on further investigations. Good luck. Thanks.
Hi,
I’m wondering if the information from lobby could let me find what’s causing the initialization time.
Or if the running background jobs affect the initialization time.
The time in seconds in first column varies, the longest at nigth.
But when I take a new device and login to mWO and start initialization, does it have to wait for a particular process in server to finish?
I did a test yesterday, connected to TEST environment and start initialization. It was running quickly first, but next for a good 20-30 minutes it seemed like it was waiting for the server.
@James Ashmore - you probably know the most how does it work - could you please add a coment?
Customer has reported me 2-3 users who were unable to initialize in 2 hours. They got new tablets and were unable to work.
That’s how it looked yesterday on TEST - a long break between 13:07:09 and 13:41:07
For some entities there are filters using contract (one user = one contract/site) but people using mWO replace each other, so I can’t see other way to limit number of data.
Best regards,
Hubert
The delay in the sync looks like it is down to Grouped Push.
Grouped Push collects data for known user filters based on the users already initialized. If the filter changes then the Grouped Push process will start the collection of data for the user on Initialization. If its a large dataset then this will take time.
This is why we often see the first Initialization takes time yet subsequent initializations are faster.
At the moment the Lobby doesn’t display Grouped Push statistics but we are working on this.
