cancel
Showing results for 
Search instead for 
Did you mean: 

Owning library of System Process not correctly set

Highlighted
Occasional Contributor

Owning library of System Process not correctly set

Dear community,

 

We encounter an annoying problem when modelling System Process hierarchies with HOPEX V2. 

 

- If a System Process is created directly from a Library, then we can see a relation "Owner Architecture Container" from the System Process to the Library stating the ownership. See "System Process-1" in attached file.

- If a System Process is creted directly from another System Process (child Process), then there is no relationship "Owner Architecture Container" to the upper Library. See "System Process-2" in attached file. That was NOT the case in HOPEX V1R3. In that previous release, creating a child System Process from a parent System Process maintained a realtionship to the upper Library

Problem.png

Is there a way to restore the previous behavior ? Some configuration to be done  something related to a configuration issue ?  

 

Regards,

Ismael

 

 

 

 

5 Replies
MEGA Partner

Re: Owning library of System Process not correctly set

Hi

 

This is by design. An object can only have one owner. If a System Process (or otrher processes) are created in a Library, they are owned by that library. If a System Process is created as a sub-process of another System Process, then the owner will be that System Process. This is also a mechanism that you can use to query what is a Main Process and what is a sub-process.

Occasional Contributor

Re: Owning library of System Process not correctly set

Hi hsoegaard,

Thanks for you for reply. I understand that an object can have a single owner, though I thought that rule applied to owners of kind Library (namespace) like packages in UML.

 

In our case, we need both relationships: a System Process as a child of another System Process AND the child System Process being owned by the Library. This is so, because we have a set of Queries and Reports that look for System Processes in specific Libraries, therefore we miss child processes if not referenced at Library level.

 

Our workaround is to drag & drop the  child process to the upper Library to force the ownership relationship with it. Do you see another way to achieve that ?

 

Regards,

Ismael

MEGA Partner

Re: Owning library of System Process not correctly set

Hi,

 

You just use the "deeply" value in you query. That way you get all System Processes in the Libraries, plus all the System Processes of those and so on deeply.

You can searh for Queries where deeply is being used to see examples.

Re: Owning library of System Process not correctly set

Hi,

 

Creating a process within a process should be used for BPMN "subprocess" only, in which case the sub process is owned by the parent process as it should be.

 

When willing to reuse processes, the "called process" link from a task shall be used (otherwise the ownership is reallocated, for instance when drag an dropping a process within another process).

 

It is then possible to have a System process owned by a library and used within another (or several) process via a task > called system process. The contextal information is then defined at the task level.

 

Occasional Contributor

Re: Owning library of System Process not correctly set

Hi  OLeGuellec,

 

Indeed, your are right. The proper way of modelling a process hierarchy would have been to use Task to Call System Processes, hence having a whole-part way of working. Unfortunately our model has been built using the "old" approach, that is embedding a "whole" (System Process)  in a" whole" (System Process) and we need to keep it this way for now.

 

What is still possible in MEGA is to have a System Process as a child of another System Process ("Owner System Process" relationship) and being also child of a Library ("Owner Architecture Container" relationship). What we'd like is to create those two relationshops at once at the creation time of the child System Process. See figure below

 

sans_image.png

 

In any case, thanks for your contributions.

Regards,

Ismael