Consumer Implementation

Consumer implementation consists of the following three sections:

 Core services

Introduces the core services, which allow the consumer to access business object instances.

 Transaction services

Describes the transaction services SAVE and CLEANUP, which save the changes done by the core services.

 Consumer message handling

Handles the messages returned by the core services and transaction.

1.3.1.1 Core Services

The consumer (for example, the user interface or a foreign business object) is allowed to access a business object with the help of a set of core services. These core services are described in detail in the interface documentation of the service manager /BOBF/IF_TRA_SERVICE_MGR.

 CHECK_ACTION:

This method allows you to check if a certain action can be executed. You have the option of using a given action parameter on a given set of node instances. The execution of an action can be prohibited depending on the state of the node instances, the properties of the action, or failed action validations.

 CHECK_AND_DETERMINE

With this method, you can check whether or not a certain set of node instances of a node is currently in a consistent state. The validations configured to the corresponding node and the relevant

determinations are executed in order to make the business object instance consistent. Additionally, the consistency statuses covered by the check scope are updated.

 CHECK_CONSISTENCY

This method checks if a certain set of node instances of a model node is in a consistent state. The validations configured to the corresponding node or of the complete substructure are executed in order to check the consistency.

 CONVERT_ALTERN_KEY

This method retrieves for certain node instances that are identified by an alternative key (called source alternative key) the corresponding alternative key values of another alternative key on the same node (called target alternative key).

 DO_ACTION

This method executes a certain action with a given parameter on a given set of node instances.

 MODIFY

This method allows you to create, update, and delete node instances in a mass enabled manner.

 RETRIEVE

The retrieve method allows you to read data of certain instances of a certain node.

 RETRIEVE_BY_ASSOCIATION

This method allows you to retrieve node instances that can be identified with the help of a certain associat

 GET_NEW_KEY

This method returns a new globally unique key, which has not been used to identify any other entities.

For example, this can be used to identify new node instances.

 QUERY

This method executes a query and returns the query result.

The following core services are only relevant for user interfaces accessing BOPF business objects.

 RETRIEVE_CODE_VALUE_SET

A value set is the BOPF representation of a dynamic value help (F4 help) of an entity. This method can be used to receive the values for a certain code list.

 RETRIEVE_DEFAULT_ACTION_PARAM

This method allows you to retrieve the dynamic default parameter values of a certain action. Due to the fact, that the selection of the default parameter of an action can depend on the instances on which the action shall operate as well as a prefilled action parameter, IT_KEY and CS_PARAMETERS are import parameters of this function. The method returns a reference to a parameter structure of that action, which is enriched by the default values.

 RETRIEVE_DEFAULT_NODE_VALUES

This method can be used in order to fetch dynamic, context dependent default values for node instances, without actually creating them.

 RETRIEVE_DEFAULT_QUERY_PARAM

This method can be called to receive the default parameter values of a certain query. Due to the fact, that the default parameter of a query can depend on a prefilled parameter, the

CT_SELECTION_PARAMETER parameter is imported.

 RETRIEVE_PROPERTY

This method allows you to retrieve the properties of certain entities.

Restrictions

The core services offered by the service manager must not be used out of entity implementations in order to access the individual business object. The READ object provided by the framework must be used instead.

1.3.1.2 Transaction Services Procedure

The transaction model is divided into an interaction phase and a save phase. For more information, see 1.1.3. After finishing the core service calls, a consumer can either cleanup or save the changes done in the current transaction. In both cases, the transaction manager instance must be received from the factory class /BOBF/CL_TRA_TRANS_MGR_FACTORY=>GET_TRANSACTION_MANAGER. Afterwards, the corresponding instance method CLEANUP or SAVE can be called.

Restrictions

The transaction services offered by the transaction manager must not be called in entity implementations.

Only the consumer is allowed to control the transaction.

Example

The following example shows how to save a transaction after the interaction phase took place.

DATAlo_transaction_managerTYPEREFTO/bobf/if_tra_transaction_mgr.

” start interaction phase

…

” start save phase

lo_transaction_manager = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ).

lo_transaction_manager->save( ).

1.3.1.3 Consumer Message Handling

Most of the core services return a message object (EO_MESSAGE) back to the consumer, which contains messages created by the executed BOPF entities. In order to make use of them, the following attributes of messages must apply:

 Depending on the lifetime, the validity period of the message is either restricted to the current service call (lifetime transaction) or it continues until the inconsistency is corrected (lifetime state).

 The severity of the message is expressed by the message severity. It is distinguished into error, warning, and information.

 The origin location defines which instance the message is referred to.