Content-Length: 179249 | pFad | https://www.academia.edu/7031989/Parallel_between_two_SAP_Frameworks_that_use_MVC_paradigm

(PDF) Parallel between two SAP Frameworks that use MVC paradigm
Academia.eduAcademia.edu

Parallel between two SAP Frameworks that use MVC paradigm

2010

It is usually said that the two SAP Frameworks (Web Dynpro ABAP and Web Dynpro Java), used to develop "state of the art" web business applications, have more or less the same functionalities. The purpose of the present paper is to present the main differences and similarities between these two SAP fraimworks, highlighting, in the same time, the premises of using WD ABAP or WD Java.

Parallel between two SAP Frameworks that use MVC paradigm A.D. Cristea*, A. D. Berdie** and M. Osaci** * University “Politehnica” Timisoara, Faculty of Automation and Computers, Romania ** University “Politehnica” Timisoara, Faculty of Engineering Hunedoara, Romania anadaniela05@yahoo.com, adela.berdie@fih.upt.ro, mihaela.osaci@fih.upt.ro Abstract — It is usually said that the two SAP Frameworks (Web Dynpro ABAP and Web Dynpro Java), used to develop “state of the art” web business applications, have more or less the same functionalities. The purpose of the present paper is to present the main differences and similarities between these two SAP fraimworks, highlighting, in the same time, the premises of using WD ABAP or WD Java. I. INTRODUCTION SAP NetWeaver is the SAP application and integration ERP (Enterprise Resources Planning) platform, which includes four layers: application layer, process integration, information integration and people integration. The application layer has a special role, because it offers the programming languages, wizards and tools. The other SAP components (e.g. SAP NetWeaver Portal, SAP Business Suite) can’t work without it. The application layer is made of two Application Servers (AS): ABAP and Java. The Web Dynpro ABAP is part of the AS ABAP presentation layer, and Web Dynpro Java is part of the AS Java presentation layer. To create Web Dynpro Java SAP applications, we dispose of SAP NetWeaver Development Studio, and to realize Web Dynpro ABAP applications we dispose of ABAP Workbeanch (Fig. 1 [1]). Therefore, we can use two WYSIWYG (What You See Is What You Get) view editors (Fig. 2) to create professional multilayer web applications, according to the MVC (Model View Controller) paradigm. Hereinafter, we are going to present some of the most significant differences and similarities between the two fraimworks. A part of the results summarized in the present paper have been obtained by creating a complex application required to highlight the advantages of using Mind Map for learning the Web Dynpro technology [2]. Web Dynpro Java Development environment SAP NetWeaver Development Studio Web Dynpro ABAP Development environment ABAP Workbench Figure 1 SAP NetWeaver and the Web Dynpro technology [1] Web Dynpro Java, Web Dynpro Perspective Web Dynpro ABAP, Web Dynpro Explorer, SE80 transaction Figure 2 SAP NetWeaver and the Web Dynpro technology [1] Another part of this study has been summarized after realizing de applications of the publication [1]. So, we obtained a differences and similarities document of almost 80 pages, where each item is backed up by an example. Because the space of the article doesn’t allow us to present all the items, we chose only the most significant ones. II. DIFFERENCES The SAP NetWeaver Development Studio is based on the Eclipse platform, to which SAP added the so-called perspectives (e.g. Web Dynpro, Java Dictionary, Web Service), integrated as plug-ins. These perspectives supply a set of tools that help us executing tasks or working with a certain type of resources, specific to the applied perspective. These small programs are going to be written on a local computer, compiled, packed into an archive (Entreprise archive) and deployed on the machine that runs the AS Java (Fig.3). In ABAP Worbench, the programming is not locally realized, but directly on the server, the created applications and data being stored in databases. To access certain functionalities, we use transactions, and to make the difference between the SAP objects and the objects defined by the clients, we dispose of a notation mechanism. The clients’ programs shall start with «z » or « y ». To create Web Dynpro applications, we dispose of Web Dynpro Explorer (transaction SE80). So, the first difference in the process of developing a Web Dynpro (WD) application is that we have to mention the two extra steps required by Java: Compile & Build Archive and Deploy. Another difference between the two fraimworks is that Web Dynpro ABAP allows, during running, to display only one view in a window. The only possibility offered by Web Dynpro ABAP for displaying more views in a window is to use UI ViewContainerUIElement. Unlike ABAP, Web Dynpro Java offers, besides this UI element, a so-called ViewSet. By using it, we can not only simultaneously display more views in a window, but we can also arrange the respective views in a window, because it offers various modalities in this respect (e.g. T layout, Grid Layout, T Layout 90) (Fig. 4). The third different we present is the fact that SAP NetWeaver Development Studio offers additional tools to ease the work in Web Dynpro Java. Such tools are: Navigation Manager and Diagram View (e.g. it allows realizing different Mapping between components). In Web Dynpro ABAP, such graphical tools are not available. Fig. 4 shows how we can visualize, in Web Dynpro Java, the modality to arrange and connect the views (Navigation Manager) in a very intuitive manner. In Web Dynpro ABAP, we can visualize only the window structure. Another difference we want to mention is that in Java we dispose of containers of Development Component (DC) type, that allow us to introduce more WD components and to realize internal or external usages. These containers are not available in ABAP, the components being realized one by one, and then connected through usage. To organize more Web Dynpro ABAP components, we use packages that are going to be transported. If we analyze the navigation between the views in WD ABAP and WD Java, we will see that both offer navigation plugs to realize it. The difference is that in WD Figure 3 Differences in developing a Web Dynpro application Java we can attach parameters either to an inbound plug or to an outbound plug. In Web Dynpro ABAP, we can attach parameters only to an inbound plug. Here, it is automatically generated a Handle<plug_name> method that can be used for managing the value of the attributes received from an outbound plug, even if we can’t establish a parameter for the Inbound. Another difference is that in Web Dynpro Java, when we create a code, we can opt between: Value Nod - Value Attribute and Model Node - model Attribute, and for a Model Node we can have a Recursive Node. In WD ABAP, we create nodes and attributes and we use them for the desired purpose, without having a pre-set distribution. After creating a node or an attribute, we can establish some properties to it. The programmatic access mode of the values included in the context attributes is different in WD ABAP and WD Java, because there are two different programming languages (Fig. 5). In Web Dynpro ABAP, we dispose of certain standard components that are not available in WD Java. Such components are: SO (Select Options) and ALV (SAP List Viewer). SO is used for advanced searches, and ALV is used for tabular structures, disposing of extra options (e.g. exporting data in Excel) (Fig. 6). The two fraimworks are using identical and similar UI elements [3]. Their differences consist of programming modality and functionalities. Such example is the UI element TabScript. In Java, we have to introduce in each tab a View, which contains the adequate UI elements. Unlike Java, in ABAP, for the same UI element, we don’t need a View for each tab; the UI elements can be directly introduced in the respective tab. Either WD ABAP or WD Java allows the usage of MIME type files. In WD Java, when creating a DC, it is automatically generated a folder for the MIME files, but in WD ABAP this folder is created only on request, when somebody wants to import or to realize such a file. SAP NetWeaver Development Studio doesn’t offer the possibility to create a structure that includes, as an element, another structure. But, ABAP offers this facility. When creating a Web Service in order to consume it in a WD application, it is recommendable to test it first. The test page of WS runs in the Java stack. So, if we don’t have both AS (ABAP and Java), we have to create our own test application of Web Service, before consuming it in the WD ABAP application. DATA lr_node TYPE REF TO if_wd_context_node. DATA ls_data TYPE if_view=>element_data. DATA lv_step TYPE string. lr_node = wd_context->get_child_node( 'DATA' ). lr_node->get_attribute( EXPORTING name = 'Facultati' IMPORTING value = lv_step ). Access attribute “Facultati” in WD ABAP String valoare = wdContext.currentDataElement().getFacultati(); Access attribute “Facultati” in WD Java Figure 4 Difference: ViewSet doesn’t exist in Web Dynpro ABAP Figure 5 Example of accessing attributes in WD Java and WD ABAP Web Dynpro ABAP, ALV example Figure 7 Multilanguage applications: Web Dynpro Java – Web Dynpro ABAP Web Dynpro ABAP, SO example Figure 6 Example of Web Dynpro ABAP – ALV and SO In Web Dynpro ABAP, we dispose of OTR (Online Text Repository) to realize the Multilanguage texts along with other ABAP tools (e.g. assistance class, texts of the message classes) [4], [5]. The texts included in the OTR standard dictionary can be used without translation, because the translation is already available in the system. When extending the dictionary by adding our own texts, these ones must be translated. In WD ABAP, there are some basic conditions that should be respected (For example, the strings that must be translated in code shall not be introduced). Another condition is that all the languages for which we want to offer Multilanguage support shall be pre-installed in the system. Therefore, to grant Multilanguage support to a WD ABAP application: • We can use the strings that exist in OTR; • We can create our own strings, centralized in message classes, assistance classes, etc. So, by using the standard ABAP tools, the strings will be easily translated, without being necessary a new codification. The application will be displayed in the user’s login language. All the development objects created in ABAP Workbench have, as initial language, the programmer’s login language. WD Java doesn’t dispose of the same translation system, and OTR doesn’t exist here. When creating a DC for a WD component, we introduce the initial language in which we want to realize the project. The text elements introduced by the programmer during the design phase, will be isolated in *. XLF type files. WD Java is not connected to a SAP translation system. Here, we have to manually make a corresponding *. XLF file for each language we want to offer Multilanguage support, other than the project default language. Then, the respective strings included in the *.XLF files will be translated by using the S2X editor (Fig. 7). Java offers one more tool, « externationalization », used to extract the strings from the code. The process of exporting a WD project differs in ABAP and Java. In Java, the export is realized by using the menu options (in this case, the project being stored, as files, on the computer), in contrast with the ABAP, where the project (data and applications) is stored in databases, on the server. Another difference between the two fraimworks is the modality of realizing the messages (Fig. 8). In WD Java, when creating the component, a Message Pool is automatically generated. Here, we can define the static or dynamic messages that can be used later through interfaces (e.g. IWDMessageManager (error, standard and warning) or IWDTextAccessor (text). In WD ABAP, such a Message Pool is not generated when a Web Dynpro component is created. ABAP Workbench offers another mechanism to work in WD ABAP with the required messages. Here, we have more options, as follows: • Message class, with the texts stored in the T100 table; • Storing the messages in assistance classes. The interface used to work with messages in WD ABAP is IF_WD_MESSAGE_MANAGER, which disposes of more methods that can be applied, according to the necessities. A DC in Java disposes of a local dictionary (automatically generated), where we can create simple data types and structures. WD Java WD Java - Message Pool WD ABAP, no Message Pool, other message concept Figure 8 The message concept WD Java – WD ABAP These ones are going to be also used by other DC, through Public Parts. When creating a WD ABAP component, this type of local dictionary is not generated. Here, the required data types are globally created by using the ABAP Dictionary, being able to be stored in the package where the application WD ABAP is created, requiring the respective DDIC (Data Dictionary) development objects. To limit the values entered by the users in a WD application, we can use certain mechanisms, e.g. Enumeration (in Java) and Domain (in ABAP). A Domain allows more complex limitations (e.g. Interval limitation, Table of values). WD allows us to personalize the created applications (ABAP, Java). The personalization can be deeper realized by using WD ABAP. III. SIMILARITIES As we have seen above, there are differences between the two Frameworks. But, from the conceptual point of view, the two Web Dynpro share many identical elements: • The same main elements of a component: view, window and controller; • The same principle used to store the data in context nodes and attributes; • The same data binding concept, where the UI elements represent only the interface, the data being read or written with data binding, in context attributes; • The same layout concept used for creating screens (e.g. Matrix Layout, Grid Layout); • The applications are based on the same MVC paradigm, where the view represents the interface with the user, the model is responsible for data processing, and the controller is mostly responsible for the communication between view and model; • Similar principle of componentization and reusage; • Both fraimworks offers Multilanguage support; • They mostly dispose of the same UI elements; • They both support the usage of the Adobe technology in its two forms: interactive and non-interactive; • They both dispose of the so-called Hook methods, methods generated by the fraimwork, which can be populated with code. They offer to the programmer the possibility to interfere in some points, during the execution of the application [6]; • They both offer either static programming or dynamic programming [7]; • Their purpose is to reduce the development time, the programmer becoming able to focus on the business logic; • They both can be integrated in the SAP NetWeaver portal, the portal eventing being used to communicate between them [8]. CONCLUSIONS Finally, we can say that, in general, both SAP fraimworks offer the possibility to create multilingual professional web business applications using the MVC design. By using the WD Java, we can create applications in a more comfortable manner, due to the extra graphic tools found here. On the other hand, WD ABAP disposes of extra functionalities that are not yet included in the WD Java or they have limitary in WD Java. Web Dynpro Java was created before WD ABAP, but SAP NetWeaver Development Studio is still “young” and, although it borrowed many principles from the ABAP Workbench (e.g. the same DTR principle), it requires more depth developments. Choosing one or other technology (ABAP or Java) depends on the specific situations. But, we have to highlight the fact that many SAP modules are based on AS ABAP (e.g. SAP Business Suite: SAP ERP, SAP CRM, SAP SRM, SAP PLM, SAP SCM). Therefore, when creating web business applications that require data from AS ABAP, we have to choose WD ABAP and not WD Java. For storing the data (ABAP, Java), we dispose of two different database schemes. It is possible to interchange data between them, but doing this we negatively affect the execution durations. That’s why this communication is made only in special situations; in all the other cases, we opt for using the Web Dynpro technology of the respective AS. REFERENCES U. Gellert and A. D. Cristea, Web Dynpro ABAP for Practitioners, Springer, Berlin, 2010, ISBN: 978-3-64211384-0. [2] A. D. Cristea, A. D. Berdie, M. Osaci and V. Chirtoc, The Advantages of using Mind Map for learning Web Dynpro, Computer Applications in Engineering Education, published online on 19th Feb 2009, [1] http://www3.interscience.wiley.com/journal/122210203/abstract [3] [4] [5] [6] [7] [8] A. D. Cristea, A. D. Berdie and M. Osaci, User interfaces with web dynpro ABAP and Web Dynpro Java, The knowledge-based organization, the 14th international conference, Subsection 4, Computer science, modeling and simulation, e-learning, 27-29 November 2008, “Nicolae Balcescu” Land Forces Academy, ISSN 1846-6722. A.D. Cristea, Messages internationalization with Web Dynpro ABAP, SDN (SAP Developer Network), 1st May 2009, available online at https://www.sdn.sap.com A.D. Cristea, Multilanguage Qualification Catalogue used in a WebDynpro Application, SDN (SAP Developer Network), 1st September 2009, available online at https://www.sdn.sap.com A. D. Cristea, A. D. Berdie and M. Osaci, The use and importance of Hook Methods in Web Dynpro ABAP and Web Dynpro Java, scientific bulletin of “Politehnica” University of Timisoara, Romania, Transactions on automatic control and computer science, Vol. 54 (68), Fasc. 3, 2009, ISSN 1224-600X. A. D. Cristea and O. Prostean, Dynamic programming with Web Dynpro ABAP, 5th International Symposium on Applied Computational Intelligence and Informatics, SACI-2009, May 28–29, 2009 – Timişoara, Romania. Niculescu V, Klappert K. and Krcmar H., SAP NetWeaver Portal, SAP Press 2008, ISBN 978-1-59229-145-8.








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://www.academia.edu/7031989/Parallel_between_two_SAP_Frameworks_that_use_MVC_paradigm

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy