OrgUnit API

Support - Assistance technique
1

Do you need all fields? you could probably easily shave of a quite a few bytes by only asking for the fields you need. We only support compression on the /api/metadata endpoint (zip, gzip) and I would rather see compression implemented in the caching server / proxy (nginx, lighty etc). You can also enable gzip compression in tomcat.

Are you sure its the download that takes time, and not the processing on the server side?

···

–
Morten

On Fri, Sep 5, 2014 at 10:16 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi,

We are making a call to /api/organisationUnits.json?fields=[:all] which is taking a long time because the payload is close to 800KB. Is there any way we can reduce the payload size (maybe by compressing) so that we can get a faster response?

2

Hm, no. We only allow filtering for a specific value, but I guess you don't
really know the values here. Its more difficult to filter inside a
collection, not sure how the API would look for that.

We might want to support something like that in the future, but its
definitely not supported today.

The best solution here would be to use http gzip if you don't already use
it. You could also get the data from
/api/metadata.gz?assumeTrue=false&organisationUnits=true but that probably
won't work as expected in a browser setting, unless you use some kind of JS
gunzip.

···

On Fri, Sep 5, 2014 at 11:55 AM, Mahendra Kariya < mahendra.kariya@thoughtworks.com> wrote:

It looks like attributeValues field takes most of the time. We have around
6-7 custom attributes for each orgUnit. We don't need all of these. We only
need the value of one particular attribute. Is there a way to do this?

--
Morten

3

You mean children, or descendants? if you just want the full view of the children of a few OUs you could probably get away with

?fields[:all,children[:all]] ?

···

–
Morten

On Fri, Sep 5, 2014 at 12:18 PM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

OK.

So we need all fields for an org unit, but we don’t need all org units. We only need a few org units with all fields and all its children (recursively).

I tried GETting this information with the URL http://localhost:8080/api/organisationUnits.json?fields=[:all]&includeChildren=true&filter=id:eq:a42405657c4&filter=id:eq:ade053ef050&paging=false

But the response doesn’t have all children recursively. Can we use includeChildren=true param on /api/organisationUnits or it only works on /api/organisationUnits/{id}? If this param is not supported on /api/organisationUnits, is there some other work around?

On Fri, Sep 5, 2014 at 10:42 AM, Morten Olav Hansen mortenoh@gmail.com wrote:

On Fri, Sep 5, 2014 at 11:55 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

It looks like attributeValues field takes most of the time. We have around 6-7 custom attributes for each orgUnit. We don’t need all of these. We only need the value of one particular attribute. Is there a way to do this?

Hm, no. We only allow filtering for a specific value, but I guess you don’t really know the values here. Its more difficult to filter inside a collection, not sure how the API would look for that.

–
Morten

We might want to support something like that in the future, but its definitely not supported today.

The best solution here would be to use http gzip if you don’t already use it. You could also get the data from /api/metadata.gz?assumeTrue=false&organisationUnits=true but that probably won’t work as expected in a browser setting, unless you use some kind of JS gunzip.

4

Hm, ok… no we don’t currently support that.

As a workaround, you could of course just do ?fields=:all,children[:all,children[:all]], i.e. :all,children[:all] for as many levels as you have, its a bit of a hack, but it would work (if you add too many, it will just be ignored)

If its only two, you could also just have two requests

/api/organisationUnits/ID1?includeDescendants=true

/api/organisationUnits/ID2?includeDescendants=true

It might be quicker in your case if the amount of OUs is that not that (this is not ideal obviously).

I could extend the controller to add support for includeChildren/descendants after our main filters are run, but I don’t think that will help you right now, since you are running an older version of trunk anyways, right?

···

–
Morten

On Fri, Sep 5, 2014 at 12:31 PM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

We need full view of few OUs along with full view of their descendants along with full view of descendants’ descendants and so on.

I tried the following URL, but it doesn’t help.

http://localhost:8080/api/organisationUnits.json?fields=[:all,children[:all]]&filter=id:eq:a42405657c4&filter=id:eq:ade053ef050&paging=false

On Fri, Sep 5, 2014 at 10:55 AM, Morten Olav Hansen mortenoh@gmail.com wrote:

You mean children, or descendants? if you just want the full view of the children of a few OUs you could probably get away with

?fields[:all,children[:all]] ?

–
Morten

On Fri, Sep 5, 2014 at 12:18 PM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

OK.

So we need all fields for an org unit, but we don’t need all org units. We only need a few org units with all fields and all its children (recursively).

I tried GETting this information with the URL http://localhost:8080/api/organisationUnits.json?fields=[:all]&includeChildren=true&filter=id:eq:a42405657c4&filter=id:eq:ade053ef050&paging=false

But the response doesn’t have all children recursively. Can we use includeChildren=true param on /api/organisationUnits or it only works on /api/organisationUnits/{id}? If this param is not supported on /api/organisationUnits, is there some other work around?

On Fri, Sep 5, 2014 at 10:42 AM, Morten Olav Hansen mortenoh@gmail.com wrote:

On Fri, Sep 5, 2014 at 11:55 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

It looks like attributeValues field takes most of the time. We have around 6-7 custom attributes for each orgUnit. We don’t need all of these. We only need the value of one particular attribute. Is there a way to do this?

Hm, no. We only allow filtering for a specific value, but I guess you don’t really know the values here. Its more difficult to filter inside a collection, not sure how the API would look for that.

–
Morten

We might want to support something like that in the future, but its definitely not supported today.

The best solution here would be to use http gzip if you don’t already use it. You could also get the data from /api/metadata.gz?assumeTrue=false&organisationUnits=true but that probably won’t work as expected in a browser setting, unless you use some kind of JS gunzip.