SAP API CLASSIFICATION ABAP Statements



Get Example source ABAP code based on a different SAP table
  


VERSION 5 OUT
• TX_CONTRACT ABAP_INTERFACE
• IF_ABAP_TX_COMPLETE ABAP_INTERFACE
• IF_ABAP_TX_FUNCTIONAL ABAP_INTERFACE
• IF_ABAP_TX_READ ABAP_INTERFACE
• IF_ABAP_TX_MODIFY ABAP_INTERFACE
• IF_ABAP_TX_SAVE ABAP_INTERFACE
• IF_ABAP_TX_SURFACE ABAP_INTERFACE
• IF_ABAP_TX_WEAK ABAP_INTERFACE

API Classifications to Ensure Transactional Consistency
Released APIs can contain classifications for methods to ensure transactional consistency of custom extensions within the SAP LUW. The classifications are used to control that functionality encapsulated by the APIs is only used in specific contexts where allowed, for example, for enforcing the RAP BO contract in the context of RAP.
A violation can result in an unconditional runtime error. Typical violations can result from restrictive contexts. In the context of RAP, for example, strict mode version 2 is specified in a behavior definition or an artifact is marked for the use in the ABAP for Cloud Development.
The classifications are typically included as type definitions in interfaces, classes (in a local class include for all public and protected methods) and function modules (in the top include of the function group).
The structured type tx_contract contains components whose names are the names of those methods that are to be classified. tx_contract is a predefined name. The individual components are typed with an enumerated type (ty) available in the IF_ABAP_TX_* interfaces. When used as shown below, the ABAP compiler interprets the methods as classified. TYPES: BEGIN OF tx_contract,
method_a TYPE if_abap_tx_read=>ty,
method_b TYPE if_abap_tx_modify=>ty,
...
END OF tx_contract.
The following table shows the classifications and what is allowed and what not: ClassificationAllowedNot Allowed
IF_ABAP_TX_FUNCTIONAL AB_SQL SELECT , lbr calling APIs tagged with IF_ABAP_TX_FUNCTIONAL ABAP_EML requests, lbr locks, lbr authorization checks, lbr database modifying operations ( standard connection), lbr calling update function modules , lbr calling remote-enabled function modules, lbr PERFORM, ON COMMIT, ROLLBACK, lbrCOMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES, ROLLBACK ENTITIES, lbr implicit and explicit database commits, lbr calling APIs tagged with IF_ABAP_TX_SAVE, IF_ABAP_TX_MODIFY, IF_ABAP_TX_READ and IF_ABAP_TX_SURFACE
IF_ABAP_TX_READ ABAP_EML read and permission requests, lbr AB_SQL SELECT, lbr implicit database commits, lbr calling APIs tagged with IF_ABAP_TX_FUNCTIONAL and IF_ABAP_TX_READ ABAP_EML modify requests, lbr ABAP_EML requests in local mode, lbr ABAP_EML key conversion, lbrlocks , lbr authorization checks, lbr database modifying operations ( standard connection), lbr calling update function modules , lbr calling remote-enabled function modules, lbr PERFORM, ON COMMIT, ROLLBACK, lbr COMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES, ROLLBACK ENTITIES, lbr explicit database commits, lbr calling APIs tagged with IF_ABAP_TX_SAVE, IF_ABAP_TX_MODIFY and IF_ABAP_TX_SURFACE
IF_ABAP_TX_MODIFY ABAP_EML read, modify, permission and lock requests, lbr AB_SQL SELECT, locks, lbr authorization checks, lbr implicit database commits, lbr calling APIs tagged with IF_ABAP_TX_MODIFY, IF_ABAP_TX_FUNCTIONAL and IF_ABAP_TX_READ ABAP_EML requests in local mode, lbr ABAP_EML key conversion, lbr database modifying operations (standard connection), lbr calling update function modules, lbr calling remote-enabled function modules, lbr PERFORM, ON COMMIT, ROLLBACK, lbr COMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES, ROLLBACK ENTITIES, lbr explicit database commits, lbr calling APIs tagged with IF_ABAP_TX_SAVE and IF_ABAP_TX_SURFACE
IF_ABAP_TX_SAVE ABAP_EML RAISE ENTITY EVENT, lbr ABAP_EML read requests, lbr ABAP_EML key conversion, lbr AB_SQL SELECT, lbr locks, lbr database modifying operations ( standard connection), lbr calling update function modules , lbr calling remote-enabled function modules, lbr PERFORM, ON COMMIT, ROLLBACK, lbr calling APIs tagged with IF_ABAP_TX_SAVE, IF_ABAP_TX_FUNCTIONAL and IF_ABAP_TX_READ ABAP_EML modify, permission and lock requests, lbr ABAP_EML requests in local mode, lbr authorization checks, lbr COMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES, ROLLBACK ENTITIES, lbr implicit and explicit database commits, lbr calling APIs tagged with IF_ABAP_TX_SURFACE and IF_ABAP_TX_MODIFY
IF_ABAP_TX_SURFACE Each of the following operations is allowed within the API, but not in behavior implementations lbr lbr ABAP_EML requests, lbr AB_SQL SELECT, lbr locks, lbr authorization checks, lbr Database modifying operations ( standard connection), lbr calling update function modules , lbr calling remote-enabled function modules, lbr COMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES, ROLLBACK ENTITIES, lbr implicit and explicit database commits, lbr calling APIs tagged with each of the tags available PERFORM, ON COMMIT, ROLLBACK, lbr ABAP_EML requests in local mode, lbr lbr ABAP_NOTE Not to be called in behavior implementations .
IF_ABAP_TX_COMPLETE lbr lbr ABAP_NOTE The call of the classified API is put under transactional control. When called, an API with this classification always starts in the modify transactional phase, as if the transactional phase had been explicitly set by calling cl_abap_tx=>modify( ). At any time during its execution, the API can enter the save transactional phase by calling cl_abap_tx=>save( ). From this point on, operations that violate the SAVE transactional contract are not allowed. When the API is exited, transactional control ends. An API with this classification must not be called from within a transactional contract, i.e. ABAP behavior implementations, APIs classified with a transactional contract (including IF_ABAP_TX_COMPLETE itself) and a transactional phase that has been explicitly set (e.g. using cl_abap_tx=>modify( )). Locks, lbr AB_SQL SELECT , lbr calling APIs tagged with IF_ABAP_TX_FUNCTIONAL lbr lbr Allowed in the modify phase in the API implementation: lbr ABAP_EML read, permission, modify and lock requests, lbr authorization checks, lbr implicit database commits, lbr calling APIs tagged with IF_ABAP_TX_READ and IF_ABAP_TX_MODIFY lbr lbr Allowed in the save phase in the API implementation: lbr RAISE ENTITY EVENT, lbr ABAP_EML key conversion, lbr database modifying operations ( standard connection), lbr calling update function modules , lbr calling remote-enabled function modules, lbr PERFORM, ON COMMIT, ROLLBACK, lbr calling APIs tagged with IF_ABAP_TX_SAVE ABAP_EML requests in local mode, lbr COMMIT WORK, ROLLBACK WORK, COMMIT ENTITIES, ROLLBACK ENTITIES, lbr explicit database commits, lbr calling APIs tagged with IF_ABAP_TX_SURFACE



Latest notes:

NON_V5_HINTS
The classifications have no dependency to RAP.
ABAP_HINT_END
BEGIN_SECTION SAP_INTERNAL_HINT
IF_ABAP_TX_WEAK
For APIs with this classification, contract violations are weakened, i.e., violations do not result in a runtime error, even if they occur in a restrictive context that would otherwise force a runtime error.
The classification should not be used for artifacts that are marked for the use in the ABAP for Cloud Development.
It should only be used temporarily and removed once the underlying functionality complies with all RAP BO contracts.
A warning is issued when the classification is used.
END_SECTION SAP_INTERNAL_HINT

ABAP_EXAMPLE_VX
The following code snippet demonstrates an interface that contains methods that are typed with classifications. INTERFACE if_some_interface
PUBLIC.

TYPES: BEGIN OF tx_contract,
meth_complete TYPE if_abap_tx_complete=>ty,
meth_read TYPE if_abap_tx_read=>ty,
meth_functional TYPE if_abap_tx_functional=>ty,
meth_modify TYPE if_abap_tx_modify=>ty,
meth_save TYPE if_abap_tx_save=>ty,
meth_surface TYPE if_abap_tx_surface=>ty,
END OF tx_contract.

METHODS:
meth_complete ...,
meth_functional ...,
meth_read ...,
meth_modify ...,
meth_save ...,
meth_surface ....

ENDINTERFACE.
ABAP_EXAMPLE_END

Return to menu