Order processing queue

Hi, thanks a lot.

And in case, if i add to my question:

  1. No Deadline
    Priority High
  2. No Deadline
    Priority Normal

It will be No Deadline with Priority High at first place, after that it comes No Deadline with Priority Normal, and after that all that you wrote it ?

Thanks a lot !

Jan Lemon

Hi @Jon_Smith,

Just a correction:
When an item is added to a queue without any priority mentioned, the default priority in Orchestrator is set to “Normal” and not “High”

2 Likes

Deadline and priority are decoupled, so if you don’t enter a deadline it will not affect the priority.

So deadline is more of a boolean style, it either has one or doesn’t.

Priority is a tri state, with none defaulting to High.
The two don’t affect each other when making a queue item, they just affect the order they are retrieved.

1 Like

No, unless you orchestrator works differently to mine it defaults to High. Make a queue item with a missing priority. It makes it high.

How are you making your queue item without a priority? I perhaps think you don’t understand what situation I am talking about?

I meant the Bulk Add to Queue Items. Almost all of our dispatchers use Bulk Add to Queue Items activity. Unless there is a dedicated column “Priority”, the priority is always set to Normal and not High.

Does not matter which Orchestrator version you have.

Ok so if i dont enter a Deadline with exact Date, it will always be at last queue item (high first, medium second, low third). And everything with date will be first.

Thanks again and greetings from Czech

Jan Lemon

I haven’t tested with any ‘Low’ priority items, but it seems to me that items with a deadline are always selected first, these are ordered by deadline date (oldest first) and then by priority.

After all items with a deadline are selected it then selected the remaining items that have no deadline and that is sorted solely on priority.

That is inconsistent with the documentation. (to quote specifically ‘If the priority is not specified in the file, the items are uploaded with a high priority, by default.’

I have also tested via the API and omitted the priority column, it defaults to high.

Are you sure? I haven’t tested the Bulk activity and UiPath often make errors but this one seems to be correctly documented considering my API tests.

Hi again,

Yes, one thing with a fast growing company is a lot of inconsistencies.

One of the queues which has items from bulk add to queue items
image

Some other inconsistencies : Bulk Uploading Queue Items with Reference & Deadline - Feedback / Activities - UiPath Community Forum

So, together we now know

  • Add Queue Item → allows us to choose the Priority before dispatching
  • Bulk Add to Queue Item → defaults to “Normal” priority
  • API add queue → without a priority mentioned defaults to “High”

Thank you for the knowledge sharing

Well looks like we are both right and found another inconsistency then. Thats a real shame the documentation about Bulk is clearly wrong based on your experience.

If I get some time at some point I might test it out sometime and also look at the source code to see where the mistake is.

Did you log a bug about the way bulk items behave vs the documentation?

I havent logged a bug til now since I did not realize the documentation Add Bulk Queue Items was missing information.

I think they might have fixed it in the 21.4 and 21.6 orchestrator versions. We are still at 2019.10 on Prod and 2020.04 on DEV.

I have to check on my community version / orchestrator to see if the three things we discussed replicates in the newest version or not.

I just checked the source code and, to me, it looks like it should default to high. But I should test it with real items to make sure my understanding of the code looks correct.

That being said, the documentation is definitely incorrect and there are inconsistencies as you mention in your other post. Here is a snip of the headers it looks for in the datatable

Those are completely at odds with the documentation which states that you should use ‘Deadline’ (not DueDate) and Postpone (not DeferDate).

This is from version 21.4.1.0

Do you use SwaggerUI to quickly test APIs? If so perhaps you can quickly check using it on your older orchestrator version to isolate if infact there are changes between versions. The activities in UiPath are using the API’s underwater so it makes sense they are consistent unless the code fiddles with the values.

I’d like to just point out, whilst my answer is correct here.

The behaviour only occurs like this if the deadline has already passed.
The logic is different if the deadlines are all in the future.

In that case the items are ordered based on IF they have a deadline, then by priority (the number of days til the deadline is irrelevant if its in the future, however items with the same priority are sorted by deadline). Then all items without a deadline are ordered by priority.

Its important to know as they require you to know this sort of stuff for advanced RPA exams and I don’t want someone to be caught out by not realising that items with a future deadline are handled differently than those with a deadline in the past.

1 Like

Hi @jlemon,

Excellent question! If the API send to queue behaves differently, we might have found a crucial bug via this thread.

I prepared a test to find out what is going on with the queue logic and confirm if there are any bugs.

I started out with the 8 cases you stated in the question (Reference 1-8) and to test the future deadlines I added two more scenarios (Reference 9, and 10).

  • One thing to remember here is to use DueDate as column name when we want to send items with deadline.

  • My datetime is in MM/dd/yyyy hh:mm:ss

Bulk Add to Queue

Here I add the entire ItemData as a datatable. Some of the items which do not have priority are defaulted to “Normal”.

Dispatcher results in the following in Orchestrator:

Performer picks up the items in this order. Here you see the order as how the performer pick the items as well:

So it looks to me that @lakshman was correct. @Jon_Smith is also right when he said that this order will be different if future deadlines existed in the data.

The thumb rule will still be as mentioned by @lakshman

Performer_TestPriorityDeadlineOrder.xaml (13.5 KB)
Dispatcher_TestPriorityDeadlineOrder.xaml (14.9 KB)

Not Tested:

  1. I did not use the add to queue activity as it does not allow us to test the default behaviour for Normal priority. We have to explicitly mention a priority.

  2. Using API to send items to queue. (May be the items are defaulted to High as @Jon_Smith suggests) This will change the order significantly.

3 Likes

This is a really nice breakdown.
I think you referenced lakshman as being correct when he is not however.

He indicated the order was:
1,4,6,3,5,2,7,8
But your test shows:
1,4,6,2,3,5,7,8

That is the order that I indicated was going to happen in my response when I said lakshman order/logic was wrong. The Due Date/Deadline is more important than the Priority. The statement by lakshman ‘Among those with Deadline, High priority>Normal>Low regardless of what the deadline is’ is incorrect.

I can also confirm that, via the API, a queue item defaults to High.
If you use the API
​/odata​/Queues​/UiPathODataSvc.AddQueueItem
And add

{
  "itemData": {
    "Name": "TestQueue",
    "SpecificContent": {},
    "DeferDate": "2021-09-27T15:18:54.701Z",
    "DueDate": "2021-09-27T15:18:54.701Z",
    "RiskSlaDate": "2021-09-27T15:18:54.701Z",
    "Reference": "Test",
    "Progress": "Test"
  }
}

The response you get is

{
  "@odata.context": "/orchestrator_/odata/$metadata#QueueItems/$entity",
  "QueueDefinitionId": 59788,
  "OutputData": null,
  "AnalyticsData": null,
  "Status": "New",
  "ReviewStatus": "None",
  "ReviewerUserId": null,
  "Key": "601a56d4-ed85-4037-99b6-37d8373ca8ba",
  "Reference": "Test",
  "ProcessingExceptionType": null,
  "DueDate": "2021-09-27T15:18:54.701Z",
  "RiskSlaDate": "2021-09-27T15:18:54.701Z",
  "Priority": "High",
  "DeferDate": "2021-09-27T15:18:54.701Z",
  "StartProcessing": null,
  "EndProcessing": null,
  "SecondsInPreviousAttempts": 0,
  "AncestorId": null,
  "RetryNumber": 0,
  "SpecificData": "{\"DynamicProperties\":{}}",
  "CreationTime": "2021-09-27T15:20:27.495948Z",
  "Progress": null,
  "RowVersion": "AAAAABA+GY0=",
  "OrganizationUnitId": 1098302,
  "OrganizationUnitFullyQualifiedName": null,
  "Id": 105393402,
  "ProcessingException": null,
  "SpecificContent": {},
  "Output": null,
  "Analytics": null
}

You can note in there the Priority is set to High and confirm by looking at the queue item.

The documentation I linked above it definitely wrong as it is clearly referencing incorrect column names and the Bulk Add Items action I would say also has a bug as the documentation clearly states that items added without a priority default to high yet your tests confirm it defaults to medium whereas the API behaves as expected.

I think its fair to say that I was correct if using the API, @jeevith is correct when using the bulk add items due to what we may consider is a bug in assigning priority and @lakshman is not correct under either circumstance due to a misunderstanding of the order of importance between priority and Due Date.

Hi @Jon_Smith and @lakshman,

Did I not check the order correctly! I must avoid saying correct / incorrect. We cannot conclude anything here given the inconsistency of default priority. My bad if my post felt like picking favorites.

Ok lets recap what we know. We know that Item Reference 1, Item Reference 4, Item Reference 6 are the starting point.

In my tests the Item with a future DueDate Reference 9 comes ahead on the basis of Priority (High) to position 4. So no matter how far away in the future, we do have to check the priority for the item and order it by priority.

Given the test results the algorithm must then

Group 1 rules:

  • If deadline has past, deadline is more important than priority and then is ordered by deadline.
  • If deadline is in the future, then priority is more important and is ordered high–>Normal → High

Group 2 rules:

  • If deadline is null then always order by priority

Results from Group 1 rules will always come first in order sequence and later the results from Group 2 rules can append to Group 1.

Clarification needed
The challenge here is that the order is different when API and Bulk Add to Queue are used due to the default priority is different.
@loginerror, I think we have a bug here and would be great if someone who knows more why the two methods (API and Bulk add to queue) behave differently can help clarify.

Correct. I have verified and this is the correct answer. Thank you Lakshman

Hi Peter,

Your tests are wrong or something extremely weird is going on. Look at the further posts, jeevith and I did extensive testing on this and there is even example workflows to use to demonstrate it.

That post you reference shows the wrong order and is incorrect.
Jeevith and I have posted to correct orders and also explained how they work that way and the caveats.

This is simply a quiz question. As far as the quiz question, I meant I tested Laksman’s theory and it led me to the correct answer. Feel free to refute or explain your reasoning.

You are saying there is a UiPath quiz question that asks this and accepts Laksmans answer as the correct one?

Because if that is the case then the quiz is wrong.
As a said, we demonstrated that to be the case, look at the rest of the topic, we did real tests and posted the results with explanations of why they worked as they did.

1 Like