cancel
Showing results for 
Search instead for 
Did you mean: 

Related sync bo is deleted, but is still needed on client

Former Member
0 Kudos

Hello,

we have implemented an individuall application using the smart

synchronization. Now we have an issue with the synchronization in the

following case:

Szenario:

We have a SyncBO ZSRVPROC which has a relation to the SyncBO ZPARTNER.

1. If we create a data set ZSRVPROC (A) which has a relation to ZPARTNER(C) both data set are send to the client.

2. Now we send a this data set ZSRVPROC (B) to the client which has a

relation to the same ZPARTNER (C) SyncBO.

3. We delete the first data set ZSRVPROC (A) from the client.

4. Now the data set ZPARTNER (C) is also deleted from the client.

5. Now we have an issue, because the data set ZSRVPROC (B) is still on

the client, but the related SyncBO ZPARTNER (B) is missing.

So the issue: if we have two data sets with a relation to the same thirddata set and we delete one of the first SyncBOs, the related SyncBO is

deleted also. But the related SyncBO is still needed on the client.

We are on SP 17 with the current SAP Notes and SP 17 Patch 1 on the client.

Is this a known issue and is there a SAP Note we have to implement?

Greetings,

Kai

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

hello kai,

generally, the smartsync client API does not delete the

referenced SyncBo when you delete the referencing object.

it is on your logic implementation where you usually do

this. check on the code where you are invoking the data

facade's deleteSyncBo method.

on your BAPI also, you have to check also that your

delete BAPI <b>does not</b> removed the referenced objects when

a header is removed.

regards

jo

Former Member
0 Kudos

Hi,

sorry for the missunderstandig. With "deleted" I mean that the data set is remove from the client during the synchronisation. So we do not call a delete method from the client API. In the mean time I opend a OSS Call and got the answer that the Note 954642 will solve this issue...mmhh..we will see....

Thanks,

Kai