Base model usage has been improved so that editing the base model or any child models does not lock the other models using the same base model, i.e. it is possible to edit the base and child models concurrently. However, there are some things you should note:

 

•If a base model is edited while a child model is open, the child model is updated the next time it is opened from the Server.

•In the case both the base model and any of the child models are edited simultaneously, conflicts can occur due to possible deleted elements. In these cases a warning message is displayed and the models should be closed and reopened to make them "valid" again.

•In the case a base model is deleted or its base model status is removed while a child model is being created (but not saved yet), a dialog asking whether to merge the base model elements into the child model is displayed when the child model is saved. After this the child model can be used as a regular Server model.

•The "Use from base model" settings in a child model are loaded from the base model in the following cases:

•New model is created based on a base model

•An existing model is changed to use a base model and the base model forces read-only usage for element types.

•If the child model has model-specific web publishing settings enabled, those settings are always used in dynamic web publishing. However, in the case the child model is not using model-specific web publishing settings and the base model is using them, the base model settings are used also in the child model except for web publishing settings set for individual model elements. In the case the child model contains custom element types, generic QPR Web Application Server settings are used for them. The generic QPR WAS settings are used also in the case neither the base model nor the child model are using model-specific web publishing settings.

•As regards the Matrix View, the matrix cell values are not inherited from a base model, the cell values are set in the child models. Cell values set in a base model are visible only in the base model.

 

There are also two special cases when data loss can occur:

 

•An element type was deleted from the base model and an element of this type was created to a child model. When the child model is saved, the element type is changed to an existing element type in the base model. This element type is either the default activity or subprocess type for process steps or first information/non-information connector type for connectors. When the element type is changed, all values of custom attributes are lost.

•An element type was deleted from the base model and an existing element's type was changed to this type. In this case the element's original type is kept. All custom attribute values for this element are lost.

 

As regards View Settings, note the following:

 

•When a model is changed to use a base model (i.e. the model's type is changed to child model), the model's view setting is considered to be a duplicate of the base model's view setting if the view setting has the same name and if it shows the same hierarchy. When such a duplicate view setting is found, the child model's view setting is deleted.

•Matrix View Settings can be modified only in a base model. When the matrix row/column elements are set to be a Custom set, it is possible set this as undefined and then define the actual row/column elements in a child model. This way it is possible to define a matrix where, for example, the matrix columns are set in the base model, but the matrix rows are defined in the child model.

 

Matching element types and elements between a base model and a child model:

 

•Element types are matched by comparing the element type symbols and the meta type (e.g. process step type). The name, behaviour settings, and custom attribute types are ignored. If the element types are set as read-only, a child model contains elements of a read-only type, and an element type symbol match is not found from the base model, additional element type matching is done in the following order:

1.QPR Modeling Client tries to find an element type with the same name and meta type.

2.The default subprocess type of the base model is matched for all the subprocess types in the child model. (The default subprocess type is internal to QPR Modeling Client and cannot be changed.)

3.The default non-subprocess type of the base model is matched for all non-subprocess types in the child model. Note that the base model doesn't necessarily have a default non-subprocess type (i.e., when the base model doesn't have any non-subprocess process step types).

4.The first information flow type (if one exists) of the base model is matched for all information flows in the child model. The first flow type is the first one that is in the flow type list of the base model.

5.The first non-information flow flow type (if one exists) is matched for all non-information flows in the child model.

6.If a matching flow type is not found based on steps 4 and 5, the first flow type of the base model is matched for the unmatched flow types in the child model (if the base model has any flow types.)

7.If a matching element type is still not found in the base model and element types are set as read-only, element types not found and all elements of those types are deleted from the child model.

•Elements are matched by the element's type and symbol. If a matching element is found from the base model, the element in the child model is replaced by the element from the base model and the child model element is deleted. If a matching element is not found, the child model element is left in the model or deleted if the base model doesn't allow such child model elements.

 

Using Type Groups (available with a separate license) with base models and child models:

 

•Type Groups are inherited from the base model. Child model types can be added to base model groups in the child models.