Bedienkonzept

Nach Aufruf von Conigma CCM (Transaktion /GAL/CCM_RB) erscheint der sogenannte Repository Browser.

Ein Repository kapselt das gesamte kundenspezifischen Customizing sowie Stamm- und Bewegungsdaten. In der Regel sieht ein spezifischer Benutzer nur das für ihn freigegebene Repository. Technisch ist es jedoch möglich mehr als ein Repository in einer Conigma Instanz zu verwalten (z. B. zusätzlich ein Test-Repository oder unterschiedliche Repositories für verschiedene Kunden eines Service Providers). Konzeptionell besteht bei der Trennung in verschiedene Repositories eine gewisse Ähnlichkeit zum Konzept der Mandanten-Trennung in SAP Systemen.

Der Repository Browser ist die Hauptarbeitsansicht für alle Conigma Benutzer. Abhängig von der Benutzerrolle werden unterschiedliche Sichten mit einer spezifischen Detailtiefe dargestellt (s.a. Rollenspezifische Sichten ). Im linken Fenster des Split-Screens befindet sich die Baumstruktur aller für den Benutzer relevanten Objekte, in im rechten Fenster die jeweiligen Details für das aktuell ausgewählte Objekt. Oben stehende Abbildung zeigt die hierarchische Baumstruktur eines Benutzers mit relativ umfangreichen Rechten.

Verschiedene Objekttypen im Repository Browser 

Im folgenden werden einige der Objekte im Repository Browser näher erläutert. Je nach Repository und Customizing zeigt der Repository Browser unterschiedliche Icons für die jeweiligen Objekttypen. Darüber hinaus ist es vom Repository abhängig, welche Objekttypen überhaupt Verwendung finden (inkl. kundenspezifischer Objekttypen). Einen Überblick über Objekttypen eines Repositories kann über das Drop-down Menü Repository-Browser --> Legende oder den Button Legende angezeigt werden.

Button Legende:

	Repository
	ROP - Repository Object Provider oder View
	Release (geplant /geschlossen, in Entwicklung, in Wartung)
	Change Request
	SAP Workbench Transport (offen oder geschlossen)
	SAP Customizing Transport (offen oder geschlossen)

Aktionen, Statusübergänge und Genehmigungen 

Alle Aktionen in Conigma CCM werden über Kontext-Menüs gesteuert, welche durch einen Rechtsklick auf das betreffende Objekt im Baum aufgerufen werden. Die Menüfindung ist frei customizebar. Typische Parameter hierfür sind Objekttyp, Status eines Objekts oder seiner Unterobjekte, Rolle des Benutzers oder der Inhalt beliebiger Objektattribute (inkl. kundenspezifischer Felder).

Folgende Abbildung zeigt das Kontextmenü für einen Change, der in den nächsten Status Implemented weitergeschoben wird.

Grundsätzlich unterscheidet Conigma CCM zwischen zwei Typen von Statuswechseln sowie Genehmigungen.

Manueller Statuswechsel

Das Objekt wird manuell durch einen Benutzer in einen anderen Status verschoben. Das kann z. B. über das oben beschriebene Kontextmenü erfolgen.

Automatischer Statuswechsel

Das Objekt wechselt regelbasiert automatisch den Status.

Beispiel: Ein Change ist im Status Ready for Production während ein Zeit-gesteuerter Import Container die zugehörigen SAP Transporte in ein Produktivsystem importiert. Nach Abschluss des Imports wird der Change abhängig vom Returncode des Imports (z. B. Returncode <= 4 oder Returncode > 4) automatisch von Conigma in den Status In Production oder in den Status Import Error verschoben. Der neue Status wird immer nach einem Neuaufbau eines (Teil-)Baums angezeigt. 

	Button: Alles aktualisieren
	Button: Knoten aktualisieren

Auch eine vollständige Genehmigung durch alle erforderlichen Rollen kann zu einem automatischen Statuswechsel führen.

Genehmigung

Genehmigungen unterscheiden sich durch unbestimmte zeitliche Abfolgen von Statuswechseln. Im Statusmodel wird z. B. definiert, dass ein Change vom Status In Development über Implemented  in den Status Qualitiy Assurance und wieder zurück nach In Development wechseln kann. Sind für einen Change in einem bestimmten Status zwei Genehmigungen erforderlich, dann ist im Normalfall die Reihenfolge der Genehmigunen nicht vorher definiert (Ausnahmen können im Customizing hinterlegt werden). Ein typisches Beispiel hierfür ist eine Genehmigung eines Changes durch einen Fachtester und eine technische Genehmigung, bei der die Reihenfolge der beiden Testtypen keine Rolle spielt.
In der nachfolgenden Abbildung genehmigt der Benutzer einen Change durch die Auswahl von Production approval by tester (=Genehmigung). Alternativ könnte der Benutzer für den Fehlerfall den Change durch die Auswahl von Back to "In Development"  (=Statuswechsel) auch in die Entwicklung zurückgeben.