Technical Articles
Be prepared for the Upgrade 2008! Clean Up your RAP Implementation to Pass the Reinforced RAP Contract Checks
With release 2008 of SAP BTP ABAP Environment, SAP releases stricter business object (BO) contract checks for the ABAP RESTful Application Programming Model (RAP) to help you make your RAP implementation consistent, user-friendly, and compatible to further RAP features. These contract checks ensure that both, the client and the provider can rely on the consistency and the correctness of any transactional request. Requests that are not contract-conform may result in short dumps, triggered by these checks.
For new implementation code, the RAP framework will not allow you to create such incorrect requests that trigger short dumps. This will be ensured via syntax errors during compilation.
However, if there are already erroneous requests in your code before the upgrade, the execution of such requests will provoke a short dump during runtime after the upgrade to ABAP environment 2008.
In the following, you will find explanation and solutions to prepare your code for the upcoming contract checks, even before the upgrade takes place and thus help you to prevent problems after the upgrade.
Creating and Updating Read Only Fields via EML
It is not allowed to modify (create or update) read only fields via EML requests externally, that is from outside of the business object (e.g. from an independent ABAP class or from another BO). A new ABAP syntax check prevents the compilation of such modify calls. However, if these EML requests are already in your code and are executed during runtime, a short dump will be raised.
How to solve the problem:
Check if these fields are really meant to be read only. Defining a field as read only in the behavior definition means that it is not modifiable from outside of the business object.
If the read only attribute in the behavior definition is correct, remove the fields from the EML request in BO-external ABAP code.
For internal modify requests add the addition in local mode to the EML request to indicate BO-internal EML calls.
Syntax:
MODIFY ENTITIES OF business_object IN LOCAL MODE ENTITY bo_entity CREATE | UPDATE FIELDS (...) ...
Note: Read only fields in OData modify calls for CREATE or UPDATE are simply ignored by the RAP runtime framework. Other fields can still be processed successfully.
For more information, see Defining Static Feature Control at Field Level.
Executing Modify Calls in a Late Save Phase
The RAP runtime does not allow modify calls after the point of no return in the save sequence. Whereas changes on your business object are still possible during the phases FINALIZE and CHECK_BEFORE_SAVE in the save sequence, you cannot change the BO during the phases ADJUST_NUMBERS and SAVE. After CHECK_BEFORE_SAVE, the state of the business object must be ready to be persisted on the database and it must be ensured that this state is not changed anymore. Therefore, modify calls in the late save phase are forbidden.
If you have used modify calls in late save phases, the RAP runtime framework will raise a short dump for these modify calls.
How to solve the problem:
Make sure your BO is in a consistent state after the CHECK_BEFORE_SAVE phase and remove any modify requests from late save phases. Final changes of the BO must be done in the FINALIZE method, either directly or with determinations on save.
If you use late numbering, the assignment of the final key value is done by filling the changing parameter MAPPED. You do not need a modify request to set the final key value.
In the actual SAVE method during the save sequence, the only thing allowed is saving the current state of the business object to the database. No changes on the BO are allowed.
For more information about the orchestration of the save sequence, see Save Sequence.
Working with Determinations and Validations
As of ABAP environment 2008, the runtime of determinations and validations will be managed by the new determinations-validations-machine (DVM). This machine enables new options for determinations and validations, for example new trigger conditions. In return to the widened scope, you must ensure that some new rules apply to your implementation of determinations and validations:
- The determination result must not change if the determination is executed more than once (idempotence). You must ensure that the result of a determination stays the same, even if the determination is executed several times within one logical unit of work. In other words, the determination must always have the same result under the same circumstances.
- The execution order of validations and determination is not determined. You cannot know which determination or validation is executed first. You must implement your determinations and validations independently of each other. This also means that determinations cannot trigger other determinations or validations.
- You are not allowed to use EML modify statement in validations. Instead, use determinations to modify BO instances.
- If you create or update an instance and delete it with the same request, it can happen that an EML read operation in a determination on modify fails as instances with the given key cannot be found.
Using Authorization Control
Dynamic feature control for standard operations is displayed in the OData service metadata by a path expression on the respective operation. With ABAP environment 2008, these consumer hints will also reflect authorization control. That means, if you define authorization control for your business object, the authorization-relevant entity sets receive a path description instead of a static information about their ability to be updated or deleted. In addition, the corresponding properties are included in the property list of the entity type.
If you already use authorization control, the OData service metadata of your business service will look different after the upgrade to ABAP environment 2008.
Before the upgrade:
<EntityContainer Name="MyContainerName" … > <EntitySet Name="MyEntity" EntityType="MyEntityType" ... /> … <EntityContainer/>
As the default for binary expressions in OData is "true", the static information about the entity being creatable, updatable and deletable is omitted. Authorization control is not reflected in this information.
After the upgrade:
<EntityContainer Name="MyContainerName" … > <EntitySet Name="MyEntity" EntityType="MyEntityType" ... sap:deletable-path="Delete_mc" sap:updatable-path="Update_mc"/> … <EntityContainer/> <EntityType Name="MyEntityType" … > … <Property Name="Delete_mc" Type="Edm.Boolean" sap:label="Dyn. Method Control" sap:creatable="false" sap:updatable="false" sap:sortable="false" sap:filterable="false"/> <Property Name="Update_mc" Type="Edm.Boolean" sap:label="Dyn. Method Control" sap:creatable="false" sap:updatable="false" sap:sortable="false" sap:filterable="false"/> … </EntityType>
The fact that authorization dynamically controls the business object entity is reflected by the path expression pointing to the property for method control. This property is listed in the property list of the entity type. Dynamic authorization control for the create operation is not available. As the default is "true", the annotation for creatable is omitted here.
For other service consumers than Fiori Elements UIs, this can lead to problems if the path expressions are not evaluated correctly.
How to solve the problem:
Make sure that your business service consumer interprets the method control on standard operations correctly.
Consuming Actions or Functions with Parameters
As of ABAP environment 2008, the RAP runtime framework strictly checks the length of input parameters for actions and functions. This check will reject any incoming request for action execution with a parameter exceeding the defined length.
The defined length of the parameter can be seen in the OData service metadata:
<FunctionImport Name="MyAction" ... > <Parameter Name="Myparameter" Type="Edm.String" Mode="In" MaxLength="N"/> </FunctionImport>
It is possible that you encounter problems after the upgrade, if you execute actions or functions with parameters that are longer as the defined length. Whereas before the upgrade, these requests were accepted and the parameter was cut after the respective number of characters, after the upgrade, requests with an exceeded parameter length will be rejected.
How to solve the problem:
Check your service consumer for actions and functions with parameters. If you use parameters that are longer than the defined length, evaluate if you can shorten them to align them with the parameter definition.
If your parameter values cannot be shortened, modify the length of the parameter type in the action/ function definition in the behavior definition, or in the place where you have defined the type of the parameter.
If you stick to these guidelines, the upgrade to ABAP environment 2008 will pass smoothly and your RAP implementation will be more consistent and stable afterwards. The action to solve the problems can be taken immediately, so you can eliminate the problems even before they arise.
Find more information about the ABAP RESTful Application Programming Model in the official documentation: ABAP RESTful Application Programming Model.
You can also get really helpful insights into RAP implementation in the ABAP Flight Reference Scenario, which you can download from GitHub.
If you still run into problems or if you have questions regarding the presented issues, please raise a ticket on component BC-CP-ABA.