/ORM/CL_ORM_PERSISTENT_OBJECT - Persistent object base class

RFUMSV00 - Advance Return for Tax on Sales/Purchases   TXBHW - Original Tax Base Amount in Local Currency  
This documentation is copyright by SAP AG.

Basics

Transient and regular persistent objects

Basically there are two types of classes that inherit from /ORM/CL_ORM_PERSISTENT_OBJECT:

1. Classes that use the persistence manager for caching loaded objects and as manager for the data storage process.
2. Classes that can't be managed by the persistence manager because they belong closely to another class like /ORM/CL_ORM_LONGTEXT and /ORM/CL_ORM_DOCUMENT. These objects are called 'transient' objects.

The following explanations will provide you with information, how classes that inherit from /ORM/ORM_PERSISTENT_OBJECT can and should take advantage of this class.

Non transient childs should care about all methods of the interface /ORM/IF_ORM_PERSISTENT_OBJECT becausethis interface is used by the persistence manager. Furthermore they have to care for their related transient childs and call their appropriate methods especially in the following cases:

• /ORM/IF_ORM_PERSISTENT_OBJECT~SAVE

• /ORM/IF_ORM_PERSISTENT_OBJECT~ROLLBACK

• SET_INVALID

• SET_DELETED

For more information see the interface documentation.

States of an persistent object

A persistent object always has a specific state, that in most cases is updated by the class /ORM/ORM_PERSISTENT_OBJECT itself. It can be retrieved by calling "GET_STATUS". The following states are possible:

• New (GC_STATUS_NEW): The object has just been created but not been saved yet. This state is automatically set by the constructor of the persistent object class.

• Sync (GC_STATUS_SYNC): The object is in a synchronized state to it's represantation in the database. Automatically set by the constructor or the "SYNCHED" method.

• Changed (GC_STATUS_CHANGED): The object is no longer synchronized to it's database represantation.It has already been changed and the database needs to be updated during the next "save" processing.
  Take care: As the persistent object doesn't know, when data on a inheriting class is changed, it hasto be noticed in that case. Therefore always call "CHANGED" on the persistent object when data has been changed on a child object.

• Edit (GC_STATUS_EDIT): The object is in any kind of edit mode.

• Deleted (GC_STATUS_DELETED): The object shall be deleted in the next "SAVE" process.

• Invalid (GC_STATUS_INVALID): The object is declared as "invalid". This means, that the current instanceshall no longer be used and may no longer be edited/ saved. A new instance should be read from the database.

• In update (GC_STATUS_INUPD): This status is currently not used.

Edit mode

To ensure consistency during the change of objects, the following edit-concept is foreseen on the persistent object class.

Before any persistent object may be changed, it should be set into edit mode. This can be done using the method "SET_EDIT". There are three kinds of edit modes, that can be set:

1. External (GC_EMODE_EXTERNAL, Default)
2. Internal (GC_EMODE_INTERNAL)
3. Internal exclusive (GC_EMODE_INTERNAL_X)

Whenever data is to be changed on persistent object by the user and the object presentation in the UIis set to edit mode, the external edit mode type has to be used. Therefore by checking the edit mode, the UI can always find out, if the object is in change mode on UI level (external).

If the object data is automatically changed by the system, always only the internal edit mode shall be requested. Internal and external edit modes can be requested independently of each other.

This is different with the exclusive internal edit mode:

In some cases it might be necessary to save data changed by the system before the user may access theobject again. In these cases edit mode internal exclusive should be set. Objects with this status set may no more be switched into external edit mode unless they are saved again.

The current edit mode of a persistent object can be retrieved using the method "GET_EDIT_MODE". To simplycheck if a persistent object may currently be set into a specific edit mode the method "IS_EDIT_POSSIBLE" may be called.

SET_EDIT is a protected method to ensure, that this method is never called directly from outside theclass. There should always be a separate method provided to set a persistent object into edit mode.As default such a message should be called "EDIT". In this method it should also be guaranteed, thatthe object is explicitly locked by calling the method "LOCK" from the "EDIT" method, or that it is alreadyimplicitly locked by a referred risk or activity object. As an example classes like /ORM/CL_ORM_RISK_DATAor /ORM/CL_ORM_RISK_RESPONSE may only be set into edit mode from the /ORM/CL_ORM_RISK object, if the current risk object also has already been set into edit mode and therefore is locked.

Changing data on persistent objects

Whenever data on a persistent object has been changed, this should be flagged by calling the method"CHANGED". This method sets the status of the persistent object to "CHANGED", if it is not already set to "NEW" or "CHANGED".

Declaring persistent objects as invalid

If changes were made on a persistent object, but these changes shall be discarded, "SET_INVALID" hasto be called on the persistent object. As a result the persistent object is deregistered from the persistencemanager and will no longer be saved. The status of the instance is set to "invalid" and therefore it may no longer be edited any more.

This method has to be redefined by inheriting classes. In this redefinition all dependent (transient) objects have also to be set "invalid".

Requiring objects to be deleted

To delete a peristent object the method "SET_DELETED" has to be called. This sets the status of theobject to "deleted" and during the next "SAVE" process it has to be deleted from the database. To ensurethis, the "SAVE" method on /ORM/IF_ORM_PERSISTENT_OBJECT has to be implemented accordingly. -> See inferface documentation for details.

This method has to be redefined by inheriting classes. In this redefinition all dependent (transient) objects have also to be set "deleted".

CPI1466 during Backup   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.


Length: 6518 Date: 20120526 Time: 070107     triton ( 257 ms )