Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
jrgkraus
Active Contributor
In Branching in ABAP?  I described our approach to manage concurring requests for program changes using a branching-like technique.

After 6 months of "living" this approach, I would like to give an overview of our experiences.

Things to be aware of

New methods, attributes and types in classes

Instead of creating them in our branched sub-class, we create them in the master and pass them immediately to the productive system. Since they are not uses if not in the sub class, they do not influence the behavior of the class

Big program sources

We had some really big reports containing many local classes. Merging is very annoying here. We decided, in accordance with the SAP programming guidelines, to split such sources into includes, one for each: class def, class imp, all report events, data declaration, all screen modules.

Master changes in report includes

A change of the master branch in includes can lead to syntax errors in branches - especially when one adds new methods or attributes. Always make a check of the branched versions around when doing this.

Dictionary objects, messages and others

We create and modify those non-source objects directly in the master branch and put them to prod system as soon as possible. Keeping track of different dict types is a mess. When heavy modifications occur, we use new objects instead of modifying the existing ones

Things we introduced

Personalized packages

We started leaving the sources in the original packages. But since we use also a newly programmed "branching cockpit", it comes handy to put all branches in dedicated packages. We did it like this:

  • one general branching package

    • sub-package for each developer




This keeps it simple to have an overview of all branched objects. Since the objects vanish after merging, these packages will not overwhelm with objects.

Branching monitor

One of our programmers wrote a beautiful cockpit transaction that selects all branches and objects related and offers developer notes to be stored and integration of merging as well as creating new objects following the naming convention. Each branch has a dataset in a z-table containing also a status, creation and change dates, responsible person and so on

Branching parameter

In a simple case, a new transaction with the branch name in it can be given to the user for testing it. But when it comes to changes that are deeply nested in several programs, this is difficult. So we created a user parameter for the actual branch. Then we coded a class that determines the possible name of a class or a program source within this branch. Whenever we want to be able to call branched versions of classes, we use this class to instantiate the object. It goes like this:
    zcl_dv04_branch=>get_branch_name(
exporting
iv_name = 'ZCL_CS01_CONF2_TABLE' " 30 Characters
importing
ev_name_br = data(lv_type) " 30 Characters
).
create object mo_conf_table
type (lv_type)
exporting
* io_data = " Datenobjekt für die Rückmeldetabelle
io_model = me
iv_factory_calendar = mv_factory_calendar
iv_present = abap_true. " allgemeines flag

The method call constructs the name of the given class in the branch and checks the existence. If existing, it returns the branch type, if not, it returns the original type. There are similar calls for reports and function modules. Here's the coding of the method:
  method GET_BRANCH_NAME.
data lv_branch(3).
get parameter id 'ZDV04_BRANCH' field lv_branch.

if lv_branch is not initial.
* i.e. 'ZCL_CLASS_TO_BRANCH___________ or 'ZP_PRINT_PROGAM_______________'.
ev_name_br = iv_name.
translate ev_name_br using ' _'.
data(lv_offset) = 30 - strlen( lv_branch ).
ev_name_br+lv_offset = lv_branch.
data(lv_pattern) = ev_name_br && '%'.
select count(*) from trdir
where name like @lv_pattern
into @data(lv_found).
if lv_found = 0.
ev_name_br = iv_name.
endif.
else.
ev_name_br = iv_name.
endif.

endmethod.

General experience

We really are able to manage simultaneous program changes now, although there are cases in which we do not use branching because of unfavourable constellations in the dependencies of older program coding. Merging is a challenging job, but the advantages outweigh this.
3 Comments
Labels in this area