What does it do? The output parameter for an action> or function> is defined with the keyword result >. It can be used to store the result of an action or function in an internal table. However, it does not affect the result of an action or function that is committed to the database. For details on the components of the result structure, see topic TITLE >. If a result parameter is declared in the action or function definition, it must be filled in the implementation in the ABAP behavior pool>. The return type of the result parameter can be an entity or a structure:
$self> specifies that the result type is the same type as the entity for which the action or function is defined.
entity OutputParameterEntity> specifies that the result is a different entity> of the same or another BO>.
ResultParameterStructure>: A RAP abstract BDEF> or a DDIC structure> can be specified as a return type. A resulting structure for actions or functions is defined without the keyword entity>. For result structures, it is possible to define an alias to clearly identify the result in the OData metadata. The keyword external> after the result type defines this OData representation of the action or function result.
Latest notes:
If the result is a CDS abstract entity>, the result must be defined without the keyword entity > as abstract entities are generally considered to be structures in ABAP.
If BDEF strict mode> is enabled, OutputParameterEntity> specified after the keyword entity> must be a CDS view entity>.
If BDEF strict mode> is enabled, ResultParameterStructure> must be a CDS abstract entity>. NON_V5_HINTS ABAP_HINT_END
ABAP_FURTHER_INFO Development guide for the ABAP RESTful Application Programming Model, topic Action Definition>.
ABAP_EXAMPLE_VX5 The following example shows a managed BDEF with two actions, Approve_Order> and Reject_Order>. The result is $self> with cardinality 1, so the output parameter has the same type as the entity for which the action is executed. BDEF DEMO_CDS_PURCH_DOC_M In the behavior pool BP_DEMO_CDS_PURCH_DOC_M>>, the result parameter is declared as follows: result = VALUE #( FOR purchase IN lt_purchase ( %tky = purchase-%tky %param = purchase ) ).> The class CL_DEMO_CDS_PURCHASE>> accesses the business object and executes the action Approve_Order> for one entity instance. Code snippet: ABEXA 01535 Result: the changed entity instance is stored in the result> structure. IMAGE ABDOC_RESULT.jpg 469 233 ABAP_EXAMPLE_END
ABAP_EXAMPLE_ABEXA The example from above is explained in detail in topic RAP BDL - action>. ABAP_EXAMPLE_END
ABAP Addition
What does it do? When using the optional addition deep>, the syntax for the output parameter is as follows: ... deep result $[selective$] [cardinality] AbstractBDEF;> The output parameter AbstractBDEF> must be a RAP abstract BDEF> with hierarchy>>. The BDEF derived type for an abstract BDEF is a hierarchy that contains all entity fields plus a component for every composition. The optional addition selective> can be specified to return only parts of the result structure.
ABAP_EXAMPLE_VX5 The following example shows a managed BDEF. The action a2_deep_result> uses the abstract BDEF DEMO_CDS_ABSTRACT_ROOT>> as deep output parameter. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. The RAP handler methods> are not implemented in the ABAP behavior pool> here. BDEF DEMO_CDS_DEEP_PARAMETER ABAP_EXAMPLE_END
ABAP Addition
What does it do? With the optional addition selective>, it is possible to return only parts of the result structure, for example the keys only. This can help to improve performance. An implementation in the ABAP behavior pool> is required. If selective> is specified in the BDEF, the action or function signature has the additional input parameter REQUEST requested fields>, which marks all requested fields with 01>.
ABAP_EXAMPLE_VX5 The following example shows a managed BDEF based on the CDS view entity DEMO_RAP_MANAGED_SELECTIVE_1>>. It defines the function myfunction> with a selective result. BDEF DEMO_RAP_MANAGED_SELECTIVE_1 In the ABAP behavior pool, the instance function myfunction> is implemented so that it reads the values of all fields and returns them in the result structure. The result structure interprets the importing parameter requested_fields > and fills only those fields that are requested by the EML consumer. Code snippet: METH BP_DEMO_RAP_MANAGED_SELECTIV_1(CCIMP)=>myfunction For the complete implementation in the ABAP behavior pool, see BP_DEMO_RAP_MANAGED_SELECTIV_1CCIMP>>. The class CL_DEMO_RAP_MANAGED_SELECTIVE>> accesses the business object and executes the action myfunction>. It requests only the fields KeyFieldRoot> and Timestamp> and therefore, the result structure displays only the values of these two fields. Code Snippet: ABEXA 01550 The following image shows that the importing parameter requested_fields> marks the field requested by the EML consumer with 01>. IMAGE ABDOC_REQUESTED_FIELDS.jpg 444 113 Result: the result structure contains only the values of the requested fields. IMAGE ABDOC_RESULT_1.jpg 444 168 ABAP_EXAMPLE_END
ABAP Addition
What does it do? Defines the cardinality> of the output parameter. This is a mandatory addition. The square brackets are part of the syntax. The following values can be specified for cardinality: