When running a model, the engine will instantiate a model and will contextualize an environment.

The environment contextualization is based on the Configurator input parameters, given by the configuration.xml file. These input parameters can be used to identify the user that is running the model, or to explicit which application is launching the model, but more importantly, it will create a session. This session will be based on some mandatory parameters, mainly focused on (1) the identification of the Configuration Process to run and (2) the regional settings (language, currency, etc.) to be applied.

The identification of the Configuration Process to be run is based on (1) the workspace and (2) the name of the Configuration Process. These 2 parameters will be used in order to know in which environment the engine is working.

Once a session has been created and once the context has been set, the model will be instantiated. This means that a “copy” (an instance) of the root Configuration Process will be created in the session, based on the previously created context.

In the previous example, if the rootCP_B is run, it can be represented as follows:

This example clearly shows that the model has been instantiated (a copy has been create with only the content of rootCP_B) and contextualized (the workspaces have been applied to it).

When using the Designer in order to create a domain BRC attached to the form property indicated by (1), a CPE will be automatically generated for that form property. Although the absolute CPE has the following form:

CPE.wksA/CP/rootCP_A.wksA/CP/CP1.wksA/FO/FO1.FP/FP1.value

the generated CPE will be a relative CPE which is synonymous with it, having the following format:

CPE.currentFP.value

This happens for a very simple reason: reusability. This reusability can be demonstrated with the following 2 examples.

Example 1:

Suppose that the form property (2) should have the same domain as the form property (1). If absolute CPE would be generated, then 2 different domain BRCs should have been necessary, one for the first form property and one for the second form:

CPE.wksA/CP/rootCP_A.wksA/CP/CP1.wksA/FO/FO1.FP/FP1.value

and

CPE.wksA/CP/rootCP_A.wksA/CP/CP2.wksA/FO/FO2.FP/FP2.value

Using a relative CPE, one BRC is sufficient as the same CPE (CPE.currentFP.value) is used to point out the two form properties.

Example 2:

Suppose that the Configuration Processes CP1 and CP2 are copied and linked (meaning: reused) in another root Configuration Process (5), in this case rootCP_B. If absolute CPE would have been used, the configuration engine would be incapable of determining a domain for form property (1) and (2) because of the fact that the CPE would point to an object unknown to the engine (when running rootCP_B, the engine does not know of rootCP_A because it is not a part of the rootCP_B model).

If however, relative CPE are used, the CPE will be correctly interpreted by the engine and everything will still work perfectly. Remember, the keywords that can be used in a relative CPE are

the following:

• rootCP: the root Configuration Process. Determined by the configuration.xml file.
• currentCP: the current Configuration Process
• currentForm: the current form
• currentFP: the current form property
• [current]: the current instance for a nested Configuration Process, form or sales breakdown line
• currentSBL: the current sales breakdown line
  Tip: In order to enhance reusability and to avoid frequent model changes, relative CPE should be privileged over absolute CPE.

Although you’ve seen that the workspace is a part of a full absolute CPE, in most circumstances you can easily ignore it. For instance, the absolute CPE for form property 1 as a complete representation:

CPE.wksA/CP/rootCP_A.wksA/CP/CP1.wksA/FO/FO1.FP/FP1.value

as well as an abbreviated representation:

CPE.CP/rootCP_A.CP/CP1.FO/FO1.FP/FP1.value

The abbreviated format is valid because of two important factors:

• First of all, the workspace for a certain object in the CPE structure will be inherited by the workspace of the parent object In the above example, the workspace of FO/FO1 is inherited from the parent object CP/CP1.
• Secondly, the “initial” workspace is the one specified as a parameter at run-time; the following parameter in the configuration.xml parameters is used for that purpose:

  <cam:Param cpe="CPE.Settings.Session.Workspace" value="wksA" />

However, if we look at the form property in form (3), it is clear that the abbreviated representation

CPE.CP/rootCP_A.CP/CP1.FO/FO3

cannot be used because it would, based on the run-time parameter, derive a non existing form:

CPE.wksA/CP/rootCP_A.wksA/CP/CP1.wksA/FO/FO3

Therefore, an explicit workspace has to be marked in the CPE:

CPE.CP/rootCP_A.CP/CP1.wksB/FO/FO3

In most cases, relative CPE are enough to address a certain object or attribute in the model. In these cases, you typically know the object or attribute to address, and you also know in which branch (or “part”) of the model the targeted object or attribute is located.

In some circumstances however, this is not so obvious. A typical situation is the following, in which independent modeling teams work on the business data as well as the business logic, but yet other teams work on the integration of these business rules in root Configuration Processes.

Example:

In the figure here above, 3 independent business teams work on parts of multiple Configuration Processes. The first business team works in workspace “wksB” and works on a reusable set of business data and rules, represented by “CP1”. The second business team works in workspace “wksB” on a set of business rules represented by “CP2”. The third business team works on a root Configuration Process model that will reuse the business rules configured by business teams 1 and 2.

Let’s suppose that a business rule BRC_FpAtt which has to be put in place models a relationship between form property FP1 (modeled by business team 1) and form property FP2 (modeled by business team 2). To be more specific, this business rule would define an attribute of FP1 in function of the value of FP2. In this case, both business teams know of each other, but they do not know about the final structure of the root Configuration Process. In other words, they do not know the exact final location of the business rules they have modeled.

In a normal situation, a relative CPE would take care of this situation: BRC_FpAtt would have a target CPE which is the following:

CPE.currentFP.attribute

and an input CPE which is the following:

CPE.rootCP.CP/CP2.FO/FO2.FP/FP2.value

However in this situation, a relative CPE cannot resolve this issue, because the depth of the target branch is not identical in the different root Configuration Processes. Indeed, in the Configuration Process rootCP_A, FP2 is contained in FO2, which is contained in CP2. However, in the Configuration Process rootCP_B, FP2 is contained in FO2 which is immediately contained in rootCP_B. Therefore the input CPE mentioned here above is no longer valid.

In order to resolve this situation, you can search for the input CPE, by using the following CPE form:

CPE.rootCP.nearest.FO/FO2.FP/FP2.value