Help with modeling a scenario

Help Orchestrator
,
1

I’m wanting to make a robot with REFramework.
The scenario is the following, I have a queue loaded in the orchestrator and within the items I have several fields, one of those fields indicates whether an “Access Page” process should run with that item.

My question is the following, suppose I want to update the queue dynamically, that is. If one of the items changes state in a field for some reason. Should I update the value of that field in that item? In the next processing of the robot will it already be updated?

I had done a similar procedure with Excel, but hey, I’m migrating to orchestrator to see if it’s really better.

2

@Matias_Clemente.Arg

  1. For in progress items in wueue you cannot update the specific content
  2. One way you can go about is to close the item and readd a nee item with all relavent data and additionally add new data or modify data too
  3. If the item is not in in progress but in new then we can use orchestrator http request to modify the specific content of the queue items

I hope this summarizes

Cheers

1 Like
3

What an unusual method for handling items. What would you recommend in a situation such as the one I described? Should I utilize the Orchestrator? Perhaps I am misunderstanding the function of queues…

Suppose I have a table like this:

Item ID Name Process A Proces B Process C
1 Alfa Yes NO Yes
2 Beta NO Yes NO
3 Omega Yes Yes NO
4 Epsilon NO NO Yes
5 Copernico Yes Yes NO

The idea is that once a month it is controlled through a process made with REFramework and the processes that appear with YES are executed, but depending on certain factors, the fields can become YES or NO the following month.

Would it be correct to use queues to manage this control?

4

@Matias_Clemente.Arg

queues cannot be tagged to multiple process …it can be tagged only to one process

for your scenario which again is complete different from what you asked initally…you might need to run a process to check the table whenever needed and based on that we cna use start job activity to trigger the respective jobs

cheers

1 Like
5

I apologize for my mistake; I added some confusion by referring to the columns as “process A.” In reality, they are not processes but rather a simple property that, depending on their value, determines whether the process I am working on runs or not. The idea is that perhaps the condition for the next cycle might change, and I thought it was simply a matter of updating the property.

6

Hi @Matias_Clemente.Arg

If I understand correctly, your scenario can be summarized as follows (please correct me if I’m wrong):

  1. 1 Process - 1 Queue: The table items are loaded into the queue as individual Queue Items.
  2. Each Row is a Queue Item: Within each Queue Item’s SpecificContent, you define whether the REFramework should execute 3 steps, 2 steps, 1 step, or none. (I refer to “steps” instead of “processes” for better clarity.)
  3. Monthly Runs: The table is executed monthly—for example, in August—and the same table is loaded in September, possibly with different values for StepA, StepB, StepC.

Given that this is a monthly process, I would suggest the following approach:

Option 1: REFramework with Integrated Dispatcher

  • Monthly Time Trigger: A monthly time trigger initiates the process, that contains the dispatcher within the Init part of the REFramework, which then loads items into the queue. The performer starts consuming the items immediately after.
  • Fresh Data Each Month: Since the trigger runs monthly, the queue items are freshly generated just before the performer begins processing.
  • Transactional Processing: The “Process” section of the REFramework reads the StepA, StepB, StepC values for each item. Based on simple logic (e.g., If, Switch), it determines which steps need to be executed.
  • Continuous Updates: The following month, the time trigger will run again, recreate the items in the queue, and re-evaluate the YES/NO logic, ensuring that the actions taken may differ from the previous month.

Option 2: REFramework with Separate Dispatcher

  • Monthly Time Trigger: The dispatcher is triggered monthly to evaluate the logic and create the queue items.
  • Queue Trigger for Performer: The performer is linked to the Queue Trigger, meaning it starts processing as soon as the dispatcher begins filling the queue.
  • Fresh Data Each Month: Similar to Option 1, items are freshly generated right before the performer begins processing.
  • Transactional Processing: The REFramework’s “Process” section handles the decision-making for StepA, StepB, StepC, determining which steps to execute based on simple logic.
  • Continuous Updates: Each month, the dispatcher re-evaluates and recreates the queue items, ensuring different actions may be taken compared to the previous month.

In any of the cases mentioned above, there’s a need to modify the QueueItems for the following month because they will be newly created before each month’s processing. This approach also helps in reporting, as you can view the values for each month by simply checking the queue and filtering by the created date.

I hope this clarifies the issue! Let me know if anything needs further explanation.

Best regards,
Ignasi

1 Like
7

@Matias_Clemente.Arg

If you are trying to add this data to wueue then you can create a dispatcher which would read this file always and based on yes or no it would add the items

Cheers

1 Like
8

Thank you both, @Anil_G and @ignasi.peiris, for clarifying my doubts.

1 Like
9

Thanks for such a thoughtful response. It is very useful.

1 Like
10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.