Do i have to use REFramework?

Hello,

I’m working on project that gets data for each customer from sap, copy to excel data and mail excel file for each customer.

I wonder that do i have to use REFramework? Can’t i work with just process and add trigger to orchestrator? What will be different if i use REFramework? Sorry there are so many questions :smiley:

Hi @Oguzhan_Celik ,

One process can be done in many ways.

If you go with REFramework you don’t need to create base of process like creating config file, reading config file and all states are their and properly defined.

Your process seems straight so you can also go with normal workflows.

It all depends on you how want to achieve this.
But still I recommend to use REFramework.

Thanks

1 Like

You don’t have to use REFramework. In fact, I would recommend not using it. It’s overkill for pretty much every automation I’ve seen it used, and overly complicated. You can create your automation from scratch, use one of the other templates, or create your own template. I created my own “framework” template that’s much simpler and therefore easier to maintain than automations done with REframework.

1 Like

If you’re doing unattended automation you shouldn’t be using config files at all. Use arguments/parameters.

1 Like

But why ?

We have to store constants and Assets Name somewhere and Config file is best for that.

Config file is not best for that. Arguments/parameters are best for that. No file to manage and secure, no need to republish to change settings, easier to manage dev vs prod settings (just set the parameters differently in each), parameters also make it easy to have different settings per trigger.

But why their is a need to republish it?
If we are storing everything in Assets then only value need to be changed on Orchestrator.

I never face such issue moving code from dev to qa and lastly to prod.

We can also place config on shared drive and we don’t require republish project when any changes done to config.

If your config file is in your project folder (which people shouldn’t do, but do anyway) then you have to republish to make config file changes.

You shouldn’t be storing everything in assets, either.

Trust me. I got away from config files a long time ago. Arguments/parameters are much easier to manage. One thing it makes easier is testing. You can set the arguments in Studio for local/attended testing then when you publish to qa/dev you can set the parameters there to override what’s in Studio. Then you don’t have to touch a config file every time you switch from local to unattended testing. It’s all automatic.

2 Likes

Thanks for your tips, Paul