Skip to Content
avatar image
Former Member

SAP Workmanager 6.2 Change Detection Time Limit

Dear all,

I need your expert advice to resolve this issue.

We have configured Work Manager 6.2 in our landscape and customized it in accordance to our customer requirements. However, I want to understand how the delta detection works.

I checked GetWorkordersStepHandler class and found the following lines of code.

String agentryLastUpdate = this._user.eval("<<lastUpdate format=\"%m/%d/%Y %H:%M:%S\">>");

agentryLastUpdate contains the exact time when the application was last updated successfully. However, I have noticed that the agentryLastUpdate is OK when I sync the device within a couple of minutes elapsed from the last successful sync. But when time elapsed from the last successful sync becomes more, even though no change is done, all the work-orders, notifications and catsrecord start syncing.

Can anyone put some light on this. Any kind of help in this regard will be much appreciated. Thanks in advance.



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Oct 30, 2015 at 02:39 PM


    Hi. We are trying to review your question in this query. We are not really sure what you mean by "agentryLastUpdate is Ok" and "start synching for Workorders".

    It will be easier if you have actual time example for us to give a comment in this thread.

    We have several fixes tied to time stamp and we are not sure if you are referring to something that we may give you. Please add more detail so we can assist.

    Thanks in advance,

    SAP Mobile Support Team

    Add comment
    10|10000 characters needed characters exceeded

    • I would recommend the following test

      1. Perform the initial sync to get the 10 WOs and 5 Notifications and note the date/time
      2. Perform a second sync to confirm nothing new comes down and note the date/time
      3. Check the exchange table to confirm the last update timestamps
      4. Wait 15+ mintues
      5. Check the exchange table and confirm the last update timestamps still match those from step 3

      If the timestamps don't match then ther eis most likely something running on the backend that is updating the objects and triggering the exchange processing.  If the timestamps still match and the next transmit brings down all objects again then you will need to check the logs to confirm the last update date being used initially, after the delta and after 1 minutes.