Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.
SAP NetWeaver Application Server ABAP
SAP NetWeaver Application Server ABAP provides highly valuable innovations with SAP NW 7.02 and 7.03, they cover a wide range from language and tool enhancements to UI technologies and services, but don’t be concerned you can still rely on your existing ABAP skills and easily extend to emerging technologies like In-Memory, Cloud and Mobile.
Lets take a overview look at the key needs and innovations introduced in ABAP 7.03 for custom development.
ABAP 7.03 – Custom Development Enhancements
Lets take a overview look at the key needs and innovations introduced in ABAP 7.03 for UI (User Interface)
ABAP 7.03 – Custom Development Enhancements for UI
SAP NetWeaver Business Client 3.5 (NWBC)
New Side Panel for enriching applications without ABAP modifications
The SAP NetWeaver Business Client (NWBC) is a rich desktop client that offers a unified environment for and a single point of entry to SAP applications. It provides a solution for hosting classical dynpros (SAP GUI UIs), Web Dynpro applications, BSP pages, portal pages, and other content. You can use the SAP NWBC either with or without the portal depending on whether you want to access ABAP back ends directly or not.
The SAP NWBC also supports generic desktop functions, like drag and drop, popup windows, and so on through the utilization of the corresponding APIs. The result is an efficient, modern and attractive client environment ideally suited to the power user.
-Adds instant value to custom specific apps and 500+ SAP GUI apps in SAP Business Suite 2011
-Interoperability between ABAP Dynpro and Web applications running in NWBC Side Panel
-Contextual data from Dynpro applications can be accessed by WD ABAP, WDA Page Builder and JavaScript/HTML applications
-Enterprise Search enabling
-All active Enterprise Search connectors are automatically offered as search providers
-Central administration
The side panel in more detail
Side Panel used for Notes / Attachments
Side Panel used for Master Data Detail Information
Side Panel used for BI Analytical Content
For more information about NetWeaver ABAP AS Business Client, see SAP Note 900000.
For release restrictions, see SAP Note 1620514 (NWBC for Desktop) and SAP Note 1620576 (NWBC for HTML).
For the latest changes and updates to the documentation for SAP NetWeaver Business Client 3.5, see SAP Note 1757400.
To view the first blog in this series please click What’s New in ABAP 7.02 and 7.03 – Part 1
In the next part of this BLOG series on What’s New in ABAP 7.02 and 7.03, I will take a look at the Floor Plan Manger for Web Dynpro , The “Business Rule Framework Plus” and SAP Stream work.
If you enjoyed this blog on What’s New in ABAP 7.02 and 7.03, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels 
Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.
SAP NetWeaver Application Server ABAP
SAP NetWeaver Application Server ABAP provides highly valuable innovations with SAP NW 7.02 and 7.03, they cover a wide range from language and tool enhancements to UI technologies and services, but don’t be concerned you can still rely on your existing ABAP skills and easily extend to emerging technologies like In-Memory, Cloud and Mobile.
Lets take a look at each release and I will try and distill what it’s FOCUS is for us, the developers..
SAP NW ABAP AS 7.02 – Focus on ABAP Language, tools, UI developer productivity
- New language features for more efficient business programming (2nd keys for internal tables etc.)
- Higher developer productivity (code-completion, layer-aware debugging, debugger scripting etc.)
- Enable harmonization and extensibility with Floorplan Manager
SAP NW ABAP AS 7.03 - Focus on end user experience and development services
- Enjoyable user experience with SAP NetWeaver Business Client 3.5 and side panel
- Easy configuration & custom development with Floorplan Manager using WebDynpro ABAP
- BRFplus innovations (Business Rules Framework)
Future Direction - Focus on In-Memory, Cloud, Mobile and developer productivity
- Leverage potential of In-Memory (push code to data, HANA, etc.)
- Higher developer productivity and open standards with ABAP in Eclipse
- Strengthen Cloud infrastructure
Lets dig a little deeper in each release and see what innovations SAP has provided us in the ABAP Language and Tools area.
ABAP 7.02 – Custom Development Enhancements
ABAP language improvements
- Secondary keys for internal tables
- Resumable exceptions
- Data types for exact calculations of large numbers
Developer Productivity features
- Comprehensive string processing
- Efficient and resource optimizing memory usage
- Complete code completion, use expressions as operands and more
Testing, Debugging, Runtime Analysis and Memory Inspection of multi-layered web-based applications
- Coverage results integrated with ABAP Unit results, ABAP Unit Browser in SE80, more detailed coverage results
- Debugger Scripting, Layer-aware Debugging, External Debugging
- Memory Analysis of Web Dynpro for ABAP applications
- New ABAP Runtime Analysis SAT (successor of SE30)
Intelligent Code Completion
Use the keyboard shortcut Ctrl+Space to access the information you need right at your fingertips. Intelligent code completion proposes what to type in and inserts the text proposed: for the entry of all methods, attributes, and interfaces of global and local classes, function modules, and so on.
Secondary keys for internal tables
Internal tables just got even better! Use secondary keys to improve the performance of your application.
New ABAP Runtime Analysis (SAT)
State-of-the-art debugging
In the next part of this BLOG series on What’s New in ABAP 7.02 and 7.03, I will take a look at the Custom Development changes in ABAP 7.03 as well as the new Custom Development Enhancements for UI i.e SAP NetWeaver Business Client.
If you enjoyed this blog on What’s New in ABAP 7.02 and 7.03, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
ABAP OO in your Custom Workflow – Part 3
Lets conclude our exploration of ABAP OO and using it in SAP workflow. In this final post, Bill will continue his discussion of classes, introduce functional method calls, and give us some great tips we can use as we move forward in our own coding. Here is a little bit about Bill….
Bill Craig is the president of ASAP Consulting Inc., located in Centennial, Colorado. Bill has over 10 years of experience with SAP ECC systems and integration with SRM. His areas of expertise include SAP Business Workflow and ABAP development. He made his way into programming as a COBOL programmer, switching to SAP when the company he worked for migrated from mainframe programming to SAP. Prior to programming, Bill ran an upholstery shop in Denver, where he managed the workforce, payroll, sales, scheduling and delivery. You can reach him at bill.craig@asapconsultinginc.com
ABAP Object Oriented Coding and Workflow BOR Integration
In the first part of this blog regarding the use of ABAP OO with SAP Workflow, I explained how to use an ABAP OO class to start a workflow as well as call one of the methods in the class from a work item. In this final installment I will demonstrate how to instantiate an ABAP OO class from workflow, the use of functional methods, and finally some tips I have learned while developing custom workflows using ABAP OO.
Since BOR is still a common repository for a number of objects it is likely that you have a workflow that is triggered by a traditional BOR event. But for our demonstration purposes you want to use a class to handle many of the functions and rather than add these methods to the BOR. You want to utilize an ABAP OO class.
When the workflow starts you have an instance of the BOR object which is defined by the key fields that were instantiated and passed during the normal event creation. Now you want to instantiate the class which you are going to utilize. Leveraging the class we developed in the previous blogs, create a method that has in input parameter as which is the key to the class, and an export parameter that is a type reference to your class. The method ‘CREATE_INSTANCE’ is defined as static and public.
Create a New Workflow Task
Create a task using the Workflow Development Tools which calls the new method, and make sure to indicate that it is ‘Synchronous object method’.
Next, include this task in a custom workflow. For this demonstration I created a workflow that is started from BOR LFA1 event CREATED. Test the workflow using SWUS passing in the key to LFA1 which is the Vendor Number. View the workflow log and container to see that you now have an instance of the ABAP OO class which will allow you to reference the class methods and attributes.
Within a BOR object you can have different types of attributes, so that once the object is instantiated the value is calculated.
To do the same in a class, you can create an attribute that is populated from a method that is executed from the constructor method. I created a simple attribute ‘VENDOR_NAME’ as a read only attribute. I then created a method named ‘READ_ATTRIBUTES’ which will read the name of the vendor and populate the attribute. I placed the execution of this method into the constructor, and when the class is instantiated the ‘VENDOR_NAME’ is populated and is available to workflow.
An alternative to an attribute would be a functional method. These would be an approximate equivalent to virtual attributes for a BOR object. The added value here is that you can pass in parameters to use during the method, and you can call these methods again and again when you need to rather than only executing the code when the class is instantiated.
I created a method to get the list of user ids assigned to a particular work center. I then created a simple task that passed in the value of the work center and returned the users assigned.
Experience Matters….. Tips &Tricks
Lastly I wanted to share an issue that I ran into while using ABAP OO with a new custom workflow that I had created. When I first learned workflow I was taught to develop the method first, then a task that calls the method and finally insert the task into the workflow. This would allow the system to automatically generate the container elements required at each step so that I only defined them once at the method level. I still use this practice today, but while developing my first ABAP OO based workflow I had used a method from a class where the return parameter was typed using ‘begin of’ instead of a data dictionary type.
So when I went to create the task to call the new method it automatically created the data element with a definition as below.
This worked in development and tested just fine. The issue was when we transported the workflow and class to the QA environment, the transport failed with a return code of 12. After several attempts to fix it, I finally discovered that the workflow was unable to generate because it could not find the type CLASS=ZCLZZ_WF_DEMO_CLASSTYP which was truncated. In order to fix it I had to create a structure that matched the definition to use as the type and it transported successfully.
Final thoughts…
Using ABAP OO with my workflows has been a learning experience, which has allowed me to enhance my knowledge of ABAP OO as well as workflow as more SAP developed workflows go down this route. As I stated in the first part of this series, I have been comfortable using BOR for many years, and had to step outside my comfort zone in order to try using ABAP OO. It was not an easy first step, but as with any new skill, the more you do it the easier and better you become.
If you want to read Part 1 of this Blog Series click ABAP OO in your Custom Workflow – Part 1
If you want to read Part 1 of this Blog Series click ABAP OO in your Custom Workflow – Part 2
If you enjoyed this blog on SAP Workflow, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
ABAP OO in your Custom Workflow – Part 2
Lets continue our exploration of ABAP OO and using it in SAP workflow. In this post, Bill will show us how to use ABAP Classes to streamline our code for an easier and elegant solution. Here is a little bit about Bill….
Bill Craig is the president of ASAP Consulting Inc., located in Centennial, Colorado. Bill has over 10 years of experience with SAP ECC systems and integration with SRM. His areas of expertise include SAP Business Workflow and ABAP development. He made his way into programming as a COBOL programmer, switching to SAP when the company he worked for migrated from mainframe programming to SAP. Prior to programming, Bill ran an upholstery shop in Denver, where he managed the workforce, payroll, sales, scheduling and delivery. You can reach him at bill.craig@asapconsultinginc.com
Using ABAP Object Oriented Coding in your Custom Workflow
In the first part of this blog regarding the use of ABAP OO with SAP Workflow, I explained some of the benefits of using ABAP OO with your custom workflows. In this part I will go into more detail about creating an ABAP OO class and using it within a workflow. This blog does not go into great detail about ABAP OO programming so learning some basics via other blogs or books is helpful.
Creating a class that can be used by workflow is a little more time consuming than creating a copy of a standard SAP Business Object and delegating your new object, but once you have done it a few times it is rather simple and allows you to utilize ABAP OO.
Using SE24 I created a class ZCLZZ_WF_DEMO_CLASS which I will use in this example to represent a vendor. In order for workflow to be able to use this class you need to add the interface IF_WORKFLOW. The important part of this interface is called the Local Persistent Object Reference, which is used to convert the workflow object reference into the specific instance of the ABAP Class, as well as the reciprocal. This transformation is handled in the two interfaces included with IF_WORKFLOW; BI_PERSISTENT and BI_OBJECT.
The methods BI_PERSISTENT~FIND_BY_LPOR will convert the current object reference used by workflow into instance of the ABAP Class. The BI_PERSITENT~LPOR method will convert the ABAP instance into the workflow instance. While this communication was handled behind the scenes with BOR objects and workflow, a little bit of coding on your part is now needed.
Once the interface has been added, you need to open each method inherited from IF_WORKFLOW and activate the empty source code. As mentioned previously, the methods FIND_BY_LPOR and LPOR are the ones we need to concentrate on.
Below is the code that I added to the CONSTRUCTOR, FIND_BY_LPOR and LPOR methods, as well as the Class Attributes required.
Workflow Class Attributes:
Workflow Class Constructor:
Workflow Class – Method FIND_BY_LPOR:
Workflow Class – Method LPOR:
Next, I created a simple method DISPLAY_VENDOR which we can use in a task in our workflow for the user to execute with an exporting parameter of RETURN to match our BAPI call
The next step is to create an event which we will use to start our new workflow, as well as a method to raise the event. On the events tab I created an event START_WF. I did not include any event parameters but it is as simple as clicking on the PARAMETERS button and adding them if you need too.
Next I created a method that would raise our new event. The code for this is a little different than the function module calls we are used to using like SWE_EVENT_CREATE or SAP_WAPI_CREATE_EVENT. Instead you use a call to class CL_SWF_EVT_EVENT method RAISE or RAISE_IN_UPDATE_TASK.
If your event has parameters in an event container, call the method GET_EVENT_CONTAINER to return the definition from the event, and/or SET_EVENT_CONTAINER to populate the event container parameters.
OK – We are ready to use our new class in a Workflow!!
I have built a simple workflow that will start from our event defined in our ABAP OO class, as well as call a task using our DISPLAY_VENDOR method.
From the workflow builder screen (Part of Workflow Development Tools) click on the define workflow Triggering Events tab, and rather than selecting BOR Object Type, instead select ABAP Class as the object category. Enter the class and the event, and bindings, binding the event object to a workflow container defined as your class, and finally activate the event.
Next, create a task that calls the method within the class. A trick you need to know, is that after you save the task, you need to check the Synchronous object method box
Once you have inserted the task into your workflow and activated it you can test the process from SE24 and executing the method START_WF. If everything was done correctly you will see your workflow was started and by executing the work item in the Workflow INBOX, the vendor is displayed.
This is just a very simple example, but as you can see using ABAP OO opens up a whole new dimension to workflow processes. As I stated in the first part of this blog, most of the workflows that I have done in recent years aren’t designed to deliver the work to the right people at the right time, but rather to automate as many processes as possible in an effort to minimize segregation of duty issues. With ABAP OO it is much easier to incorporate complex code and access standard SAP logic.
In the next part of this blog I will go into more details about work items using ABAP OO, how to create the equivalent of BOR attributes within the class, as well as some tips and tricks that I have learned and continue to learn as I expand my use and knowledge of SAP Workflow using ABAP OO.
If you want to read Part 1 of this blog click ABAP OO in your Custom Workflow – Part 1
If you enjoyed this blog on SAP Workflow, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
ABAP OO in your Custom Workflow – Part 1
In the next few installments of this blog I will be inviting a good friend of mine William Craig to teach us about ABAP Object Oriented coding and custom workflow development. Here is a little bit about Bill….
Bill Craig is the president of ASAP Consulting Inc., located in Centennial, Colorado. Bill has over 10 years of experience with SAP ECC systems and integration with SRM. His areas of expertise include SAP Business Workflow and ABAP development. He made his way into programming as a COBOL programmer, switching to SAP when the company he worked for migrated from mainframe programming to SAP. Prior to programming, Bill ran an upholstery shop in Denver, where he managed the workforce, payroll, sales, scheduling and delivery. You can reach him at bill.craig@asapconsultinginc.com
Using ABAP Object Oriented Coding in your Custom Workflow
SAP Business Workflow was built on an approximation of object orientated programming called the Business Object Repository or BOR. It uses object oriented techniques which allowed developers the ability to create copies of standard BOR objects, modify them and through inheritance allow them to be used in place of the standard.
This was my comfort zone. I learned SAP and ABAP programming using BOR objects, creating attributes, coding methods, and developing workflows to meet my client’s needs. As a workflow consultant I was special, as most of my ABAP friends felt intimidated by the concept of workflow and using Business Objects. However, as I enjoyed my specialized skill, I started doing a lot more ABAP development apart from workflow, and realized the new tools such as the ABAP workbench were much easier to use that the Business Object editor.
When I used the Business Object Editor I felt I was going back towards my COBOL days of 72 column limitations. How free I felt being able to write code that continued right past my visible screen. Then came ABAP OO, and I started to realize my version of object oriented programming, was a far cry from where SAP was heading. I was an old dog! I enjoyed the ABAP workbench, but at the same time I intimidated by what seemed to me as a completely new programming language.
ABAP OO and Workflow – The Turning Point
A couple of years ago, I was working with a Workflow consultant who I did not know, and as soon as he was done with his first workflow I decided I would take a peak to see what level of developer was on our team 
Well, I opened the workflow, went to the triggering events, and saw an ABAP class rather than a BOR as the triggering event. I drilled into the class, saw all of the methods, attributes, types, events, and realized all of his tasks used this class as well. As I looked at the workflow I was immediately impressed. While I had been relying on my use and knowledge of BOR, this Workflow consulting had taken the next step and was using ABAP OO for everything. At that point I decided I needed to figure out how to use this new technique, and force myself to learn using ABAP OO in this way.
Why Use ABAP OO for SAP Business Workflow?
Now that I had a mission, I had to figure out what the advantages of using ABAP OO had over BOR. As I started investigating, reading blogs, workflow books, and looking at our current SAP system, I started to find that SAP was using ABAP classes for many of their own workflow processes, and most of their code base was now ABAP OO.
I kept on seeing was that the code was easily maintained by ABAP programmers without workflow knowledge, A huge advantage! I had to think about this one. My lively hood depends on the fact that clients need workflow specialist. But as I continued pondering this dilemma, I also came to the conclusion that if I did not start to learn this, I would not be able to maintain the newer workflows that utilize ABAP OO. In addition, if I could master ABAP OO I would be able to broaden my skill set and my own marketability.
I have worked with various customers and clients over the past decade and I have noticed that most of the workflows that I have developed aren’t as much about delivering decision tasks to the correct people, but rather automating a complicated set of procedures that cross various functional areas of responsibility. This is where ABAP OO can really help. Complex code used for common business processes is much easier to access and reuse with classes and methods instead of the traditional BOR Editor.
Now please do not misunderstand me…. There is still a need for BOR and the use of it in SAP Business Workflow. A lot of business processes have been built on this foundation, and to replace them with ABAP OO would not make fiscal sense, as the cost of developing, testing, and the disruption to current processes would be too great. So when a new requirement came along which did not have a current workflow I could build upon, I took the plunge and built it using ABAP OO.
Now that you can have a good understanding of how SAP Business Workflow can benefit from using ABAP OO, the next blog will get into details on how make a custom class usable in workflow as well as how to create events and start workflows using ABAP OO.
If you enjoyed this blog on SAP Workflow, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
An introduction to Web Dynpro – Part 3
Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.
Getting started with Web Dynpro
OK, like I promised, I will dive deeply into the MVC Object design pattern and the way SAP has modified and extended it.
While many of you may be familiar with the MVC design paradigm, SAP has modified and extended it, so you need to understand what the differences are, why they are there, and what consequences those differences will have on the way you think when writing Web Dynpro applications.
The Model View Controller (MVC) design concept
The MVC design concept is not at all new.12 In fact, it was created in 1978 by a Norwegian software designer named Trygve Reenskaug. At that time, he was working as a visiting scientist in the Smalltalk group at Xerox PARC and was faced with the problem of designing a system in which users would have to control large and complex datasets. Here’s how he assessed part of the problem:
Problem
The input and output aspects of the [program] are technically very different with few inter-dependencies. Their combination in a single object tends to make this object unnecessarily complex.
Solution
Let the [program] contain two objects; a View object responsible for presentation, and a Controller object responsible for taking and interpreting input from the user.
I believe this is the very first time the idea of separating data presentation from data processing had actually been stated as an explicit design requirement. This idea is commonplace today, but in 1978 it was a huge conceptual leap. The result is that he split the program up into at least two parts: the view and the controller, with each part having a very distinct role to play. Having the view and controller was all very well, but the part of the program that would perform the actual business processing had still not been identified. Reenskaug recognized that a third unit of software was needed in order to have a fully functional program. This is where the model came in. To use Reenskaug’s own words again:
MODELS
Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects…
OK…I get it now…So, the model represents what the user knows (e.g., how to create a sales order), and all the information held within it relates to the business task at hand, or if the task is very complex, relates to some well defined stage of the business process.
The view is the part with which the user interacts (i.e., what appears onscreen, such as menus, push buttons, drop-down lists, and option buttons).
Finally, the controller is the intelligent part — this is where the processing takes place to determine the views the user sees on the screen, and then, based on the user interaction, determines the views the user sees next.
The essence of the MVC design concept
Many people think of MVC design pattern as a means for separating data presentation from data processing, and this is certainly true. However, the separation of data presentation from data processing is only one use case of a much more fundamental concept — namely, the separation of those parts of the program that generate data from those parts that consume data — and it is this fundamental principle that you see time and again within the Web Dynpro architecture.
Those parts of a Web Dynpro application that generate data (the models) are strictly separated from those parts of the application that consume data (the views). A controller acts as a middleman between the models and the views, and its role as a consumer or generator varies depending on which entity is being communicated with.
When designing and writing Web Dynpro applications, you must be careful not to blur the boundaries between data consumers and data generators. If, through lack of understanding or wanting to achieve a quick result, you do blur these boundaries, then it is possible that you will end up writing poor quality code.
Understanding the generator/consumer concept explains why SAP has extended Reenskaug’s original concept and consequently implemented an MVC toolset that is different from other vendors’ MVC implementations.
SAP’s adjustment to the view concept
To achieve the required level of client independence, SAP found it necessary to modify the concept of a view. Traditionally, views have been implemented as templates containing HTML and some executable coding; for example, Java Server Pages (JSPs) are HTML templates containing embedded Java coding. Unfortunately, this type of implementation carried with it all the problems SAP was trying to escape from in Web development.
With views implemented as HTML templates, the developers needed to be concerned with such client-specific rendering issues as:
HTML
JavaScript
Cascading Style Sheets (CSS)
Support for multiple client types
These development areas alone can consume in excess of 50% of the implementation timescale. This is exactly the situation the SAP Web Dynpro designers wanted to avoid. Instead, a Web Dynpro view needed to hold the UI definition in a client-independent manner. Then at runtime, the Web Dynpro Framework (WDF) determines which HTML and JavaScript statements are needed to render the screen on any particular device. To achieve this, SAP needed to modify the concept of an MVC view.
It is within a view controller that you define the layout of the screen, but to avoid having to write any HTML or JavaScript, you define the screen by making simple abstract declarations:
“I want an input field here” or “I want a drop-down list over there.” This approach means you don’t waste time struggling with HTML and JavaScript because the task of generating HTML and JavaScript has been delegated to the WDF. At runtime, the WDF renders your view for whatever type of client device is currently running the application (and this could be something other than a browser, for example, a Blackberry or a Nokia Communicator).
The view controller has its own section of coding that prepares data for display and responds to user actions on the client. All this coding has been designed to operate without you ever needing to worry about how the specific UI elements should be rendered on the client. All you need to remember is that Web Dynpro displays information on the screen using a special type of controller (one with a visual interface).
So I am sure you have a question…..
So when I write a Web Dynpro program, I’m just writing views, models, and controllers?
Remember I am a consultant…. the answer is ……. Well — not exactly……
MVC is just a design concept in the same way that object-orientation is a design concept. Therefore, every software vendor that implements an MVC-based design tool does so in a slightly different way and with a slightly different interpretation of the principles. SAP is no exception here. In fact, SAP has extended Reenskaug’s original MVC concept by introducing a completely new entity known as a “component.” Without this new entity, the Web Dynpro designers found they could not correctly implement one of their key design requirements: namely, code reuse at a business level.
The Web Dynpro component concept
When you write a Web Dynpro program, you will need to write models, views, and controllers. However, these units of code are packaged together into a larger unit called a Web Dynpro component. When you write a Web Dynpro application, you must write at least one component. The component is now both your unit of development and your unit of reuse. Now I can hear you saying why not just reuse a view, well It could be argued that views, controllers, and models could all be reused as independent units. This is true, but this was not the type of reuse SAP was after. If the only reusable units of code were low-level ones such as views and controllers, then you would create the situation in which object reuse was not directly related to any step of a business process.
Since the whole thrust of Web Dynpro was aimed at modeling and then solving business problems, the technical details of how the problem should be solved were of lesser importance. Therefore, the unit of software reuse should correspond to a distinct step of the business process, not some low-level, technical unit of coding. So when it comes to code reusability, MVC uses the following unspoken principle:
Coding is bad…if you have to write the same piece of code twice.
Using Web Dynpro’s component reuse concept, the thought is you should be able (with some careful design) to slash UI development times by more than 50% by creating a library of reusable components — each one corresponding to a distinct step of a business process.
When developers are now asked to write a new application, their job consists of:
1. Analyzing the business process to identify where currently available Web Dynpro components can be reused
2. Designing and writing new Web Dynpro components to fill any functional gaps
3. Assembling the components together into the required business application
The whole emphasis of code reuse in Web Dynpro focuses on discrete steps in the business process and not on the low-level units of code required to implement those steps. This means that a Web Dynpro component contains several distinct coding entities that all function together to deliver a single unit of business processing. A Web Dynpro application is then built using one or more Web Dynpro components as reusable building blocks.
OK at this point I am sure you want to start writing Web Dynpro’s. I understand, so I will end this with a quick recap on concept and principle and then provide you with several links. The first set will be to a great series on the SDN to learn and build a series of Web Dynpro’s from scratch starting with the infamous “HELLO WORLD”. The other link will be to a great book I believe will help further your understanding.
Let’s quickly recap what you’ve learned about Web Dynpro:
- Web Dynpro is a toolset for developing the UI layer of a business process.
- The Web Dynpro application does not care what front-end technology is used to display the business data.
- All Web Dynpro development is packaged into reusable units known as components. The component is both the unit of development and the unit of reuse.
- Try, as much as possible, to design each component so it represents an atomic unit of business processing.
OK, here are the links to the series on the SDN. Please take them in order.
Introduction to Web Dynpro ABAP: Part 1
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this first part we begin by explaining the motivations in the design of Web Dynpro.
Introduction to Web Dynpro ABAP: Part 2
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this second part we discuss the Web Dynpro ABAP programming model.
Introduction to Web Dynpro ABAP: Part 3
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this third part we learn about the View and placing UI elements on the screen.
Introduction to Web Dynpro ABAP: Part 4
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this fourth part we explore how to model data in the context and respond to events with event handler methods of the controller.
Introduction to Web Dynpro ABAP: Part 5
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this fifth part we expand our project to include the Component Controller, Context Mapping and multiple Views.
The book I recommend is
http://www.sap-press.com/products/Getting-Started-with-Web-Dynpro-ABAP.html
If you want to read Part 1 of this Blog series click An introduction to Web Dynpro – Part 1
If you want to read Part 2 of this Blog series click An introduction to Web Dynpro – Part 2
If you enjoyed this blog on Web Dynpro, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
An introduction to Web Dynpro – Part 2
Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.
The Web Dynpro development environment
You can build Web Dynpro applications using one of two development tools: SAP NetWeaver Developer Studio (NWDS) for Java, as shown in Figure 1, or the ABAP Development Workbench, familiar to all ABAP developers, as shown in Figure 2.
One of the best things about building Web Dynpro applications is that their architecture is defined declaratively, rather than programmatically. This means that you use graphical tools to build units of the application — for example, screen layout, the navigation paths from one screen to another, and the data structures used to hold the business data — and then the Web Dynpro development environment ties them together to create the final application.
This doesn’t mean you don’t have to write code, you do have to write some code, but using Web Dynpro, the quantity has been significantly reduced. The declarative part of the application design is where you specify:
- The major structural units of the application (known as components) and how they interact
- How information is to be displayed on the screen
- What data structures are to be used to hold the displayed data
- The various navigation paths from one screen to another
- How information is shared within the different components of an application
- Interaction with a business back-end system
Taken together, these declarations form a description of your business application known as the Web Dynpro “metamodel.”
The SAP original development environment idea for Web Dynpro
Originally, SAP intended to have a single, language-independent development tool in which the abstract metamodel would be created. Then the information from the metamodel would be fed into the appropriate Java or ABAP code generator to create the required coding. All you would then need to do is write the additional coding to manipulate the business data. (see below)
The actual Web Dynpro development environment
As the development of Web Dynpro started, it rapidly became clear to SAP that it would be far more economical to have the Web Dynpro tools and code generator within the confines of a language-specific development environment. Consequently, all the tools for developing Web Dynpro for Java applications can be found within the Java development environment(NetWeaver Development Studio), and all the tools for developing Web Dynpro for ABAP applications can be found within the ABAP Development Workbench(SE80). Thus there are two independent Web Dynpro development environments: one for Java and one for ABAP. (see below)
Because I am an ABAP developer, from this point forward, this Blog will focus ONLY on ABAP Web Dynpro.
The Next Steps…..
Now that we have an understanding of the evolution of the Web Dynpro development environment, we can begin to look at the two key concepts.
- The Model View Controller (MVC) design concept (upon which Web Dynpro is based), and the unique way in which SAP has tweaked it
- The Web Dynpro component architecture and its internal structure
In the next blog I will dive deeply into the MVC Object design pattern and the way SAP has modified and extended it. You need to understand what the differences are, why they are there, and what consequences those differences will have on the way you think when writing Web Dynpro applications.
If you want to read part 1 of this Blog series on An introduction to Web Dynpro click An introduction to Web Dynpro – Part 1
If you enjoyed this blog on Web Dynpro, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
An introduction to Web Dynpro – Part 1
Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.
The Origins of Web Dynpro
What is web Dynpro? It’s SAP’s newest user interface (UI) development option for the SAP NetWeaver platform — has been designed to become the de facto option of choice for SAP development. Web Dynpro was created because, like every other software vendor in the Web space, SAP needed a longterm, strategic solution for the many problems faced by Web developers during the implementation of browser-based business applications.
The seeds of Web Dynpro were bouncing around within SAP as early as the beginning of 2001. During the brainstorming phase, SAP had to consider a wide range of design criteria and combine them into a single toolset that was capable of meeting all its needs.
The following criteria were foremost in its considerations when developing the Web Dynpro Toolset:
(1) Create a UI programming paradigm that would become the standard for all future SAP software. Ease of use is the key here.
(2) Eliminate the repetitive coding tasks currently experienced by Web developers. The fewer lines of handwritten code there are in the UI, the better.
(3) Make full use of abstract modeling. The application should not care about either the communication technology required to access a back-end system or the client technology used to render its screens.
(4) Make full use of generic services. Functionality that is frequently required should be made available from a standard library of services. For example, if the user is asked to enter a date, then a date picker should automatically appear next to the input field without requiring extra coding effort on the part of the developer.
(5) Use a declarative approach for application design. With this approach, the developer tells the development toolset what should be done, but not how to do it. This concept should extend into all areas of application design (e.g., screen flow and component reuse).
(6) Change the focus of software reuse from low-level units of code to high-level units that represent distinct steps in a business process.
Web Dynpro is both a development tool for Web-based applications and a runtime environment. It has been designed in such a way that, when used correctly, it can cut the development timescale of a complex business application by as much as 50%. It achieves these dramatic savings by using graphical and declarative programming techniques. The only code developers need to write is that related to the core business process.
The power of Web Dynpro lies in its use of object-oriented (OO) design concepts. Using these concepts, you can create reusable units of business functionality that you can snap together to form a complete application. Think of our childhood days when we played with Lego’s. We could snap each brick together and end up with, well a rocket or a boat.
How is Web Dynpro Architectire different from earlier UI technologies released by SAP?
The earlier UI technology used by SAP (the classical Dynpro technology used by SAPGUI) has its origins in the IBM frame-based communication protocol used for the old 3270 green screens. ( This would be where you can tell exactly how old I am). This protocol made no attempt to separate data presentation from data processing, and consequently, this lack of separation became a fundamental part of the SAPGUI protocol (known as the Dynamic Interactive Application Gateway, or DIAG). When the World Wide Web boom started in the late 1990s, several things rapidly became clear:
- The DIAG protocol used by SAPGUI was not suitable for these new things called “browsers.” Therefore Web Dynpro Browser Support was paramount.
- Whatever technology was used would have to provide a clear separation between data presentation and data processing.
This was the motivation for SAP to go back to the drawing board and create a new UI development environment. By definition, it could not be based on anything SAP had done before. All the old SAPGUI concepts of Process Before Output (PBO), Process After Input (PAI), screen layout, and navigation had to go out the window and be replaced with what is now known as Web Dynpro. With Web Dynpro, think revolution, not evolution.
I’ll say it again: Do not think Web Dynpro is like any other development tool you’ve ever used before. It has some similarities to other Web development toolsets, but on the whole, Web Dynpro requires a new way of thinking that, when grasped, will enable you to write efficient, low-maintenance business applications in less time than before.
The Web Dynpro Development Environment – A Quick Peek
You can build Web Dynpro applications using the ABAP Development Workbench, familiar to all ABAP developers, as shown below
Now that you understand both what Web Dynpro is and what it is not, in the next blog posting I will return to the development environment and begin to explore the basic concepts you’ll need to understand to successfully build Web Dynpro applications.
If you enjoyed this blog on Web Dynpro, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.
Integrating Your Own Application-Specific Functions in the ALV Grid Control
When we ended the last blog on the ALV Grid Control I promised that we would cover adding Application Specific functions like push buttons or context menu that provides different functions to the ALV Grid Control. I also said we would learn how we can use Interactive Reporting with the ALV Grid Control. So let’s get started!!
You can add the following GUI elements to an ALV Grid instance of an SAP ALV Class:
- Push buttons and menus in the toolbar
- A context menu that provides different functions, depending on the column and row position.
Adding new GUI elements to an ALV Grid instance is event-controlled and requires experience in ABAP Objects event handling. There is an event for each element type (toolbar push button, toolbar menu, and context menu). In the relevant event handler method, you define the properties of an element (such as its menu options) and assign a function code to each executable function.
Normally, you must register control events both on the application server (for the ABAP Objects run-time system) and on the front-end. Please note Control events that are not registered at the front-end will be blocked by the Controls Technology Framework. This is done to reduce communication overhead between the front-end and back-end. (See my blog on the Control Technology Framework for a better understanding). The ALV Grid Control initially registers most events on the front end in order to simplify event handling.
Lets take a look at a generic template below. You can cut and paste this as a template for your own functions.
TYPE-POOLS: icon, cntb.
class <cl_event_receiver definition.
public section.
class-methods:
handle_toolbar for event toolbar of cl_gui_alv_grid
importing sender e_object e_interactive,
handle_menu_button for event menu_button of cl_gui_alv_grid
importing sender e_object e_ucomm,
handle_context_menu for event context_menu_request of cl_gui_alv_grid
importing sender e_object,
handle_user_command for event user_command of cl_gui_alv_grid
importing sender e_ucomm.
endclass.
class lcl_event_receiver implementation.
method handle_toolbar.
<Definition of buttons or menu buttons>
endmethod.
method handle_menu_button.
<Definition of menus for defined menu buttons in 'handle_toolbar'>
endmethod.
method handle_context_menu.
<Definition of context sensitive menu>
endmethod.
method handle_user_command.
<Query application specific function codes>
endmethod.
endclass.
[...]
MODULE PBO OUTPUT.
IF G_CUSTOM_CONTAINER IS INITIAL.
* register events on backend:
set handler lcl_event_receiver=>handle_toolbar
lcl_event_receiver=>handle_menu_button
lcl_event_receiver=>handle_context_menu
lcl_event_receiver=>handle_user_command
<call method set_table_for_first_display>
ENDIF.
ENDMODULE.
The definable GUI elements are rebuilt each time the corresponding event is triggered. For this purpose, the event has the E_OBJECT parameter that contains a reference to the toolbar, or the context menu, or the toolbar menus. In the event handler method, you can then extend or modify these objects accordingly. All application-specific function codes can then be queried in event USER_COMMAND.
The graphic below illustrates how to define a button and a menu button in the toolbar, and how the standard context menu can be extended for a new option. Please note that menus of the toolbar as well as the context menu are not built until the user invokes them. Whereas elements of the toolbar, on the other hand, are usually defined statically before list display.
Here are some helpful points to remember…
√ When defining elements of the toolbar, the field butn_type determines the type of the GUI element. For possible values, see type pool CNTB.
√ In the template, the event handler methods are declared as static methods, which means that they belong to all instances of the ALV Grid Control in one internal session. When one of these events is raised by one instance, you can identify this instance by using event parameter SENDER, which is passed implicitly with every event.
Now this is great if you need to add your own custom integration. But what if you needed to change the behavior of a standard function delivered? Well I am glad you asked….
Modifying the ALV Grid Control Standard Functions
The standard functions are not designed for specific applications. So there may be times when you want to tailor a generic function — such as sorting by a specific column — for more efficient operation with a specific application. One way to do this is to hide the standard function you want to modify and then add your own implementation. While this approach will certainly work, but there is a more elegant way. Follow these 3 easy steps.
1. Define an event handler method for event BEFORE_USER_COMMAND. This event is triggered after the user has selected a function. This means that the ALV Grid Control passes control to the application before the function is executed. Using event parameter E_UCOMM, you can trap and restrict the function code to just the function you want to modify.
2. Implement your own code for the function within the event handler method. In this context, you can even call methods of the ALV Grid Control if you need too.
3. Reset the function code to ensure that the standard function is no longer executed. You can use code similar to the below:
CALL METHOD <instance of the ALV control>->set_user_command
exporting I_UCOMM = SPACE.
Let’s end this blog series with a look at how you can incorporate the interactive reporting method we all have fond memories of from our classical reporting days into the ALV grid control.
Interactive Reporting and the ALV Grid Control
So far our discussions have dealt with functionality provided using classical interface elements, such as push buttons, toolbar menus, and the context menu. There are other interaction facilities can be integrated into an ALV Grid instance. Take a look at the chart below…
As far as the method to integrate these facilities is concerned, the double-click and the hyperlink facility obviously stand out a little bit. To respond to a double-click, you just have to implement an event handler method for event double_click. Hyperlinks do not need any event handling, because the corresponding action is always the same – open a Web browser to show the destination of a link. The links have to be defined in a table of type LVC_T_HYPE, which is passed to the ALV Grid instance using method set_table_for_first_display.
The way to designate a facility to all cells of a single column is controlled by the relevant field in the field catalog. In the case of hotspots and push buttons, you must set this field to “X” or attribute cl_gui_alv_grid=>mc_style_button, respectively. In the case of hyperlinks and drag-and-drop behaviors, a handle must be provided instead. By using this handle, the ALV Grid Control relates the cells of that column to a defined hyperlink or drag-and-drop behavior.
But what if your requirement is for just some cells of a column to be depicted as push buttons — e.g., only those where a condition of the other values of the same row is met? For this purpose, the ALV Grid Control offers a concept that might be complicated at first glance, but as it can be applied for other facilities too, you will surely encounter it more than once when you work frequently with this tool.
The idea is to extend the output table by a field that shall not be visible to the user, but which holds additional information for specific columns of the current row in the table. So lets take a look at the code below…
DATA: BEGIN OF GT_OUTTAB OCCURS 0. INCLUDE STRUCTURE <Your ABAP Dictionary structure>. DATA: CT TYPE LVC_T_STYL. "Table to refer to cells of a row DATA: END OF GT_OUTTAB.
In the specific case of push buttons, the additional field has the type of a table with line type LVC_S_STYL, the so-called cell table. This structure has two fields — style and fieldname — to communicate the row or rows which columns should be displayed as push buttons, follow these steps…
1. To assign this property to all columns, just append one line to the cell table where the field style is set to the button attribute
cl_gui_alv_grid=>mc_style_button.
2. To assign the property to designated columns, append one line in the cell table for each column. Set the field style to the button attribute and determine the column using field fieldname.
Lastly, the ALV Grid Control has to be notified of the meaning of the new field in the output table. The field stylefname of the layout structure is used for this purpose (in our example, you must assign “CT” to this field). As a consequence, the ALV Grid Control marks this field in the field catalog as a technical field that is not displayed.
The diagram below may better explain. It shows an output table where cells b1 and c1 as well as the entire second row are displayed as push buttons through the cell table (to keep the diagram simple, I have assumed that the constant CL_GUI_ALV_GRID=>MC_STYLE_BUTTON has a value “1”).
The ALV Grid Control supplies a large set of generic list functions. These standard baseline functions obviate the need for developers to implement the same code over and over again. As a result, the ALV Grid Control is used throughout the ECC system and list handling is presented in a uniform way to the user. Moreover, the ALV Grid Control offers developers great opportunities to easily adapt this technology to support application-specific requirements.
If you want to read Part 1 of this Blog series on The New ALV Grid Control, click A Guide to the New ALV Grid Control – Part 1
If you want to read Part 2 of this Blog series on The New ALV Grid Control, click A Guide to the New ALV Grid Control – Part 2
If you enjoyed this blog on the ALV Grid Control, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels
Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.
Configuring the ALV Grid Control Instance
When we ended the last blog on the ALV Grid Control I promised that we would cover some simple extensions in this blog. So lets begin………..
The key to configuring the ALV Grid Control for your particular application is the structures that are passed by the application to an ALV Grid instance before or during list display. For some simple extensions of your ALV Grid instance, you only need to set the right parameter and pass the table or structure by using method set_table_for_first_display.
Once the ALV Grid control has been integrated on the screen, you will likely want to configure it to do things like:
- Calculate totals initially
- Hide columns, the toolbar, the grid title, or the column headers
- Add, replace, or hide functions from the toolbar
- React to a double-click on a row to show a detail list
- Interpret values of a column as icons
Like it was stated above, The key to configuring the ALV Grid Control for your particular application is the structures that are passed by the application to an ALV Grid Control instance. Below is a list of the structures that can be passed.
Of the seven structure/tables listed above, the field catalog is the most important one for the ALV Grid Control.
Let’s take a look at a specific example. Lets say we want to provide a title to our ALV Grid Control. We also would like to hide the search capability from the standard toolbar so the user doesn’t have that ability.
OK — let’s grab a code snippet from the previous Blog A Guide to the New ALV Grid Control – Part 1. Look at the bold font lines below.
data: gt_exclude type ui_functions. data: gs_exclude type ui_func. data: gs_layout type lvc_s_layo.
gs_exclude = cl_gui_alv_grid=>mc_fc_find. append gs_exclude to gt_exclude.
gs_layout-grid_title = 'My Grid Title'.
CALL METHOD G_GRID->SET_TABLE_FOR_FIRST_DISPLAY EXPORTING I_STRUCTURE_NAME = 'SFLIGHT' IS_LAYOUT = GS_LAYOUT IT_TOOLBAR_EXCLUDING = GT_EXCLUDE CHANGING IT_OUTTAB = GT_SFLIGHT.
The structure gs_exclude of type ui_func is used in the internal table gt_exclude of type ui_functions. The “g” is for Global and “s” and “t” are for structure and table respectively. The search function is referenced by the class attribute MC_FC_FIND of class CL_GUI_ALV_GRID. You can hide other standard functions or menu buttons as well by adding other attributes with prefix MC_FC_ or MC_MB_, respectively.
We added the title to gs_layout-grid_title.
Finally to get these changes to manifest in our ALV Grid Control, we added IS_LAYOUT = GS_LAYOUT and IT_TOOLBAR_EXCLUDING = GT_EXCLUDE to the call statement for the method “SET_TABLE_FOR_FIRST_DISPLAY”
Setting Properties Using the Field Catalog in the ALV Grid Control
As mentioned earlier, the ALV determines the output format of values using the field catalog. If you choose to build the field catalog manually, you need to know which fields are mandatory.
Listed below are the required fields.
ALV Grid Required Fields
Fortunately, in most cases you can generate the field catalog (semi-)automatically, as I will show you, so you don’t need to fill in these fields.
Generating the Field Catalog for the ALV Grid Control
You have several options for building a field catalog:
1)Automatically through an ABAP Dictionary structure (as in our example above) — the ALV Grid Control then uses this structure to generate the field catalog on its own
2)Manually in your ABAP program (by filling at least the mandatory fields for each entry of our output table)
3)Semi-automatically by combining the first two procedures
In the case of the first option, you use parameter I_STRUCTURE_NAME, and in the latter cases IT_FIELDCATALOG of method set_table_for_first_display.
Since the last option is the most commonly used, it will be the focus of our discussion. When generating the field catalog semi-automatically, you combine structure information of the ABAP Dictionary with your own structure information.
This allows you to modify or add structure descriptions of new fields to the automatically generated field catalog, which may be helpful for the following scenarios:
- You want to display an ABAP Dictionary table without displaying all possible columns initially (using field NO_OUT, another field of the field catalog).
- You want to display additional columns containing icons or other information.
To generate a field catalog semi-automatically all you need to do is call function module LVC_FIELDCATALOG_MERGE and pass the ABAP Dictionary structure of the output table and the internal table for the field catalog.
The function module generates the field catalog and fills the internal table accordingly.
Please remember to read the rows you want to change, and adapt the fields accordingly. If your output table contains more fields than are stored in the ABAP Dictionary, you must append one row for each new field to the field catalog.
Again, an example will help clear this up. The code snippet below deals again with a list of the good old flight model. In the code, column PLANETYPE is hidden and an additional column is used to display icons.
TYPE-POOLS: icon.
[...]
data: begin of outtab occurs 0. include structure sflight. data: icon_column(40) type c. data: end of outtab.
OK, now lets semi-generate the Field Catalog for the ALV Grid Control.
CALL FUNCTION 'LVC_FIELDCATALOG_MERGE' EXPORTING I_STRUCTURE_NAME = 'SFLIGHT' CHANGING CT_FIELDCAT = fieldcat.
Now that we have a field catalog, lets modify entry of field catalog for the column PLANETYPE and stop it from displaying on the ALV Grid Control.
read table fieldcat into wa_fieldcat with key fieldname="PLANETYPE".
if sy-subrc eq 0. l_index = sy-tabix. wa_fieldcat-no_out = 'X'. modify fieldcat from wa_fieldcat index l_index. endif.
Now lets add an entry to the field catalog titled “ICON COLUMN”. This is where we would put an ICON. Later in the code, we will put the delete icon at the end of a data row.
clear wa_fieldcat. wa_fieldcat-fieldname = 'ICON_COLUMN'. wa_fieldcat-outputlen = 5. wa_fieldcat-just = 'C'. wa_fieldcat-coltext = 'Icons'. wa_fieldcat-seltext = 'Icon column'. append wa_fieldcat to fieldcat.
Finally, lets select the data from the table SFLIGHT and add the the delete icon at the end of the row and display the ALV Grid Control.
SELECT * FROM SFLIGHT INTO table sflight.
loop at sflight into wa_sflight. move-corresponding wa_sflight to wa_outtab. wa_outtab-icon_column = ICON_DELETE. append wa_outtab to outtab. endloop.
[...] CALL METHOD GRID1->SET_TABLE_FOR_FIRST_DISPLAY CHANGING it_fieldcatalog = fieldcat IT_OUTTAB = outtab[].
Some final thoughts……..
SAP developed the ALV Grid Control using a continuous naming convention, which helps you to remember structure or table names:
- LVC_S_XXXX — structures
- LVC_T_XXXX — tables; for a table there exists a table type and a corresponding line type in the ABAP Dictionary (e.g., LVC_S_HYPE is a line type for table LVC_T_HYPE)
- I_*, IS_*, or IT_* — for import or changing parameters (simple type, structure, or table) of methods
- E_*, ES_*, or ET_* — for export parameters (simple type, structure, or table)
In the next blog we will look at adding Application Specific functions like push buttons or context menu that provides different functions to the ALV Grid Control. We will also examine how we can use Interactive Reporting with the ALV Grid Control.
If you want to read the first part of this Blog series on The New ALV Grid Control, click A Guide to the New ALV Grid Control – Part 1
If you enjoyed this blog on the ALV Grid Control, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Check out are web channels