Hi @Ethan M,

Could you please elaborate this more?

• Can’t you see any records in mm_message_out?
• Do you have any mobile records(person_mobile)? If so, are they active?
• What’s the recent last_sync_dttm for person_mobile records?
• Did you check the app param value of DEVICE_LAST_SYNC_LIMIT?

If everything looks good, please follow the below steps.

• Initialize a new device.
• after initialization is completed, keep the device in offline.
• Make sure there are no records in mm_message_out for person. If exist, keep the mobile device online until records are deleted in backend.
• Assign a task to that person, and do change the task status till IN PROCESS(In Progress).
• Change some other changes on task(such as description) to make sure that there are significant changes to trigger extracts. - You can execute the related-query of task in XML poster to check the outcome.
• check mm_message_out record for person.

If still, you cannot see any records, let me know the outcome.

Thanks.

Hi @Ethan M,

Just to add to Anjula’s answer, the most common cause of this post upgrade is either not re-initialising the mobile device or still using the previous versions mobile app instead of the updated one for the new version. I would check the version showing on the mobile app matches the back office client and confirm the mobiles have been re-initialised.

Kind regards,

Lee Pinchbeck

@Anjula Priyanath , @Lee Pinchbeck 

answering on behalf of Ethan / Same org. 

when we upgraded we wiped all person_mobile records and individually walked each tech through re-initialization.  (download new version, install, then re-initialize) 

Initialization is always successful.   All tasks, notes, etc. show up as intended.

We have tried what you suggested multiple times, but mm_message_out remains empty.

1. initialize new device
2. confirm person_mobile is active
3. assign new task
4. update task values
5. check mm_message_out (nothing..)
6. sync mobile (nothing, of course) 

we are noticing that Initialization requests and Password resets ARE making it to the mm_message_out table.

1. change the password of a user in FSM
2. check mm_message_out
   1. confirmed record with transaction_type PCHANGE

we are at a loss here..  for some reason INSERT and UPDATE events are not writing to mm_message_out, where they used to before..

Sincerely, 

-Rudy

One additional finding.

there are 2 technicians that DO actually receive updates when tasks are updated/assigned.

These 2 technicians appear to be set up the same as others. (I’m running through more analysis now)

the “last sync dttm” is NULL for everyone… Except for these 2 technicians. 

Hi @Rwjgoedhart,

Couple more things to check:

1. If you set up a brand new user and install FSM on a new mobile device for them does it work?
2. Are you able to track the extract for Task? This should be what fires the update to mm_message_out so if it is not being written to perhaps this is not seeing the updates to task as a trigger for the extract?
3. Does the database show scripts running to update mm_message_out? Then we can work out if the update never fires or if it is failing to write.
4. How big is the mm_message_out table currently?

Kind regards,

Lee Pinchbeck

@Lee Pinchbeck 

Comments in Red

1. If you set up a brand new user and install FSM on a new mobile device for them does it work?
   1. mRG] No, it does not work for brand new users with brand new initializations. (i created and initialized one just now. exact same behavior, initializes OK, but no updates, no mm_message_out)
2. Are you able to track the extract for Task? This should be what fires the update to mm_message_out so if it is not being written to perhaps this is not seeing the updates to task as a trigger for the extract?
   1. mRG] ​​​​​​​Where/how would we track the extract?  we do know initialization works… and those 2 users do work on the same tasks that don’t work for others, so may not be the extract after all.. 
3. Does the database show scripts running to update mm_message_out? Then we can work out if the update never fires or if it is failing to write.
   1. ​​​​​​​�RG] Yes, we are seeing mm_message_out being updated. just not consistently.  
4. How big is the mm_message_out table currently?
   1. ​​​​​​​eRG] 45 Rows.

I found the solution

When new devices initialize --  The “Last Sync Dttm” on the Person_mobile log is onull]

any mobile device with “Null” will not update

when I (database update) the value to something/anything..  Updates start working.

This may be an actual FSM bug.   We can solve this by forcing a value into the field through metadata defaults.. .

update person_mobile set last_sync_dttm = '2022-07-24 12:00:00.000' where last_sync_dttm is null

 

after the above was executed. All updates/inserts started working as intended…

Sincerely,

-Rudy

Only problem that remains;    even though all synching is now working as intended, the “Last_sync_dttm” remains static.. It does not update to the actual last sync date..

@Lee Pinchbeck, do you by chance know what is supposed to update that field?  Any idea why it wouldn’t even when syncs are successfully completed? 

Hi @Rwjgoedhart,

My understanding is that it should be part of the clean up at the end of the sync along with removing the items from mm_message_out that were synched. If the items are now getting down to mobile and the mm_message_out queue is reducing then it should update.

There hasn’t accidentally been restrictions been put in place on the user that the system uses for the mobile service? If the role on the person record has write restricted to the person table then it will not be able to update the field whilst still being able to amend the mm_message_out table.

Kind regards,

Lee Pinchbeck

Nailed It, @Lee Pinchbeck 

role had “tables” permissions set to person_mobile disabled.

Oddly; this has been in place since March 2021, and never posed issues with previous versions.

so 2 issues.

1. FSM doesn’t sync when Last_sync_dttm is null in person_mobile
2. having table restrictions on the role only seems to affect syncing, where you’d expect it to stop the mobile initialization as well. 

in any case;   Solved by: 

• Fixing role permissions
• updating person_mobile with last_sync date for existing records.

Sincerely,

-Rudy

Hi @Rwjgoedhart ,

I can explain why the initialisation is not blocked and could not be blocked in this way using role permissions. 

When mobile initialises it first pulls down a generic database framework for FSM and after that it then goes and syncs in the specific users data. The role restrictions are specific to user so it cannot know the restrictions until after it has pulled the user data by which point it is already initialised.

The way to block an initialisation is via the licensing. If the user details entered to initialise the device are not licensed for mobile then it will fail authentication and not initialise.

Kind regards,

Lee Pinchbeck