dhis2-devs team mailing list archive

[Morten Olav Hansen <morten@xxxxxxxxx>]

Hi Lorill

Sorry for the delay in answering.


>    1. Is there any documentation outlining the response structure from
>    all API calls, including when there are errors or any other scenarios? We
>    have been upgrading our response parser on a trial and error basis
>    attempting to mimic all possible scenarios which is not ideal.
>
> Right now there is no documentation for this, but it should be easy enough
to deal with I hope.

The basic structure is like this:

{
   status: OK, ERROR, WARNING,
   typeReports: [
    {
       klass: "Klass type",
       stats: {created, updated, deleted, ignored, total},
       objectReports: [
         {
            klass: "Klass type",
            index: 123 (index into array you were sending),
            uid: "uid of object",
            errorReports: [
              {
                errorCode: (see attached image),
                message: "general message about what went wrong",
                mainKlass: (basically same klass as object report),
                errorKlass: (class where it went wrong.. if missing data
element ref, this is DataElement),
                value: (can be anything.. something useful for error report
to give more info)
              }
            ]
         }
       ]
    }
  ]
}


>    1. When submitting an identical post containing
>    {"programTrackedEntityAttributes" [...], "program" [...]}, where there
>    is an error in the Program being posted, the call to /api/metadata responds
>    with success for "programTrackedEntityAttributes" with the correct
>    "importCount" counts, but the call to /api/23/metadata responds for
>    "programTrackedEntityAttributes" with "stats" counts containing all
>    zeros, and no "objectReports". It is like the first item being posted is
>    completely ignored if the second item posted has errors. Is this the
>    intended behaviour? And should there be "objectReports" regardless? Please
>    see attached examples.
>
> Yes, what kind of error are you getting? a reference error, or a
validation error? in the old importer, it would always try to just import
what it could.. which was not always ideal (missing references etc was just
ignored). If it's just reference error, and you want to ignore them..
please try with `atomicMode=NONE`, regarding the object report..


>    1. There is no longer a "lastImported" field. Is this now deprecated?
>
> There should now be a id exported in the object report.. I think there
might be some inconsistencies there though.. I will go through it, in
general this field was mostly used for our /api/type/id endpoints.. were
you also using it for /api/metadata? (it's not very useful unless you are
only sending 1 single object)


>
>    1. The /api/23/metadata response with "errorReports" within
>    "objectReports" appears to have replaced the /api/metadata
>    "importConflicts". In /api/metadata, the "importConflicts" "object" field
>    contains the actual name of the object that has the error (eg: the Program
>    short name in our case). However, in /api/23/metadata there is only the
>    index which makes it more work to debug. Is it possible to also include the
>    name of the object in the error report like the prior API version does?
>
> Hm, right. I understand that it's useful, but that can easily add up to a
lot of data returned. Maybe we should add some kind of "debug" mode where
more output is provided.

--
Morten


> Thanks,
>
> Lorill
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>

Attachment: Screen Shot 2016-09-05 at 12.08.44.png
Description: PNG image