cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple instances of the same object?

PvD_SE
Level 12
In the system I work with, there seem to be multiple instances of some of the objects created by colleagues over time. So they are not BP objects but our own locally created objects.

With a background in programming, I find this highly unpleasant as you want only one version of an object so you know that will be the one to maintain and that will be the one that will run when called. In windows there would be a PATH that defines where to look first for whatever has to run. I'm not aware of a PATH-equivalent in BP. Now I'm left wondering what version will be the live one and which will be redundant?

Obviously, this could be easily tested by creating two objects with the same name in different groups. Unfortunately our system does not allow me to delete or rename any objects or processes, so I'd be stuck with my 'test' objects until retirement kicks in. Aiming to keep our development environment as clean as possible, this is not an option - at least not for me.

Anyone out there perhaps knows the answer to my little dilemma?


Happy coding!
Paul
Sweden
Happy coding!
Paul, Sweden
(By all means, do not mark this as the best answer!)
1 REPLY 1

Walter.Koller
Level 11
Hello Paul,

I am not sure if I understood what your actual dilemma is.
Blue Prism should prevent* creation of two objects with the exact same name but it is possible to create two references (with different names) to the same code.
Since the base code exists only once, any changes to one reference will automatically impact the code of the other reference (since there is only one code).

Is it the existence of several object references to the same code or is it the difficulty to maintain those references?
For example, references of objets should not be 'deleted' but 'removed from group', otherwise the base code and all references to this object will be deleted as well.
When exporting/importing of one reference, it will be handled as single instance, independent of any other reference.
This is different to working with releases, when moving one reference to the package will also automatically move all other references to the release package.

The creation of new references to existing objects should only happen during imports. Normally single object imports should prevent this but it can happen when working with releases. 

*I have tested in 6.4 and 6.9 by creating two public groups and creating one object in each with the same name. Every time BP prevents me from creating an object wiht the same name in the second group. I am not sure if the behavior might be different if there are any user role permissions applied, like it is in your case.