Introduction
In thread deactivate 'APPROVE' button in the ALV in RCATS_APPROVE_ACTIVITIES. it has been asked how to inactivate an ALV toolbar function within a CATS approval transaction. Having done little work on CATS and none on CATS approval I nevertheless was able to provide the specific solution.
In the following sections I describe my strategy how I found this solution based on my experience and combined with some Learning-By-Doing. Perhaps these insights may be useful for others to improve their solution finding strategies as well.
Background
About three years ago I developed a report for a customer where CATS data needed to be collected, evaluated and aggregated and then used to update cost objects in assessment cycles (transaction KSU2). During this development I became acquainted quite well with class CL_DBSEL_CATS and its BAdI enhancement (see CONSTRUCTOR method):
Following this customer report development I worked for about six months in a localization project for an Add-On of RE-FX (which was one of the best ABAP-OO training I ever had experienced; see Understanding ABAP Objects). In this project I came across an ALV based approval report for rental contracts which I assumed should be somehow similar to the CATS approval report. (see below).
Finally, about half a year ago I answered a question related to BAdI CATS_REPORTING (see Select-options in CATS_DA using BAdI).
The Problem
Below you see the ALV list with the approval toolbar function that should be inactivated (report RCATS_APPROVE_ACTIVITIES).
Thus, the problem can be split into two parts:
- Trivial aspect: Inactivate toolbar function of ALV grid
- Non-trivial aspect: How to achieve this in the context of CATS approval?
My Suspicion
My first idea was that the non-trivial aspect of this problem might be solved by using BAdI CATS_REPORTING (interface IF_EX_CATS_REPORTING).
The solution for the trivial aspect has been described in detail already many times, e.g.:
- BCALV_GRID_05
- Disable Button
The Solution
I created an implementation for BAdI CATS_REPORTING with the implementing class ZCL_IM_US_SDN_CATS_REPORTING. In order to manipulate the ALV toolbar I added the event handler method HANDLE_TOOLBAR which handles event TOOLBAR of CL_GUI_ALV_GRID.
(1) Searching for a Suitable Interface Method
Looking at the interface IF_EX_CATS_REPORTING its method IF_EX_CATS_REPORTING~BEFORE_DISPLAY_APPR immediately caught my attention. Based on its description (Arbeitszeit & Reise Genehmigung vor der Anzeige am Schirm = Working Times & Trip Approval before display on screen) I was convinced having found the right method. The IMPORTING parameter IM_ALV_GRID granted me access to the grid instance used for the approval list.
(2.a) Method Implementation: 1st Try
The first try-out was based on the assumption that I was responsible for both making the toolbar interactive and setting an event handler.
Below you see the first implementation I tried...
...which resulted in a short-dump when I executed the report. Apparently the ALV toolbar instance had not been instantiated yet when I called method SET_TOOLBAR_INTERACTIVE of the grid instance.
(2.b) Method Implementation: 2nd Try
In a silly attempt I tried to catch the exception which - of course - failed because CL_GUI_ALV_GRID does not raise class-based exceptions at its public interface.
(I also tried to replace method BEFORE_DISPLAY_APPR with BEFORE_DISPLAY yet the report never stopped at the break-point meaning that this method was not called during report execution.)
Thus, my assumption on which this coding was based on appeared to be wrong and needed to be refined.
(2.c) Method Implementation: 3rd Try
I modified my assumption that perhaps the standard report would take care of making the toolbar interactive. In this case I would only need to set the event handler method.
Below you see the third implementation I tried...
...and it worked!
The report execution stopped at the break-point in the event handler method. Looking through the entries in E_OBJECT->MT_TOOLBAR it was obvious that function 'CX_APPROVE' was the one that should be deactivated.
A quick look at the data definitions of report RCATS_APPROVE_ACTIVITIES showed that the grid instance was based on class CL_GRID_APPROVAL_ACTEXP which contains the function codes as public constants. The final version of the HANDLE_TOOLBAR implementation is shown below.
And that is how the final result looks like.
Summary
In this weblog I have tried to explain one of the strategies that I apply to find a hitherto unknown solution to a new problem. This scientific approach consists of combining experience with formulating working hypotheses. These hypotheses are tested in a systematic manner.
My first hypothesis that BAdI CATS_REPORTING is involved in the solution proved to be correct whereas the second hypothesis (ALV event handling) required a few cycles of refinement.
Conclusion
The more you know about the domain of the problem the more systematic will be your approach towards the problem. At a certain level of experience this proceeding will lead you almost inevitably to the solution.
4 Comments
