Introduction
I have several weblogs that have been sitting in my drafts folder for some time now. They aren't the most exciting weblogs, nor do they cover cutting technologies. For that reason they keep getting pushed to the bottom of my work pile. I decided this week it was time to get caught up.
My first catch-up weblog really grew out of the same question that I hear over and over again: My company only has R/3 46C. How can I as an ABAP programmer prepare myself for the new Netweaver technologies (such as BSP, WebDynpro, Portal, Java, etc)? My answer is always the same: start writing as much ABAP OO as possible. There are plenty of good weblogs on ABAP OO on SDN. I would also suggest looking through the sessions from TechED of this year and the year before. However what I would like to do today is share a detailed example of a typical ABAP Dialog Report written as a Global ABAP OO class. My purpose it so show those that may not have given ABAP OO a try yet how powerful and flexible it can be. This weblog is also for anyone who might have some experience with ABAP OO in controls programming, but who has never really tried Global Classes for this type of programming.
The Application
Well let's start off by having a look at what my application is trying to do and how it does it. What we are going to look at is a basic Bill of Materials Report. It is similar in form and function to the standard SAP transaction CS11. However my company wanted to add extra information (such as linked Document Information Records, Texts, and AMPLs-Approved Manufactures' Parts List) that the standard report didn't have. We also decided to structure the report as an ABAP Column Tree so that the levels of the BOM could be represented as indented nodes. The following is a screen shot of the report (sorry I had to blur much of the data to protect my company - hopefully everyone still can see how the report works).
The main screen of the report is made up of a custom container with a Tree Control and a Custom ToolBar in it (divided by a splitter control). So we know that we will have control based events to program for. However some of the buttons on the standard Dialog bar (such as back, exit, etc.) are also active. Therefore we will also have standard Dialog events.
Like any good report we have a selection screen. For this I have used normal ABAP Select-Options and Parameters.
Finally before we get into the coding itself there is one last element to consider. If the user doesn't choose an alternative on the main screen and there is more than one on the BOM, we display a popup screen and make the user choose one. The follow is what this popup looks like.
The Dialog Program
We will start by looking at the dialog program itself (and the lack of code that is contained there). Basically the dialog program will still be our entry point. We also still need the dialog program because of some limitations in ABAP OO, the main one being that you can't work with dialog screens. That means that our Call Screen and any PBO or PAI logic has to reside still in a dialog program. Also I had to put my selection screen definition in the dialog program. You should see that even with these limitations, there are still ways to put the majority of your logic in your global ABAP Class. We will look at each section of the program in pieces with comments. However at the end of this section I will include the complete coding for the dialog program so that it can be view in context.
We will start off by looking at the global Data section. You will see that I still need a variable for my OKCode from the dialog screen. Other than that all I have is an instance declaration for my global class.Next up is my Selection Screen definition. Nothing really very interesting here until we get to the value-request selection and at selection-screen validation. This is really the first piece of application logic we encounter. I wanted to put this in my class, but it isn't instantiated yet (You will see later why I wait to instantiate). Therefore I implemented this logic as static methods of the application class.
Finally we reach the start-of-selection logic itself. We will start this section with another call to a static method in order to perform more checks. We are now ready to instantiate our class. With this we pass into the class constructor many of the selection screen fields. Next you can see that even our custom authorization check is contained in the ABAP OO class. At this point we pass in the name of the calling dialog program. This way not only do we have security inside the class, but also for every dialog program that might consume it. Next you can see how the dialog program can work directly with global attributes of our application class. Finally we see that if everything has progressed correctly up to this point, our dialog program will call our main screen (which as far as screen elements, only contains one full screen custom container).
You might notice that I passed a selection option (dokar) into my constructor. To make this easy I created a table type with the structure that would match this range table.
The only other thing about this to pay attention to is the fact that I passed the selection option with a [] on the end of it. Selection Options automatically create ABAP internal tables with header lines. Internal Tables with header lines are no longer allowed in the OO context. Therefore I strip the header line as I pass it to the constructor by using the [] addition (which means - just process the body of the internal table).
Finally before we leave the dialog program we have to look at the dialog flow logic modules.
You can see that once again any of the logic of the program is actually implemented in the class. Even the constants for the OKCode check come from the class (more on that in a minute).
Finally as I promised earlier, the following is the complete code of the dialog program:
The Class Layout
We are ready to start looking at the application class itself. The first interesting thing that we see is from the Properties tab. From here you can see that my application class actually has a higher level Superclass.
Remember that this report is about Bill of Materials. My company has several applications and reports that all read BOM data. Therefore we decided to build one class that would have all the necessary data retrieve routines. Not only would this class contain the logic to read a full exploded multi-level BOM (provided by SAP Function module CS_BOM_EXPL_MAT_V2), but also to gather any additional details about the BOM we might need. The following are the methods and attributes that our report class will be inheriting from this Basic Data Retrieval Class.
Our next little bit of inheritence magic comes in the form of an interface that our application class implements.
My company has written many dialog programs structured like the one here. There are quite a few things (like OKCode constants) that are the same in each one of them. Therefore we place all these items in a general dialog application interface.
Before we move into the some of the logic in our application class itself, let's first look at the structure of some of its methods. You can see in the following screen shots that we have our two methods from our interface that have been redefined in our main class (MAIN_SCREEN_PBO and MAIN_SCREEN_PAI). In light blue you can see our inherited methods from our super class. Later you can see that very few of the exposed methods are public. Only those that needed to be called from the dialog program are marked public. Everything else is defined as Private to make sure that no programmer is tempted to take a short cut and change any of the internal logic from within the dialog program. Finally you can see that a few methods are marked with the event handler icon. These are the event handlers for the controls (toolbar and Tree).
The Class Logic
Once inside the application logic that is implemented in the class, there really isn't that much that is special. However there are a couple of special features that I would like to discuss. The first of which is the control event handlers. This is one of my favorite reasons for creating global application classes. I used to just create my control event handlers as local classes. Not only is this a lot of coding to build the definition of the event handler and its parameters, but I found it difficult to keep them organized in the containing program. Even if I broken them up into includes, this just seemed messy to me. However you will see how nicely everything is organized in the global class builder. First of all our event handler stand out from our other methods because they are marked with the event handler icon. Now if we select one of these methods and hit the detailed view button, we can see what class and event they are a handler for.
Furthermore it is also very easy to pull in all the parameters for the event handler. There is a special button on the Method Parameters screen that will copy all parameters from the event definition. That sure saves on the typing and eliminates the possibility of mistakes compared to local classes.
The last thing that I want to discuss about the logic in the class itself has to do with the before mentioned restriction on interacting with screens from within classes. Remember that we had the requirement to call a popup subscreen from within the class processing. This means the within the class we must call a function module to do this. The other option would have been to use the dialog box container control, but that doesn't fill every need to interact with screens. I know that WebDynpro is the way of the future, but my #1 request for ABAP is still to have an OO implementation of the classic Dynpro screen.
Also to come out of this limitation is that sometimes you might want to trigger navigation (perhaps within a control event handler). I have a sort of trick to accomplish this. First I set a global attribute in my class to a particular value signifying what screen I want to navigate to. Then I use a call to the control framework to trigger a PBO/PAI dummy event. I then have corresponding logic in my PBO/PAI dialog module to direct the flow to the screen signified. Have a look at the following code for an example:
Closing
If you have read this far, I assume that I have bored you with the details of my little BOM report. Hopefully this example shows just how functional ABAP OO is in 46C for writing just about anything. It also shows a few of the limitations that I really wish that SAP would address at some point in the future.
I have several weblogs that have been sitting in my drafts folder for some time now. They aren't the most exciting weblogs, nor do they cover cutting technologies. For that reason they keep getting pushed to the bottom of my work pile. I decided this week it was time to get caught up.
My first catch-up weblog really grew out of the same question that I hear over and over again: My company only has R/3 46C. How can I as an ABAP programmer prepare myself for the new Netweaver technologies (such as BSP, WebDynpro, Portal, Java, etc)? My answer is always the same: start writing as much ABAP OO as possible. There are plenty of good weblogs on ABAP OO on SDN. I would also suggest looking through the sessions from TechED of this year and the year before. However what I would like to do today is share a detailed example of a typical ABAP Dialog Report written as a Global ABAP OO class. My purpose it so show those that may not have given ABAP OO a try yet how powerful and flexible it can be. This weblog is also for anyone who might have some experience with ABAP OO in controls programming, but who has never really tried Global Classes for this type of programming.
The Application
Well let's start off by having a look at what my application is trying to do and how it does it. What we are going to look at is a basic Bill of Materials Report. It is similar in form and function to the standard SAP transaction CS11. However my company wanted to add extra information (such as linked Document Information Records, Texts, and AMPLs-Approved Manufactures' Parts List) that the standard report didn't have. We also decided to structure the report as an ABAP Column Tree so that the levels of the BOM could be represented as indented nodes. The following is a screen shot of the report (sorry I had to blur much of the data to protect my company - hopefully everyone still can see how the report works).
The main screen of the report is made up of a custom container with a Tree Control and a Custom ToolBar in it (divided by a splitter control). So we know that we will have control based events to program for. However some of the buttons on the standard Dialog bar (such as back, exit, etc.) are also active. Therefore we will also have standard Dialog events.
Like any good report we have a selection screen. For this I have used normal ABAP Select-Options and Parameters.
Finally before we get into the coding itself there is one last element to consider. If the user doesn't choose an alternative on the main screen and there is more than one on the BOM, we display a popup screen and make the user choose one. The follow is what this popup looks like.
The Dialog Program
We will start by looking at the dialog program itself (and the lack of code that is contained there). Basically the dialog program will still be our entry point. We also still need the dialog program because of some limitations in ABAP OO, the main one being that you can't work with dialog screens. That means that our Call Screen and any PBO or PAI logic has to reside still in a dialog program. Also I had to put my selection screen definition in the dialog program. You should see that even with these limitations, there are still ways to put the majority of your logic in your global ABAP Class. We will look at each section of the program in pieces with comments. However at the end of this section I will include the complete coding for the dialog program so that it can be view in context.
We will start off by looking at the global Data section. You will see that I still need a variable for my OKCode from the dialog screen. Other than that all I have is an instance declaration for my global class.Next up is my Selection Screen definition. Nothing really very interesting here until we get to the value-request selection and at selection-screen validation. This is really the first piece of application logic we encounter. I wanted to put this in my class, but it isn't instantiated yet (You will see later why I wait to instantiate). Therefore I implemented this logic as static methods of the application class.
Finally we reach the start-of-selection logic itself. We will start this section with another call to a static method in order to perform more checks. We are now ready to instantiate our class. With this we pass into the class constructor many of the selection screen fields. Next you can see that even our custom authorization check is contained in the ABAP OO class. At this point we pass in the name of the calling dialog program. This way not only do we have security inside the class, but also for every dialog program that might consume it. Next you can see how the dialog program can work directly with global attributes of our application class. Finally we see that if everything has progressed correctly up to this point, our dialog program will call our main screen (which as far as screen elements, only contains one full screen custom container).
You might notice that I passed a selection option (dokar) into my constructor. To make this easy I created a table type with the structure that would match this range table.
The only other thing about this to pay attention to is the fact that I passed the selection option with a [] on the end of it. Selection Options automatically create ABAP internal tables with header lines. Internal Tables with header lines are no longer allowed in the OO context. Therefore I strip the header line as I pass it to the constructor by using the [] addition (which means - just process the body of the internal table).
Finally before we leave the dialog program we have to look at the dialog flow logic modules.
You can see that once again any of the logic of the program is actually implemented in the class. Even the constants for the OKCode check come from the class (more on that in a minute).
Finally as I promised earlier, the following is the complete code of the dialog program:
The Class Layout
We are ready to start looking at the application class itself. The first interesting thing that we see is from the Properties tab. From here you can see that my application class actually has a higher level Superclass.
Remember that this report is about Bill of Materials. My company has several applications and reports that all read BOM data. Therefore we decided to build one class that would have all the necessary data retrieve routines. Not only would this class contain the logic to read a full exploded multi-level BOM (provided by SAP Function module CS_BOM_EXPL_MAT_V2), but also to gather any additional details about the BOM we might need. The following are the methods and attributes that our report class will be inheriting from this Basic Data Retrieval Class.
Our next little bit of inheritence magic comes in the form of an interface that our application class implements.
My company has written many dialog programs structured like the one here. There are quite a few things (like OKCode constants) that are the same in each one of them. Therefore we place all these items in a general dialog application interface.
Before we move into the some of the logic in our application class itself, let's first look at the structure of some of its methods. You can see in the following screen shots that we have our two methods from our interface that have been redefined in our main class (MAIN_SCREEN_PBO and MAIN_SCREEN_PAI). In light blue you can see our inherited methods from our super class. Later you can see that very few of the exposed methods are public. Only those that needed to be called from the dialog program are marked public. Everything else is defined as Private to make sure that no programmer is tempted to take a short cut and change any of the internal logic from within the dialog program. Finally you can see that a few methods are marked with the event handler icon. These are the event handlers for the controls (toolbar and Tree).
The Class Logic
Once inside the application logic that is implemented in the class, there really isn't that much that is special. However there are a couple of special features that I would like to discuss. The first of which is the control event handlers. This is one of my favorite reasons for creating global application classes. I used to just create my control event handlers as local classes. Not only is this a lot of coding to build the definition of the event handler and its parameters, but I found it difficult to keep them organized in the containing program. Even if I broken them up into includes, this just seemed messy to me. However you will see how nicely everything is organized in the global class builder. First of all our event handler stand out from our other methods because they are marked with the event handler icon. Now if we select one of these methods and hit the detailed view button, we can see what class and event they are a handler for.
Furthermore it is also very easy to pull in all the parameters for the event handler. There is a special button on the Method Parameters screen that will copy all parameters from the event definition. That sure saves on the typing and eliminates the possibility of mistakes compared to local classes.
The last thing that I want to discuss about the logic in the class itself has to do with the before mentioned restriction on interacting with screens from within classes. Remember that we had the requirement to call a popup subscreen from within the class processing. This means the within the class we must call a function module to do this. The other option would have been to use the dialog box container control, but that doesn't fill every need to interact with screens. I know that WebDynpro is the way of the future, but my #1 request for ABAP is still to have an OO implementation of the classic Dynpro screen.
Also to come out of this limitation is that sometimes you might want to trigger navigation (perhaps within a control event handler). I have a sort of trick to accomplish this. First I set a global attribute in my class to a particular value signifying what screen I want to navigate to. Then I use a call to the control framework to trigger a PBO/PAI dummy event. I then have corresponding logic in my PBO/PAI dialog module to direct the flow to the screen signified. Have a look at the following code for an example:
Closing
If you have read this far, I assume that I have bored you with the details of my little BOM report. Hopefully this example shows just how functional ABAP OO is in 46C for writing just about anything. It also shows a few of the limitations that I really wish that SAP would address at some point in the future.
14 Comments