Keeping Track of What has Been Processed

Help Studio
1

Hello,

let’s say that you have a process that has a dispatcher and a performer robot.

The dispatcher robot runs and picks up 2000 items that it then bulk uploads as queue items into orchestrator. The performer robot then processes each item until the queue is empty.

The next day the dispatcher runs again on a schedule and it finds 2100 items that it would bulk upload into orchestrator. The problem is that some of these items might have already been processed the previous day.

How would you go about ensuring that the bot (dispatcher or performer) looks at what has been processed the previous day and NOT upload ones that have been processed ( assuming you can get a unique identifier for each items every day which is possible).

2

If possible have your dispatcher take care of this the day prior. I’m not sure how or what you are uploading into orchestrator so I cant give a full analysis but take these as examples.

If you are processing files in a folder, have the dispatcher move these files out of the folder into a different one if they are uploaded to orchestrator successfully. This way you wont run to the issue of the same files being uploaded.

Same thing would go for items inside of a file, for example an excel sheet. For each row correctly processed and uploaded move it into a “completed” excel sheet and remove it from the original.

1 Like
3

Hi Joseph,

In orchestrator we are uploading customer identifying information (name, address…etc). We then use this information to extract customer attributes which we then add to word documents. You can create a unique identifier using a concatenation of the customer identifying information.

The idea of storing the files where the dispatcher can look into before processing is a good idea but unfortunately there will be thousands of files and the dispatcher will take way too long trying to look into every file to see if it exists.

4

Hi Joseph,

I think I might have discovered a way. When I upload the queue item, I will upload it with a unique reference number.

I will then use the below API call that can bring back queue item information using the reference ID in order to check if I have processes that particular item or not. If processed successfully the previous day then do no upload otherwise upload as a new queue item.

Do you think this is a viable solution?

5

Hi @BotAM97,

That is one of the best practices in RPA, an unique ID makes debugging much easier. Especially, if your customer details are encrypted strings. Another measure is to maintain a “processed” tag (Set Transaction Status) on items which are already processed. Together with the Unique ID and “Processed” tag, you will ensure that the dispatcher always populates the queue with items which need to be processed.

Another hidden advantage is as time goes on your database / visualizing index will only contain meaningful data, will consume less space and will load faster.

I guess you forgot to mention the API call, but I am sure you know the API calls well :slight_smile:

2 Likes
6

Thank you Jeevith. My performer uses the REFramework , so queue item statuses are being tracked in Orchestrator so I like your idea of combining the transaction status with the API call to determine whether something has been processed successfully in previous runs.

And you are correct, I did forget the API call

{{BaseURL}}/odata/QueueItems%24filter=Reference%20eq%20%27UniqueRefID%27

3 Likes
7

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