Creating a Central Repository 

Use

A central CCMS system repository contains data from more than one system. Setting up a central repository has the advantage that a single repository can display data from multiple R/3 Systems and other components.

To create a central repository, you must register other CCMS system repositories explicitly with the central repository. A central repository is not created automatically.

Registering a system with a central repository unifies the two repositories. This means that:

Technically, unifying the repositories means that they share a common namespace for the objects and facts that are represented in the repositories.

With Release 4.6C, you should create a central repository if either of the following applies:

Some components that use the system repository take care of their own information requirements, without requiring you to unify system repositories. Such components deposit the information that they need directly from the systems in which the data originates, into the system repository on your workplace server. You must unify repositories only if the documentation of a component requires that you do so. Unifying repositories will not affect the operation of components that have stored data on their own in a 'central' repository.

Prerequisites

Procedure

  1. Log on to a system that is to be registered with the central repository. You will need administrator authorizations (S_RZL_ADM, S_RFC, S_BTCH_JOB with Release authorization).
  2. Choose CCMS ® Configuration ® Alert monitor. Alternatively, call Transaction RZ21.
  3. Choose Technical infrastructure ® System repository ® Determine repository role.
  4. On the screen that follows, choose Managed system and enter the name of the central system.

Optionally, enter any management information that you wish to record on this system. You can separately save this information, as well as the system-role setting.

  1. Choose Goto ® RFC Destination.
  2. On the screen that follows, fill out the data required for creating an RFC destination for the subordinate repository to use to reach the central system, and for destinations in the central system back to this system. These destinations are created automatically for you under the standard names CCMS_CSM_CEN_DEST_<central system name> in the registering system, and CCMS_CSM_MNT_DEST_<registering system> and CCMS_CSM_QRY_DEST_<registering system> in the central system.

The CEN_DEST destination in the registering system has a fixed user (CSMREG) and also requires a password. This destination represents a security risk if CSMREG's authorizations are not limited to those described in Creating the CSMREG User. Normally, the registering system should be set up to update the central repository automatically at periodic intervals. In this case, the CEN_DEST destination must be active and usable. For maximum security, however, you can disable the destination by deleting the password. This action also disables any automatic periodic update of the central system repository. You must then instead update the central system repository manually.

The MNT_DEST destination on the central system is a standard destination for access by dialog users to the registered system; the QRY_DEST is intended for automatic access by the central repository to the subordinate repository for purposes of querying data. Neither destination is saved with a user ID and password, and so neither represents a security risk. The QRY_DEST is not used in Release 4.6C.

In Release 4.6C, you must create the MNT_DEST and QRY_DEST destinations yourself in the central system.

  1. Choose Enter to return to the main registration screen.
  1. Choose Enter to carry out the registration.

Result

The registration procedure creates the local RFC destination that is needed, and schedules a background job called CCMS_REPOSITORY_RECONCILIATION to run under your authorizations. This job reconciles the data in the repositories of the subordinate and central systems and unifies the repositories. The registration is complete when the job has finished running. The transaction does not wait for this event. In all but extremely large systems, the reconciliation job will run to finish in under 5 minutes.

After the reconciliation job has finished, data on the subordinate system is available to you in the central system, for example through the repository browser.

In Release 4.6C, the reconciliation job is scheduled to run only once. If you wish, you can manually reschedule it with automatic periodic restart in the background management transaction (Transaction SM37). Depending on the frequency with which you make reconfigurations on the subordinate system (new clients, new application servers, new RFC destinations), you may wish to schedule a daily or a weekly repetition of the job. The job need not run more frequently than you update the contents of the local system repository.

Note that the system repository does not let you change the roles of the central repository, nor of registered subordinate repositories. Should you wish to change the central repository or have a registered system report to another central repository, you must purge central system repository and each of the repositories that has been registered with the central repository. See Checking for Repository Processing Errors for more information on purging and re-filling the repository.