Postmortem on BD87
We have heard and experienced about the saying “Necessity is the mother of Invention“. As far as application development is concerned, its fair and true to say that “Necessity is also the mother of reuse“. Not just the need for an invention, the need to find out about things which can be reused is also driven by the requirement.
Ever since SAP started supporting ABAP Objects, there are several classes created and being created with the intention to be reused. But there are several solutions which are standardized and stable but it is not classified and distinguished as reusable……
One such requirement forced me to find out and reuse the SAP’s way of reprocessing IDOCs i.e BD87. I had to find out what BD87 does and re-implement the same from a report. It is not possible to call it through CALL TRANSACTION since BD87 is more like a monitoring report involving an ALV tree elements which cannot be manipulated via CALL TRANSACTION or a SUBMIT program.
Thinking like a typical ABAP’er (I hate this noun BTW, nobody says JAVA’er or .NET’er but why title only guys who knows ABAP?), I digged into the program of BD87 and came up with another program (RBDPROCESS) which is internally submitted from the main program. This program will run when the IDOCs are processed together irrespective of the status they are in.
Digging inside the program further, the application logic is triggered by the function module IDOC_INPUT,this FM will help to reprocess the IDOCs in ‘dark’ mode and if it is important to get the output ALV then RBDPROCESS will be of use.
What does BD87 really do ?
The main BD87 program does not make use of the above functionality directly. Instead, the BD87 is built around partially object oriented and partially procedural and main core of it is handled mostly by the instantiation of a two classes, BDMT_CONTROL and BD_LS_MON. The procedural part of the program calls a few methods from these classes for handling ALV tree,gathering IDOC data,displaying and reprocessing.
This was intriguing and I was interested to know whether it is possible to reuse these classes to fulfil my requirement of reprocessing IDOCs manually from a report program. And guess what, You Can !!
How to Reuse?
BDMT_CONTROL is a class that performs the UI part of the BD87 program and mainly for the tree structure.
We are not really interested in the tree but mostly on what the
button do. The class BD_LS_MON has the method PROCESS_IDOCS( ) which in turn has the check for relevant status and does the processing via above RBDPROCESS program. This is exactly what I wanted. Taking a closer look at this method, there are 3 parameters and one of them was mandatory parameter.
The PROCESS_MODE has a default value ‘A’ which represents IDOC processing mode ( A – All, S – Selected ) and IDOC_FROM_NODE contains the list of IDOCs that need to be processed.
The mandatory parameter, IDOC_STAT should be filled with the relevant status of the IDOCs that need to be processed. The important thing to note here is, the IDOCs sent to be reprocessed should be of the same status.
Word of caution: But what happens when I send the status ’51’ and call the method process_idocs( ) ? Will it process all the IDOCs with the status ’51’? Yes it will. So to stop that from happening and let only the required IDOCs to be processed, we need to set the filter for these IDOCs. We can do that by calling the method SET_FILTER( ). This method will set the selection criteria of the BD87 selection screen and only thoseIDOCs that fall under this selection will be taken for reprocessing.
But the IDOCs that come under the selection can be of one or more statuses, that can be identified with the help of the attribute IDOC_STAT. This is a table and it is filled when the method COLLECT_DATA( ) is called. With the help of all these methods, we can successfully reprocess IDOCs hassle free. No need to look for consistency checks since the necessary validations are coded inside the method process_idocs( ) will take care of it.
The result of the processing will be displayed as and ALV that displays the previous status of the IDOCs and its new status. It will be ’53’ if the IDOCs are processed successfully.
Getting the Results Back into the Report:
Now, the processing of IDOCs happen via. the program internally submitted from process_idocs( ) method and the result set will not be available in the program where process_data( ) is being called. But if you need to do further processing with the result (Like updating a Z table with the success results) then we need to get the results back.
This is where I used the trick suggested by Glen Simpson in his awesome blog Gain Programmatic Access to Data of SAPGUI ALV Reports. Using the CL_SALV_BS_RUNTIME_INFO class, the ALV data of the submitted program can be easily brought back to the report and the filter out the IDOCs with the NEW_STATUS as ’53’.
Summing it Up:
Thus the four step to get things done are :
It is always fascinating and interesting to find things that makes our lives easier and it gives a sense of satisfaction if the things that we build are more structured and manageable.
Programing is always a trade off between design, efficiency and quicker development time. Efficiency and development time are measurable even by a non-programmer, but design, is always the aspect that gives sense to the code and satisfaction to the guy who maintains your code. Even-though the other two factors can get you to heights,design is one of the key differentiators between good and bad programmers.Before beginning to develop anything, I like to think of what Alan Kay said,
“ Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. ”
P.S: Pardon me if you think that the title is a little macabre, I thought its interesting.
Disclaimer: The techniques and views represented in this blog are just my opinion and it is not related anyway to the organization that I work with. Please use it or follow it under your own discretion.