Under Consideration

Colaboration Between Different Version of Processes

Actually Bizagi does not include collaboration between different versions of processes . If we have a P1 process that in a certain point waits to process S1 to communicate it , the both process must be in same version. Considering that S1 process can communicate multiple instances of P1 , all of them must be in same version of S1. If we start a P1 instance in version 1.0 and then we generate the 1.1 version of P1 and S1 , the S1 1.1 version is not able to communicate P1 1.0 version instance to go on, and it will be waiting forever .

photo
0

Imagine that the process P1 has an Intermediate Message Catch Event called 'WaitOk' and the S1 process has an Intermediate Message Throw Event called 'SendOk'. The id of ‘WaitOk’ event in the Task table in the database is 162 and the id of ‘SendOk’ event on the same table is 195. In the idTaskMessage field of ‘SendOk’ Event in the Task table, Bizagi will include the id 162, of the ‘WaitOk’ event. Every new process version, all tasks are duplicated in the table Task in the database, so getting new ids. If only create a new version of the process P1, the 'WaitOk' task will receive the new Id 230, for example. S1 process, which had not generated new version, ‘SendOk’ event will continue pointing to the task Id 162. The solution proposed by Bizagi is that when creating a new version of P1 we must also create a new version of S1. In the new version of S1, the ‘SendOk’ event would point to the new id of ‘WaitOk’ event, which will be 245, for example. Well, in this case what happens to all instances of P1 in versions prior to last? They will be waiting forever because ‘SendOk’ event of the new S1 version now only communicates ‘WaitOk’ event with id 245. In my opinion the solution to this issue would be not write directly on the Throw Event in the Task table the id of Catch Event, but to create a relationship table (multiple to multiple) that would store the ids of both events, Catch and Throw multiple times. In my solution, the relationship table, would have the following records, considering the examples used above. Please see attached image.