PMC distributor procedure (OP)

The procedures for the update distributor to set up the PMC administration.

The subsequent sections provide a detailed explanation of the procedure.

The very first step in the distributor set-up procedure is to define the PMC parameters.

For details, refer to the Parameters (ttpmc0100s000) session.

You must define a base VRC before you can create and link solutions, collections, patches, and Feature Packs to the base VRC.

A base VRC is an administrative identifier for a software product and is not a physical VRC, but must always be connected to a physical VRC, which contains the software components.

The PMC distributor should connect a base VRC to an export VRC, the PMC recipient should connect a base VRC to an update VRC.

For details, refer to the Base VRC's (ttpmc0110m000) session.

Base VRC combinations are required to define relations between base VRCs.

Any base VRC must always be a member of a base VRC combination, even if no relations to other base VRCs exist.

If you have not linked a base VRC to a base VRC combination, you cannot create updates.

The following example shows a base VRC combination with two base VRCs with a relation:

For details refer to the Base VRC Combinations (ttpmc0111m000) session.

Optionally, view the collection history. To view the collection history, use the Maintenance History (ttpmc1560m000) session.

Optionally, view the patch history. You can view the patch history in the Maintenance History (ttpmc1560m000) session.

Optionally, view the Feature Pack history. You can view the Feature Pack history in the Maintenance History (ttpmc1560m000) session.

This section describes various aspects applicable to the Feature Pack development and build process.

The subsequent setup assumes that the distributor side includes a combined development/maintenance environment. This combined environment supports the maintenance of already released Feature Packs, development of a new Feature Pack, and the physical creation of solutions and Feature Packs.

The following diagrams illustrate the results over time:

As soon as the initial master product, B61_a, which for the sake of simplicity is referred to simply as Feature Pack 0 in the remainder of this document, is released, the maintenance starts for B61_a in the maintenance VRC B61M_a. The development of the new Feature Pack is carried out in B61D_a1. All fixes in B61M_a are ported to B61D_a1. In the PMC registry of B61D_a1, these fixes are registered as obsolete solutions. After B61D_a1 is frozen, a final Feature Pack is created for the Feature Pack and installed in the same environment to enable you to perform maintenance on the Feature Pack.

Currently, you can maintain B61M_a and B61M_a1, Feature Pack 0 and Feature Pack 1, in parallel. You must port bug fixes that are created for Feature Pack 0 between the freeze moment and the time of installation of Feature Pack 1 first. Feature Pack 2, B61D_a2, is currently in development.

You can repeat this cycle unlimited times for each new Feature Pack.

The setup becomes a bit more complex if derived products such as localizations or extensions enter the scope.

Suppose you must create a localization on top of Feature Pack 1.

A new VRC is created on top of Feature Pack 1, B61D_a1_loc1:

The localization is built on top of the standard Feature Pack and is delivered as a Feature Pack in PMC. Therefore, you must not create master media for derived products. As soon as Feature Pack 0 for the localization is available, the Feature Pack is installed in the maintenance VRC, B61M_a1_loc1.

The localization is also copied to a development VRC B61D_a2_loc1:

The first action that you must perform is to merge all bug-fixes of the standard VRC B61M_a1 into the localization maintenance VRC B61M_a1_loc1 and to create PMC solutions for the localization.

In addition, you must merge the B61D_a2 functional enhancements to B61D_a2_loc1.

From this moment on, the localization follows the same Feature Pack cycle as the standard software.

Repeat the same approach for Feature Pack 2.

The physical Feature Packs for the standard software and the localization are created and installed in a separate VRC tree B61_a2 and B61L_a2_loc1. New maintenance and development VRCs are created.

The maintenance and development VRC for the localization are populated with the components from the installed Feature Pack B61L_a2_loc1.

This section describes various aspects relevant to the development and maintenance process of customizations.

Customizations are, in most cases, built by organizations other than the producer of the related parent standard product.

The vendor who builds customizations installs the standard parent product in an update VRC.

The customization is built on top of the installed parent standard product.

This situation is specific in the sense that PMC serves both as recipient and distributor in such a development environment.

In some cases, the vendor of the standard parent product applies patches rather than Feature Packs as a method to provide incremental updates to the market. As opposed to Feature Packs, patches are not cumulative. The installation of a patch in an update VRC requires that you also install all preceding update VRCs in the same update VRC. This issue has consequences for the VRC setup at the distributor.

In most cases, you use a single environment to develop and to maintain multiple customizations. You build every customization on a specific patch. In addition, you must periodically upgrade existing customizations to a newer patch. As a result, you must have multiple Feature Packs of the standard parent product installed in separate VRCs. The following method is the best way to achieve this:

Install patch 1 of the standard parent product in update VRC P10U_a1_stnd. When patch 2 is available, install the patch in a new, separate update VRC P10U_a2_stnd, which is derived from P10U_a1_stnd. Patch 2 will have patch 1 as a prerequisite. You cannot install patch 2 in the new update VRC P10U_a2_stnd because patch 1 is not installed in this new update VRC. Therefore, run the Copy Solution Registry to Derived Update VRC (ttpmc2290m000) session and copy the registry of update VRC P10_a1_stnd into P10_a2_stnd. After you perform this step, you can install patch 2 directly in the P10U_a2_stnd update VRC. You can then repeat this same process for subsequent patches. The P10U_a<n>_stnd VRCs must only contain net patches. No additional solutions must be installed in these VRCs that do not belong to the relevant patch.

At this point, you have a VRC tree in which the net patches are installed in separate VRCs. In general, customizations are developed based on a net patch. However, in some cases customizations are not derived from a net patch, or a customer might want to install parent standard product solutions that have components which overlap with the customization. As a result, the customer must have the option to derive the customization VRC from any possible maintenance stage of the parent standard product. The P10U_a<n>_std update VRCs are introduced to achieve this. For every customization an intermediate VRC layer is introduced in which standard solutions can be installed that do not belong to the underlying patch. You can again use the Copy Solution Registry to Derived Update VRC (ttpmc2290m000) session to populate the PMC registry for the P10U_a<n>_std update VRCs.

The customization VRCs P10C_a_cusA, P10C_a_cusB, and P10C_a_cusC represent various customizations that are derived from various patches. Suppose customization P10C_a_cusA is developed based on the net patch 1. During development of the customization, the P10U_a1_stdA VRC will still be empty. After the customization is released and the customer installs the customization, the customer might want to install solutions of the standard parent product that also require an update of the customization. In this case, the customization vendor can install the solutions of the parent standard product in the P10U_a1_stdA VRC, port the solution to the P10C_a_cusA and provide a corresponding solution for the customization VRC. Installation of solutions in the P10U_a1_stdA VRC will only have impact on the P10C_a_cusA customization and will not impact the other customizations in the environment.

To a certain extent, the system setup is comparable to the setup described for localizations and extensions described in the section Feature Pack development. The main difference lies in the fact that Feature Packs for the parent standard product are now installed in an update VRC by means of PMC. Another differentiator is the fact that Feature Packs are cumulative, which means that Feature Packs also contain all preceding Feature Packs. To upgrade a customization to a higher Feature Pack level, having a VRC available that only contains the net changes of a Feature Pack of the standard parent product can be useful. Suppose you must create a customization on top of Feature Pack 1 for a parent standard product. Feature Pack 1 is installed in the B61U_a1_stnd update VRC and a new VRC B61W_a1_cusA is developed on top of the Feature Pack.

The customization is built on top of the standard Feature Pack and will be delivered as a Feature Pack in PMC, so no master media must be created for the customization. As soon as Feature Pack 0 for the customization is available, the Feature Pack is installed in the maintenance VRC B61M_a1_cusA.

Solutions for Feature Pack 1 of the parent standard product will be installed in the B61U_a1_stnd VRC. When you scan solutions for the parent standard product, you can also print a customization report. The customization report provides an overview of which components must be updated in the B61M_a1_cusA VRC. As soon as you install the standard solution, you can merge the changes to the B61M_a1_cusA VRC and create a corresponding PMC solution for the customization.

The approach for subsequent Feature Packs is as follows: Install Feature Pack 2 for the parent standard product in the B61U_a2_stnd VRC, which is derived from B61_a VRC. Copy the contents of the B61M_a1_cusA VRC to the B61W_a2_cusA VRC. As a result, all maintenance changes you create on top of Feature Pack 0 of the customization until the moment of the copy action immediately become available in the B61W_a2_cusA VRC. After the copy, you must also port all maintenance changes in the B61M_a1_cusA VRC to the B61W_a2_cusA VRC. Feature Pack 2 for the standard product is cumulative, which means that all changes implemented in Feature Pack 1 are also present in Feature Pack 2. Therefore, you must create an overview of all components that were changed in Feature Pack 2 as compared to Feature Pack 1, and these components also must be present in the customization. To achieve this, you can use the Compare Package VRC's (ttadv6450m000) session. In this session, specify values in the following fields as follows:

Using these settings enable you to create a net overview of customized components that must be updated to be compatible with the Feature Pack 2 of the parent standard product. You can then merge all changes implemented in Feature Pack 2 of the standard product from the B61U_2_stnd VRC into the B61W_a2_cusA VRC. You can then build Feature Pack 1 for the customization, based on the contents of the B61D_a2_cusA VRC.

You can repeat this procedure for an unlimited number of Feature Packs. In addition, you can develop and maintain multiple customizations in parallel on various levels of the standard parent product.

If multiple customization VRCs are derived from, for example, the B61U_a1_stnd VRC, then for every customization, an additional update VRC layer B61U_a1_std is required between the customization VRC and the B61U_a2_stnd VRC. You can use the additional update VRC layer to install additional solutions of the parent product, which you must port to the customization. You must use the Copy Solution Registry to Derived Update VRC (ttpmc2290m000) session to populate the PMC registry for the B61U_a1_std update VRCs. Installation of additional solutions in the B61U_a1_stdA update VRC only impacts the B61M_a_cusA VRC and does not influence the B61M_a1_cusB VRC.

Individual solutions, patches and/or Feature Packs for customizations must have dependencies to corresponding updates of the parent standard product. Not having these types of dependencies can result in runtime compatibility problems if only a solution for the standard parent product is installed, while installation of an update for the customizations was also required.

The best way to establish these dependencies is to define co-requisite dependencies between the updates of the parent product and the corresponding updates for the customized product. The co-requisite dependencies are generated automatically if the customization uses the same solution numbers that were also used in the parent standard product. Of course this method only works if the base VRC of the customization, together with the base VRC of the standard parent product, are part of the same base VRC combination at the distributor side. At the recipient side, the update VRCs for the parent standard product and the customization must also be included in a VRC combination.

The co-requisite relationship will only be in one direction: from the customization to the standard parent product. This one-directional co-requisite makes it impossible to install a solution for the customization without simultaneously installing the corresponding standard solution for the parent product. However, as long as you have not scanned the customized solution, you can still install a solution for the standard parent product without simultaneously installing the corresponding solution of the customization. This can result in run time compatibility problems. The customization report solves this problem. When you check standard solutions in a customized environment, you can optionally print a customization report, which signals customized components and informs the recipient that, together with the standard solution, an update for the customization must also be installed.

The facts described in the sections Rules to upgrade derived products and Building Feature Packs and the Infor Installation Wizard are also applicable to the development and maintenance of customizations.