Skip to main content

In my quest to integrate queues (workload management package) without API's I encounter some problems/questions.

1) is it possible to loop through each queueitem with status 'New'? I only see the option Onhold, data error, failed. This parameter is not optional, so i can not leave it blank.
2) is it possible to use the action 'Workload: update work item' outside of the "loop for each queueitem" but inside a task bot that uses a workload template? When yes, how can i get the workItemID of the currently picked up workItem? Is there a default attribute i can address to collect this data from the workitem itself?
3) when non of the above is possible: is there a way to process queueitems without needing to re-do overhead steps again and again and a again for each picked up workitem without the usage of the WLM API's? It is a waste of time to login to UI applications, get accesstokens, get credentials, check environments each time again. By doing this a lot of valuable time is lost!

4) Is it possible to insert/create a new workitem with a delay for processing? I see that this is possible through the update work item action, but i do not see how i can achieve this with the insert work item. I want to diversify in the waiting time for re-processing an item depending an its status. for example: when a work item is still being processed in an other application, i expect it to be ready within seconds and try again right away. When the status is In progress, some one needs to take manual action before necessary additional information will be available. employees do this only twice a day! so keep on polling continuously is not an option.
5) are changes relating WLM scheduled in the upcoming releases. v35 or v36?
6) Is there any transparent exhaustive uptodate documentation on working with workload package without API's?

Kind regards,

Jan

​@jan.marien - These are all the same limitations i’ve come to realize. I was curious if you found any work arounds or information as it doesn’t seem to be documented or implemented widely? I am specifically trying to understand the limitations around your 3rd point above. It seems like if we have to re-initialize all the setting and applications for every work item, this introduces unnecessary risk to the work items chance of being successful i.e. every click is a potential failure point in Ui automation. At scale, this really diminishes the value that WLM ultimately is supposed to provide to deploy across machines in parallel and meet SLAs, given that 95% of your task bot with this method could be just reaching the point in a web page where you actually perform the work. Other platforms have the ability to loop through queues for a single job execution and it isn’t clear if that's possible through automation anywhere queue functionality. 

​@Dylan 560: WLM actions do not provide this functionality. I do not see any use case where WLM (as-is) comes in handy.  At first I did not want to use the Control room API’s to build such a functionality myself. One argument is that i expect A360 as a low-code solution to provide this as predefined actions. The second argument is no longer standing: there was a misunderstanding in the communication if the API’s came with an additional charge or not. The confusion was created because the use of the syntax ‘API tasks’ which is sometime different than regular API calls. Currently i have build myself a framework with the control room API’s. By doing so, i encountered a lot of other issues and shortcomings that needed to be covered. It works fine now, but i do not understand why automation anywhere is not improving this functionality. I see it as the spine of more complex processes.

Letting each customer develop his own queueing-solution is not really helpful.

Reply


Terms & ConditionsCookie settings