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 -- Mailing list: https://launchpad.net/~dhis2-devs-core Post to : dhis2-devs-core@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs-core More help : https://help.launchpad.net/ListHelp
