Skip to Content
Technical Articles

abapGit for customizing – Beta Version

Motivation

Since we are well aware of abapGit, thanks to Lars Hvam. We could see more and more open source projects being created/contributed from our ABAP community developers. The abapGit focused on supporting TADIR objects, there were several request from the developers/users to handle the customizing content.

Existing solution is to use the BC Sets to capture the customizing content and export it to repository. Then import this BC Set to target system and using transaction SCPR20, unpack the BC set.

Idea

The idea is, create a BC Set metadata from customizing transport request. The BC Set metadata is created for each object name i.e. E071-OBJ_NAME

 

Beta Version – is not bug free!!

  • Using abapGit(developer version), install the repo abapGitcustomizing
  • Run transaction ZAGC
  • It will list all your cloned repositories using abapGit
    Repository%20list
  • Double click on the repo in which you would like to export your customizing content
    Display%20available%20customizing%20content%20from%20repoSince there is no customizing content in your repo, the list will be empty
  • Use “Customizing Transport” to select the request in which your customizing content is recorded
    Customizing%20contentThe recorded customizing content is converted to BC Set metadata i.e. object type SCP1
  • Select the line and click on “Stage” to export the customizing content to your repository
  • New folder “customizing” is created in your repo and the staged customizing content is available in BC Set metadata format
  • You could also import this customizing using action “Pull” but make sure that there is one open customizing request under your name, so that the customizing content is recorded in that request

Advantages

  • BC Set is an existing tool to handle the customizing content. So there will be many APIs available and we do not need to create anything new 🙂
  • Using BC Set, we can make sure that all the application related checks like foreign keys, table events and screen modules implemented, After-Import methods etc. are executed while content is imported from repo
  • We can also handle the deletion of customizing content via BC Set

Jump In – Let’s start coding!!

Git repo – https://github.com/goreraks/abapGitcustomizing

 

There are some discussions regarding handling of customizing content in abapGit itself. See 3866, 3441, 3834.

But I just started this as a separate project because of pure love for ABAP 🙂

6 Comments
You must be Logged on to comment or reply to a post.
  • Nice job!

    If I’m not wrong, the include zabapgit_password_dialog is missing in your Github repository.

    Could you confirm that one BC Set is created per object name and type, using the template <name>_<type>, in your example that would be the BC Set V_T005_BAS_VDAT. But shouldn’t there be a customer prefix? (“Z” for instance)

    • Thank you!!

       

      Not sure, may be I have missed this include. Since I did some refactoring in the report ZABAPGIT_CUSTOMIZING, I can see that include zabapgit_password_dialog is part of the report.

       

      Yes, One BC Set metadata per object name and type. But no BC Set persistency would be created in the system.

      Since there is no BC Set footprint in the system, so there was no need for customer namespace.

       

      Thanks & Regards,

      Rakshith Gore

      • If you have a dummy BC set(s) in the Git repository, what happens if you pull using AbapGit? Won’t it try to create the BC set(s) and fail if the data is in a standard table/view? In fact, I thought your tool was to help to create BC sets in a minute, and you could then push to the Git repository easily. Having the programs and configuration data in one repository. So I guess that your tool can be used to have a repository of customizing exclusively.

  • This is the “missing link” as it were. It may only be in Beta now but this is so useful that the open source community will chime in and fix up anything missing, so this will just get better and better.

    What this (brings to the table is proper version management for customising which is just not there in standard SAP like it is for workbench objects.

    This is a wonderful time for ABAP development. ABAP has gone from “dead” to not only jumping out of the grave but is actually tap dancing all about the room.