Since we updated to iOS 10, and up to the iPad App version 16.20.010, with browser version 16.10000.24, we have had a trickle of reported sync issues, where sync times have suddenly jumped from 1 or 2 minutes up to 20 -30 minutes, or are timing out. Over the years we have done a lot of work in reducing our sync times, and we had got them to point where the times were acceptable, but from about October onward, we are getting these persistent reports of these longer sync times.
The problem with this issue, is that it is seemingly random, it affects different users at different times, and in different places, we have received reports from all the world; all i can say is, there is a steady trickle of one or two reported incidents a week, though there is probably a number of occurrences that are not being reported. We have tried to replicate the problem by logging in as the user having the problem, but of course, it all works as expected when we try it.
Sometimes, to fix the issue, the user simply tries again, other times a full reset is needed.
In the main the system works as well as it ever did, its just that we are getting these persistent reports of problems, has anybody had any similar experiences?
iOS 10 could just be a coincidence.
Are you regularly emptying the org recycle bin?
Are you deleting job logs regularly (and afterwards emptying the org recycle bin?
Thanks for coming back, yes it may be a coincidence, it was about the same time that we updated to alter version of the Winter 17 app as well. We turned of syncing logs a few months ago, (on Smx advice) as they were causing some syncing problems.
Its hard to quantify, but it feels the number of reported incidents is increasing.
I am seeing very similar issues, and have been for a while. Exactly as you describe in your original post but not sure I can attribute it to the iOS10 upgrade. I do not see the problem when I try to troubleshoot as the user either. I am interested in the effect that the size of the recycle bin and sync logs has on the timing. Have you done anything to monitor or manage them to avoid the sync problems?
I keep asking for some troubleshooting tools to dig deeper into the errors so I can find the query or object that is causing the problems, but nothing forthcoming so far.
Have you tried this tool? https://msupport.servicemax.com/
It used to be invite only, but I think it's generally available now.
You need to login as a user, but it lets you simulate initial and subsequent syncs for that user.
We just tried the Mobile Client for the first tome on IOS 10. Over the same Wifi connection the Mobile Client on a iPhone can't sync but on the laptop (Windows) the field service client does sync.
so in the picture, it designates [min:sec:msec] as time dilineations - in actual practice, does that hold true?
As in, does an initial sync on a live mobile device able to complete all those download steps in seconds?
9629 total records
Servicemax have found an issue with our set up, we only had one Apex scheduled job running, rather than 2. We have no implemented the fix, so we are now monitoring the long sync times, early indications are not good though, our colleagues in Germany are still seeing them.
which scheduled job are you referring to? The one that deletes sync log records - Or something else?
Here's a template for scheduling jobs if that is what you are missing?
:: Developer Console - Debug - Open Execute Anonymous Window
SVMX_MobileSyncRequestScheduler aj1 = new SVMX_MobileSyncRequestScheduler ();
// 'sec hr mn yr
// min day day.name (MTWHF)
String sch1 = '0 24 * * * ? *';
System.schedule('SVMX Sync ClearOut Daily Job xx24', sch1, aj1);
**above exmaple runs a scheduled job on the 24th minute of every hour, the '*' indicates a wildcard, or a "any possible entry" qualifier
We had a single scheduled apex code event, set up by Smx, which would run each hour, and delete any accumulated sync logs, when they recently reviewed our set up, they said the job should run every 30 minutes, rather than each hour, so they sent up instructions to create 2 scheduled jobs, which we applied.
The feedback from the field is indicating that this hasn't fixed the issue though, so it back with Smx.