14-04-23 08:34 PM
Hi All - Let's say we have a process that has to work on 10 different web applications. The work that is to be performed in each of this 10 applications is unique. Which below is the better approach in terms of design/debug). Feel free to suggest any other approach.
1. Create different pages within a master process for each application ( in this case it would result in 10+ pages) and run the process.
2. Create a separate process for each application (which would result in 10 sub-processes) and call all of these from a master process.
I do observe sometimes that resetting/saving a process with a lot of pages takes times and there is a significant lag. Would creating sub-processes and calling them from a master process reduce the reset/save time?
14-04-23 10:38 PM
Hi@maneesh.vemula1 , Is there any inter-dependencies of data collected or activities done as feed to the other among these websites.
I would certainly think of the efforts/activities it does on a single website if it's extensive/have bigger chunk of automation minutes, giving a feel of one big process within itself- I would create different processes itself keeping different status or tags of Queue Items to be picked up as per their status/tags.
If it doesn't have much of extensive work and requires either to be called as sub process or subpages - I would think of what advantages/disadvantages I have with above two approaches- dividing a bigger process into more manageable sub-processes sounds good but it would definitely reduce the visibility/add complexity to process flow.
Calling a Sub process from a master process would create a separate instance and load memory but it will run separate from the instance of master process, this approach follow modularity and reusability but both of these approaches would heavily rely on the size of object it uses.
If the automation minutes are low for each websites I would go with creating sub-pages as it will allow me have to better control and visibility on process flow - as I am not 100% sure if creating a Sub Process and calling it from Master process would be faster as system would have two different instances/memory allocation of processes running which is additional memory usage and Creating a subpage would load subpage in master process would be increased memory usage but in terms of references in the same memory, system might find it easier to access refrencing same memory block as it's created in the master process memory itself rather than passing data values from one instance to other.
It's difficult to say unless observed with amount of automation efforts/minutes it has overall to act and complete.
------------------------------
Kindly up vote this as "Best Answer" if it adds value or resolves your query in anyway possible, happy to help.
Regards,
Mukesh Kumar - Senior Automation Developer
NHS, England, United Kingdom, GB
------------------------------
18-04-23 05:38 PM
Based on the information provided, I would recommend going with the second option: creating separate processes for each application and calling them from a master process. This approach is more modular, maintainable, and scalable.
Designing each sub-process separately allows for better organization and modularity of the overall solution. This can make the debugging process easier and more efficient. Additionally, updating or changing one sub-process will not affect the other applications.
While creating sub-processes and calling them from a master process may not necessarily reduce resetting/saving time significantly, it can help in better management of the overall solution, which can indirectly result in better performance. If resetting/saving time is a concern, breaking down the sub-processes into smaller, more manageable modules can help in reducing the complexity and size of each sub-process, which may result in faster resetting/saving times.
Overall, the second approach of creating separate processes for each application and calling them from a master process is generally considered a better design choice, as it allows for better organization, modularity, and easier debugging.