Server exposes "retrieve SOH" API

[ihassin]

The server must expose an API that returns the SOH as it has it on record at the time of the call. (This may lead to discrepancies if the client calls this API prior to server-side scripts running, or after they ran but with un-synced client reports).

This service is needed to assure that the a re-installed app on a tablet can get starting SOH numbers.

The client-side story is: Scenario: Querying the server for current information Given the server has "5" items of type "A" When I re-install the app on the tablet Then the SOH shown on the tablet for item of type "A" is "5" for my clinic

[ihassin]

@garymabin Do you have the URL against which we can test this API? Do we have contract tests in place for this API?

[karloskalcium]

Hi Itamar - when you say "contract tests" - is this a sort of integration test with a live server, or more of a unit-level test which would require standing up a new instance of DHIS2, configuring the services, and confirming both sides of the transaction? We do have another card (#236) which deals with integration tests, but we may not have sufficient budget to complete these.

[ihassin]

Contract tests are usually written by both sides of the contract, i.e. some for the client and others for the server. They both test adherence to expectations: For a given API call, when I supply a certain JSON, I expect a certain HTTP code or a specific JSON back. I want to be covered from the client side, but ideally the server people should write against the client too: i.e. when returning JSON for an API call, the client returns a certain HTTP code or specific JSON back. Integration tests test functionality - i.e. that the SOH is actually updated after the R scripts are run at midnight. Contract tests allow you to stub out functionality and simply prove that you're adhering to the interface.

[ihassin]

@egwuma it seems that the server does not have an API to retrieve SOH values that the tablet would need in order to update and reset SOH on it locally if/when this is needed, i.e. when we reinstall the app on the tablet. Please verify with DHIS2 that they can provide this API. The existing API transfers all the transaction separately and assumes that the tablet will do the calculation, which is not such an efficient way of doing this.

[ihassin]

@garymabin Do you have the URL against which we can test this API? Do we have contract tests in place for this API?

[garymabin]

@ihassin I update the URL for the upload in another thread #254, I'm afraid we do not have contract test for this API for now.

[ihassin]

252 is for the server to accept data from the client. I am looking for the URL that the client uses to get data from the sever.

We'll write contract tests against that once we have that URL

[garymabin]

We do have contract tests for the URLs that the client uses to get data from server at the client side

[ihassin]

This is in DHIS2EndPoint.java

[chai-lmis]

Not sure if this has been sorted, but the API for the SOH is the same API as other activities (Dispensed, Adjustments etc) but uses the suffix STOCK_ON_HAND