SAP® Documentation

Single view

CL_CCMS_MONIDIR - Monitoring Object Directory

Fill RESBD Structure from EBP Component Structure   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.
SAP E-Book


This class implements the monitoring objekt buffer. It currently manages the following objects:

Monitor sets

Monitor definitions


The monitors and monitor definitions are closely connected. The monitor definition is part of the monitor. In the current model, it is, however, realized as a separate object. In this way, it is possible to change a definition several times without modifying the associated monitor.

The object buffer is fully versioned. Every time one of the registered objects is changed, a new version of this object is automatically created. The internal directories are updated correspondingly. Using the methods GET_VERSION_HANDLE, RESTORE_FROM_HANDLE, and ACCEPT_CURRENT_STATE, you can realize UnDo and ReDo functions in a calling transaction.

The monitoring objects are uniquely specified by a GUID. The different versions of an object (Versions for a GUID) are held in the version container of the GUID. A version container is an object that implements the interface IF_CCMS_ALMONIVERSCONT. The buffer only holds directories using version containers. The dependencies are basically defined at the level of the current versions. Every container knows its "current" object version. Dependent objects do not hold references directly to each other, but references to their version containers. The version containers therefore allow the dependencies between the various objects to be maintained over changes, as only the "current" version of each container is changed with an UnDo or a ReDo. Changes to one of the objects that require a reaction or update of a dependent object (such as deleting a monitor) trigger corresponding events that are synchronously processed by the dependent objects.

Instances of the individual monitoring object classes are only created using the appropriate GET methods. Only in this way is the new object correctly registered. The GET methods are both search and create methods. The search mode is active if at least one of the input parameters is filled. In this case, the system first tries to find an existing version of the object in the buffer. If there is no existing version, a new object with the specified specification is created and registered.

Message Handling

The class CL_CCMS_MONI_DIR also provides the option of creating a simple message handling. To do this, a message pool is provided that can hold messages in BAPIRET2 format. Each message in the pool can be specified using the GUID of the object during the processing of which the message was displayed. If no GUID is provided at Append_Message, it isa general message that affects the entire processing or its environmen (Customizing, user authorizations, and so on). There can be up to 256 messages concurrently for each GUID (initial or non-initial). The messages can be managed and collected using the methods APPEND_MESSAGE, DELETE_MESSAGES, and GET_MESSAGES. It is certainly of interest,and scenario-specific, which messages are displayed and deleted when. In certain scenarios, it is even necessary to set up a significantly complexer message management that presupposes the sender, recipient, lifetime and perhaps other attributes of a message. A solution of this type is not realized in the current class. In the current version of the runtime API for monitor definitioins, the messages of the individual components in the above message pool are displayed and are therfore available to the caller of the API.




Further information

CL_GUI_FRONTEND_SERVICES - Frontend Services   General Data in Customer Master  
This documentation is copyright by SAP AG.

Length: 3851 Date: 20190626 Time: 230550     sap01-206 ( 36 ms )

Our Service

Looking for Support? Questions?




Leave us your contact details and we will call you back. Panels marked with * are mandatory.