Enhanced REFrameWork

Hi, the activity is dependant on the UiPath.Credentials package for the GetCredentials activity, which hooks in to both Orchestrator and Windows Credential manager. If you install it, you'll be good to go!

The way i thought about it was this:

The framework offers you the ability to operate on a set of programs while not having to worry about exceptions, logging, and so on. Well if that's true, why wouldn't this layer be replicable such that you could stack it one on top of the other. And that is what services are.

Your questions is where to call them, and two of them are called by default in The Main.xaml file and can be enabled/disable from the Config.xlxs file. They are the FirstRun and GetData services.

Task1/Task2 and whatever other tasks you create should be used in ProcessTransaction.xaml . Examples due to char count: What if you had a data source containing items that belonged to 10 different categories, each category having the meaning that you had to treat the data in a different way (for example, go to a different website to process the information). By calling 10 different services in the you could execute the desired behaviour.

Hi Rony,

The "SetTransactionStatus" workflow has been removed from this framework.

First of all, one of the problems with setting it in the "SetTransactionStatus" activity were cases where the user wanted to perhaps do something else with a transaction other than set it's status to Business Rule Exception, Application Exception or Success. One can easily image a case where a transaction is simply postponed.

Therefore, the Enhanced ReFramework has the statuses set in the Process Layer, in the ProcessTransaction.xaml, by the user of the framework.

The other reason why the workflow is gone is because the Closing of the apps in case of ApplicationException was moved to the Init layer, where it can now be retried (which was impossible before).

I think this increases flexibility and allows a number of retries of the Init state.

Hi Devashish,

I am not currently planning to do this in the short term, but might do it in the future. For now, what i would like to do to the Enhanced is to write its documentation, which will take me some time as it's going to be quite long.

Afterward video tutorials are a very good idea i think!

Glad you figured it out!

Hi Dzmitry,

I assume here that you are referring to the two tasks given as example and meant to be called by the user (Task1 and Task2 - or any such task the user might create).

Weather you should call these tasks in a sequence or in parallel depends on the actions taken in the process layer of these tasks. Let me try to be more explicit.

If one were to create two tasks which retrieve data using an API or database connection and then populate that data in, for example, a web browser, using input methods that work in the background (https://studio.uipath.com/docs/input-methods) then you can surely execute them in parallel.

On the other hand, if they need to use hardware input methods and you execute them in parallel they are going to fight to access to the same hardware resource (keyboard or mouse) and fail.

Task1 and Task2 are not executed by the framework automatically, and cannot be started from the config, unlike the GetData and FirstRun tasks, which are part of the default implementation of the framework but disabled by default.

Task1 and Task2 are meant to server as a example which you can reuse for a blank task, which you might decide to call in the process layer of the framework. Their role is to accomplish a standalone task and provide a safe way (exception handled) to do so.

For example, one might use them in a scenario like this:

Premise: Suppose in the data layer you get a datatable with each row representing a transaction. But now, there are multiple providers for the transactions, meaning that the actual operation uses the same data, but that data is exchanged with a different system. Thus, each system requires a different implementation.

1. We can use tasks to build the implementations for each of the different systems.
2. In the data layer of the framework we get the transactions datatable, sort it according to the system type column.
3. Each transaction will be a list of rows of the same system type
4. In the process layer, we call the Task which solves the correct system type. The TransactionItem of the Main Process (which is a list of datarows as stated above) becomes the TransactionData of the Task. The individual Tasks can then take care of opening the application, closing it and recovering from it smartly.