RE-framework process with dynamic config-files

Hello,

I’m facing some questions regarding a process that is developed with the RE-Framework. I’m going to scale up this existing process for several end-users. The process will be the exact same procedure as before except that I need different config-files for each end-user. I want to avoid having several identical processes/packages in Orchestrator due to the massive work that comes when an update is needed. (Avoid having to do updates in all different processes).

So the question I’m facing is if it would be possible to make the config-files more dynamic and use them as inputs directly from Orchestrator. Perhaps as a filepath-asset in Orchestrator.
My question is really if someone else has faced the same issue and how you solved it.

Thank you!

Hey @KlaraN,

Just few questions to understand better how you intend to run the process

  1. Are these end-users going to run the Robot?
  2. If so, are they going to run from their local machine or from a VM?
  3. Considering VM, will they share the same Windows user? Or would there be a user for each of them on this VM? (if they are going to run from their local machine, don’t consider this question)

@KlaraN

The biggest trick here is identify the user.

That’s why I want to understand how you intend to run this process.

If these end-users are going to run it from their local machine or even from a VM where they have their own Windows user (and not a shared one), you could follow the steps below:

  1. Create a config file for each user. Important: Follow a pattern and name this file considering exactly the Windows username (the same used to unlock Windows / log in). Then, you will have something like this:

image

  1. Go to Initialization state, and before “Invoke InitAllSettings workflow” add an assign activity
  2. Create a String variable and references it in “To” field of assign. Set its scope only to First Run
  3. In value field of assign, use “Data\Config_” + System.Environment.UserName + “.xlsx”. Then you will have something like this:

image

  1. Update “Invoke InitAllSettings workflow” arguments, replacing in_ConfigFile value “Data\Config.xlsx” to our new variable UserConfigFile

That’s all!

@gustavo.cervelin

Thank you for all your input :slight_smile:

Yes, the processes will run unattended on a VM and each end-user will probably have their own AD-account. I think this is the best way, so that each end-user can manage their own account and limit user rights to correct data.

I will try your suggestion with fetching the correct config-file with the active username. One question about the System.Environment.UserName function, do I understand right that this fetches the current user logged in to the machine?

1 Like

Any time @KlaraN :slight_smile:

Nice!

Just considering possibilities… if they need to share the same AD-account to access the VM, please let me know and then I try to share another solution.

About your question about System.Environment.UserName… Exact, it fetches the current user logged in to the machine.

1 Like

Using Arguments on your Framework are pretty powerful. This allows you to set how the Job runs directly inside Orchestrator without needing to go through any efforts to re-deploy.

So if you have an Argument for the config file path or directory, then you can provision different processes that use different config files. You can also combine this with Assets, and place the Asset name into the Argument.

Another idea would be to base the processing when the job runs on files that are updated in a location. For example, you could have many users that have their own template file, and when that file is updated recently (like within the last 24hrs), you can get those files, pull in the ‘Last Written By’ user, then pull in the config file that associates to that user. - This method is used a lot in my organization, like when many users want to go download documents from a web application as they need to, where they might have a different list of documents daily or weekly.

I hope this gives you some ideas.

Yes, you can also get the robot’s username upon login then base the config location on that, but my experience is with unattended where the robot’s are different than the users who own the processes being deployed into Orchestrator.