SP17 P3 issue with "Cannot insert as entity"

[Former Member]

Hi,

I have a short question to SP 17 client patch 3, but I have to describe the szenario first. We are using SP 17 client patch 3, and from time to time we are missing some data on the client. I digged really deep in the merep_mon and I can see that the data is send to the client. And on the client I can see the missing data in the tracefile. But the data is missing in the MI persistence layer.

I could see that the data is send via different containers with container id or sequenc numbers. And I could see that I get a

com.sap.ip.me.spi.persist.IPersistenceException: Cannot insert as entity already exists for IClassDescriptor/Key: cZPARTNER_TOP/1729771

Exception during the process of a specific container. And than I notices, that all the missing data, was send with this specific container.

So the client is processing the container, gets the exception above, cancels the processing and discards the data in the container.

Has anyone the same issue and is this fixed with SP 17 Patch 6?

Greetings,

Kai

[Former Member · Accepted solution]

hello kai,

i think this is by design. MI client processes the messages on a container-based

manner. formerly, 1-container has 1-syncbo but was later changed for performance

reasons.

the message exchange between the MW and client is somewhat "trusted" thus

when one party messes up, it will cause the whole mess. first, try to check why

the middleware sent a syncbo having the same synckey to the same client? the

client won't be expecting this. thus when this happens, it means that the replica

DB of the device had become inconsistent with that of the client.

regards

jo

[Former Member · Accepted solution]

Hello Jo,

I agree with you, that the client and the replica db is a kind of "out-of-sync", but I do not know the reason for that and I have no idea how I can analyse this issue. We have the application running on 150 client since several month and it seems, that from time to time we get some clients out of sync, followed by the issue I mentioned in my question. The clients are synchronizing several times a day, so we have huge log files and it is very difficult to locate the one synchronization where the client is getting out of sync.

In my opionion the client should do following after a duplicate key issue came up: It should ignore the data where the Exception occured, but of course it schould process the other data sets and it should not throw the other data away, without telling the server, that this issue occures. The perfect way would be, that the client would inform the server about the duplicate key, so the server can add the data set to the replica db. Than we would have a kind of self healing replica db, if the issue occures. At the moment I am hoping that the issue is gone with SP 17 Patch 6, if it is not, I have no idea how I can prevent the out of sync with the replica db....

Greetings,

Kai

[AjithC · Accepted solution]

Hi Kai,

This might be due to duplicate Add requests from the server. There is already a note available for this problem. Apply the note 947091. Hopes this solves the problem.

Regards

Ajith Chandran

[Former Member · Accepted solution]

Hi Ajith,

thanks for the note 947091.

Unhappily the note describes a scenario where the data is modified from the client and the modification in the backend fails. In our case we are working with the customizied SyncBO ZPARTNER, which can not be modified on the client in any case. So the SyncBO is a T51, but we did not implement the MODIFY BAPI in the backend. Therefore the SyncBO is only a download SyncBO.

And we implemented the SAP Note in the system allready...

I think it is more an issue more related to the communication between the middleware and the client. We are synchronizing via GRPS or UMTS...maybe this

tangles the synchronization from time to time...

Greetings,

Kai

[kishorg]

Hi Kai Mayer,

<<<

com.sap.ip.me.spi.persist.IPersistenceException: Cannot insert as entity already exists for IClassDescriptor/Key: cZPARTNER_TOP/1729771

>>

<<cZPARTNER_TOP/1729771>>

Here the duplicate entry error happened for header data (TOP),

In this case , duplicate entries for the same header key is existing in the header data. just check the key field mappings in the 'Tables' tab of your SyncBO for GETLIST Bapi Wrapper.

If the problem is with ITEM data (010,020,...)

I think it is because of insufficient key field mappings in the GETDETAIL BAPI Wrapper. Just have a look at the key field mappings of the GETDETAIL in your syncbo and make it sure that you have properly mapped all the key fields.

Just check, there is no chance for getting more than one record in the BAPI Wrappers if you have only one field as key in your SyncBO(applicable to GETLIST also)...

refer this forum also.. I have already discussed a similar problem in this thread..

Regards,

Kishor Gopinathan

[Former Member]

Hello Kishor,

thanks for your reply. I missed to mention that the application is running on 150 clients since several month and we have this issue on only some of them. So the mapping of the key fields is correct. The issue is more that the replica db and the client is a kind of "out of sync", but I do not know the reason....

Greetings,

Kai