Skip to Content
Technical Articles
Author's profile photo Marina Blank

Be Prepared for the Upgrade 2105! Clean Up your RAP Business Objects to Adapt them to the Upcoming Changes

With release 2105 of SAP BTP ABAP Environment, the ABAP RESTful Application Programming Model (RAP) evolves further. It contains numerous enhancements to make your RAP implementation consistent, user-friendly, and compatible with further RAP features.

RAP has been improved and consolidated continuously to help developers build high-quality and robust applications. We want to give you assistance to avoid mistakes, or, detect them at an early stage. At the same time, it is our goal to avoid mandatory adaptations in existing RAP implementations, or rather reduce them to an absolute minimum. Nevertheless, technical improvement necessarily involves change. In general, these changes relate to contract-enforcements in specific areas that have been conceptually insinuated but haven’t been technically ensured. With the upcoming release, the programming model will operate with further contract checks to ensure that both, the consumer and the provider can rely on the consistency and the correctness of any transactional request. This is equally beneficial for custom development and SAP standard development, for example in S/4HANA.

In the following, you will find explanations and solutions to prepare your code for the upcoming checks, even before the upgrade takes place and thus help you to prevent issues after the upgrade.

Using Outdated Syntax

Outdated syntax can be detected via ATC checks that you should run regularly to monitor existing implementations. These ATC checks safeguard your development for future upgrades and make your business objects compatible to the latest standard of RAP development. For more information about the ABAP test cockpit, see Checking Quality of ABAP Code with ATC.

The check variant SAP_CLOUD_PLATFORM_ATC_DEFAULT* contains all the relevant checks that you must take care of to keep your development upgrade-stable. ATC findings of priority Error must be resolved immediately in the current release, because in following releases, those warnings will become a syntax error.

* As of release 2105, this check variant is called ABAP_CLOUD_DEVELOPMENT_DEFAULT.

How to solve the problem:

The following ATC findings with priority Error in 2102 will turn into a syntax error with upgrade to release 2105. Resolve them as described.

Syntax Deprecate “dependent” with foreign keys is deprecated

The syntax “dependent” + foreign keys has been superseded by “dependent by” + association. It has never been supported for draft instances. A syntax warning has been introduced in behavior definitions.

Use “dependent by” + association to avoid the syntax warning. For more information, see CDS BDL – locking (ABAP – Keyword Documentation) and CDS BDL – ETag (ABAP – Keyword Documentation).

Reorganize Precheck for CBA cannot be defined outside groups in BOs with managed implementation type anymore

In managed BOs, you get a syntax error if you define a precheck for a create-by-association outside of groups.

Use groups to get rid of the warning.

For more information about groups, see Using Groups in Large Development Projects.

Deprecate “late numbering in place” is deprecated

The keyword “late numbering in place” in behavior definition results in a syntax warning.

Use the syntax “late numbering”.

For more information, see CDS BDL – late numbering.

Bugfix hyphens in BDEF identifiers are not allowed

Hyphens in BDEF identifiers (=names for BO operations, determinations, validations) result in a syntax warning.

Use names without hyphens.

Functionality Internal operations in static EML MODIFY don’t imply IN LOCAL MODE

For EML calls of internal operations in ABAP behavior implementations, “IN LOCAL MODE” was added implicitly. Now, it is not added anymore.

If you need to execute the call in local mode, you need to specify explicitly.

For more information, see IN LOCAL MODE (ABAP – Keyword Documentation).

Functionality “total etag” for draft BO is required

In draft BOs, you must specify a total ETag in the behavior definition.

For more information, see Total ETag.

Functionality cardinality = 1 for factory actions is required

If you define factory actions with cardinality >1, you get a syntax warning.

Use cardinality =1 for all factory actions.

Syntax: <code> [static] factory action myFactoryAction [1]; </code>

Bugfix Action renaming in projection behavior definition If you rename an action in the projection behavior definition with a name that already exists, you get a syntax error.
Bugfix Disallow “precheck” on draft and determine actions in projections

If you define precheck for draft and determine actions in the projection behavior definition you get a syntax error.

Draft and determine actions cannot be prechecked.

All of these changes are documented in SAP Note 3017989 Possibly Incompatible Changes ABAP RESTful Application Programming Model 2102.

The following ATC findings with priority Error since 2008 will turn into a syntax error with upgrade to release 2105. Resolve them as described.

Syntax Correction Internal Actions and Create-by-Associations with “feature:instance”

You cannot specify internal Actions/Create-By-Associations with “feature:instance” for dynamic feature control.

The reason is that names of internal operations are disclosed in the derived types for request/result of GET FEATURES, and consequently, changing the names later might lead to syntax errors for consumers.

Feature Fields for master join conditions must be “readonly” or “readonly:update” Elements used in the join condition to parent, lock, authorization or etag master must be marked with readonly/readonly:update.

These changes are documented in SAP Note 2943709 Possibly Incompatible Changes ABAP RESTful Application Programming Model 2008.

Using Data Type CURR

The decimal shift logic for currency amounts of data type CURR only works in a consistent way across different channels and consumption frameworks if the data type for currency amounts is of type CURR with two decimals. That’s why, RAP only allows you to use the data type CURR if it is defined with two decimals.

If you use this data type with another number of decimals, you will get an error on creating a new service binding. If you already have an OData service that uses data type CURR with more or less than two decimals, you will now get a metadata error, and you will see an error message in your service binding.


The decimals that are specified in the data type define the numbers of decimals with which the amount is stored on a DDIC database table:

Amount CURR(23,1) CURR(23,2) CURR(23,5)
123,45 1234,5 123,45 0,12345

The number of decimals with which the currency amount is displayed on a Fiori UI and other outputs depends on the currency that is referenced by the amount field. The referenced currency code field must have ABAP type CUKY  (which is a CHAR(5) field with allowed values in table TCURR). Their decimal places are defined in database table TCURX.


1.234,56 EUR (2 decimal places)

123.456 JPY   (0 decimal places)

123,456 KWD (3 decimal places)

Since storing and output formats are not necessarily the same, an elaborate shifting logic is applied throughout the different channels of a RAP service. Consistency can therefore only be ensured if the amount uses data type CURR(x,2).

How to solve the problem:

Check if you can avoid using fields with data type CURR that have more or less than two decimals in the data model for your RAP service.

If there is no other way in your RAP Service than using the data type with a number of decimals unlike two, adjust the number of decimals in the CDS view that uses those data elements by casting the element to data type CURR(x,2).

  • Cast an element Amount_m with data type CURR(x,m)  (where m > 2) to CURR(x,2) with the following casting logic:
                  Amount_m as abap.dec(x,m)
                ) * 1000   as abap.curr(x,2)
          )  as CastAmount_m,

The data type has to be cast to type abap.dec(x,m) (packed number) first, before it can be cast back to a currency amount type to avoid warnings for casting to an identical type.

Once cast to abap.dec, multiply the amount with a multiple of 10 (depending on the number of decimals of the original type) to get the amount with two decimals without losing digits.

  • Cast an element Amount_1 with data type CURR(x,1) to CURR(x,2) with the following casting logic:
                                  Amount_1 as abap.dec(16,1) 
                                 ), 10, 1 
                          ) as abap.dec(16,2)
                ) as abap.curr(16,2)
           ) as CastPrice1,

The division by 10 triggers the conversion to type abap.decfloat(34). Since abap.decfloat(34) cannot be cast to abap.curr, it has to be cast back to abap.dec before it can be cast to abap.curr(x,2).

The casting logic for fields with data type abap.curr(x,0) is done analogously.

  • On writing access, the incoming values must be converted to the original data type. This can be done by using operation augmentation in the projection business object if the casting logic for read access in the CDS projection view. By using augmentation, the incoming values is converted before the request reaches the transactional buffer and any potential further checks during runtime are executed on the values that are already converted to the format on the database table.

If the casting logic is done in the projected CDS view, the backconversion for incoming values must be done in a determination for managed business objects or in the modify implementation method for unmanaged business objects.

For more information, see

CDS DDL – DDIC-Based View, cast_expr

Operation Augmentation

Implementing Read-Only Operations and Characteristics

It is not allowed to use MODIFY ENTITIES statements in the implementation of the following behavior definition operations and characteristics:

    • read
    • read-by-association
    • function
    • feature control
    • authorization control
    • validation
    • lock
    • precheck

The listed behavior is uniquely read-only, which means it does not change data on the database and therefore any modify operation is forbidden in their implementation.

If you use an EML MODIFY statement (MODIFY ENTITIES) in read-only implementations, you will get an ABAP runtime error when the implementation is called. The runtime error will only be raised for EML MODIFY statements, not for other direct database modifications. Nevertheless, you shouldn’t use any data modification option in the listed behavior implementations.

How to solve the problem:

Remove any EML MODIFY statement in a read-only implementation.

Check if the behavior is really modeled in the correct behavior definition operation or characteristic.

  • If you want to use MODIFY in a function implementation, implement the logic in an action instead. A function is only designed for read-only access to the database.
  • If you want to use MODIFYin a validation implementation, implement the logic in a determination instead. A determination is designed to change data based on incoming values. A validation just checks if the incoming values are correct.
  • If you want to use MODIFYin any other read-only implementation, implement the logic in a behavior pool implementation that allows changes on the database.

Consuming Instance Authorization and Feature Control in Managed BOs

With 2105, instance authorization and feature control is called once for all requested operations, and not for each operation separately. In other words, there is no separate authorization or feature control check for operations using %CID_REF.

If instance authorization or feature control depends on the successful execution of a preceding operation in the same request, the authorization or feature control might be denied because the instance checks are checked only once for all operations before any operation is executed.


A consumer issues an update and an action request in one EML call and the authorization for the action depends on a value the update request modifies. Since authorization is only checked once for both operations, the action might be involuntarily denied, even if the update would set that value for which the consumer would be authorized.

How to solve the problem as BO provider:

Check if the change during runtime has an impact on the authorization and feature control results for interdependent operations. If needed invoke a proper authorization or feature control check within the action implementation.

How to solve the problem as BO consumer:

If you want to ensure that the authorization and feature control is checked for each operation separately to avoid interdependencies between operations, issue a separate request for each operation.

Issuing Modify Requests for Read-Only Fields in Managed BOs

Stricter checks are introduced for dynamic feature control. The managed runtime framework used to ignore fields that were dynamically set to read-only by dynamic feature control in update requests. The read-only fields were not updated and the incoming values were ignored, but the others were processed and saved to the database. The consumer did not get any information that the values for the read-only fields were not processed.

Now, the managed runtime framework rejects such requests that attempt to update fields that were dynamically set to read-only and the consumer receives direct feedback about the rejected request.

How to solve the problem:

The consumer can request the permissions to check which fields are modifiable before executing update requests.

      FROM  InstanceKey
      REQUEST RequestField
    RESULT DATA(result_permission)
    FAILED DATA(failed_permission)
    REPORTED DATA(reported_permission).

Implementing Instance Feature and Authorization Control in Unmanaged BOs

Before the upgrade to 2105 the unmanaged runtime framework did not call the instance feature or authorization implementation before modifying operations. In UI scenarios, these implementations were just called for the consumer hints. The authorization check had to be implemented inside the modify implementation. This changes with 2105 with possible impact for the BO provider.

How to solve the problem:

  • If possible, move the authorization and feature control logic to the corresponding implementation methods. Make sure that the related messages are moved as well, so that messages are returned to the consumer if the request is denied due to authorization or feature control issues. If not, only a generic message will reach the consumer.

If moving is not possible, you can leave the implementation method as is and opt out via the following code:

    cl_abap_behv_aux=>get_current_context( IMPORTING for_permissions = DATA(for_permissions) ).
    IF for_permissions = abap_false.
  • If authorization or feature control is denied in the corresponding implementation methods, the implementation for the subsequent modify request is not called at all. Check your modify implementations for any side effects that might not be called if the execution of the modify request is denied by authorization or feature control.
  • If authorization is checked for an authorization dependent entity, the authorization check is delegated to the authorization master entity. This is done via a read-by-association. It is always mandatory to implement the read-by-association to the authorization master entity, but in this case it is absolutely indispensable to avoid runtime errors. Check if the the read-by-association is implemented from all authorization dependent entities to the authorization master entity.

If you stick to these guidelines, the upgrade to ABAP environment 2105 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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Alejandro Sensejl
      Alejandro Sensejl

      Requests that are not contract-conform may result in short dumps,


      Please don't do that. We had an implementation project at a customer (custom development), which does not have own developers. We currently do not have any contact with them as project has ended. Application will crash in production, if BO contract is changed in that way.

      Author's profile photo Alejandro Sensejl
      Alejandro Sensejl

      Another thing that comes in my mind (not relevant for us): If I remember correctly, there is a partner approach for that. If - let's say: - 100 customers of a partners uses their add-on, then partner has to update 100 customers incl. test/go-live etc. within 2 months?! Not manageable!

      Author's profile photo Marina Blank
      Marina Blank
      Blog Post Author

      Hi Alejandro,

      The sentence you are referring to was phrased a bit misleading. External Requests (OData calls) that are not contract-conform do not necessarily lead to short dumps. Instead, the stricter checks on consumer side (EML calls) enable direct feedback to such incorrect requests.  These requests are rejected and the reason is communicated, which is transparent for BO consumers and they can react to it immediately. This behavior is more beneficial than processing ambiguous or incorrect requests with an unclear result. Contract checks are always introduced to avoid errors; and naturally developing with RAP requires contract-conformity to exploit the many advantages of this programming model!

      Author's profile photo Daniel Ojados Conesa
      Daniel Ojados Conesa

      Looking forward to it Marina Blank

      Actually long time waiting for being able to use abstract entities with hierarchy so we can provide actions with deep structures as input/output parameters

      Author's profile photo Sunil Gupta
      Sunil Gupta

      These kind of drastic changes and upgrade is detrimental to the ongoing productive system. We have a large scale application developed and deployed productively for a customer since several months. if the the changes mentioned in this upgrade are to be done manually then it is simply not possible. Another issue is due to critical nature of Supply chain application. They are running this 24x7 and cannot afford even 1 hour downtime.

      SAP should come up with any upgrades with major changes with the necessary tools and utilities to coed inspection and mass changes to be done in Dev and QAS before taking to production and upgrading the production system.

      Author's profile photo Shai Sinai
      Shai Sinai

      To be honest, I'm quite surprised.

      All these "solutions" are quite cumbersome, in my opinion.

      Should we expect such dramatic changes (which breaks the code) in every upcoming release?

      Author's profile photo Andre Fischer
      Andre Fischer

      No, not in all, but unfortunately in this release.

      Author's profile photo Andre Fischer
      Andre Fischer

      When you run into the problem with your BDEF using foreign keys check out my following blog post

      lock dependent with foreign keys causes syntax errors as of 2105 | SAP Blogs