If you recall from last month’s blog, the Function Module we are using follows a naming convention “IDOC_
ITP Insights
An IDoc is the run−time instance of an IDoc type. An IDoc consists of a control record, several data records,and a list of status records. The control record defines control information such as sender and receiver information. The data records contain the application data that is to be transferred via IDocs. The status records contain status information (success or failure) recorded at each point in the process.
A large enterprise’s networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc (for intermediate document) encapsulates data so that it can be exchanged between different systems without conversion from one format to another. IDocs are used for for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP’s Application Link Enabling (ALE) system.
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.
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.
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.
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.
he 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.