abap language version prevents import into older system

[dominikpanzer]

hi team,
a database table has ABAP language version 5 assigned because it was originally developed in an ABAP steampunk environment. I can't import a function group into older systems because of this. but the table should (hopefully) be compatible with older ABAP versions. here's the demo repo / issue dominikpanzer/ABAP-Meterdata-Manager#1
import via online repository is not possible.
import via offline/zip is possible, but the function group will be skipped

[larshp]

there is a long discussion at SAP/abap-file-formats#44, my opinion is that it should not be part of the XML

try commenting the following line and check if it works, or perhaps it has to be X to set it to unicode compatible

[larshp]

or adjust the XML files manually to be "normal" unicode, which can be imported into both old systems and new Steaumpunk

[larshp]

tho, perhaps we should add a workaround here to have it default to a supported UCCHECK

[dominikpanzer]

ok. it's quite strange. the ABAP language version only exists for a DB-Tabe and ana table type, but not for the FM. ABAPGit imports both without problems. but not the FM. https://github.com/dominikpanzer/ABAP-Meterdata-Manager/search?q=language+version
The FM actually doesn't use the table-type or the db-table.

after reading the thread: it could also work if I just remove the XML-Tag from the objects? I'll try that. Thanks Lars!

[larshp]

Steampunk uses the UCCHECK field for storing the langauge version, see https://github.com/dominikpanzer/ABAP-Meterdata-Manager/blob/main/src/zbilling_functions.fugr.saplzbilling_functions.xml#L14

try setting it to <UCCHECK>X</UCCHECK>, this indicates the program/include is unicode compatible

[mbtools]

abapGit is not handling the language version consistently. for some objects the field is cleared (example DDLS and DDLX), for some it is serialized (PROG, CLAS, FUGR). Function group/modules have additional logic for includes:

abapGit/src/objects/zcl_abapgit_object_fugr.clas.abap

Lines 543 to 576 in 004885f

	METHOD get_abap_version.
	DATA: lt_includes TYPE ty_sobj_name_tt,
	ls_progdir TYPE ty_progdir,
	lo_xml TYPE REF TO zif_abapgit_xml_input.
	FIELD-SYMBOLS: <lv_include> LIKE LINE OF lt_includes.
	ii_xml->read( EXPORTING iv_name = 'INCLUDES'
	CHANGING cg_data = lt_includes ).
	LOOP AT lt_includes ASSIGNING <lv_include>.
	lo_xml = zif_abapgit_object~mo_files->read_xml( <lv_include> ).
	lo_xml->read( EXPORTING iv_name = 'PROGDIR'
	CHANGING cg_data = ls_progdir ).
	IF ls_progdir-uccheck IS INITIAL.
	CONTINUE.
	ELSEIF rv_abap_version IS INITIAL.
	rv_abap_version = ls_progdir-uccheck.
	CONTINUE.
	ELSEIF rv_abap_version <> ls_progdir-uccheck.
	*** All includes need to have the same ABAP language version
	zcx_abapgit_exception=>raise( 'different ABAP Language Versions' ).
	ENDIF.
	ENDLOOP.
	IF rv_abap_version IS INITIAL.
	rv_abap_version = 'X'.
	ENDIF.
	ENDMETHOD.

I missed the AFF discussion last year. The conclusion there looks ok to me (although it's still up to the object type implementation to include the version or not). AG doesn't follow this logic at the moment.

I suggest centralizing the mapping logic in AG since it's now all over. Then add an exit so everyone can have their own release/repo/object-specific logic.

[mbtools]

Closing in favor of #6154