I'm trying to change the status of queue items which is more than 100. But once after reading 100 items BOT won't pick up the rest of queue items even if the pagination value (skip) has been set to 100. Here I have added all the images for more information.
Note: I have used RE-Framework to build up the code
I am facing the same issue
There appears to be a Solution ( link below ) using Index
and Increment is when 100 Items are hit
Get Queue Items 100 record limit
forum.uipath.com/t/get-queue-items-100-record-limit/73676
Related
I have a list of IDs coming from a Database. Now I want to send out an API request that includes the list of IDs in the request. I can only send 1000 IDs in one API request.
Currently, I'm building an Array for the API Request based on the DB ID'S with a for Each loop. This loops through the retuned list of a lookup.
Now my problem is that I need to handle the case when the DB returns more than 1000 items. How can I batch the request by chunks of 1000 items.
Check Values: Gets the ID from the DB
For each, loops through the results and builds the array for the JSON.
The If conditions checks, if there are any values returned, if yes it sends the request to the API. Otherwise no request is send.
For your pipeline to work when the look up returns either less than or equal to 1000 records or for more than thousand rows, you can use the following approach.
First use lookup to get the all the id records. Then instead of using if condition, use a set variable and make use of both success flow and failure flow as an if condition instead, to check if the returned records are more than 1000 or not.
I used a string variable, used if function to check whether the count of records are less than or equal to 1000 or not. If yes, then I use that count (converted to string) if the condition is false, directly assign any integer value (so that the activity fails throwing an error where we can use the failure flow to implement batch logic for records greater than 1000)
#if(less(activity('Lookup1').output.count,1001),string(activity('Lookup1').output.count),0)
If condition is true and records are less than thousand, directly pass the lookup array to an execute pipeline activity. This execute pipeline activity must contain your send request activities.
If there are more than 1000 records, we need to take batches of 1000 until all the records are read. Using the failure flow of our fake_if variable, take a new variable left (indicating number of records left to send request.)
#string(activity('Lookup1').output.count)
I took another variable to count the number of records processed as done.
#string(0)
Now use until activity to process until the left value is less than 0.
#less(int(variables('left')),0)
Now, use the same execute pipeline activity and pass the following array process.
#if(greater(int(variables('left')),999),take(skip(activity('Lookup1').output.value,int(variables('done'))),1000),take(skip(activity('Lookup1').output.value,int(variables('done'))),int(variables('left'))))
Now we have to update the values of left and done where we increment the value of done and decrement the value of left.
Since we can't self-reference a variable, we have to take a temporary reference variable and then update it.
To update the value of done, I have taken as change_done variable with following value.
#string(add(int(variables('done')),pipeline().parameters.thousand))
Assign the above change_done value to done variable.
Follow similarly for left as well. The following is an entire debug output when there are 2500 records.
NOTE: Since you are getting the data from database, you can query to get records in batches using sort and Row number and implementing the same logic as above (in case there are more than 5000 records).
I'm using REST API for updating the SharePoint list item (Counter). In my code on form load I'm fetching the count from list and increment to 1 & on submit button click I'm updating the value of count. Till here I have achieved.
Problem arises , If two users submit the form at the same time, then counter value is incremented by 1 instead to 2 in the list.
Checked with etags . But I found that during post if etag doesn't match with get request etag then error will be thrown.
Is there way to achieve this functionality using REST API also incrementing the counter properly , if more than 3-4 users submit the form ?
SharePoint doesn't expose a transaction manager such that you could group multiple rest operations in one atomic transaction.
I'm trying to get a total count for a give event,however I get a number much bigger(10-20 times bigger), than I see on the GA website, what am I doing wrong? (api v3)
here is the segment
metric:
ga:totalEvents
segment:
dynamic::ga:eventCategory==mycategory;ga:eventAction==myaction;ga:eventLabel==mylabel
note that I get wrong results with the query explorer as well.
You are using a segment instead of a filter.
Segments are session based so it will include all events in a session if it matches you specification. So essentially if I triggered the event you want plus other events they will all be included in the total events field.
What you need to do Is remove the segment and add a filter, the filter will include only the data you request.
Hope that helps
I am tryning to list all messages for a thread in the inbox. I notice that I get the 25 last messages by default by doing something like this:
https://graph.facebook.com/<threadID>/comments?access_token=<token>
I get data for the 25 last messages in the thread, in this case message 4 to 28. The first message has a created_time" of "2011-01-21", the last (newest) has a
"created_time" of "2013-09-24".
The data returned for the "comments" connection has paging, the "next" and "previous" links are present and looks like this:
"previous"
https://graph.facebook.com/<threadID>/comments?access_token=<token>&limit=25&since=1380049638&__paging_token=<threadID>_28"
"next"
https://graph.facebook.com/<threadID>/comments?access_token=<token>&limit=25&until=1295625728&__paging_token=<threadID>_4
However, both return empty data sets!
How can I get this to work?
Another obeservation: when experimenting with "until", I noticed that when setting "until=2013-02-23" or earlier the response is also an empty data set!
I have also noticed another thing: the default limit seems to be 25 messages, however even when setting limit to a high number (like "limit=100) you only get around 28-30 messages per request. So it seems that for the thread/comments connections there are two problems: 1) "limit=" does not work as expected 2) "until=" does not work as expected: going back before a certain date/time returns an empty data set (this is why the paging does not work I guess).
Any ideas on how to get around this?
If you have a problem with next URL for the pagination, try using the offset along with the limit parameters in the URI.
For example, instead of making an API call to <threadID>/comments, make a call to /comments?limit=100&offset=0. This will start the list of the messages from an offset of 0 and will display a list of 100 messages on each page. The next URL will work just fine in this case. You can however increase the limit of the messages per page.
Also, there are some issues with the paging. Have a look at this post to learn how it works actually.
Is there any restriction on the number of entries that are retrieved using a single call to the Network Updates API? I found this forum comment "The per-user limit is per call, so 300 requests with however many updates they have." on the thread
http://developer.linkedin.com/forum/increase-search-api-throttle-limit
I want to confirm that indeed there is no limit. I have received as many as 106 entries in a single call.
Thanks in advance.
The maximum number of updates returned from the Network Updates API appears to be 250. Performing the following query as an example:
http://api.linkedin.com/v1/people/~/network/updates?count=500
Even if I try to specify the start parameter at, say, 250, I can't get the next 250 updates from the API:
http://api.linkedin.com/v1/people/~/network/updates?count=250&start=250
So it looks like 250 is the max, with no ability to page beyond that.
UPDATE:
Have verified that 250 is the maximum number returned, either in a single call or via the paging parameters. Looks like the documentation has been updated to reflect this.