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.
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
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:
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:
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:
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 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!
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!
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.
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.
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 | |
2 | |
2 |