CL_CCMS_MONIDIR - Monitoring Object Directory

General Data in Customer Master   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.

Functionality

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

Monitor sets

Monitor definitions

Monitors

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 versionof this object is automatically created. The internal directories are updated correspondingly. Usingthe 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 (Versionsfor a GUID) are held in the version container of the GUID. A version container is an object that implementsthe interface IF_CCMS_ALMONIVERSCONT. The buffer only holds directories using version containers. Thedependencies 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 theirversion containers. The version containers therefore allow the dependencies between the various objectsto be maintained over changes, as only the "current" version of each container is changed with an UnDoor 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 createmethods. 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 bespecified using the GUID of the object during the processing of which the message was displayed. Ifno GUID is provided at Append_Message, it isa general message that affects the entire processing orits environmen (Customizing, user authorizations, and so on). There can be up to 256 messages concurrentlyfor each GUID (initial or non-initial). The messages can be managed and collected using the methodsAPPEND_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 upa significantly complexer message management that presupposes the sender, recipient, lifetime and perhapsother attributes of a message. A solution of this type is not realized in the current class. In thecurrent 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.

Relationships

Example

Notes

Further information

TXBHW - Original Tax Base Amount in Local Currency   TXBHW - Original Tax Base Amount in Local Currency  
This documentation is copyright by SAP AG.


Length: 3681 Date: 20120526 Time: 095155     triton ( 243 ms )