Why does Sync send data several times during one request?

[Former Member]

Mobile Time and Travel version 1.6 SR2, MI version 2.1.

During data sync, we observe that the data gets resent several times on R/3 side.

Looking in trace.txt, we see the same thing. No errors are generated. This has been onging for a while, but only became a real concern recently. We have added a custom table with 4,000 rows X 6 character fields, which syncs only as needed. However, table MESYBODY is growing - when we analyze the oracle redo logs, the vast majority of redo log activity is being generated by MESYBODY.

I hope we can eliminate the repeated sync action. I have found a few SAPNotes relating to MESYBODY, and have passed them on to Basis team.

Thanks for your time.

[Former Member · Accepted solution]

Hi Tom,

When you start using MI, the tables MESYHEAD & MESYBODY grow considerably, but at a certain time it stops growing. These records are necessary for synchronization, these will get automatically deleted in the later syncs.

Can you please be more clear regarding "We have added a custom table with 4,000 rows X 6 character fields, which syncs only as needed". Where have you added this custom table?

@Alexander: WAF_MW_MAPPING is not used to remove unnecessary records from MESYBODY, but it is basically for processing the asynchronous generic sync requests. The records in MESYBODY are not unnecessary. They are needed for synchronization.

Regards,

Nameeta

[Former Member · Accepted solution]

Hi Nameeta,

I agree with what you write; this is the behaviour like it should be.

MTT is using GenericSync only in synchrone modus. IMO the report WAF_MW_MAPPING would not be required at all, as it is only required for asynchronous requests, right? But on many MTT customers I saw that the table growed and growed. After runnign WAF_MW_MAPPING, millions of records got deleted from MESYBODY . Thats why I say these records are unnecessary.

So my recommendation is to run WAF_MW_MAPPING even if you have a synchronous only GenericSync application. I'm not sure if I should call it a bug in GenericSync, but there are records that do not get deleted during the synchronous sync.

Best Regards, alex

---

alexander ilg

msc mobile

http://www.msc-mobile.com

[Former Member · Accepted solution]

Nameeta and Alex,

Thank you for your quick reply. MESYBODY has grown very large (89,000,000) records.

The custom table I mentioned is a Z_PICKLIST table and every user gets it every time they sync data. Is there anything special about limiting the frequency of synchronizing?

It appears that when one user synchronizes their data, the tables get sent and re-sent. We see this in the R/3 logs and mobile's trace.txt.

I passed along your suggestion to run WAF_MW_MAPPING.

Alex, I do remember you. We still use the connection verifier java you helped me write. Hope you're doing well.

Regards,

Tom

[Former Member · Accepted solution]

Hi Tom,

have you added your custom picklist to the CATS_MY_PUSH table? With that you should be able to limited the downloads to only one per user.

Best Regards, alex

---

alexander ilg

msc mobile

http://www.msc-mobile.com

[Former Member · Accepted solution]

Hi Nameeta and Alex,

Running WAF_MW_MAPPING does reduce the size of MESYBODY. In one environment, we saw the table size go from 1.2 million rows to about .25 million.

It seems that CATS_MY_PUSH table doesn't help control custom picklists. It still synchronizes.

Another idea we have is to implement a user exit during synch to control synchronizing that custom table. Is there a user exit available?

Thanks,

Tom

[Former Member]

Hello again,

Please advise if this follow-up question should be posted somewhere more appropriate.

Our concerns have evolved somewhat. We can tolerate the increased activity with MESYBODY, but it has also affected the redo logs. If we had to restore, it would take days. This has our basis team very concerned.

We would like to create a custom solution to somehow restrict updates to MESYBODY during sync. Is it possible to bypass those updates when synchronizing the custom picklist?

Our problem is really that we can't prevent the custom picklist from being sent every time the user synchronizes.

Your suggestions would be most welcome.

Thanks,

Tom

[Former Member]

hi Tom

There is one blog which talks about the "behind the screen" process of Generic Sync Apps. Check this one out /people/arun.av/blog/2006/03/09/process-flow-of-generic-synchronization-in-mi-abap-server-component

Your MESYHEAD and MESYBODY are just a collector of data containers. They have a flag on each of the record. On successful submission from client, a record gets created. WAF_MW_MAPPING sends those records to the respective backends. When the client gets the processed data successfully, the flag changes and the corresponding records gets deleted.

Hope that blog helps you to understand the scenario and help you to develop that custom solution to limit the updates!

Regards

Ak

Message was edited by:

Arunkumar Ravi

[Former Member]

Hi Tom,

even if this should not happen, the tables MESYHEAD and MESYBODY keep growing and growing.

To clean them, try to run the report WAF_MW_MAPPING. This should remove most of the unnecessary records from MESYBODY. Let me know if this works.

MTT works in a way that the data will get pulled out of the backend separately for each user. So if you have 1000 users, the backend will be accessed 1000 times, even if the data is the same for every user. What exactly do you mean with the data is resent by R/3 several times? Several times for one user, or several times for multiple users?

What type of custom table did you create? A picklist?

Take care, alex

PS: Remember? We once meet in Nashville ...

---

alexander ilg

msc mobile ltd.

http://www.msc-mobile.com