Jerry has mentioned several times in previous articles that the ABAP syntax On the SAP Cloud Platform ABAP programming environment is just a subset of the ABAP syntax that SAP consultants use On on-premises environments. In other words, ABAP code that works in an on-premises environment may fail to compile simply by copying and pasting it to a cloud environment. Look at some examples:

MOVE

Fixing this syntax error is as simple as replacing MOVE with the assignment operation “=”. This error would only occur in Legacy Code, and most people don’t write Code that uses MOVE for simple assignments.

Data Elements not Released for Cloud

Each ABAP Cloud project created within the ABAP Development Tool has an Released Objects folder that maintains a list of Objects that ABAP developers can use in the Cloud environment. In Data Elements is all available Data Elements. First on the list is ABAP_BOOLEAN, which describes Boolean types.

Also for historical reasons, we know that to define a Boolean variable in an on-premises environment, we have a number of options: BOOLE_D, ABAP_bool, Boolean, etc.

But when it comes to the cloud, stick with the types maintained in the checklist.

Not all SYST structure fields are directly accessible

The SYST structure contains many system fields that allow ABAP developers to easily obtain information about various dimensions of an ABAP application execution.

In the ABAP cloud environment, use these fields with special care to avoid syntax errors such as “Access to the field “sy-datum” is not permitted in the restricted language scope” :

Instead, use the CL_ABAP_CONTEXT_INFO=>GET_SYSTEM_DATE method provided by the utility class.

Here are some other examples.

Fortunately, because we were programming in the ABAP Development Tool IDE, we didn’t have to memorize these on-premises conversion rules On the ABAP Cloud. Most of the time, it’s not hard to find clues to Fix syntax errors by relying on the IDE’s syntax error reporting or Quick Fix functionality.

Of course, if this kind of one-by-one repair is slow, or imagine a scene like this: You have a development kit On your ABAP on-premises system that contains a lot of ABAP secondary development code, Before migrating code from on-premises systems to the Cloud using Jerry’s previous article On code transfer between ABAP systems and SAP Cloud platform ABAP environments using abapGit, you want to do a uniform “Cloud Readiness” check. Make a list of all the potential cloud hazards at once.

The traditional ABAP Test Cockpit is now in the Cockpit again. Follow the note in this SAP community blog post to install an implementation containing the new ATC check options on an ATC central check system:

How to check your custom ABAP code for SAP Cloud Platform ABAP Environment blogs.sap.com/2018/10/02/…

This new ATC checking option, named SAP_CP_READINESS_REMOTE, helps us identify all barriers preventing clouds On the currently inspected ABAP code in the on-premises environment well before the ABAP code migrates to the cloud.

Of course, this check can be performed in the opposite direction, that is, in the SAP Cloud Platform ABAP environment, triggering ATC checks in the connected ABAP on-premises environment. Since the on-premises environment is accessed from a Cloud environment, the SAP Cloud Connector is required to traverse the Intranet and exnets:

Enter the Custom Code Migration application from the Fiori Launchpad and create a new Migration project:

The migration target is of course the SAP Cloud Platform ABAP environment, and the source is the ABAP on-premises environment, so a Destination pointing to that environment needs to be maintained, which is created On the SAP Cloud Platform.

At this point we can trigger ATC checks On the ABAP on-premises system On the Fiori UI and monitor its progress.

After the inspection, you can follow the prompts to return to the on-premises environment for code adjustments.

For more of Jerry’s original articles, please follow the public account “Wang Zixi “: