Tracked Entity API submission rejection for attributes/dataelements with option sets

Support - Assistance technique
,
1

Good morning community,

We are submitting data via the API to some Tracked Entity programs that use option sets for both Tracked Entity Attributes and some of the Data Elements in the Events. We are on 2.37.3 and want to force DHIS2 to reject the JSON package we are submitting (which includes the tracked-entity creation, enrollment, and submission of events).

We believe it used to do this, but it no longer seems to reject the submissions, which ends up being a bit of a pain as we need to identify these in DHIS2, correct in the source, do a deletion, and then resubmit. We’d prefer to get a rejection response if option sets values aren’t valid so we can deal with this in the interoperability stage, but can’t see any parameters that we can set for this specific use case.

Is there some setting to force this behavior, or have any changes been made between 2.36 and 2.37 onwards? (I’m going to do some rigorous testing now of different versions, but hopefully some of you already have an answer to this).

All the best,

David Hagan

2

Sounds similar to this question: Using sending bulk events API , how can you identify which event has successfully passed and which one has any issue?

Instead of a rejection, the API is responding with a message which contains the ID of the DE that had an issue. Isn’t there a way to use the response which sends back these IDs and delete/update or modify the values?

3

Thanks for the thoughts. Yes, that is one route we are exploring. It’s just that it is much simpler (and already set up) in our interoperability layer to get a report of full rejections, and parse that for values that may have been mapped incorrectly or problems in the source data. The rejected data can then be resubmitted with the push of a button. Using your suggested approach means keeping an incomplete record in DHIS2, while maintaining all the UID’s of the tracked entities in the interoperability layer for future upedates. While possible, it means a whole lot more work in scripting the response parser.

What we are looking for is if there is a setting for ‘strict’ adherence to lookup lists, with full rejection of the submitted package if this setting is on and there is a value that doesn’t match.

Cheers.

1 Like
4

Hi @djhag ,

Did you try and use the “dry run” feature? I think you should be able to get an import summary, which your interoperability layer should be able to use. I am not 100% certain that you will get the information back regarding whether or not values are valid with respect to a given option set (you should), but if you do not, then I think that should be considered a bug. Have a look here and particular the dryRunand importReportMode parameters.

Best regards,
Jason

1 Like