cancel
Showing results for 
Search instead for 
Did you mean: 

Blueprism multi object design

iamharshith
Level 4
Hi All,

I hope everyone is safe and doing great.

I was going through the blue prism documentation on Object Design Guide(v 1.2).  In section 4 i.e. Multi-Object Designs (page 10) it is written that "A good rule of thumb to work by is to build a single object for each screen that is to be automated".

Can someone explain to me what exactly is a screen and give some insights on how should one go about using that rule?
I have attached the document for reference.

Thanks in Advance.

------------------------------
Harshith Kumar
Graduate Engineering Trainee
Schneider Electric
------------------------------
1 BEST ANSWER

Helpful Answers

MadhurChopra
Staff
Staff
Hey Harshith,

I hope you're staying safe yourself and having fun exploring Blue Prism.

To answer your question, I will direct your attention to the diagram in section 4 on page 10. There are three levels to the diagram from top to bottom, viz. (a) Blue Prism automation, (b) Required application screens that each automation accesses and (c) the ERP system.

The middle layer with screens is like any standard application that uses authentication and then allows various operations. I'll use a very simple use case, consider your email account and the way you use it. In order to use it, you will interact with the following screens in your browser:
1. Screen 1: Login screen
2. Screen 2: Inbox view
3. Screen 3: Compose a new message
4. Screen 4: Account settings
5. Screen 5: Change Password
6. Screen 6: Create email signature
.. and so on.

When building a multi-object automation, you will create a separate object for each screen above. This will create multiple components for your application that can be used as needed to achieve the purpose of your automation. For eg. In order to change your email signature, you will call screens 1, 4 and 5, whereas to send an email you will call screens 1 and 3. Now extrapolate this example to an application like SAP which requires complex business processes to navigate multiple screens that overlap with other business processes. Using multi-object approach, you are enabling re-use of those objects while getting some major benefits from it, such as:
  1. Multiple developers can now build objects without waiting on each other to release the lock
  2. Any process which automates the ERP System only consumes less actions into memory
  3. A change to actions within the ERP object will impact less processes
  4. The individual objects will be smaller and more efficient with a smaller Application Model
  5. The testing cycle will be more efficient as regression testing will only be needed for automations that use that particular screen as against testing all automations that use a larger single-object (with multiple screens)
I hope this helps answer your question and provide you some context on using the multi-object approach.

Regards.

------------------------------
Madhur Chopra
Sr. Product Consultant
Blue Prism - Professional Services
America/Los_Angeles
------------------------------

View answer in original post

4 REPLIES 4

MadhurChopra
Staff
Staff
Hey Harshith,

I hope you're staying safe yourself and having fun exploring Blue Prism.

To answer your question, I will direct your attention to the diagram in section 4 on page 10. There are three levels to the diagram from top to bottom, viz. (a) Blue Prism automation, (b) Required application screens that each automation accesses and (c) the ERP system.

The middle layer with screens is like any standard application that uses authentication and then allows various operations. I'll use a very simple use case, consider your email account and the way you use it. In order to use it, you will interact with the following screens in your browser:
1. Screen 1: Login screen
2. Screen 2: Inbox view
3. Screen 3: Compose a new message
4. Screen 4: Account settings
5. Screen 5: Change Password
6. Screen 6: Create email signature
.. and so on.

When building a multi-object automation, you will create a separate object for each screen above. This will create multiple components for your application that can be used as needed to achieve the purpose of your automation. For eg. In order to change your email signature, you will call screens 1, 4 and 5, whereas to send an email you will call screens 1 and 3. Now extrapolate this example to an application like SAP which requires complex business processes to navigate multiple screens that overlap with other business processes. Using multi-object approach, you are enabling re-use of those objects while getting some major benefits from it, such as:
  1. Multiple developers can now build objects without waiting on each other to release the lock
  2. Any process which automates the ERP System only consumes less actions into memory
  3. A change to actions within the ERP object will impact less processes
  4. The individual objects will be smaller and more efficient with a smaller Application Model
  5. The testing cycle will be more efficient as regression testing will only be needed for automations that use that particular screen as against testing all automations that use a larger single-object (with multiple screens)
I hope this helps answer your question and provide you some context on using the multi-object approach.

Regards.

------------------------------
Madhur Chopra
Sr. Product Consultant
Blue Prism - Professional Services
America/Los_Angeles
------------------------------

Thank you so much, @Madhur Chopra.
That was very helpful.​

------------------------------
Harshith Kumar
Graduate Engineering Trainee
Schneider Electric
------------------------------

Just to add to Madhurs good advice, the single object approach does work but experience has shown that you can end up painting yourself into a corner. Over time a single object can bulge into a cumbersome piece that is slow to load, save and run. The app modeller gets so busy that developers start to duplicate elements, and there are many pages that nobody has a full understanding of the object anymore. So just as you would never write code in one gigantic method, don't make mega objects - I've done it and paid the price. Find a way to divide the logic to take advantage of the points Madhur makes.

------------------------------
John Carter
Professional Services
Blue Prism
------------------------------

Thanks, @John Carter​.

------------------------------
Harshith Kumar
Graduate Engineering Trainee
Schneider Electric
------------------------------