Hi @DipinDevP ,
The concept of the sharable business object is often misunderstood in a wider range of context when it comes to solution designing.
Basic Definition Of Sharable Business Object:
Usually, the basic definition of this concept states that when you mark a business object as Sharable from the Information section of your Initialize action page of the business object, then you basically are exposing the application modeler to be used as a starting point for your other business objects that is also called as model sharing (till this part many people lay their eyes on) but then there is the second part of the definition which is very critical to understand that is you also are going to just create one single instance of the business object and the application model within a single process.
Understanding the First Part Of The Definition:
Let's try to understand these two parts separately first. The first part of the definition makes it sounds as a very cool feature as it lets us know that well you can make any of your existing business object reusable and also at the very same time fasten your development efforts.
So how exactly this is achieved? Well, the answer is pretty straight-forward which I can explain using an example, let's say we have a web application with multiple screens and as per the best practices recommended by Blue Prism, there should be a separate object that we should create for a different screen at the bare minimum now this too can change if let say a screen has a lot of elements and if we keep spying all of them together in one object we will end up making our application modeler very heavy which will ultimately impact the performance of the business object so yes we technically can take a call to segregate the business object in such a case to multiple business objects even if they are meant to function for the same screen of the same web application.
Now, assuming we tomorrow have some sort of a separate process which basically needs to interact with one of the screens of the same web application that we already used in one of the existing processes but there are some additional elements in that screen which we did not interact with as part of the existing process, but we do need to add those as well. So, question is would you dare and try to make modification to the same business object which already is now running in Production and add more elements as well to it which can the application modeler heavy?
To mitigate such issues what many teams do is basically create an initial business object for basic actions such as Launch, Attach, Terminate and Detach. Then, they would create another business object more specific to the screen they want to automate and spy the commonly used fields such as let say any dynamic navigation tabs or any kind of reusable field and mark it as sharable.
Now, if let say there are multiple teams who want to work on the same screen but on different projects with different number of elements, they can just create the new business objects for the screen and while configuring the application modeler just refer to the shareable business object application modeler and that would eventually give them by default all the dynamical navigation field and the reusable elements.
This way these team can now add more elements to their newly created business object, but the changes won't be reflected on the parent object and neither the changes will appear on the other team's business object. So basically, we managed to develop a common sharable parent business object whose attributes got inherited by two child business objects and they remain independent of each other thus speeding up the development and reusability by some extent.
On the same note, every firm has their own rules related to what type of business objects should be considered as sharable and what should not but when a solution architect is assessing the same, he needs to keep the second part of the definition in mind which is very important.
Understanding the Second Part Of The Definition:
Now, by definition you already must be aware that when a Blue Prism process runs, any business object that is called via the action stage will always occupy the memory at the time of the initialization and will basically hold that memory for the entire duration of the process and creates an unique instance of the application modeler and the business object. - It means if I call three business objects named Object A, Object B and Object C within a process and they are non-shareable, then a separate instance of the object and associated application occurs. In the example below, there would be three separate instances of Object A, Object B and Object C and the associated application.
When you basically use the action stage in a process to call one of the actions of the business objects that refers to a shareable business object, then it is the shareable business object which would hold the memory for the entire duration of the process and would be part of a single session. It means that later even if you call another action of let say another business object that refers again to the same shareable business object within that process, it would not create a separate session but would be treated as part of the same session of the shareable business object.
Here, Object C is a sharable business object and only a single initialization of the associated application occurs. So, what does it mean? - In simple terms I would say if you wanted to access the same application as part of different sessions you basically cannot do that if your associated business object is referring a shareable business object.
For example, I have a process where I got a business object A which wants to login into the application with Credential XYZ and then at the same time I want to open another instance of that same application to login with Credential ABC using business object B. I cannot do that as they are referring to a sharable business object so in that same process, I basically cannot open two different instances of the same application. Yes, you can log out from the application using Object A and then log in again using Object B but that is different as it is just using the same instance of the application not two separate instances.
Now, if let say I still want to use separate sessions using Shareable business object can I do that? If you remember the definition it says, using shareable business object or any child object which refers to a shareable business object it is only possible to create one single instance of the business object and the application model within a single process. - So, the answer lies here only, if I use a separate process or in simpler terms create a sub-process for accessing the login action used within Object B then yes even if the business objects A and B are referring to the shareable business object C, I still can create two separate instances of the objects as they are now two different processes and not a single process anymore.
Sample Workflow For Testing:
Let say I have four business objects, Notepad Object - A, Notepad Object - B, Notepad Object - C and Notepad Object - D. Here, Notepad Object - C is a shareable business object while Notepad Object - A and Notepad Object - B are using the shareable Notepad Object - C business object. While Notepad Object - D is an independent business object which is not referring to any shareable business object.
Also, for all of these business objects I have a common action created called as 'Launch' which would simply launch the notepad application.
Now, I have prepared a workflow as below to demonstrate my explanation provided earlier:
Main Process:
Sub Process:
What I am doing here is pretty straight forward, I will first call launch action of Notepad A, then call launch action of Notepad B, if any error occurs while calling launch action of Notepad B, I will call a sub-process where I am calling the launch action of Notepad B and then at the end I call the launch action of the independent business object Notepad D.
When I execute my workflow, you will first see that the first action will launch the notepad application. Here the Notepad - A business object is referring to a shareable business object Notepad C so a single instance will be created for Notepad C during the entire execution of this process.
Now, when I will execute the next launch action for Notepad - B business object, I will get an error stating that the application has already been launched so it cannot re-launch it. This will happen since Notepad - B business object is also referring to the shareable business object and we know that in a single process only one instance of the business object can be used for a shareable business object.
Now, when I execute the sub-process, there the flow would work and launch a new notepad application for Notepad - B business object as even though it is referring to a shareable business object it was used in a separate sub-process which by definition should allow the action to work.
Finally, when the workflow will execute the launch action of the Notepad - D business object it should also open the Notepad application as it is not referring to any shareable business object and thus it will create it's own application instance.
Conclusion:
Pros:
- The shareable business objects are a great feature if one wants to speed up the development process.
- It can significantly help to enforce reusability across different related business objects being developed.
- It can be easier to maintain if frequent updates are handled responsibly as updates to the application model need to be made only once and are automatically reflected in all processes using it.
- It can ensure that all processes use a consistent application model, reducing the risk of errors and discrepancies.
Cons:
- One needs to be careful while maintaining the same as any changes in the parent shareable business object can impact all of the related children business objects especially if it is being used in Production environment.
- Identifying and troubleshooting issues can become more complex as multiple processes rely on the same model and if the underlying application modeler of the shareable business object is complex.
- One needs to be careful to ensure that the application modeler of the shareable business object is not too heavy as it can impact the children business objects.
- One needs to carefully consider the design requirements of a process where it should be used as shareable business objects do not allow the separate instances of the child or the parent shareable business objects to be created individually during the duration of the entire process.
- If any of the business objects which are shareable in nature or if are referring to another shareable business object need to be called in such a way that separate application instances can be used, then they must be used in individual sub-processes but again this approach can add nuances to the existing process design making it more complex and can also introduce unwanted memory leaks if the referred sub-processes are repeatedly being called within the main process.
