dhis2-devs-core team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

As yoou have seen I have already started to commit a few bits of code
in support of the ADX implementation.  I hadn't been planning to do
this so will proceed quite slowly, but let me outline the approach I
am considering for your comment and suggestion.

1.  Currently we have a datavaueset service which can import dxf2 data
from an inputstream.

2.  I would like to use that existing service and place the adx
service as a thin veneer above it rather than create a lot of
duplicated code.

3.  The adx data importer would read its adx input from a stream and
convert that into a dxf2 stream.  The main tasks it would need to
perform are:
(i)  convert periods into dxf2 format
(ii) lookup catoptcombos and attributeoptioncombos for the dimensions
in the adx message
All other attributes and ImportOptions would be passed through
directly to the dxf2 datavalueset service.

4.  In order to present the resulting dxf2 to the service as an
InputStream it would have to use PipeReader/PipeWriter combination
(Something Lars will recall from earlier dxf1 code).  The equivalent
alternative would be to post the dxf2 datasets backout to the REST
endpoint but that seems wasteful and more awkward.

Does that approach sound reasonable?

I have some lingering uncertainty about the best way to deal with
ImportSummary.  The adx data is naturally grouped by orgunit/period.
So I would likely split the stream and post each as a separate dxf2
datavalueset.  So probably this would imply collecting the results
into an <ImportSummaries ... /> element.  ADX is currently silent on
the result message as it deliberately does not define the transaction
(just the message) so we have some latitude here to do whatever is
best.  The above is my best suggestion.

Cheers
Bob