Bug: Importing other releases overwrites a different release

[bothaanton]

We have identified this issue yesterday. A release, lets call it A, was created in a different environment and promoted to our production environment. This was the first import of release A. In production we had another completely different process not related to A, lets call it B. On importing A it saw itself as B and completely wrote over release B. When the schedule for release B ran it ran the process for A. 

On investigation we found that the ID's for the two processes were exactly the same. This should not happen in a world where we have 1000's of people creating releases and sharing them with other.

------------------------------
Anton Botha
------------------------------

[david.l.morris]

My first thought is that the import conflicts window probably indicated that the IDs were the same, but I would agree it still should notbe possible for this to happen or at the very least it needs to be a very obvious import conflict. I think it might set so that by default, that kind of import conflict it set to overwrite based on the ID primarily and then by the name only secondarily.

So just trying to think through how to reproduce this issue since I'm not at home to try it... The only thing I can think is that both processes originally were created from the same initial release. For example, if someone created a process and then exported it and then sent that process to you. Then two people each take that process or release that contains the process and import it into their separate environments, I think the preferredid field in the xml would cause them both to have the same ID in their separate BP environments. Then both got worked on separately, then exported from their respective environments. At this point, they would both show the same preferredid in the xml. When someone imported the first one into your production environment, there would be no import conflict as you mentioned. But when the second one got imported, it probably showed an import conflict and the person importing may not have noticed it specifically say it was going to overwrite a different process. I personally think the UI in BP needs improvement there because it is not easy to read or work with. 

I hate that this happened, and hopefully nothing bad happened from the wrong process running at that time. One suggestion I have is to first import processes into a Test/UAT environment first. I know not everyone has enough environments for that but it's helpful for things like this.

------------------------------
Dave Morris
Cano Ai
Atlanta, GA
------------------------------

[Prashant]

Hi Anton,

I agree that this should not happen but I understand the different environments are completely disconnected and there is no way for the Blue Prism to determine if the import is intended to overwrite an existing process or create a new process except to rely on some sort of id. I presume that the 2 processes A & B were created in separate Blue Prism instances and the guid created in both instance were the same - though this should be rare this can happen. 

However while importing the release A you should have gotten a "Resolve Import Conflicts" screen with a messge saying "A process with the same internal ID and name already exists in the database. Please choose one of the following ways to resolve this conflict" and 3 different options including "Assign a new ID and rename the incoming process" and "Don't import this process"...

if you did not get this screen - then this is a even more serious issue.

A probable resolution for this could be using deploying some URN scheme for identifying the processes and objects instead of just a guid.

------------------------------
Prashant imf.org
Software Engineer
IMF
------------------------------

[bothaanton]

Hi. Thank you for your reply.

The "Resolve Import Conflicts" did not have a resolve conflict for the particular process. It only had the options for the VBO's that were being imported. This release did not contain any other created objects.

------------------------------
Anton Botha
------------------------------

[ewilson]

The chances of two different machines generating the same GUID are not zero, but they are astronomically low. There are several sites on the web that discuss the odds if you're interested in them.

As @Dave Morris said, ​the only way I can see this happening is if someone started with an existing release or process and then edited it on a different machine. Alternatively, I've seen instances where people deploy tools that directly act on the XML of the .bprelease file or an exported process/VBO file. In those cases it's entirely possible to introduce a GUID collision.

What version of Blue Prism are you using?

Cheers,

------------------------------
Eric Wilson
Director, Partner Integrations for Digital Exchange
Blue Prism
------------------------------

[bothaanton]

We are using version 6.9.

------------------------------
Anton Botha
------------------------------