Layered approach in UiPath

Help
1

May someone help me to understand - how UiPath supports layered design approach to design a multi layers application for process, sub process and components? To avoid any change on the underlying layer due to any change in any dependent layer.

Like BP supports Process, Sub Process and object modeling.

2

This is how it works in UiPath:

  • Each project has one entry point, the workflow initially called Main. This is the workflow that automatically opens when you open a project and also the one that is executed when a deployed project is run.
  • Apart from this, all workflow files are equal. A workflow can invoke other workflows, interact with one or several applications or none at all, for example just performing some data manipulation or putting items on a queue.
  • How you divide the task you are automating into separate workflows is entirely up to you. You don’t have to plan this in advance as you can just start designing a workflow and use the right-click action Extract as Workflow to put activities, sequences or flowcharts in separate workflows. There are many examples in the academy video tutorials.
  • If you have workflows you could use in multiple projects, the currently recommended approach is to store these in a location that will also be accessible to the robots.

In short, workflows are similar to BP (sub)processes, but with UI interactions directly integrated; there is no equivalent to the BP business object where you define these interactions separately for each application.

3

Building on this since I think it is related.

Several different projects will end up using the same application screens. I’m inclined to pull each screen into its own workflow and share those. I’m wondering if I should even subdivide those further so there is a workflow for every object, screen selection, tab selection etc.

Have you seen any drawbacks to making things too granular? For example, does UiPath have memory issues if too many workflows are called?

Thanks for any guidance.

4

@cynthia,libby
You can create separate workflows based on screens and call them again as and when application demands.
I am sure there will not be any memory issues or tool issues.

But, i am trying to understand what you are trying to achieve with this.
Similar frame work used to create Actions for each screen and call them based on the test flow by using another automation tool which is called keyword driven frame work.

Please provide more insight, i would like to learn more from you on the same :slight_smile: