pradeep | 2020-11-12 01:08:36 UTC | #1
Hello,
I'm trying to get the management units for a particular business unit using the API api/v2/workforcemanagement/businessunits/{BUId}/managementunits. I get the response that has some details as shown in the below snapshot.
However, the request url is different ( *api/v2/workforcemanagement/businessunits/{BUId}/managementunits* ) and the firstUri/lastUri/selfUri (may be nextUri as well) point to a different uri ( */api/v2/workforcemanagement/managementunits?pageSize=20&pageNumber=1* ). I would expect the selfUri/lastUri/nextUri all to be similar to the original uri in order to fetch the next paging details. Due to this I'm unable to get the data from the next pages. This is currently blocking my work. Any help/clarification on this would be great.
John_Carnell | 2020-11-12 01:28:23 UTC | #2
Hi Pradeep,
It does look the uri information is incorrect. I would open a ticket with our Care team and they will get it routed to the appropriate development group to fix the issue.
However, I am a little confused as to why you would be blocked. If you are trying to page through the data a do..while loop and the page count will allow you to build a page through the code results.
Here is an example of some Javascript code I wrote recently using some Javascript. In the code snippet below I am calling the groups API to get all of the data for groups for an org. I call the API, page through all the API calls, and then flatten the data from an array of arrays to a flat array of groups "pages." Even though the example is Javascript, the concept is pretty portable over to any other language.
let groups = [];
let i = 1;
let pageCount = 0;
do {
const group = await getGroup(i);
if (group != null) {
pageCount = group.pageCount;
groups.push(group.entities);
}
i++;
}
while (i <= pageCount);
groups
.flat(1)
.filter((value) => value != null)
.forEach((value) => { groupsMap[value.name] = value; });
//Cloning the internal representation to keep the data immutable
return { ...groupsMap };
}
The full code can be found here
A full explanation of the tutorial this was taken from can be found here.
That code example should be to able unblock you if all you are trying to do is pagination.
I hope that helps.
John Carnell Manager, Developer Engagement
pradeep | 2020-11-12 01:40:53 UTC | #3
John_Carnell, post:2, topic:9295
pageCount
I'm blocked because, the pageSize and PageNumber doesnt work with this API. Other APIs works fine. But this API returns the same page no matter what the pageSize/pageNumber is.
pradeep | 2020-11-12 01:48:10 UTC | #4
Heres the sample for queue API that works fine.
John_Carnell | 2020-11-12 02:09:14 UTC | #5
HI Pradeep,
Ok. So I can't tell how many records were actually returned in the payload, but with the example, you showed above only three records were part of the query you made. Were you expecting more data on the call?
In the queue example, you ask for 1 record to be returned per page and you were trying to access page number 25 of the total pagination set. You had 218 records available for the entire query. So everything looks correct.
You probably all ready know this so I apologize if I am getting too basic here but I want to make sure we are using the same definitions for terms:
pageSize is the number of records to return per page. pageNumber is the specific number of the page you are trying to access pageCount is the total number of pages.
In the management units example, the self uri is definitely wrong and needs a ticket open on it. But in the screenshot, you provided there are only three records total for the whole data set, which means you only have 1 page of data and you would not get the nextUri with only a single page of data. You requested that each page return a maximum of 20 records per page.
Thanks John Carnell Manager, Developer Engagement
pradeep | 2020-11-12 02:10:47 UTC | #6
Yes. I think we both have the same understanding.
For queue API, when I say pageSize=1 & pageNumber=25, it returns me the 25th page with only one entry. So all good here.
But, if you see my management unit request, i have pageSize=1 similar to that of queues API. So when I say pageSize=1 & pageNumber=3, I would expect the API to return the 3rd page with the last single entry since the total count is 3.
Do you agree on this?
John_Carnell | 2020-11-12 02:11:43 UTC | #7
Hi Pradeep,
Just as an aside to you really dont want to return back a page size of one. In the queue example you provided you are making 218 individual API calls to return each record. That goes against your per minute rate-limits and also you allocated fair use quota. You might be a low enough volume where no one would notice, but its pretty inefficient. If you set the page size to 25 you will only have to make ~5 APi calls vs. 218.
Thanks, John Carnell Manager, Developer Enagement
pradeep | 2020-11-12 02:14:29 UTC | #8
I agree with you. pageSize=1 is just for a sample data. I don't have any real data for management units that has more pages. I have this sample data that just has 3 entries. Ideally i'll not use pageSize=1. But my point here is, pageSize/pageNumber arent being considered for this api.
John_Carnell | 2020-11-12 02:16:36 UTC | #9
Hi Pradeep,
Ahhhh.. I think where we might have a differences in the APIs. Many APIs have a certain floor that you can not go below. While the structure looks the same the underling implementation might be different. I would have to ping the WEM team, but my of our APIs I thought only allow a minimum of like 25 records to be returned at one time. Different teams might implement things differently. I am not saying its right or that is the case but that is probably why you are seeing different behavior.
Let me look at your following comments and then I can give you some guidance going forward.
Thanks, John Carnell
pradeep | 2020-11-12 02:21:15 UTC | #10
I appreciate your quick reply :slight_smile:
Even if i agree with you on the APIs records limit, when I give pageNumber=2, I would expect it not to return the first page?
Not sure. I'll leave it with you :slight_smile:
John_Carnell | 2020-11-12 02:29:07 UTC | #11
Hi Pradeep,
I am going to see if I can get some answers in the morning from the WEM team. It's either a bug or the team literally ignores any values under X amount.
Its tough to say its a bug unless you can get enough data to actually prove it. What I would do it still create a ticket with care and reference this forum post in the ticket. That way we have something to track on and it can give a point of reference. Do me a favor and post the care ticket back in this forum post. I will follow up in the morning and make sure that I can help guide it through the process.
Thanks, John Carnell Manager, Developer Engagement
system | 2020-12-13 02:22:53 UTC | #12
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 9295