With a properly configured solution, there should be no reason for manual manipulation of the table contents. If messages remain in the table for more than a day for active users, there is usually a configuration problem. Therefore, the recommendation is to analyze the table contents to determine why the messages are not being removed in a timely fashion.



One of the main problems is usually device management. If a user goes on extended vacation or leaves the organization, messages will build up for the user’s devices without proper administration. Be sure that the DEVICE_LAST_SYNC_LIMIT app param is set and that Replications are running. If a user leaves, change Person Status to Inactive and delete all their mobile device records. There are many other potential reasons, so the message records will need to be analyzed to find other root causes.



In the meantime, if system performance is a problem because of volume of messages, you can simply delete all messages created more than N days ago. Start with the same value as the DEVICE_LAST_SYNC_LIMIT value (default of 14 days), and work down until the table is at a reasonable size. Any users that haven’t synced within that time interval will need to Initialize their devices to be sure to have all the data they are supposed to have

---

With a properly configured solution, there should be no reason for manual manipulation of the table contents…. 

The content in the above answer is really good info on how to analyze and manage a situation likely caused by configuration problems.  

To answer the original question more directly, the process that removes the records in mm_message_out on the FSM database is simply the normal mobile client synchronization process.  When the client gets messages from the server, they are deleted from mm_message_out.

---

Hi Dilan,

 

Adding to above the table mm_message_out holds messages for mobile users, if they are not consuming, it will be stacked there. Which need to be monitored to find the cause why it's being not consumed and accordingly alignment of configuration needs to be done. As with the growth of table size other Engineers/FTs might start facing sync issues, like slowness in sync.

 

As an temp solution we can purge messages of Engineers/FTs to facing issues, asking them to re-sync.

 

Hope this works and you will be able to solve the issue.

 

Thanks,

Shivam

---

HI,

i think to add little bit to above. 

Last_Synchronization_date is recorded under person_mobile tab. So use it to find out what devices are not get sync in last ‘N’ days. you can use below simple SQL query to find out mm_message_out records which devices are not synced for last 14 days,

 

SQL Query for MS SQL Server

select * 
from mm_message_out mmo
where 
(person_id+convert(nvarchar(255), device_sequence)) in 
 (select (person_id + convert(nvarchar(255), sequence)) 
 from person_mobile
 where last_sync_dttm < getdate() - 14)

 

If you think that 14 days is not enough, change the numeric value here. You can use above logic with delete statement to delete the records from the mm_message_out

 

According to how FSM mobile is initialize and sync process, it is good to initialize the device when the device is not synced fro last 14 days. 

---

Hi Dilan,

I found that @anpelk  & @brian.gummin  has explained the process concerning mm_message_out deletion. And also I assume, you aware of the relation and behind the scene of the mobile initialization and mm_message_out table.

First of let’s verify person_id for the records of mm_message_out and then find an assigned role for that person.

You can see the ‘table’ tab in the role screen for each role as below.

User can add tables here manually and set the restrictions for that table such as Disabled/ Read Only or No Delete. Or else after click the Generate Role Tables button, it will create the restrictions automatically. Because of this reason, mm_message_out cannot be cleaned up at the mobile initializing process.

Extra - This caused to the INIT process also. So, INIT process takes unterminated loop.

//Anjula

---