Operating concept

After calling Conigma CCM (transaction /GAL/CCM_RB), the Repository Browser appears.

A repository encapsulates all customer-specific Customizing and master and transaction data. As a rule, a specific user only sees the repository released for him or her. Technically, however, it is possible to manage more than one repository in a Conigma instance (e.g. additionally a test repository or different repositories for different customers of a service provider). In conceptual terms, the separation into different repositories is somewhat similar to the concept of client separation in SAP systems.

The Repository Browser is the main working view for all Conigma users. Depending on the user role, different views are displayed with a specific level of detail (see also Role-Specific Views). The left window of the split screen contains the tree structure of all objects relevant for the user, the right window contains the respective details for the currently selected object. The figure above shows the hierarchical tree structure of a user with relatively extensive rights.

Different Object Types in the Repository Browser 

Some of the objects in the Repository Browser are explained in more detail below. Depending on the Repository and Customizing, the Repository Browser displays different icons for the respective object types. The repository also determines which object types are used (including customer-specific object types). For an overview of object types in a repository, use the drop-down menu Repository Browser → Legend or the button Legend.

Actions, status transitions and approvals 

All actions in Conigma CCM are controlled by context menus, which are called by right-clicking on the object in the tree. You can customize menu determination as required. Typical parameters for this are object type, status of an object or its sub-objects, user role or the content of any object attributes (including customer-specific fields).

The following figure shows the context menu for a Change, which is moved to the next status Implemented.

Basically, Conigma CCM distinguishes between two types of status changes and approvals.

Manual status change
The object is manually moved to a different status by a user. This can be done, for example, using the context menu described above.

Automatic status changeThe object automatically changes status based on rules.Example: A Change has the status Ready for Production while a time-controlled import container imports the corresponding SAP transports into a production system. After the import is completed, the Change is automatically set by Conigma to the status In Production or to the status Import Error. The new status is always displayed after a (partial) tree reconstruction (alternatively, click Buton Refresh all or Refresh node). Complete approval by all required roles can also lead to an automatic status change.

Approval
Approvals differ from status changes by indefinite time sequences. In the status model, for example, you define that a change can move from the status In Development via status Implemented to the status Quality Assurance and then back to In Development. If two approvals are required for a Change in a particular status, the sequence of approvals is not normally defined beforehand (exceptions can be defined in Customizing). A typical example of this is the approval of a Change by a technical tester and a technical approval in which the sequence of the two test types is irrelevant.
In the following graphic, the user approves a Change by selecting Production approval by tester (=Approval). Alternatively, in the event of an error, the user could reject th Change by selecting Back to "In Development" (=status change).