Easy implementation of BEx-Userexit-Variables

[hendrik_brandes]

If you want to control the processing of BEx-Queries you can define different types of variables: Manual Entry/Default Value, Replacement Path, SAP Exit, Authorization or Customer Exit. This blogs deals about how to define such variables and how you can develop them by using ABAP Objects.

UPDATE: A new blog post has been created to this topic: BEx-Userexits reloaded . There, I discuss an important change and share some experiences within the usage of this framework.

Introduction

For implementing customer-exit variables you have to implement the Extension RSR00001 in the transaction SMOD. There have been some documents about it, like http://scn.sap.com/docs/DOC-26617.

The used customer-exit has to following interface-definition based on the function module EXIT_SAPLRRS0_001:

The parameters have the following meaning

• I_VNAM: Name of the Variable
• I_VARTYP: Type of the Variable
• I_IOBJNM: Used InfoObject
• I_S_COB_PRO: Structure with the properties of this InfoObject
• I_S_RKB1D: Structure with the properties of the executed query
• I_PERIV: Current fiscal-period
• I_T_VAR_RANGE: Selected Values of the variablen screen
• I_STEP: Processing Step
• E_T_RANGE: Result-Selection of the variable
• E_MEEHT, E_MEFAC, E_WAERS, E_WHFAC these fields are not used!
• C_S_CUSTOMER: Structure with steering data

The processing of the variable will be managed by the importing parameter I_STEP. Each step represents a specific point in the processing of a variable screen. The following diagram shows the several options. The green check marks means an error-free proceeding and the red bolt means an error is raised by an exception.

For your own variables you will have to program in ABAP your extension and interpret the parameters. This behaviour will be discussed here:

Now - If you want to implement customer-exit variables, you will have several options:

1. Implement directly in the include ZXRSRU01, as it is shown in the SAP Help. Using this way, you will have a very fast implementation, but the price will be very high:

• Every user of exit-variables will have to change this include. The main disadvantage of this approach is the fact, that each modification of this peace of code will influence all users of exit-Variables.
• An error in this include leads into an error for each report with exit-variables.
• Tracing and debugging will be very difficult because you will have to look about the whole source code.
• Some more...

2. Encapsulate your exit-variables. E.g. use function modules or classes for building your user-exit variables. As we are in 2012, I will show a framework with ABAP Objects, which makes it very easy to implement BEx-Customerexit Variables.

By using this approach, you will gain a lot of features, without dealing with them directly:

• Minimal effort for new Variables through Inheritance.
• Type-safe and clear structure for variables.
• No coding dependencies between different variables.
• No redundant parameters while step-processing.
• You can see at anytime, which coding implements a variable.
• Tracing and debugging will be very easy, through a clear structure.

The Idea

The idea is quite simple: Just say, every variable is a instance of a class. Every instance must support at least the following events of the processing-cycle (in Brackets, I write the "old" abbreviation 😞

- Initialization

- before Variablescreen ( I_STEP = 1 )

- after Variablescreen ( I_STEP = 2 )

- Authority check ( I_STEP = 3 )

- check  ( I_STEP = 0 )

Now, put this events in methods of an interface. Why using a interface? I often talk about a contract, when building dynamic systems with ABAP OO based upon interfaces, because both partners ( client and service ) can rely on it. If a class implements an interface, every client can be sure, that this interface will be fulfilled by its specification.

In the following, I will show, how easy it is to encapsulate exit-variables with ABAP Objects. You will need at least these classes:

• A factory for creating and managing variable instances
• An variable interface, which defines the methods of the variable processing
• A abstract variable for building the first node in your variable hierarchy
• Concrete implementations of the variable interface

Look at the UML diagram. The central element is the variable interface, which will be implemented by an abstract class and used by a factory. The used function-pool has been inserted due to the example-class later.

The factory used here based upon the pattern, which I have discussed in http://scn.sap.com/community/abap/application-development/objects/blog/2012/02/20/factory-pattern-in.... At least, the implementation pattern for the BEx-Variables is the so-called "Strategy-Pattern".

I suggest the usage of an abstract class from which every concrete variable should inherit. With this construction, you will gain more flexibility and can reuse a lot of coding.

The Variable-Interface

The interface should looks like this:

Every method of the interface encapsulate a step in the variable-processing. But the main difference is the fact, that every method has only those parameters which are needed in this step.

Now you can see what is the big advantage of using this strategy: At least you have a simple but powerful method signature for each processing step. If you develop a new variable you do not have to consider about "I_VNAM", "I_STEP" and those other parameters, because the method signature has been optimized for each step!

Customization

By using the described factory-oo-pattern, you will have to define a customing table, which holds all implementation classes for the variables. In this table, you can define foreign-keys to the table RSZGLOBV where all variables are stored. With this key, you can ensure, that only variables of type "Customer-Exits" are entered and you can ensure, that only classes with a valid interface are used-for. ( Ok, this check have to be built by another view/search-help ).

By the way: Do you know who and how are your Customizing-Exit-Variables are implemented within your system? Even if you have function modules and select them at runtime - you do not know exactly where they are and if they are existing. With OO-approach, you can even ensure this at design-time!

Implementation in RSR00001

The implementation in the corresponding User-Exit include is even quite easy:

As you can see, the coding in the include is very small and does not include any application specific coding.

At least, it is in the responsibility of each project to define and test the correct variables. But: No variable can destable the whole system!

If you have already an encapsulation, I will suggest that you only create the new variables with this new approach and only changes in existing exit-code will be migrated.

Example

The following class will show, how you can build an implementation class for a customer-exit variable. In my example, I need a customer-exit for determining the last day of the first quarter of the selected year. This exit has to be processed after the variable screen have been executed and the user inputs the selected year.

First, you will have to define your variable in the BEx-Querydesigner - because without this definition, no entry will be made in the RSZGLOBV-table and we use this for our customizing.

After this, you need to create a new class which implements the interface  ZIF_BIU001_VARIABLE. In the described framework, I implemented an abstract class, do this for me and give me some supporting features.

Then you have to redefine the method "after_variable_screen" of the corresponding interface:

In this method you implement your desired functionality. When you look at this code you will discover that it is very short and does not handle to much interaction with the classical BEx-Customer-Exit Interface. So, you can get a clean and stable implementation for BEx-Customer-Exit variables.

The last step for using this variable is the customizing in the customizingtable above.

In one of my future blogs, I will show, how you can tests these variables with ABAPUnit.

Conclusion

In this blog, I show how easy it is to implement BEx-User-Exit-Variables with ABAP Objects. The here shown framework will bring up some very important features:

• A more use-case centric development. For those you will have to implement a User-exit, it will be easier to say "the variable have to been executed {before|after} the variables popup" instead of the classical "i_step"-handling
• Tracability: You can very easy track and debug each variable without having to much effort.
• Easy-Enhancements: Use an abstract class and inherit from this and you will have your new variable.
• Inherit different features for similar use-cases. Through a implementation hierarchy, you can reuse a lot of coding in similar variables.
• Using other patterns like proxy and adapter bringing new aspects to your variables. For example: Tracing-Proxy or Authority-Proxy.
• Unit-Testing with ABAP Unit. No more to say: Using a "variable-class", it will be very easy to build up a Unit-Test for this variable.

The coding examples, I have shown here and the framework itself has been published at the CodeExchange Project "BI-Utils". In the future, I plan to publish some more nice tools in this context.