Consistent handling of ABAP Language Version during pull/push #6154

ThomasPloski · 2023-03-16T10:50:14Z

Dear abapGit community,

With the 7.52 release, SAP provides the usage of the ALV (ABAP language version) information in the onPrem world.

In order to support a consistent handling of the ALV across the different abapGit "flavours" (Open Source / part of SAP BTP ABAP), we are currently working on a concept/proposal (also referring to issue #5921).

The idea is to use this issue to discuss the topic and its boundary conditions as well as collect feedback.

Further links:
https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/abenabap_versions.htm
https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/abenabap_versions.htm
https://blogs.sap.com/2022/09/09/abap-language-versions-faqs/

larshp · 2023-03-16T10:59:06Z

a. Dont serialize ALV to files
b. During deserialization set the ALV according to the ALV from the package

mbtools · 2023-03-16T11:51:28Z

Appreciate the initiative, Thomas 🙏

a. agree
b. agree, but needs clarification if package does not exist (yet)
c. specify "orignal ALV" and a list of "compatible-with ALVs" in repo settings

larshp · 2023-03-16T11:59:25Z

b. IMHO, require users to always create packages manually, we cannot automatically determine things like transport route/layer
c. nice to have

fabianlupa · 2023-03-16T12:33:43Z

Somewhat off topic, I am seeing the use of the acronym ALV for ABAP Language Version here for the first time. Is that a fixed term? (Many people might get confused with the ABAP List Viewer :P )

BeckerWdf · 2023-03-16T12:40:11Z

Somewhat off topic, I am seeing the use of the acronym ALV for ABAP Language Version here for the first time. Is that a fixed term? (Many people might get confused with the ABAP List Viewer :P )

Not it is not - but often used inside SAP. It can easily cause confusion because of the ABAP List Viewer. We should not use it here.

larshp · 2023-03-16T13:36:15Z

so, it turns out that in on-prem it is possible to have a package with mixed ALVs, ie. ignoring the field in serialization would loose information.

the nice world would be developers using the ALV on package level

so perhaps, by default ignore ALV, but have a setting(in .abapgit.xml) which will enable serialization of the field

hmm

BeckerWdf · 2023-03-16T13:41:09Z

The language version on package level is just the "default" when creating new development objects in that package.
But the language version of individual development objects can be change to other language versions. AFAIK each package (or software component) also contains a list of allowed language versions. When you try to change the language version it is checked if the package / sw component does allow it and if you have the needed authorization for it.

anfisc · 2023-03-16T14:14:01Z

The language version "ABAP for cloud development" on package level is enforced if the package is part of a software component that uses ABAP language version 5.
Setup Developer Extensibility

schneidermic0 · 2023-03-17T07:12:34Z

Just as a reference. There was a discussion on the topic related to ABAP language version and ABAP file formats in issue SAP/abap-file-formats#44

schneidermic0 · 2023-03-17T07:32:08Z

so, it turns out that in on-prem it is possible to have a package with mixed ALVs, ie. ignoring the field in serialization would loose information.

Yes, this is possible. @BeckerWdf confirmed the same. This was also the reason why I wanted this field (at least as optional information) per object in the ABAP file formats. There we need the possibility to ensure to keep the ABAP language version of an object.

I guess, it wouldn't be an issue to specify the ABAP language version per object (as it is for other object-specific property) if there weren't the need to work with repositories in different releases (releases which support the ABAP language version as property and releases which don't).

This situation would lead to the fact that abapGit serializes object differently (dependent on the release). Same situation as for other fields which might be introduced in later releases, but are unknown in lower releases. Since ABAP language version affects a broad range of object types this might lead to diffs for almost all objects in a repository. :(

schneidermic0 · 2023-03-17T07:43:50Z

so perhaps, by default ignore ALV, but have a setting(in .abapgit.xml) which will enable serialization of the field

I am in favour in storing the ABAP language version per object (since it is a property of the object). However, I can understand the issue with the serialization/large diffs. Therefore, I guess @larshp's proposal to provide a configuration in the repository could be a solution for abapGit.

If this approach is taken, we should be aware of the implications if no ABAP language version is not serialized (due to the setting):

There is no option to have mixed ABAP language version in a repository
If we don't store any further information (e.g., in the repository) which ABAP language versions the objects shall get. The ABAP language version might not be set in the target system. If we take up the approach of set this information manually on the root package of the repository, each developer would have to set it manually
If the ABAP language version for the repository is not consistent specified (at least for systems which support the ABAP language version ;), developers might use functionality which are not supported for ABAP language version to be used in ABAP Cloud. I.e., they might introduce usages of non-released APIs or use statements which are not allowed in ABAP Cloud.
Most probably there are further implications ;)

In any case, we would need a clear contract for abapGit how objects are deserialized in systems which support ABAP language version if the ABAP language version was not specified for the object.

fabianlupa · 2023-03-17T07:46:01Z

This situation would lead to the fact that abapGit serializes object differently (dependent on the release). Same situation as for other fields which might be introduced in later releases, but are unknown in lower releases. Since ABAP language version affects a broad range of object types this might lead to diffs for almost all objects in a repository. :(

Maybe if the field is not available, serialize ABAP Language Version "Standard ABAP", if it is available, serialize the one in the system? Then we'll have a one time diff for every repo when this logic is applied, but not on each pull / commit when a repo is used in two different systems.

larshp · 2023-03-17T07:51:10Z

We want to build an ecosystem where its easy to share and contribute to code.

Eg. if I implement a cool Fibonacci algorithm in 702, then it should be possible to pull it to Steampunk, and vice versa, without causing too many diffs.

Currently abapGit does not enforce/carry information as to which syntax or statements that are used, its a job for CI to check.

Also, what are the recommendations from SAP on how to build nice systems, eg. I'd guess its nice to have ALV enforced via the software component? Whereas having mixed ALVs should not be a recommended setup?

schneidermic0 · 2023-03-17T07:53:18Z

Maybe if the field is not available, serialize ABAP Language Version "Standard ABAP", if it is available, serialize the one in the system? Then we'll have a one time diff for every repo when this logic is applied, but not on each pull / commit when a repo is used in two different systems.

I had following situation in mind: One developer works in a system which supports ABAP language version (e.g. in the Cloud) and another developer in a system which doesn't support it (e.g. 7.50).
If the objects are developed in ABAP language version for ABAP Cloud, the one system would set "abapLanguageVersion": "cloudDevelopment", the other would set it either to "abapLanguageVersion": "standard" or wouldn't serialize the value at all.

This would lead to a diff for all affected object, wouldn't it?

larshp · 2023-03-17T08:00:29Z

yea, which breaks the ecosystem, as the contribution from a developer on 750 with ALV=standard, cannot be accepted if the author develops on ALV=cloud, even though all syntax and API calls are compatible

(assuming the developers use tooling from SAP, and there are no additional process steps)

schneidermic0 · 2023-03-17T08:03:41Z

Also, what are the recommendations from SAP on how to build nice systems, eg. I'd guess it's nice to have ALV enforced via the software component? Whereas having mixed ALVs should not be a recommended setup?

Recommendation is to go for "ABAP Cloud" and not mixed (per software component). ;)
See also https://www.sap.com/documents/2022/10/52e0cd9b-497e-0010-bca6-c68f7e60039b.html

mbtools · 2023-03-17T11:14:44Z

SAP offers max flexibility by allowing a different ALV for each object. Mixing ALVs in package/swc might be necessary to support SAP legacy scenarios but that does not mean it's a good practice for custom developments nor does it mean that abapGit must support such questionable practices.

It's similar to the "original language" of objects. Sure you could mix English, German, and French objects in a package. But it's not a good idea. For abapGit we decided to define/fix the main language at repo level which enforces the good practice.

Is there any reasonable use case where a repo must support mixed ALVs (note: different branches can still have different settings)? If not, there's no need for abapGit to support it.

How about these options for a repository setting:

Standard: Repo is limited to on-prem (won't work on Steampunk)
Key user: Repo is limited to key user extensibility
Cloud: Repo is limited to BTP and embedded Steampunk (won't work on-prem)
Cross-platform: Repo is compatible with on-prem and Steampunk

When serializing, objects with an ALV that does not match the repo settings are marked as "not supported" (handled the same as unsupported object types).

When deserializing objects, ALV is set according to the following rules:

Standard, Key User, & Cloud:
- If target package does not exist, set ALV to the repo ALV
- If target package already exists and does not match the repo ALV, raise error
Cross-platform:
- If target package does not exist, set ALV to the ALV supported by the system
  - If system supports exactly one ALV, set ALV accordingly
  - If system supports multiple ALV, raise error and ask user to create target package with the desired ALV
  - If system does not support ALV, deserialize without ALV
- If target package already exists, set ALV to the ALV of the target package

schneidermic0 · 2023-03-17T14:07:21Z

Is there any reasonable use case where a repo must support mixed ALVs (note: different branches can still have different settings)?

I can imagine users want to go for "ABAP Cloud", but it hasn't been possible (yet) to change all code to ABAP cloud. E.g., some objects still require to call functionality which is not released by SAP. I am not sure whether you want to move these to a dedicated repository (with a different language version).

How about these options for a repository setting:
...
Cloud: Repo is limited to BTP and embedded Steampunk (won't work on-prem)
...

Actually, ABAP language version "cloudDevelopment" works on-premise, too. This ABAP language version indicates this code can run in the cloud. It does not mean "cloud-only".
Maybe, this is one of the misleading aspects.

Cross-platform:

If target package does not exist, set ALV to the ALV supported by the system
-- If system supports exactly one ALV, set ALV accordingly
-- If system supports multiple ALV, raise error and ask user to create target package with the desired ALV

If system does not support ALV, deserialize without ALV
-- If target package already exists, set ALV to the ALV of the target package

@mbtools If I I understand your proposal, "cross platform" means it is compatible with both, but you want to set the same ABAP language version for all objects in the repository. Right?
Can't we set the repository to "Cloud" in this case. Objects would be set to "Cloud" in systems which support ABAP language version "cloudDevelopment", in other systems it is anyhow "standard".

mbtools · 2023-03-17T15:47:40Z

I see the mixed case then as a customer-specific choice that is not relevant for the ecosystem or for moving code to steampunk (which needs "all cloud"). Pretty much "inner-source". Diffs to other systems won't matter. If that should be supported, ALV must be serialized for each object. Could be another repo setting "object-specific ALV".

You might be right and we won't need "cross-platform". I'm not sure if all steampunk-compatible code runs on an on-prem of the same ABAP release. There's certainly a delay until new cloud features/object types/apis reach "on-prem". If there's compatibility today, is this something that SAP will keep up in the future? Any public statements from SAP about this?

As a developer if I see "Cross-platform" (or "On-prem & BTP"), it's very clear, that it must run on both. If I see "Cloud", I have no expectation of what happens if I try to run it "On-prem"). A separate setting might make sense to have clear intentions and expectations. It would also help when searching for a solution across the ecosystem.

anfisc · 2023-03-17T18:53:53Z

When looking at the discussion I see that various versions of terms are used to describe the name of the ABAP language versions.
When storing ABAP language version as a property for an object I would suggest that the values should follow the names we find in the domain ABAPVRS, namly:
Standard ABAP, ABAP for Cloud Development and ABAP for Key Users
, so we should probably use these values in a camel case like fashion

"abapLanguageVersion" : "standardABAP"
"abapLanguageVersion" : "ABAPForCloudDevelopment"
"abapLanguageVersion" : "ABAPForKeyUsers"

or in an ABAP style

"abapLanguageVersion" : "standard_abap"
"abapLanguageVersion" : "abap_for_cloud_development"
"abapLanguageVersion" : "abap_for_key_users"

fabianlupa · 2023-03-17T19:21:31Z

Maybe if the field is not available, serialize ABAP Language Version "Standard ABAP", if it is available, serialize the one in the system? Then we'll have a one time diff for every repo when this logic is applied, but not on each pull / commit when a repo is used in two different systems.

I had following situation in mind: One developer works in a system which supports ABAP language version (e.g. in the Cloud) and another developer in a system which doesn't support it (e.g. 7.50). If the objects are developed in ABAP language version for ABAP Cloud, the one system would set "abapLanguageVersion": "cloudDevelopment", the other would set it either to "abapLanguageVersion": "standard" or wouldn't serialize the value at all.

This would lead to a diff for all affected object, wouldn't it?

Yes, I thought that scenario wouldn't apply as the 750 developer would have to "blindly" develop compatible code without accidentally using unreleased APIs or disabled ABAP statements. But I guess there is other tooling available to check for compatibility without the syntax check which would rely on the ABAP Language Version.

mbtools · 2023-03-17T19:27:16Z

@fabianlupa in general true and tooling would be a necessity. at the same time, there are also many "open-source ABAP libraries" to be invented which would not rely on any or only well known APIs.

schneidermic0 · 2023-03-19T09:07:01Z

When looking at the discussion I see that various versions of terms are used to describe the name of the ABAP language versions.

I agree, we shouldn't use different terms in the discussion. I suggest to use the same values as they are defined in the ABAP file formats "standard", "keyUser", and "cloudDevelopment".

See https://github.com/SAP/abap-file-formats/blob/ea84f27da76ff525e6262ff1675afe1ef17ba890/file-formats/ddls/ddls-v1.json#L38-L40

schneidermic0 · 2023-03-19T09:20:55Z

I'm not sure if all steampunk-compatible code runs on an on-prem of the same ABAP release. There's certainly a delay until new cloud features/object types/apis reach "on-prem".

Following blog states that ABAP Cloud was released also for the on premise edition of SAP S/4HANA 2022. However, you are right. Release cycles of the cloud editions is faster than the on-premise editions. Therefore, there are already APIs in the cloud editions which are not (yet) available in on-premise.

See https://blogs.sap.com/2022/12/22/abap-cloud/

larshp · 2023-04-27T12:12:18Z

todo, update https://docs.abapgit.org/development/serializers.html

todo, split into concrete development tasks

Preparation for #6154, no functional changes Add class `zcl_abapgit_sap_report` to handle all situations dealing directly with report sources. This provides a central place to handle ABAP language version. Includes factory/injector to facilitate testing and open-abap. Ref #6298

ThomasPloski · 2023-07-13T09:23:18Z

Just want to give you a short overview about the raised pull requests:

Introduce ABAP Language Version as repository setting in .abapgit.xml with no implication to the current behavior. Pull Request Introduce ABAP Language Version (ALV) to .abapgit.xml #6335
Introduce ABAP Language Version functionality as part of new class zcl_abapgit_abap_language_vers. Pull Request #Introduce ABAP Language Version base functionality #6346
a. Check whether an import can be performed based on the the repository settings and package respective software component settings.
b. Determine allowed ABAP language version for a given object/object type and package based on the corresponding software component setting.
Call IS_IMPORT_ALLOWED check within import logic (no change to current behaviour) Pull Request #Introduce ABAP Language Version base functionality #6346
Call GET_ABAP_LANGUAGE_VERS_BY_OBJT for to be deserialized object Pull Request #Introduce ABAP Language Version base functionality #6346

mbtools · 2023-07-13T16:42:48Z

Looks good to me. There's also the case where you create a repo in AG with a new, not existing package. The package is created with the first pull and should inherit the repo ALaV setting. Need to check if this works.

Which SAP releases contain CL/IF_ABAP_LANGUAGE_VERSION?

schneidermic0 · 2023-10-05T15:01:31Z

Object types supporting ABAP language version:

ADVC, AIFC, AOBJ, APLO, AUTH, BDEF, BGQC, CACC, CCAC, CDBO, CFDA, CGRC, CHDO, CHKC, CHKE, CHKO, CHKV, CLAS, DCLS, DDLS, DDLX, DEVC, DMON, DOBJ, DOMA, DRAS, DRTY, DSFD, DSFI, DTDC, DTEB, DTEL, EEEC, EEEP, ENHO, ENHS, ENQU, EVTB, FUGR, G4BA, G4BS, GCPM, GSMP, HTTP, ILMB, INA1, INTF, IWMO, IWOM, IWSG, IWSV, IWVB, LRCC, NONT, NROB, NTTA, NTTY, OA2S, PCFN, RONT, SAJC, SAJT, SKTD, SMBC, SMIM, SOD1, SOD2, SQL1, SRVB, SRVC, SRVD, SUSH, SUSO, TABL, TOBJ, TRPR, TTYP, UIAD, WAPA, WB2J, WMPC, XINX, XSLT

mbtools · 2023-10-05T17:02:32Z

Included in #6476:
CLAS, DEVC, FUGR, INTF, PROG

Supported by abapGit but will need ALAV handling:
AIFC, AUTH, BDEF, CHDO, DCLS, DDLS, DDLX, DOMA, DTDC, DTEL, ENHO, ENHS, ENQU, G4BA, G4BS, IWMO, IWOM, IWSG, IWSV, IWVB, NROB, SKTD, SMIM, SRVB, SRVD, SUSH, SUSO, TABL, TOBJ, TTYP, WAPA, XINX, XSLT

mbtools · 2023-11-01T12:52:26Z

Hello Everyone,

with great effort (#6298, #6476), abapGit is now able to handle ABAP Language Version end-to-end. It's still behind a feature switch and support is limited to the object types listed in the previous comment but should work well otherwise.

Please go ahead and test.

Best,
Marc

mbtools · 2023-11-16T15:51:00Z

Ref abapGit/docs.abapgit.org#184

Issues:

Consistency: "Any" serialized ALaV for classic objects but not for AFF
Compatibility: AFF in AG does not serialize ALaV but other SAP tools would contain it (can't exchange files)
Diffs: Since "Any" contains ALaV in metadata, importing might show diffs

Suggestion:

"Any": Always serialize ALaV
AFF: Always serialize ALaV
New mode "None" (no ALaV): Never serialize ALaV ("Lars Mode"), import sets ALaV based on root package
This might or might not work for a given object. But there won't be diffs.

xtough · 2023-11-17T14:27:05Z

After some internal discussions on how to deal with this repo-setting on Steampunk, we came to a similar proposal like the "Lars Mode":

import any repo, log warning in case repo ALaV is not "Cloud", set ALaV on all objects to "Cloud" upon inactive import --> ABAP Cloud rule violations will surface upon activation in target system (this allows initial import of non-cloud "legacy" code to Steampunk)
export to any repo, log warning in case repo ALaV is not "Cloud", set ALaV on repo to "Cloud", never write ALaV to individual objects (to avoid unnecessary deltas)

We are aware that the 2nd part leaves a bad taste in the mouth but it still seems the better alternative. Otherwise developers intending to use tier 1 extensibility (ABAP Cloud compliant) also in SAP S/4HANA Private Cloud Edition or on-premise would have to be mindful to explicitly set their abapGit repo to "Cloud". If they forgot this small but important step, the ALaV setting on individual objects will be missing on the target system and the whole application will not be usable.

mbtools · 2023-12-08T15:29:49Z

Closing this with #6689 as a follow-up

Any problems, just create a new issue

ThomasPloski added the serialization Translate between object types and files label Mar 16, 2023

ThomasPloski assigned larshp, xtough, ThomasPloski and schneidermic0 Mar 16, 2023

mbtools added the discussion Things to talk about label Mar 17, 2023

mbtools mentioned this issue May 21, 2023

Preparation for handling ABAP language version #6298

Closed

9 tasks

mbtools mentioned this issue May 21, 2023

Consolidate READ/INSERT/DELETE REPORT statements #6299

Merged

ThomasPloski mentioned this issue Jul 5, 2023

Introduce ABAP Language Version as repository setting in .abapgit.xml #6334

Closed

albertmink mentioned this issue Jul 27, 2023

Do the ABAP Language Version for the AFF objects #6375

Merged

albertmink mentioned this issue Aug 21, 2023

[INTF] Write the ABAP language version from the package #6424

Closed

albertmink mentioned this issue Sep 1, 2023

Set ABAP Language Version in settings page of repository #6459

Closed

This was referenced Sep 15, 2023

Add ABAP Language Version to Repo Settings (experimental) #6488

Merged

Enhance ABAP Language Version class #6484

Merged

Handle ABAP Language Version for source code objects #6476

Merged

mbtools changed the title ~~Consistent handling of ALV (ABAP Language Version) during pull/push~~ Consistent handling of ABAP Language Version during pull/push Sep 21, 2023

mbtools mentioned this issue Nov 9, 2023

Add ABAP Language Version abapGit/docs.abapgit.org#184

Merged

mbtools closed this as completed Dec 8, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Consistent handling of ABAP Language Version during pull/push #6154

Consistent handling of ABAP Language Version during pull/push #6154

ThomasPloski commented Mar 16, 2023 •

edited by mbtools

larshp commented Mar 16, 2023

mbtools commented Mar 16, 2023

larshp commented Mar 16, 2023 •

edited

fabianlupa commented Mar 16, 2023

BeckerWdf commented Mar 16, 2023

larshp commented Mar 16, 2023

BeckerWdf commented Mar 16, 2023

anfisc commented Mar 16, 2023

schneidermic0 commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023

fabianlupa commented Mar 17, 2023

larshp commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023 •

edited

larshp commented Mar 17, 2023 •

edited

schneidermic0 commented Mar 17, 2023

mbtools commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023 •

edited

mbtools commented Mar 17, 2023

anfisc commented Mar 17, 2023

fabianlupa commented Mar 17, 2023

mbtools commented Mar 17, 2023

schneidermic0 commented Mar 19, 2023

schneidermic0 commented Mar 19, 2023

larshp commented Apr 27, 2023 •

edited

ThomasPloski commented Jul 13, 2023 •

edited

mbtools commented Jul 13, 2023

schneidermic0 commented Oct 5, 2023

mbtools commented Oct 5, 2023

mbtools commented Nov 1, 2023

mbtools commented Nov 16, 2023

xtough commented Nov 17, 2023

mbtools commented Dec 8, 2023

Consistent handling of ABAP Language Version during pull/push #6154

Consistent handling of ABAP Language Version during pull/push #6154

Comments

ThomasPloski commented Mar 16, 2023 • edited by mbtools

larshp commented Mar 16, 2023

mbtools commented Mar 16, 2023

larshp commented Mar 16, 2023 • edited

fabianlupa commented Mar 16, 2023

BeckerWdf commented Mar 16, 2023

larshp commented Mar 16, 2023

BeckerWdf commented Mar 16, 2023

anfisc commented Mar 16, 2023

schneidermic0 commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023

fabianlupa commented Mar 17, 2023

larshp commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023 • edited

larshp commented Mar 17, 2023 • edited

schneidermic0 commented Mar 17, 2023

mbtools commented Mar 17, 2023

schneidermic0 commented Mar 17, 2023 • edited

mbtools commented Mar 17, 2023

anfisc commented Mar 17, 2023

fabianlupa commented Mar 17, 2023

mbtools commented Mar 17, 2023

schneidermic0 commented Mar 19, 2023

schneidermic0 commented Mar 19, 2023

larshp commented Apr 27, 2023 • edited

ThomasPloski commented Jul 13, 2023 • edited

mbtools commented Jul 13, 2023

schneidermic0 commented Oct 5, 2023

mbtools commented Oct 5, 2023

mbtools commented Nov 1, 2023

mbtools commented Nov 16, 2023

xtough commented Nov 17, 2023

mbtools commented Dec 8, 2023

ThomasPloski commented Mar 16, 2023 •

edited by mbtools

larshp commented Mar 16, 2023 •

edited

schneidermic0 commented Mar 17, 2023 •

edited

larshp commented Mar 17, 2023 •

edited

schneidermic0 commented Mar 17, 2023 •

edited

larshp commented Apr 27, 2023 •

edited

ThomasPloski commented Jul 13, 2023 •

edited