Using Developer Extensibility in parallel to Classic Extensibility- S/4HANA On-Premise

[Vijay]

As we all know by now, SAP S/4HANA Cloud ABAP Environment is the official name for embedded Steampunk and is now can be used to do cloud ready developments in S/4HANA On-Premise also.

Development of custom object can be made cloud compatible by changing the ABAP language version to "ABAP for Cloud Development" in the Object Properties as shown below.

This will enforce the strict ABAP cloud syntax and runtime checks for cloud compatibility i.e. we can use only release objects and APIs in the custom development, only released extension points can be used to extend standard objects and only ABAP RAP model can be used to build applications and services.

But it cannot be expected that on-premise customers switch completely to this pure cloud extensibility model overnight and reason could be very well scope of the custom requirement versus the availability of released objects or APIs for Cloud ready developments.

So, in contrast to S/4HANA Cloud where language version is forced to be "ABAP for Cloud Development", in On-Premise ABAP for cloud and ABAP classic code can coexist since the ABAP language version is defined on ABAP object level.

In SAP S/4HANA on-premise, for any new development ABAP Cloud development will be a recommended option to start with.

Now, the questions comes, as it is controlled at the object level, Do we need to switch the language version for each object we create as part of the custom solution development? How the ABAP for Cloud and Standard ABAP developments will work in parallel?...And we will look at the answers to these in this blog.

The steps to set up developer extensibility include:

Creation of a new Software Component

Using developer extensibility requires a separate software component if you want to use it in parallel to classic extensibility.

Use standard report "RSMAINTAIN_SWCOMPONENTS" to create new software component for Cloud  ready developments. Make a note that language version selected here is "ABAP for Cloud".

Note: Report "RSCTS_CVERS" can be used to create new software component in case of ABAP Platform 7.56 and earlier

Create Structure Package

We need to create a structure package under which development packages and cloud-ready custom development in ABAP language version "ABAP For Cloud" will be created .

In eclipse, create a new package and select the package type  "Structure" as shown below.

Assign the newly created Software component with "ABAP for Cloud" language version.

Follow the steps to save it in transport. Now we have a new software component and structure package for cloud ready custom developments.

Now, the packages and objects we will create under this structure package will by default have the language version as "ABAP for Cloud development" with no option to switch,

So for applications, we want to restrict cloud ready development, we can enforce to have developments only under the created structure package.

Lets test with as example how it looks.

Create a new package for custom development under the structure package

Now, create a custom object under this package. In this case i tried creating a class

And if we check the properties of this class, we can see the Language version selected is" ABAP for Cloud Development" by default with no option to switch

And if we try to access unreleased objects/APIs , we will get the syntax error as shown below. Moreover the error message will suggest the possible solution to fix the error as well.

Once we address the issues , it will activate successful with custom development being cloud ready.

So, all the developments done under the new software component structure package will be enforced to be cloud ready with "ABAP for Cloud Development" language version.

Any development done out of this structure package will by default pick the language version "Standard" with the option to switch to other versions as can be seen below for another demo class i created in a package out of the new software component.

And here it is possible to use the standard ABAP with any issues

It is also possible to restrict developers to be able to do only cloud ready developments. This can be done by  Adding authorization object S_ABPLNGVS to all existing roles which contain S_DEVELOP with value for field ABP_LNG_VS as "ABAP for Cloud Development".

Conclusion

Now we know how Cloud ready developments can be done parallel with Classic developments in S/4HANA On-premise system by creating a new software component.

 

Keep Learning & Keep Sharing!!

[Davidlc_01]

Great!

[kedarT]

Good to know that we can have old ABAP and Cloud ABAP in On-Prem parallelly. But why we would like to do Cloud ABAP in On-Prem when we are sure this code doesn't have any purpose to be moved to Cloud.

[JAEUK]

Great blog.

It is great that we can convert Classic ABAP code to Cloud ABAP code even on On-Premise system,

but what is the value of re-developing it to Cloud ABAP code with a lot of effort?

thanks~

 

 

 

[Vijay]

Hi Kedar,

It need not necessarily be the case only if you want to move your code to cloud. See, the idea with cloud ready developments is to make your code upgrade stable along with it being ready for cloud. So, recommendation is to go for cloud ready development for any new developments if that could meet your requirement and else for classic ABAP.

[Vijay]

Hi Jae,

The value is upgrade stable custom code. The recommendation is to start with the cloud ready developments for any new developments. For legacy code you can assess if that really make cost to value benefit.

The good part i would say is now you can do it within on-premise without additional cost which was the case with ABAP Environment. Obviously ABAP on BTP has its own use cases and you can skip if does fit your specific scenario

[former_member752390]

Hi Vijay,

Good and crisp info on cloud ready developments.

In case the goal is upgrade stable custom code only (not using any additional BTP features), which option one should go for ABAP based extensions, Steampunk or Embedded Steampunk as both offer the same capability ?

Do you see any advantage of Embedded Steampunk over Steampunk or vice versa for custom code development and extensions ?

Regards,

Anubha

 

[Vijay]

If the goal is only upgrade stable code , i would prefer embedded steampunk and the reason being the usage of local released API's (CDS views) which will avoid the huge data replication which will be required in case of Steampunk.

Upgrade stable BADI extension points to extend fields and logic is again more powerful then Key user extensibility and definitely provides edge .