Questions for Confluence license has expired.

Please purchase a new license to continue using Questions for Confluence.

Attribute __SYNC_BACK_ON on the remote replica when using syncHelper.syncBackAfterProcessing

 
1
0
-1

Hello,


We are trying to make sure only some fields are updated when syncHelper.syncBackAfterProcessing() is used. There are some warnings at https://docs.idalko.com/exalate/display/ED/syncBackAfterProcessing but the provided solutions are far from clear.


There is this undocumented __SYNC_BACK_ON attribute on the remote replica when receiving the data from a syncHelper.syncBackAfterProcessing() on the other side. It is not present when the synchronization is caused by an update. 



{
  "version": {
    "major": 1,
    "minor": 14,
    "patch": 0
  },
  "hubIssue": {
    "status_update": "Test F",


    "__SYNC_BACK_ON": 1649857792812,




    "key": "MYTEST-4683",
    "summary": "Test F",
    "comments": [],
    "internalMap": {
      "status_update": "Test F",
      
      
      "__SYNC_BACK_ON": 1649857792812,
      
      
      "eventTriggerContext": {}
    },
  },
  "issueUrl": "https://mytestjira.com/browse/MYTEST-4683"
}


We are planning to use it like this



   if (replica.__SYNC_BACK_ON) {
        //Updates only some fields
        
        entity.u_external_reference_id  = replica.key 
		...
        
    } else {

     //Update all fields

   ...

   }



Is it safe to use it? Is it going to be deprecated any time soon? Is there any documentation about this attribute?


Thanks.



    CommentAdd your comment...

    1 answer

    1.  
      1
      0
      -1

      Hello, Enrique Cadalso , at the moment, there are no plans on deprecating it.
      I'd actually suggest to use syncRequest.remoteSyncEventNumber == 1 (on connections that have syncBack configured) instead (even though it's not directly saying, that sync is caused by sync back), it's consistently same on all the platforms.

      Regards, Serhiy.

      1. Enrique Cadalso

        Hi Serhiy,


        Thanks for the suggestion. I will use syncRequest.remoteSyncEventNumber == 1 instead.


        One caveat of that option is that, for troubleshooting purposes,  we can inspect the replica and see the replica.__SYNC_BACK_ON attribute on the "remote replica" using the "Entity Sync status" option on Exalate, but I we won't be able to see the value of syncRequest.remoteSyncEventNumber had on the last replica.


        Thanks again,


        Enrique

      CommentAdd your comment...