Ansicht
Dokumentation

CL_CCMS_MONIDIR - Monitor-Objektdirectory

CL_CCMS_MONIDIR - Monitor-Objektdirectory

ROGBILLS - Synchronize billing plans   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

Die Klasse implementiert den Monitor-Objektpuffer. Sie verwaltet zur Zeit folgende Objekte:

Monitorsammlungen

Monitordefinitionen

Monitore

Die Monitore und die Monitordefinitionen hängen eng miteinander zusammen. Die Monitordefinition ist ein Teil des Monitors. Im gegenwertigen Modell ist sie allerdings als separates Objekt realisiert. Dadurch ist es möglich, eine Defintion mehrfach zu verändern, ohne den zugehörigen Monitor zu modifizieren.

Der Objektpuffer ist voll versioniert. Bei jeder Änderung an einem der registrierten Objekte wird automatisch eine neue Version dieses Objekts erstellt. Die internen Verzeichnisse werden entsprechend aktualisiert. Über die Methoden GET_VERSION_HANDLE, RESTORE_FROM_HANDLE und ACCEPT_CURRENT_STATE ist es möglich UnDo und ReDo Funktionen in einer aufrufenden Transaktion zu realisieren.

Die Monitorobjekte werden eindeutig durch eine Guid spezifiziert. Die verschiedenen Versionen eines Objekts (Versionen zu einer Guid) werden in dem so genannten Versioncotnainer der Guid gehalten. Ein Versionscontainer ist ein Objekt, das das Interface IF_CCMS_ALMONIVERSCONT implementiert. Der Puffer hält ausschließlich Directories über Versionscontainer. Die Abhängigkeiten werden grindsätzlich auf der Ebene der aktuellen Versionen definiert. Jeder Container kennt seine "aktuelle" Objektversion. Abhängige Objekte halten keine Referenzen direkt aufeinander, sondern Referenzen auf ihre Versionscontainer. Die Versionscontainer ermöglichen dadurch das Erhalten der Abhängigkeiten zwischen den verschiedenen Objekten über Änderungen hinweg, da bei einem UnDo oder ReDo nur die "aktuelle" Version jedes Containers geändert wird. Änderungen, die an einem der Objekte eine Reaktion oder Aktualisierung eines abhängigen Objekts erfordern (z.B. Löschen eines Monitors) lösen entsprechende Events aus, die von den abhängigen Objekten synchron abgearbeitet werden.

Instanzen der einzelnen Monitorobjekt-Klassen werden nur über die entsprechenden GET-Methoden erzeugt. Nur dadurch erfolgt eine korrekte Registrierung des neuen Objekts. Die GET-Methoden sind gleichzeitig Such- und Create-Methoden. Der Suchmodus wird dann aktiv, wenn mindestens einer der Eingabeparameter gefüllt wird. Dann versucht das System zunächst eine vorhandene Version des gesuchten Objekts im Puffer zu finden. Ist eine solche nicht da, wird ein neues Objekt mit der angegebenen Spezifikation erzeugt und registriert.

Message Handling

Die Klasse CL_CCMS_MONI_DIR bietet auch die Möglichkeit zum Aufbauen eines einfachen Message-Handlings. Dazu wird ein Message-Pool bereitgestellt, der Meldungen in BAPIRET2-Format halten kann. Jede Meldung im Pool kann durch die Guid des Objekts spezifiziert werden, bei dessen Prozessierung sie ausgegeben wurde. Wird bei Append_Message keine Guid mitgegeben, so handlet es sich um eine allgemeine Meldung, die die gesamte Prozessierung oder deren Umfeld (Customizing, Benutzerberechtigungen etc.) betrifft. Zu jeder Guid (initial oder nicht initial) kann es bis zu 256 Meldungen gleichzeitig geben. Durch die Methoden APPEND_MESSAGE, DELETE_MESSAGES und GET_MESSAGES können die Meldungen im Pool verwaltet und abgegriffen werden. Es ist sicherlich interessant und auch szenario-spezifisch, welche Meldungen, wann gezeigt und gelöscht werden. In manchen Szenarien ist es sogar notwendig eine wesentlich komplexere Meldungsverwaltung einzurichten, die Absänder, Empfänger, Lebensdauer und eventuell weitere Attribute einer Meldung voraussetzt. Eine solche Lösung ist in der aktuellen Klasse nicht realisiert. In der aktuellen Version des Laufzeit-APIs für Monitordefinitionen werden die Meldungen der einzelnen Komponenten im obigen Message-Pool ausgegeben und stehen dadurch dem Aufrufer der API zur Verfügung.

Beziehungen

Beispiel

Hinweise

Weiterführende Informationen






General Material Data   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 4428 Date: 20240328 Time: 094308     sap01-206 ( 129 ms )