Bala Shunmugam
Member
What is Shared application modeler?
How to configure it?
How is it useful in Blueprism?
Thanks in advance.
How to configure it?
How is it useful in Blueprism?
Thanks in advance.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Shared Application Modeler
- Thread starter Bala Shunmugam
- Start date
Two or more Objects can share the same Application Model, if they both interact with the same application. This can make it easier to maintain, since a change to an element will apply to both Objects via the shared Application Model. However, there is a cost to doing this: the Application Model can get quite large.
Let me give an example. Suppose you have an Object that interacts with a mainframe application. Typically, a mainframe system will contain many screens, each of which displays different information or accepts updates to the information on that screen. Let's say you create your Application Model and define 2 screens (QUOTE and SALE) and the elements associated with each. Later, if you create another Object that will also interact with the mainframe system, and you share the Application Model of the first Object, you can use the 2 screensand elements that have previously been designed for the first Object in your new Object. If the 2nd Object requires the definition of additional screens (say, PYMT and CUST), you can add them to the shared Application Model for use by the 2nd Object. They will not interfere with the 1st Object because the 1st Object doesn't reference them. But they are also available to the 1st Object if needed in the future. So you can see that the shared Application Model allows for reuse of screen elements that have been previously defined.
I mentioned that the Application Model can get very large. Imagine if there were 50 screen elements defined. Then, all 50 elements are held in memory whenever you use Object 1 or Object 2, even though these Objects do not refer to (i.e., use) some of the screens/elements in the Application Model. That wastes memory, and can be an issue especially on virtual Runtime Resources since they rely on the amount of memory allocated to them by the system administrator.
The use and benefits of a shared Application Model depends on what you think is appropriate. I use both shared and individual Application Models in my automations.
You should also know that if 2 Objects share an Application Model, and you make changes to the child Object, then you need to import both the child Object and the parent Object (the one that owns the Application Model) in your Release, even if the parent Oject was not modified. You can tell if the Application Model is shared by opening an Object in Studio, and then opening that Object's Application Model. There is a notice shown near the top of the Application Model screen that tells you if the Application Model belongs to the Object that's open for editing or to a different Object. The notice will tell you the name of the parent Object if the Application Model is shared.
To share an Application Model, simply select Shared Application Model when creating your new Object, and select the Application Model that you want to use from the list.
Hope this helps.
Let me give an example. Suppose you have an Object that interacts with a mainframe application. Typically, a mainframe system will contain many screens, each of which displays different information or accepts updates to the information on that screen. Let's say you create your Application Model and define 2 screens (QUOTE and SALE) and the elements associated with each. Later, if you create another Object that will also interact with the mainframe system, and you share the Application Model of the first Object, you can use the 2 screensand elements that have previously been designed for the first Object in your new Object. If the 2nd Object requires the definition of additional screens (say, PYMT and CUST), you can add them to the shared Application Model for use by the 2nd Object. They will not interfere with the 1st Object because the 1st Object doesn't reference them. But they are also available to the 1st Object if needed in the future. So you can see that the shared Application Model allows for reuse of screen elements that have been previously defined.
I mentioned that the Application Model can get very large. Imagine if there were 50 screen elements defined. Then, all 50 elements are held in memory whenever you use Object 1 or Object 2, even though these Objects do not refer to (i.e., use) some of the screens/elements in the Application Model. That wastes memory, and can be an issue especially on virtual Runtime Resources since they rely on the amount of memory allocated to them by the system administrator.
The use and benefits of a shared Application Model depends on what you think is appropriate. I use both shared and individual Application Models in my automations.
You should also know that if 2 Objects share an Application Model, and you make changes to the child Object, then you need to import both the child Object and the parent Object (the one that owns the Application Model) in your Release, even if the parent Oject was not modified. You can tell if the Application Model is shared by opening an Object in Studio, and then opening that Object's Application Model. There is a notice shown near the top of the Application Model screen that tells you if the Application Model belongs to the Object that's open for editing or to a different Object. The notice will tell you the name of the parent Object if the Application Model is shared.
To share an Application Model, simply select Shared Application Model when creating your new Object, and select the Application Model that you want to use from the list.
Hope this helps.
Bala Shunmugam
Member
Yes it does a lot. Thanks