RPA Framework for Document Understanding

Hi! We have on-premis Orchestrator, Studio, and unattended robot licenses.

Do we need to make an account on cloud.uipath.com to get the DU API key?
The OCR engine “UiPath Document OCR” uses the ApiKey, do you still need DU ApiKEy if you’re using Google OCR?

I didn’t understand the difference between the two main files in the template, are both with human in the loop?
I image a person outside of the UiPath team will be at the validation station.

Please tell more about the pre-requisites for Document Understanding.

Hi @Ferdinand!

In order to obtain an API Key for Document Understanding, yes you need to create a cloud account. Alternatively, you can also request an on-premise trial. If you’re not making use of any activity that requires a key, then you don’t need one, of course.

The difference between the two Main workflows is only regarding how the robot interacts with the Human-in-the-Loop: via local Classification/Validation Station for attended robots or via UiPath Action Center for unattended robots (Action Center licenses being required in this case).

For pre-requisites - please take the Academy course on Document Understanding to get started :slight_smile:


1 Like

Hey @Alexandru-Luca, on the same note, how could we use this implementation with queueitems? Invoking this process in REF would actually suspend the entire performer if it creates a validation station task, is there any workaround here

Hi @LivAutomate!

As I explained above, there are no viable solutions. In your case, you either:

  • Shouldn’t wait for the DU process to finish. Just run the job in a fire-and-forget manner and let it trigger subsequent processes
  • Set the transaction item status as successful before suspending the job.
1 Like

hi @Alexandru-Luca thanks for the update. do you have an update log where we can check at least some high level details on what has been updated?

Hey @zell12! There’s a Changelog.txt in the project itself :slight_smile:

Hi @Alexandru-Luca ,

:thinking: I’m just theorizing assuming that I have understood this correctly. A Queue abandonment problem is something generic, and we have to deal with it somehow regardless of what is being processed.

But in this scope, can the solution using Queues be a bit simpler?

Let’s suppose this scenario:

  1. The Dispatcher adds a file path to a Queue that is tied to a Queue Processer automation
  2. Queue Processer automation triggers, it consumes the file and initiates the DU Process by passing the file name
  3. As soon as it triggers the DU process, the Queue Processor automation marks that transaction successful and exits
  4. If it fails, then that transaction is marked as failed (the unprocessed file on this transaction can be fed back into this queue via a different mechanism)

This way, the responsibility of the Queue Processor remains minimal, with a small footprint. The transaction is limited only to trigger the DU flow, not to ascertain if the file has succeeded/failed DU processing. I think that responsibility lies majorly with the DU Process as long as it has been triggered successfully and has a file to process.

Possible Caveat: :worried:

At least in the Community Edition, this will need to be tested because we have only 1 Unattended Robot license to work with, and two Unattended Processes - one being the Queue Processor Automation, and another being the DU Automation.

In this scenario, will the Queue Processor fail to trigger the second Unattended DU Automation?
Or will will the triggered DU Automation wait in line for the Queue Process to release the Unattended Robot?

Just my thoughts. I hope I get the opportunity to test this out. If anyone in the Community does, please let us know! :+1: