I am designing a process that handles the classification of documents as part of a wider document understanding framework.
The requirement is for the process not to suspend. This is because all items need to be processed in one run and those that require actions are returned to using postponed items.
I can create the action without issue using Create Document Action. I can then check if the item is completed using Get Task Data. However, I am stuck on how to then retrieve the validated results. I would imagine that wait for and resume would work without having to suspend if it is known that the item is complete, but I am not certain that this is the case.
Can I use wait for and resume without suspension as described, or even better can I create the validated results object from the Get Task Data output?
You cannot use âWait for and Resumeâ without suspension UiPath always suspends for that activity.
But you can still get the validated results without suspending by checking the Action with Get Task Data and then reading the validated values from task.Data.Output which contains the full JSON of the user-validated results.
So Create Action â Poll with Get Task Data â When Completed â Deserialize task.Data.Output to get the final validated results
There is no meaningful difference between making an action, then suspending, and making an action, not suspending and finishing the process and then later running a new process which looks for a completed action and tries to resume. Infact the latter adds needless complexity and delays.
Suspending your workflow releases the licence, so I dont see the issue here? What problem are you trying to avoid, because I think you are âsolvingâ it in the wrong way and creating bigger problems.
The material differences are that without suspension the framework can iterate through x documents creating actions or completing them as required in one run, and variables do not have to be serialisable. With suspension, multiple processes must be run, not to mention saving documents.
We are currently using the DU framework provided by UiPath. I had to move json to xdocuments to hold our config and had to create a folder for files (the opposite of a temp folder). As a result, we are moving to our standard framework which is essentially an enhancing REFramework. Suspension stop the job though, so I canât see how you might suggest it then does the next item until it resumes or until a new job starts.
A transactional framework is not fit for a process that has a human in the loop. You cannot/should not modify the Reframework for this purpose and youâll end up in a mess with the suspension anyway because the suspension point has to be on the Main.
A process like this should be linear and deal with a single item. Iâd advocate for skipping the UiPath framework for Document Understanding, its pretty crap and over engineered. A simple linear workflow will handle this far more effectively and allow you to persist / suspend the workflow.
Unfortunately because this process is utilised by a variety of other processes, it has to use queue items. triggering 1 linear process per item does not assist in handling volume. Therefore, our framework that we use will be applied to each of the steps that take place within the DU process with each orchestrated by a parent.
One of the key reason behind this move is maintenance - as it stands if the taxonomy or post-processing of any document changes the entire DU process needs a release. The intent with modularity is to create a process per document type, so only that document type needs a release when it changes and new document types add to the classify taxonomy alongside itâs new release (easily automated through deployment pipelines). This means fewer releases and less overlap of branches, a well as simpler processes.
Nothing you have said changes or contradicts with what I said about a linear process.
I didnt say you shouldnt use queue items, its not a bad way to start a linear process.
I also didnt say you needed one linear process that can handle every single document, infact I advocate for the opposite in my frameworks where each document gets a dedicated linear process.
The thing I challenge is that you want to use a transactional framework, which is not fit for a process that suspends. You dont HAVE to use a transactional framework because you want to use queue items.
I understand your argument, but fundamentally speed isnât our primary concern. DU is indeed quite transactional once broken down though I do appreciate that linear is simple and a good place to start or indeed exist for many use cases.
Our main reasons to work this way I have already outlined. These are maintenance (fewer and better releases) and creating of action items in as much bulk as can be achieved (which creates a better user experience compared to a drip-feed).
Modularity should be a major aspiration in automation architecture and by doing this it opens up the opportunity to make the process more transactional.
This also helps with reprocessing elements without incurring additional costs, and that should be valuable in itâs own right (this is achieved because it is no longer required to reclassify and then extract data from each document - saving AI Units and duplicate actions - as any offending extraction item can be individually reprocessed).
and store the output to a new local resource variable
Unzip, and store the output as an array of local resource
Use Read Text File to read the first of these files (there will only be one) to a string variable
Deserialise this string to the classificationResult variable used as normal. Use Deserialise JSON and not Deserialise JSON Array.
Turns out there is a further benefit to this approach I hadnât previously mentioned - when UiPath have an outage it doesnât kill your suspended jobs because there arenât any!