Sushil, you cannot use start and end dates for the /analytics resource, you must use the standard period types (frequencies) as described here. Note that you can define fixed and relative periods in your query. Docs here:
The API does not have extensive support for daily data yet. There are no relative periods for days, so you have to list them each explicitly, using the yyyyMMdd format:
Unfortunately, I think this means you cannot get daily data for a whole year in one query, because the URL would be more than 9*365 (over 3000) characters long. So you would probably have to split it.
I agree that for daily data (what is the use case?), start and end date would be much more convenient. But you could build that logic in the javascript that constructs the query URL.
Knut
···
On Tue, Oct 1, 2013 at 12:20 PM, Lars Helge Øverland larshelge@gmail.com wrote:
Thanks Namrata for the good explanation.
Sushil, you cannot use start and end dates for the /analytics resource, you must use the standard period types (frequencies) as described here. Note that you can define fixed and relative periods in your query. Docs here:
So you will have to calculate indicators based on their definition on your own.
There is a small bug that I remember seeing sometime back that throws a NullPointerException if you pass only one orgUnit. The workaround is that you will have to pass a dummy orgunit (say the root orgUnit) that will not have data for the required dataset.
The API does not have extensive support for daily data yet. There are no relative periods for days, so you have to list them each explicitly, using the yyyyMMdd format:
Unfortunately, I think this means you cannot get daily data for a whole year in one query, because the URL would be more than 9*365 (over 3000) characters long. So you would probably have to split it.
I agree that for daily data (what is the use case?), start and end date would be much more convenient. But you could build that logic in the javascript that constructs the query URL.
Knut
On Tue, Oct 1, 2013 at 12:20 PM, Lars Helge Øverland larshelge@gmail.com wrote:
Thanks Namrata for the good explanation.
Sushil, you cannot use start and end dates for the /analytics resource, you must use the standard period types (frequencies) as described here. Note that you can define fixed and relative periods in your query. Docs here:
I would not start calculating aggregated data from the raw data (dataValueSets resource) as there are lots of business logic and performance concerns involved in that process. Rather construct daily period identifiers in your app like Knut suggests and use the analytics web api or java api. Pulling out daily values for a full year in a single report sounds like a lot in any case.
Lars
···
On Tue, Oct 1, 2013 at 3:43 PM, Saptarshi Purkayastha sunbiz@gmail.com wrote:
So you will have to calculate indicators based on their definition on your own.
There is a small bug that I remember seeing sometime back that throws a NullPointerException if you pass only one orgUnit. The workaround is that you will have to pass a dummy orgunit (say the root orgUnit) that will not have data for the required dataset.
The API does not have extensive support for daily data yet. There are no relative periods for days, so you have to list them each explicitly, using the yyyyMMdd format:
Unfortunately, I think this means you cannot get daily data for a whole year in one query, because the URL would be more than 9*365 (over 3000) characters long. So you would probably have to split it.
I agree that for daily data (what is the use case?), start and end date would be much more convenient. But you could build that logic in the javascript that constructs the query URL.
Knut
On Tue, Oct 1, 2013 at 12:20 PM, Lars Helge Øverland larshelge@gmail.com wrote:
Thanks Namrata for the good explanation.
Sushil, you cannot use start and end dates for the /analytics resource, you must use the standard period types (frequencies) as described here. Note that you can define fixed and relative periods in your query. Docs here: