How abapGit handles generated artifacts during export?

[ThomasPloski]

trafficstars

Hi abapGit community,

How abapGit currently deals with the export of generated artifacts?

Situation: During the activation, several objects will be generated based on a main object (e.g. SRVB or SRVC). Will these objects also be exported during a push run?

My assumption would be to identify, whether a to be serialized object is generated or not. Only in case of the object is not generated, the object will be serialized and pushed to the repository.

The impact of the export of such generated artifacts would lead to issues during import or activation.

Every object type has a different storage of the generation information (e.g. GENFLAG in TADIR, part of the individual Object main table etc.), so that every object type handler should provide this information as part of a newly introduced method in the interface zif_abapgit_object, so that the abapGit core can consider the provided information during an export.

What is your opinion?

Cheers, Thomas

[larshp]

should treat generated as non existing, example in https://github.com/abapGit/abapGit/blob/main/src/objects/zcl_abapgit_object_view.clas.abap#L188

documented in https://github.com/abapGit/docs.abapgit.org/pull/13 / https://docs.abapgit.org/development/serializers.html

[ThomasPloski]

@larshp, does it mean that it is recommended to identify the generation information of a given object as part of the exists methode of interface zif_abapgit_object? If yes, we should enhance the documentation you have linked.

[larshp]

yea, and yea

we cannot do it in the serializer itself, and it should not be centralized(see the example)

[ThomasPloski]

Perfect.

@larshp, should we enhance the linked interface documentation for the exists method, so that the meaning is more clear?

[larshp]

yea, pull requests welcome 😄

[mbtools]

There's a bit more to it.

The core logic is in zcl_abapgit_tadir->read. Automatically excluding objects based on tadir-genflag makes sense (we do for delflag).

SKIP_OBJECT is listed in https://github.com/abapGit/abapGit/issues/4187 as one of the items to bring to the serializer interface. But it's probably possible to replace it with the exists method.

I propose two parts:

1. exclude tadir-genflag = abap_true (new)
2. if that's not sufficient, exclude by returning exists = abap_false in the serializer class (depends on object type)

[ThomasPloski]

Hi Marc,

Thanks for your comment.

I suppose the GENFLAG information will be evaluated before the exists method is called, right?

Otherwise we would consider the GENFLAG information also in the exists method (dependent on the object type).

[larshp]

well, I dont think SAP consistently fills GENFLAG, plus not sure exactly what the semantics of the field is.

If the object is generated by importing a different object in abapGit we can ignore it

Objects generated by manual steps in the system, we should not ignore

[mbtools]

the exists method has to be implemented for the generated object type. so if an interface is generated (by another object type), zcl_abapgit_object_intf->exists needs to return abap_false.

it becomes challenging, if an object like srvb generates several objects of different types. then you would have to adjust a few serializer classes. overtime, this will "dirty" these classes with exceptions for handling generated objects.

as far as I know genflag=x means that the object is created/updated in the system by another process and should therefore not be transported.

If the process is triggered by user or automated (f.e. after-import of a transport) does not really matter. There must be a reason why it's manual and therefore the same process should be run manually in the target system. Including them in the repo actually might lead to inconsistencies (f.e. if generating manually leads to different results).

I think we should exclude tadir objects marked as generated.

[larshp]

@ThomasPloski close?

[larshp]

closing