Version structure

The version of the business models and their model items are not related to the different versions, releases, and customisation of the different LN software packages.

To create reference models and project models, use links to model items, such as business functions and business processes, which have been defined in the repository in a certain version. Therefore, to change the description of a business function referred to as One, which is used in one reference model, you can only do this in the repository.

This means that if this business function is also used in a number of other reference models or project models, and the description is changed in the repository, this change will be automatically implemented in all the reference and project models of the same version.

Beispiel

If you change One into Ten, this change is implemented in both reference models.

This is a problem if you only want the change to be implemented in reference model 1. The dotted lines indicate that the descriptions of business functions in reference and project models are retrieved from the repository.

Changing the repository without version management

This problem is solved through version management. In the example shown in, you must define a new version derived from the version that was being used.

When you define this version, the model items of the previous version, including the repositories, reference models, and project models, can be used, although they are not physical copies and only available through a link.

In the example shown, the descriptions and places of the business functions in the repository of Version 2 are retrieved from the repository of Version 1.

The descriptions of the business functions in both reference models of Version 2 are retrieved from the repository of Version 2. Therefore, they are indirectly retrieved from Version 1 because of the derived-from structure.

The place of the business functions in the reference models of Version 2 are derived from the reference models of Version 1. Therefore, nothing is stored in Version 2, except for the link to Version 1.

This situation is displayed below. The white circles in the repository of Version 2 indicate they cannot be modified, because they are only physically available in Version 1.

Creating a derived-from version.

After a new version has been created, you can change the description of the business function. In this example, the description One in Reference Model 1 of Version 2 must be changed into Ten.

You can only change model items if they belong to your current modeling version. Because the description of a business function used in Version 2 must be changed, your current modeling version must be set to Version 2.

To do this, use the Current Modeling Version of Users (tgbrg1510m000) session, as described in the Repository chapter.

• Before description One can be changed to Ten, you must copy the business function to the current modeling version, which is Version 2, because the business function cannot be changed in Version 1.
• Copying a model item to your current modeling version means you place a physical copy of the business function in the repository of Version 2. You also break the link with the business function in Version 1.
• When you have changed the description in the business function repository of Version 2 to Ten, the business function in both reference models of Version 2 will be automatically changed.

This is because both models use the model items as defined in the repository of Version 2.

The advantage is clarified in Figure 2.11, which indicates that Reference Model 2 must not be used in Version 2, but in Version 1.

Figure 2.11 shows the situation after you have copied the description to the current version, and after you have changed the description in the repository.

Business function Ten, or One before the description was changed, is now physically available in Version 2.

This procedure also applies to components such as business processes, or reference models and project models. This places the creation of a new version in a broader perspective, because the model items do not have to be created from scratch. Instead, you only need to implement and store the changes.

You must indicate whether the authorization mechanism must be applied after you have created a new version.

If you choose for the authorization mechanism to be applied, you are automatically authorized for that version.

You can also set version authorizations by using one or more of the three sessions discussed below.

If no LN user has been authorized for a specific version, all LN users can use that version.

To quickly authorize one or more LN users for all versions by only specifying their LN user logons, use the User Authorization for all Versions (tgbrg1140m000) session. When an LN user is included in this session, they can access all versions, including those created after the LN user was inserted in the session.

If you do not authorize a single LN user for a version, all LN users can use that version.

However, setting authorizations using this session does not mean you have authorized a user for a version; if only this session is used to implicitly authorize some LN users for a certain version, all other LN users can still use that version.

To authorize a specific LN user for one or more versions, use the Version Authorization by User (tgbrg1150m000) session. If you only specify one LN user, all other LN users cannot use the specified versions.

To revalidate the authorization to use a particular version initially purchased from Infor, use the Revalidate Licensed Version (tgbrg1247m000) session.

After the expiration date of a license code, a new license code must be acquired from the manufacturer.