REFramework: any arguments not to use it?

I’ve always been a proponent of the REFramework, because it essentially works out of the box, including exception handling, logging and pretty much anything you’d need for an enterprise robot. Perhaps you might want to tweak a few things, but the basis is solid.

Recently I’ve started working with a few developers who do not wish to use the REFramework and wanted to create their own thing instead, from scratch. I was a bit shocked… why reinvent the wheel when the REFramework already exists? Could it be that they don’t fully understand how it works? We are building enterprise-level robots.

Do you use the REFramework? If so, why or why not? Are there any arguments against using it or arguments for creating something from scratch? I will need to talk with these two developers about this subject, hopefully I can convince them. Every UiPath team I’ve seen, uses the REFramework or a slightly tweaked version of it.

1 Like

@trog

Welcome back to our UiPath community.

I will prefer to use ReFramework only whether it’s small or large business process as it provides better Exception Handling, Logging and Retry mechanism.

Hey @trog

Good day.

Any programming language we go, We have something called framework to build Enterprise standard solutions.

Benefits

  1. Everyone on the same page will be easy to maintain by any developer without much dependency

  2. Good Exception Handling and Recovery mechanisms

  3. Less time consuming as the standard template is already built where a developer will be concentrating on logic building

  4. Easy to maintain and scale the process

There is a lot many as well.

Hope this helps you.

Thanks
#nK

There definitely should be a framework, and in my opinion the REFramework does everything perfectly fine out of the box… no serious changes needed. It just works brilliantly with Orchestrator for both small and large processes.

Any tips on how to convince 2 other developers of equal rank of this (they’re supposedly seniors but this title is being handed out liberally I have noticed…)? We’re a new team. They want to build their own “template” that will likely be some kind of flowchart mimicing the REFramework but with less robust exception handling/logging and no retry scope, sadly I’ve seen this before… As I said I have a suspicion they don’t understand how state machines work and why the REFramework is so good.

The clients we have, we can’t get away with building citizen-developer level bots…

1 Like

I think the way REF uses the state machine concept is a bit overrated, building a simple flowchart results in the same, but it is what it is I suppose :slight_smile:

I did build my own framework once (in a different RPA tool) which was actually somewhat more self steering than REF in UiPath, but the Orchestrator architecture in UiPath has some limits to support that logic and span of control.

However, there are definately advantages in using the out-of-the-box setup, you get a lot of flexibility and ease of automation, especially when just starting with RPA.

State machines allow for much more readability since you can have multiple transitions from one state. Mimicking the same in a Flowchart would result in exponentially more code.

Also every Uipath Developer is taught about the REFramework, so it doesn’t matter who you hire, they are already familiar with the basis of your bots… at least they should be.

I just see no reason to reinvent a perfectly fine wheel and when I tried to ask them about it I didn’t really get a reason either. This is a start-up company and the existing code base is very amateuristic, I almost couldn’t believe it since we work for a government agency. The good news is only a few small bots have been built so far, so it can be salvaged. Those bots were built by people that already left, the 3 of us have not built any new bots.

Unfortunately RPA attracts a lot of “fortune seekers” and I fear this might be the case here. Combined with the infamous stubbornness developers can have in wanting to “rebuild everything from scratch”, especially with X years of different tools on their resume (not UiPath) I might be in for a challenge convincing them.

But I’m not going to build robots for a government agency without a solid framework, which UiPath already provides… I have a few other job options lined up that I KNOW use the REFramework or a tweaked version of it, it’s truly a dealbreaker for me. Unfortunately we are all “seniors” because that looks cooler for the customers… aahh, the world of consultancy.

I have never worked anywhere or visited a team that did not use the REFramework or something similar. Only lone citizen developers…

I suppose I am a little bit of both sides that you describe. The time I had to build my own, in different toolsets simply outdates UiPath. There simply was nothing out there at that time (that I did know of). But I completely agree with you as I did back then, that a solid Framework is definately required if you want to solidify RPA on an enterprise level. And with the (failing) hype of citizen development you indeed can have a hard time convincing people of its benefits.

It just that… mine was just better :slight_smile: So when my new job stated that they Used UiPath icw REF it was fine, but also a slightly step back in features I had become used to. It sounds extremely arrogant I know… but it was there nonetheless.

Oh and:

Unfortunately we are all “seniors” because that looks cooler for the customers… aahh, the world of consultancy.

I sympathise… ‘fake it untill you make it teams’ are a consultants nightmare. Also their goldmine though…