Why the RE framework does not have queue item postpone logic built in yet?
Looking at this multiple users are creating their own custom logic but ideally this can be easily integrated in REF and get it updated.
Thoughts?
1 Like
Actually the RE Framework is meant to be a generic template for transactional processing and its focus is on retry logic, exception handling, logging, and transaction state flow and i think it intentionally avoids embedding business-specific queue behaviors like postponing items.
Cheers
Hello @tejaskumar.darji
Interesting subject.
Where would you like to implement this general logic?
Set Transaction Status? Process?
Hard agree. But the REFramework has been very poorly supported by UiPath professional services, who are very very slow to adapt and are providing clunky Frameworks (The Document Understanding one is awful).
This could and should have been solved years ago. My framework does it very simply, in the workflow to process the transaction, the queueitem is an In/Out argument.
If during processing you decide you need to postpone, you simply add a postpone date to the QueueItem argument. My framework, when setting the queue item status, checks for a postpone date, if its in the future, it postpones, if its not present or in the past, then it marks as success.
Its very simple logic in my opinion, and another reason I have been saying for years the REFramework needs to be rebuilt with fresh eyes and the professional services team do not have the innovation mindset to keep it updated or using new UiPath features.
2 Likes
Hello @tejaskumar.darji
The REFramework is kept generic by design, so features like queue item postponement are not built in because every business has different rules for when to delay a task. This gives developers the flexibility to implement postponement logic in a way that best fits their business requirements
2 Likes
Hello @tejaskumar.darji
Because postponing a queue item is a specific business requirement, not a one-size-fits-all need for all automation projects.
Regards,
Rajesh Rane
Thats a bad answer in my opinion, because IF the business requirement is required that a queue item is postponed, then they need to do quite alot of manipulations to the Main to accommodate that.
Postpone logic is not difficult to add, in a generic way, so that it can easily be use, when the business case requires it, but not interfere with operations otherwise.
I already explained how this can be done, by checking if a value is present of the Postpone date property on a queue item before setting the transaction status. This allows the developer to very easily set that value, when processing the queue item, if they want to postpone it.
The REFramework should include this, its not designed well enough and needs many updates, this included, but there are many more, since it doesnt require the right level of flexibility.
Taking screenshots is another example where it misses the mark and is too legacy mindset based.
2 Likes
Yes, thatâs exactly the point. REF should have handled this correctly from the start, instead of requiring us to figure out the placement, build custom logic, and run tests. Iâve seen many posts and users implementing their own logic for this. REF was intended to eliminate such development delays, and this feels like a small but important gap that should be addressed.
If thatâs the case, why use REF at all? Everyone might as well build their own design. REF is supposed to be a framework that handles these common scenarios out of the box, while allowing custom logic to be added or modified as needed.
Fully agree to this thought process.
IMO you shouldnât even be using REFramework. Itâs overcomplicated, outdated, and overkill for most automations.
Youâre much better off building your own template that supports your standards. Itâs not that difficult. REFramework is overcomplicated, outdated, and frankly results in blackboxes.
1 Like
Exactly thatâs why this should be included in REF as commented-out code by default. Itâs much easier and safer to enable existing code than to build new postpone logic from scratch.
This is a common scenario, in every 5 automations, at least 1 typically requires postpone logic. So, the question is: why reinvent the wheel each time, when REF could provide a built-in, ready-to-use and tested postpone logic (as commented code) version? I hope it makes sense.
No need to even comment it out, the scenario I painted gives a totally safe way to handle postpones, with minimal additional changes and, when a developer does want to postpone, it can be done in a single assign in the process and the framework will handle the rest.
Another reason why the REFramework shows its age and poor effort in maintaining it for the future.
1 Like
I dont disagree that using the REFramework is a bad idea, given its flaws, and you are better off making your own, but that ignores the fact that it IS still so widespread an accepted as a baseline and a huge number of developers rely on UiPath to lead here.
They need to step up and just kick the professional services team aside and take this framework into products, have one of the teams own it and have some vision over innovating it alongside the other things they build and innovate.
2 Likes
IMHO - Isnât REFramework is listed as âBest Practicesâ by all of the UiPath training?
ButâŚ
- It doesnât keep up with current Activities packs
- It doesnât utilize âGlobalâ Config similar to the Attended Framework
- It doesnât include an Inbound path for the Config source so you can alter depending on the environment
Shouldnât all Templates be starting points for current âBest Practiceâ?
Keep up with UiPath technology and certification tests?
I bet it doesnât pass many âProject Analysisâ rules.
Iâd argue we donât need config files anymore, global or otherwise. There are much better options for us now. So in my opinion the Attended Framework is also not âBest Practiceâ.
I would agree.
Unfortunately, having tried to really discuss a couple of years back, with the guy responsible for the monstrosity that is the Document Understanding Framework that the template is far to over complicated and should be rebuilt using a Orchestration design pattern, I realized that unfortunately it seems the people in Professional Services, who are responsible for maintaining these templates, just donât want them to change.
I am not sure if thats because they also do all the support tickets, and already have alot of pressure to keep up with all the changes in UiPath, so want this to be as stable as possible, but whatever the reason, it surely hampers adoption of new features in the platform and innovation.
Its why I feel like it should be considered a product, and be taken into the products team.