Edit Specific Data for a Queue Item

orchestrator
i_considering
pb
#1

@productEnt Would you need this or for traceability is better to create a new item with the same Reference?

0 Likes

Setting TransactionItem specific content in runtime
#2

If changes are reflected in ‘History’, I see nothing wrong as having them editable.

This would logically be scope to Edit privilege on queue I guess?

Cheers

3 Likes

#3

This will help us to add Review as well, Sometimes few queue item will Fail and that will be the scenario i think, this will help us track them.

0 Likes

#4

This would also help with queues with UniqueReference set, where adding a substitute item isn’t straightforward (i.e. Reference is used somewhere, although is not the Best way does happen from time to time, or its used to identify items cross queue or even cross systems).

Could we get adding a queue item manually from Orchestrator bundled up with this as well (or separately)? If there’s an edit, create is just a minor addition away.

1 Like

#5

Andrzej,
Can you please describe in what concrete scenario(s) this would be useful/used? It will help us understand and refine the suggestion.

Thanks,
Nic

0 Likes

#6

Sure.

For adding:

  • testing end to end queue processing specific scenarios by business users (‘robot is ready, please add sample scenarios and run the test job whenever you have the time’). While these could be added as f.e. input files, its not always feasible, especially if originally the data is fetched from some hard to reach places
  • On demand (re)runs by business users (‘can you rerun reconciliation just for company Z?’ and ‘let me run reports for these 4 companies’). StartJob with parameters could potentially serve similar function but queue is more natural for this
  • Queueing work for robots night runs or front office runs by successively adding work during the day and then just running it once (especially useful with floating licenses)
  • Urgent transactions for 24/7 or multiprocess robots (‘i need this new contract processed ASAP and there is a long queue/queue was already built for this run, let me add it with high priority’)

Editing:

  • Changing priorities and due dates / postpones of items
  • Editing input for business rule rejected items and rerunning them

Ideally to make both of those easier and safer it would be possible to define input structure for individual queues.

2 Likes

#7

So…to sum it up

  • editing priorities, due date, defer date and input makes sense and
  • it is more important to achieve this from the Orchestrator UI than from the robot (via activity)
3 Likes

#8

Editing would be very helpful, mainly from the Orchestrator but I think we should give some liberty over this from studio activities as well.

Thanks,
Prankur

4 Likes

#9

I agree with @PrankurJoshi, it would be valuable to Edit them via activity (or see changes we make with an assign activity persistent) as it could be widely for automating testing purpose and would open many new design options while building workflows.

Cheers

1 Like

#10

Hi,

Being able to edit specific content would be really helpful in some cases. Just for keeping track of details on an item.

If a process needs to perform 5 main steps, you could use this functionality to update the latest successful operation. If the task encounters a business exception, this makes it so much easier for operation to see how the process came before stopping.
I know the same thing can be achieved by variables, but keeping a track record of this could be necessary for statistics. As well as gathering key properties that is encountered during run time.

I dont see any reason why as a developer i should not be able to assign variables to the queueitem.

1 Like

#11

If this is the use case, I still think you may have 3 types of data and the tracking may be done in Progress.

  • SpecificData, Reference - input, json, immutable, set it only in the beginning
  • ProgressData - json but you may change it during the transaction, set it anytime
  • OutputData - output, set it only in the end

Now, this is the debate. Should we split it or not? In theory we may remove the Output field too, if you allow editing the SpecificData. In this case you will end up with only one field that can be editable at any time.

Why should I choose one approach vs the other?

0 Likes

#12

I wouldn’t remove Output field, as it serves IMHO a different purpose.
Suppose you have some transaction with SpecificData (payment to be done - bank account details, amount etc.).
The Output after processing might be something like “WasScheduled: True, ScheduledFor: [someDateTime], RequiresFurtherApproval: False, RejectionReason: null”.
This information doesn’t belong to SpecificData, because it would change the meaning of its content - instead of SpecificData representing a PaymentProposal it would now represent a ProcessedPayment|RejectedPayment union thus weakening or confusing the meaning.

If we go the route of using Progress for current Output, then it changes the meaning of Progress - instead of representing steps/intermediary data, it now also may represent result.
I might be alone in this, but I think that removing Progress on transaction completion is a good thing - what’s done is done and the result is what matters and that’s what Output is for.

Now for setting SpecificData only at the beginning, we have cases like this:
Input comes in semi-structured email. It needs to be parsed and then processed.

One of the hot questions becomes - what should the transaction represent?
With current possibilities, you could design it (simplified):

  1. 2 separate queues - one for parsing emails (where email is the transactionItem), one for processing (where parsed email content is the transactionItem).
    It works, but is fiddly.

  2. 1 queues - since parsing the email content is part of processing, transaction has to start when you find the email. Thus the parsed content (which is the “real” SpecificData) can only be stored in Progress field. This makes it fiddly (again) to work with and there’s a risk of: overwriting data, data not being immutable throughout the transaction, losing data at the end of processing (unless stored in Output, which it doesn’t really belong to).

If all 3 fields stay, these cases could be:

  1. Find email -> AddTransactionItem. Reference (immutable and set on construct only) -> some email identifier. SpecificData -> null/placeholder for serialized DTO or other properties.
  2. Parse data from email -> enrich SpecificData with content from parsing, set Progress -> transaction details parsed.
  3. (Maybe possible?) Lock SpecificData editing, making it ReadOnly from now on.
  4. Process normally.
  5. Set result to Output (Progress erased, not useful anymore).

That gives maximum flxibility for however you need to design it and the locking would prevent data mutability in the middle of transaction.

0 Likes

#13

Would you like to have this from activity too?

As of current spec

  • editing a new item will do edit
  • editing a failed/abandoned item may do “just edit” or “edit, save and retry”. the current item will change its status to retry and a new one with edited data will be created - equivalent of editing and then clicking retry
  • clone an item will create a new one (reference is editable this time)
0 Likes