Hello,
I recently noticed that one of our services generated a lot of duplicate entities in a data source. Upon further inspection, it appears that the web request fails to update existing objects, and that the Object State of every entity that is received from the API call is “New” regardless of whether the entity exists in the Dokumenter I Landax (temp) already or not. The log to console node below would consistently return 1000/1000 objects as “New” even when they clearly were not.
During debugging I deleted all objects in the data source, introduced a uniqueness constraint on the “Dokumentlink ID” parameter before re-running the service to get the API data. After filling the data source again from the API, the second attempt at running the service (update with changes) threw an error when I tried to persist the objects in the data source with Object State “New” citing the uniqueness constraint. From how I understood the Object State the “New” object that causes the error should have been either “Updated” or “Synchronized” since it already exists.
Any ideas as to what could cause this error?
Hi!
I just tested this, and the object state New vs Synchronized behaves as expected, both in Apps and Services.
Could it be that the property mapping of that web request has not been set for Dokumentlink ID?
Here is a similar case that works. Companies (temp) is read before the web request. After the web request, existing companies found in the “Companies (temp)” data source gets object state Updated or Synchnronized (whether they have a change or not) and all new companies received (not in the companies (temp) DS) gets object state New. But for this to work, the property mapping must be set for the mapping property:
Hello again,
Thanks for the quick response. The property is mapped as seen in the image below:
And “Id” is returned from the API as seen in Postman here:
Ok, good.
Can you also verify that Dokumenter i Landax (temp) actually contains object with Dokumentlink ID 1933 in the step before the web request? If it only exists in the database, and not in the temp-datasource, it will get object state «New».
Yes,
Here I ran an “End execution” right after reading to Dokumenter i Landax (temp).
Hi!
Just tested a exact similar setup: Having a data source with 13 objects, iterating with a While, reading 2 and 2 into it from a web request (add to existing, update + an integer mapping property). The object state is always correctly set (Updated if it exists in the data source already and is received from the web request, and New if is does not exist and is recieved in the web request, and Synchronized if it just read initially but not received in the data source). Also tested persisting only New objects (persist, with filter on object state New), and with a uniqueness constraint on the integer property.
It works as expected. So, I believe it may be something else. Maybe it may be tested to just try this with 1 object: To store that 1933 in the database as the only object, then read it, run that web request, and persist - to see if if still fails in uniuqueness? Could it be that 1933 in fact is received twice in the same request, or exists in the database already (but not in the temp-datasource, or that it is some other property with uniqueness constraint?
Hello again,
Duplicated the service and stripped it of anything not strictly necessary. Tested with one object and it worked, expanded to more objects which also worked. Ran it 5-6 times, where I got the persist error once, but after re-running it disappeared and has yet to show up again. If I run the old service the error comes back immediately, not really sure why that is, but for now it seems to be resolved.
Thanks for the help.
Great! Let’s leave it like that 
1 Like
