Trademarks
• • • • • • Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation. IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. ORACLE® is a registered trademark of ORACLE Corporation. INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
• • • •
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.
g2006112212631
About This Handbook
This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
American English is the standard used in this handbook. The following typographic conventions are also used. Type Style Example text Description Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options. Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet). Example text EXAMPLE TEXT Emphasized words or phrases in body text, titles of graphics, and tables Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE. Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program. Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.
Icons in Body Text
The following icons are used in this handbook. Icon Meaning For more information, tips, or background Note or further explanation of previous point Exception or caution Procedures
Indicates that the item is displayed in the instructor's presentation.
Unit 1: Overview and positioning of development tools.......... 1
Overview and positioning of development tools ....................2
Unit 2: Visual Composer ............................................... 19
Visual Composer ...................................................... 20
Unit 3: Using SAP NetWeaver Developer Studio ................. 39
Create a portal application........................................... 40 Debugging ............................................................. 53
Unit 4: Portal Applications and the Portal Runtime.............. 75
Portal Applications and the Portal Runtime ....................... 76
Unit 6: Portal Services and Web Services ........................ 199
Portal Services .......................................................200 Web Services.........................................................222
Unit 7: Standard Portal Services .................................... 237
User Management ...................................................238 Connector Framework...............................................266
Web Dynpro Context and Navigation .............................332 Web Dynpro Architecture ...........................................338
Unit 10: Web Dynpro Controllers.................................... 361
Model, View Controller ..............................................362 Web Dynpro Controllers.............................................398
Unit 11: The Adaptive RFC Layer ................................... 433
Remote Invocation of ABAP Functionality .......................435 The Adaptive RFC (aRFC) Model Object.........................441 Configuring SLD and JCo Connections ...........................486
Unit 12: Visualising the Java Web Dynpro through the SAP Portal....................................................................... 521
Introduction ...........................................................522 Creating a Web Dynpro iView ......................................525 Portal Eventing, Navigation and WorkProtect ....................531
Unit 13: ABAP Web Dynpro .......................................... 561
Introduction to ABAP Web Dynpro ................................562 Creating an ABAP Web Dynpro....................................569 Integrating an ABAP Web Dynpro into the Portal................575 Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro .............................................................578
Glossary................................................................... 613 Index ....................................................................... 615
Course Goals
This course will prepare you to: • • • • Use Visual Composer Use SAP NetWeaver Development Studio Develop NetWeaver Portal components and services Use and Understand NetWeaver Portal APIs and services
Course Objectives
After completing this course, you will be able to: • • • • Use Visual Composer Use SAP NetWeaver Development Studio Develop NetWeaver Portal components and services Use and Understand NetWeaver Portal APIs and services
SAP Software Component Information
The information in this course pertains to the following SAP Software Components and releases:
Unit 1
Overview and positioning of development tools
Unit Overview
Describe and differentiate approaches of content development on the SAP NetWeaver platform.
Unit Objectives
After completing this unit, you will be able to: • • • • • • • • Describe and differentiate the different approaches of content development on the SAP NetWeaver platform: SAP NetWeaver Visual Composer SAP NetWeaver Developer Studio The Portal Developer Kit for Java and .Net Know the main resources for developing EP applications: The Portal Content Studio The SAP Developer Network (SDN) The SAP Help Portal
Unit Contents
Lesson: Overview and positioning of development tools .....................2 Exercise 1: Citrix Login .......................................................9 Exercise 2: System Setup.................................................. 13
Unit 1: Overview and positioning of development tools
EP120
Lesson: Overview and positioning of development tools
Lesson Overview
SAP provides a number of tools and resources to assist you in developing applications on the SAP NetWeaver platform. This track focuses on the tools and resources required to build NetWeaver Portal Content on the Java platform. Some of the tools and resources available to you as a developer are: • • • • • SAP NetWeaver Visual Composer SAP NetWeaver Developer Studio SAP Enterprise Portal Developer Kit (PDK) SAP Developer Network (SDN) – http://sdn.sap.com SAP Help Portal - http://help.sap.com/nw04s
Lesson Objectives
After completing this lesson, you will be able to: • • • • • • • • Describe and differentiate the different approaches of content development on the SAP NetWeaver platform: SAP NetWeaver Visual Composer SAP NetWeaver Developer Studio The Portal Developer Kit for Java and .Net Know the main resources for developing EP applications: The Portal Content Studio The SAP Developer Network (SDN) The SAP Help Portal
Business Example
Choose the appropriate technology to develop portal applications.
Lesson: Overview and positioning of development tools
Overview and positioning of development tools
Figure 1: Positioning of content approaches
For consultants, developers, and business process designers … …in organizations using the SAP NetWeaver portal ... …who need to develop, deploy, and maintain business content (iViews) for their portal… …SAP NetWeaver (though a component code-named “Visual Composer”) ... …reduces the TCO through model driven development of portal content ... … by eliminating the need to program which improves stability, maintainability and accelerates the time-to-value. Unlike integration platforms or portal solutions of other vendors… … which require massive, error-prone custom coding to bring business content into their portal... …SAP NetWeaver has a solution for the complete life-cycle of portal content that does not require programming. So what's the difference between Visual Composer and Web Dynpro? … NetWeaver provides the ability to develop portal content without programming through Visual Composer (Outside-in approach). … NetWeaver provides the user interface technology for individual applications through Web Dynpro (Inside-out approach). … Both Visual Composer and Web Dynpro are being developed as complementary technologies.
Unit 1: Overview and positioning of development tools
EP120
Figure 2: The SAP Portal Content Studio
Former SAP iViewStudio More than 6000 iViews in about 160 Business Packages categorized in 24 industries! The SAP NetWeaver Visual Composer (NW VC) • Visual Composer is a visual modeling tool that enables sophisticated content development for the SAP NW Portal merely by dragging and dropping appropriate objects and establishing relationships between them. No programming required. Visual Composer is completely Web based. Business experts can sit next to the business users and access Visual Composer from any machine to build or customize to reflect the business needs on demand The purpose of Visual Composer is to provide a visual tool that enable customers quick and easy content development thereby – – – – Minimize the time and effort to create content Lead to quicker go live decision Reduce Total Cost of Ownership (TCO) Increase ROI
•
•
The word Portal has been widely abused lately. Over 100 companies now say they provide a portal of some sorts, from IBM and Microsoft down. What is clear is that there is no absolute definition, but most people agree that it is a “webtop” of information targeted at audiences both within and external to a company. What is
Lesson: Overview and positioning of development tools
important is to consider all kinds of information to be made available in the portal, and to extend the idea to actually make the portal a work-place where all functions and applications are unified together.
Figure 3: The SAP NetWeaver Developer Studio
Eclipse provides an open architecture platform for developing and integrating your own tools. That is why much of the Eclipse function set is generic in nature. The main priority for Eclipse is to provide a robust and (as far as possible) universal infrastructure for developing highly integrated tools.
Unit 1: Overview and positioning of development tools
EP120
The Portal Development Kit (PDK) • The Portal Development Kit (PDK) is an extension of the SAP NetWeaver Development Studio and represents a collection of: – Development documentation – Sample applications providing reference coding – Tools for use by developers It’s shipped as Business Package available in the Portal Content Studio and requires a full installation of a SAP NetWeaver Portal Use the Software Delivery Manager (SDM) in order to install the PDK After installation assign the predefined role com.sap.pct.pdk.JavaDeveloper to your user. Contains a huge bundle of documentation and howtos All available coding samples you find here Sample Applications include: – – – – – OBN - Object Based Navigation Navigation Connector – Application Integrator – Work with various web applications Webdynpro – Integrate WebDynpro applications into the portal HTML Business for Java (HTMLB) - Browser-independent HTML based on the SAP style sheet that maintain the corporate identity throughout the application. Internationalization - Access the required language resource files for multilingual applications. Portal Data Viewer (PDV) - Present data from different sources (XML, JDBC query, etc.) in tabular form. JCo - to connect to SAP systems. User Management – User Mapping examples Enterprise Portal Client Framework (EPCF) – Eventing framework examples
Lesson: Overview and positioning of development tools
Figure 4: The Portal Development Kit (PDK)
Once you have been assigned the Java Developers Role, you will be able to navigate to different SAP Portal development menu options. These include Tools, Getting Started, User Interface Development, Portal Development, Portal Runtime Technology, Knowledge Management and Javadocs.
Figure 5: The SAP Developer Network (SDN)
Access further information via the website can be located at http://sdn.sap.com.
Unit 1: Overview and positioning of development tools
EP120
Solution 1: Citrix Login
Task:
Login to the Training Environment using Citrix. 1. Follow the solution to login to the training environment using citrix. a)
Lesson: Overview and positioning of development tools
Exercise 2: System Setup
Exercise Objectives
After completing this exercise, you will be able to: • Create Portal users and System Setup
Business Example Task:
Create Portal Users and setup system. 1. Follow the solution to create
User: EP120.E-XX Password: welcome User:EP120.D-XX Password:welcome
where XX is your group number as assigned by the instructor. The EP120.E-XX user is an end user and EP120.D-XX is a content developer. Create a System to connect to the backend ABAP system.
Unit 1: Overview and positioning of development tools
EP120
Solution 2: System Setup
Task:
Create Portal Users and setup system. 1. Follow the solution to create
User: EP120.E-XX Password: welcome User:EP120.D-XX Password:welcome
where XX is your group number as assigned by the instructor. The EP120.E-XX user is an end user and EP120.D-XX is a content developer. Create a System to connect to the backend ABAP system. a)
Unit 1: Overview and positioning of development tools
EP120
Figure 14:
Figure 15:
Logoff the portal and the windows desktop session. You will use the citrix common training environment for all exercises. Follow path Start → Favorites → Template URL Portal Training. Change the URL address replacing twdfxxx with your portal server. Login with user EP120.D-xx password welcome where xx is your group number.
Lesson: Overview and positioning of development tools
Lesson Summary
You should now be able to: • Describe and differentiate the different approaches of content development on the SAP NetWeaver platform: • SAP NetWeaver Visual Composer • SAP NetWeaver Developer Studio • The Portal Developer Kit for Java and .Net • Know the main resources for developing EP applications: • The Portal Content Studio • The SAP Developer Network (SDN) • The SAP Help Portal
Unit Summary
You should now be able to: • Describe and differentiate the different approaches of content development on the SAP NetWeaver platform: • SAP NetWeaver Visual Composer • SAP NetWeaver Developer Studio • The Portal Developer Kit for Java and .Net • Know the main resources for developing EP applications: • The Portal Content Studio • The SAP Developer Network (SDN) • The SAP Help Portal
Drag a Page from Compose Model to Design tab of workspace. Double click to enlarge to entire design area. Drag an IView from Compose Model to Design tab of workspace. Double click to enlarge to entire design area. Add a data Service by selecting Find Data. Choose System and enter search criteria. Select a Service and drag to Design tab of workspace. Right mouse click and select execute to test Service.
Drag input from Service and Add Input Form Drag output structure from Service and Add either a table view, chart view, filter or sort the data. Click Run to test
Models designed in Visual Composer can be deployed to run in one or more technology engines, including SAP HTML/B and Flex. The same model can be deployed to more than one environment, although not all components and controls are fully supported in each. Visual Composer implements a proprietary XML-based Visual Composer Language as its source code for creating the models. Only at deployment is the model actually compiled into the executable code required by the selected UI technology. The result is a model once run anywhere capability. The models that you build in Visual Composer are generated in Generic Modeling Language (GML) code. To deploy your application to a portal, the GML code must be compiled into a language supported by the portal. During compilation, warnings and possible errors may be discovered, enabling you to check the model validity. The compiled content is deployed directly to the portal, in the runtime environment that you select. In runtime, transactional content can run through HTML/B and Flex, while analytic content which may require a more animated environment may run through Flex. The models deployed by Visual Composer to the portal include runtime metadata, which is stored with the model in the PCD and exported in the business package, for delivery to customers.
Exercise 3: The SAP NetWeaver Visual Composer
Exercise Objectives
After completing this exercise, you will be able to: • Work with the SAP NW Visual Composer • Develop applications using the features of the SAP NW Visual Composer
Business Example Task:
SAP NetWeaver Visual Composer 1. Create a page with an iView to enable a portal user to view a list of flights for a specified airline, departure city, departure country, arrival city and arrival country. Please install the Visual composer. Use service BAPI_SFLIGHT_GETLIST. Sort the list by departure date and flight time. Generate an input form with the following. Airlineid Arrdate Arrtime Cityfrom Cityto Connectid Deptime Flightdate
Solution 3: The SAP NetWeaver Visual Composer
Task:
SAP NetWeaver Visual Composer 1. Create a page with an iView to enable a portal user to view a list of flights for a specified airline, departure city, departure country, arrival city and arrival country. Please install the Visual composer. Use service BAPI_SFLIGHT_GETLIST. Sort the list by departure date and flight time. Generate an input form with the following. Airlineid Arrdate Arrtime Cityfrom Cityto Connectid Deptime Flightdate a)
Unit 3
Using SAP NetWeaver Developer Studio
Unit Overview
Getting started with SAP NWDS. Creating a Portal Application Project. Creating a Portal Application Component. Upload and test the component.
Unit Objectives
After completing this unit, you will be able to: • • • • • • Getting started with SAP NWDS Create a portal application project Create a simple portal application component Upload the component to the portal Test the component Debug a portal application
Unit Contents
Lesson: Create a portal application ........................................... 40 Exercise 4: First Portal Component ....................................... 45 Lesson: Debugging .............................................................. 53
Lesson: Create a portal application
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • • • • • Getting started with SAP NWDS Create a portal application project Create a simple portal application component Upload the component to the portal Test the component
Business Example
Build a simple portal application.
If the buttons do not display on the toolbar, you may need to add them to your perspective. Choose Window → Customize Perspective → Other → Enterprise Portal Project Actions
Figure 44: Create New Portal Component
A Portal project usually consists of one or more components. Create a new component (application object) and specify the type of component you wish to create. You can use File → New → Other → Portal Application → Portal Application Object
There are currently 4 templates that you can choose from: AbstractPortalComponent, AbstractTestComponent, JSPDynPage, and DynPage. The templates are stored in the directory <IDE_Install_Dir>\eclipse\plugins\com.sap.ep.applicationDevelopment\templates The location refers to where the generated Java class will be located. If you select “Core”, then the class is located in the private space and is not accessible by other components. If you select “API”, then the class is located in the public space and other components may access objects and methods defined in the class. This PRT functionality simplifies sharing of components in a large, complex portal installation.
Figure 45: Create New Portal Component Example
See the “Tips and Tricks” and “What's New” from the Help Menu for information about how to use Eclipse. Code Assist and other features are configurable via the Window → Preferences menu
Figure 46: Uploading the Portal Application - Configuration
After your project has been created, you can upload it to the portal. For convenience, the portal landscape servers should be entered in the preferences dialog so that it will be easier to upload on subsequent development sessions. You need to perform this process only once.
Figure 47: Uploading the Portal Application
The Uploader defaults to the project selected in the Navigator window
The name of your project should contain a namespace that is not reserved by SAP. Although you are not technically prevented from doing so, do not use “com.sap.*” for the name of the PAR file. Once you have uploaded your project one time, you can use the key combination Ctrl-Alt-U to quickly upload it again. This shortcut is configurable via the Window → Preferences → Keys → Enterprise Portal → PAR Upload option.
Figure 48: Testing Your Application
Testing the application can be done within NWDS or the portal. It is often convenient to unit test the component before you create an iView out of it. NWDS will remember your ID/password for the duration of your session so you don't have to type it in each time you want to test. If you exit NWDS, then you will have to enter your credentials again.
Exercise 4: First Portal Component
Exercise Objectives
After completing this exercise, you will be able to: • Leverage the wizards and tools available in the SAP NWDS • Realize easy Portal Applications
Business Example Task:
First Portal Component Write your first Portal Component which presents a simple output like “Hello World” to the portal user. Use the integrated wizards to fulfill this task. 1. 2. Start the SAP NWDS and create a new Portal Application Project named 03-FirstPortalProjectXX where XX is your student number. Click on the icon of the Portal Application Object wizard. Select Portal Component → Abstract Portal Component as template. Enter HelloWorldComponent into the name field. Enter com.sap.training.portal into the package name field. Click finish. Implement the doContent method and so that some simple HTML output like “Hello World!” is written to the response. Use the code assistant to find the right method of the response object. Create a PAR file named 03-FirstPortalProjectXX.par where XX is your student number and deploy this using the Create/Export PAR File wizard. XX is your group number Test the application by executing it from within NWDS.
Solution 4: First Portal Component
Task:
First Portal Component Write your first Portal Component which presents a simple output like “Hello World” to the portal user. Use the integrated wizards to fulfill this task. 1. Start the SAP NWDS and create a new Portal Application Project named 03-FirstPortalProjectXX where XX is your student number. a) (Detailed Solution below) Start the SAP NWDS and create a new Portal Application Project named 03-FirstPortalProjectXX. 2. Click on the icon of the Portal Application Object wizard. Select Portal Component → Abstract Portal Component as template. Enter HelloWorldComponent into the name field. Enter com.sap.training.portal into the package name field. Click finish. a) Create a new AbstractPortalComponent subclass named com.sap.training.portal.HelloWorldComponent by means of the Portal Application Objects wizard.
3.
Implement the doContent method and so that some simple HTML output like “Hello World!” is written to the response. Use the code assistant to find the right method of the response object. a) The class HelloWorldComponent is opened automatically by the wizard. You also find it in 03-FirstPortalProjectXX → src.core → com → sap → training → portal. Enter “response” Into the doContent{} function. The code completion wizard offers all available methods and fields. Select write(String arg 0) – void and enter “Hello World!” as argument.
4.
Create a PAR file named 03-FirstPortalProjectXX.par where XX is your student number and deploy this using the Create/Export PAR File wizard. XX is your group number a) Click on the Icon Create/Export PAR File. Verify the name of the PAR and mark “Deploy PAR”. In the section Servers verify the connectivity and enter the valid password. Click on Finish. Double click on 03-FirstPortalProjectXX → dist → PORTAL-INF → portalapp.xml. The portalapp.xml editor opens. Click on the button Run next to the link HelloWorldComponent. The Application is executed in a new browser window. Continued on next page
5.
Test the application by executing it from within NWDS. a)
Lesson Summary
You should now be able to: • Getting started with SAP NWDS • Create a portal application project • Create a simple portal application component • Upload the component to the portal • Test the component
Lesson Objectives
After completing this lesson, you will be able to: • Debug a portal application
Business Example
Debugging
Preparation for Debugging • • • • Stop the Portal if running Launch the Config tool of J2EE engine Start SAP NetWeaver Developer Studio and open your project for debugging Make sure that the latest version of the debuggable code is deployed in the debug portal
You can make your programs easier to debug by following these guidelines: • Where possible, do not put multiple statements on a single line, because some debugger features operate on a line basis. For example, you cannot step over or set line breakpoints on more than one statement on the same line. Attach source code to JAR / PAR files if you have the source code.
First step of the debugging setup is to start the config tool of the J2EE engine. The tool is located in the directory <J2EE_Install_Dir>\JC00\j2ee\configtool\configtool.bat Switch to the current instance and goto the debug tab. Set Enable debug mode checked, starts the VM of J2EE in debug mode. Set a valid debug port, default port is 50021. Save the settings and restart the J2EE Engine
Add the host name, port, and alias of each EP6 instance in which you wish to connect to NetWeaver Developer Stuido. A valid user ID and password must also be supplied!
Goto Debug → Remote Java Application and create a new setting for your current Portal Application project Insert the portals DNS or IP Address and the debug port specified in the config tool, default port is 50021. If the portal runs on the local machine you can enter localhost instead of IP adress or DNS name. Important: Make sure that your portal application is already deployed in the portal
The export function allows an option to include the source code of the project in the PAR file (located in: /PORTAL-INF/srclib.api/parname.src.jar and /PORTAL-INF/srclib.core/parname.src.jar) and to deploy your application to your local Portal.
The Breakpoints view lists all the breakpoints you have set in the workbench projects. You can double-click a breakpoint to display its location in the editor. In this view, you can also enable or disable breakpoints, delete them, or add new ones. This view also lists Java exception breakpoints, which suspend execution at the point where the exception is thrown. You can add or remove exceptions.
To enable the breakpoint using the Breakpoints View • • • Locate the breakpoint in the marker bar of an editor Open the breakpoint's context menu and select Enable Breakpoint. The breakpoint image will change back to a blue circle.
To disable a breakpoint: • • • Locate the breakpoint in the marker bar of an editor Open the breakpoint's context menu and select Disable Breakpoint. The breakpoint image will change to a white circle.
To add a method breakpoint: • • • Open the class in the Outline view, and select the method where you want to add a method breakpoint. From the method's pop-up menu, select Add/Remove Method Breakpoint. A breakpoint appears in the Breakpoints view. If source exists for the class, then a breakpoint also appears in the marker bar in the file's editor for the method that was selected. While the breakpoint is enabled, thread execution suspends when the method is entered, before any line in the method is executed.
To set a hit count on a breakpoint: • • • Select the breakpoint to which a hit count is to be added. From the breakpoint's pop-up menu, select Hit Count. In the Enter the new hit count for the breakpoint field, type the number of times you want to hit the breakpoint before suspending execution.
When the breakpoint is hit for the nth time, the thread that hit the breakpoint suspends. The breakpoint is disabled until either it is re-enabled or its hit count is changed.
Choose Add Java Exception Breakpoint from the Breakpoints view or the workbench Run menu. A dialog listing all of the available exceptions is shown. Either type the name of the exception you want to catch or select it from the list. At the bottom of the page, use the check boxes to specify how you want execution to suspend at locations where the exception is thrown. • • Select Caught if you want execution to suspend at locations where the exception is thrown but caught. Select Uncaught if you want execution to suspend at locations where the exception is uncaught.
When stack frame is selected, you can see the visible variables in that stack frame in the Variables view. The Variables view shows the value of primitive types. Complex variables can be examined by expanding them to show their members. To launch the Variables View: • • Choose Window → Show View → Other Select Debug → Variables View
Force the portal to execute your deployed coding, e.g. an iView can be launched with PortalAnywhere.Go. The VM stops at the specified break point. The current values of the member variables can be tracked in the variables window of SAP NetWeaver Developer Studio.
Debugging with the variables view may be useful in situations where you are not receiving a runtime error but the component is not functioning correctly.
Unit Summary
You should now be able to: • Getting started with SAP NWDS • Create a portal application project • Create a simple portal application component • Upload the component to the portal • Test the component • Debug a portal application
Unit 4
Portal Applications and the Portal Runtime
Unit Overview
Review the Portal Runtime Guide. Describe a Portal application. Describe the PAR file format. Describe the properties of the deployment descriptor file (portalapp.xml). Describe Portal Components and Services.
Unit Objectives
After completing this unit, you will be able to: • • • • • • Download and review the Portal Runtime Guide Describe what makes up a Portal Application Describe the PAR file format and how it relates to deployment of a portal application Describe the various properties of the deployment descriptor (portalapp.xml) Describe Portal Components Describe Portal Services
Unit Contents
Lesson: Portal Applications and the Portal Runtime ........................ 76 Exercise 5: Portal Applications and the Portal Runtime................ 87
Unit 4: Portal Applications and the Portal Runtime
EP120
Lesson: Portal Applications and the Portal Runtime
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • • • • • • Download and review the Portal Runtime Guide Describe what makes up a Portal Application Describe the PAR file format and how it relates to deployment of a portal application Describe the various properties of the deployment descriptor (portalapp.xml) Describe Portal Components Describe Portal Services
Business Example
Portal Applications and the Portal Runtime
The Portal Runtime (PRT) • • • • The Portal Runtime (PRT) is one basic part of the portal environment integrated into the Web AS Provides a runtime and its corresponding services Provides a development environment Defines and manages the objects that make up a portal environment
Note: The architecture and components of the PRT are described in the PRT Guide. You will find a copy of the PRT Guide in the PDK Documentation under: Java Developer → Getting Started → Portal Runtime Guide You can also download a copy of the current PRT Guide from SDN using Portal Runtime Technology Release 6 as keywords in the SDN search field. The Portal Runtime is one basic part of the SAP Enterprise Portal Environment integrated in the SAP J2EE environment.
Lesson: Portal Applications and the Portal Runtime
The Portal Runtime Technology provides a Java based framework to define, build, and execute Applications in a Portal Environment by allowing the aggregation and the display of various contents such as rich text, xml, videos etc… The Portal Runtime Technology provides a runtime and its corresponding services as well as a development environment for Portal applications. The motivation behind the design and the technical implementation of the Portal Runtime are the following: Area of concern: The goal of the PRT is very well identified and restricts itself to the life cycle of portal applications. Open and Extensible: Many of the components of the PRT can be changed or customized to be adapted to the environment in which the PRT is executed. So the model proposed by the PRT can be extended to support, for example, different user interface models or different programming models. So, the Portal Runtime clearly positions itself as one of the key block used to build and execute any kind of Portal. The Portal Runtime defines and manages two kinds of objects that define a Portal Application. They are: Portal Components. From a user point of view, a component that can be displayed into a portal page. From an application development perspective, a plug able component designed to be executed into a Portal environment. Portal Services. A Component offering a globally accessible function in the Portal. The portal runtime development model offers a way to implement a clear separation between a Service API and its implementation. Portal Applications • Portal Applications ... – – – .. are bundles of Portal Components and Portal Services. .. are packaged as PAR (Portal Application ARchive) files – format that the Portal Runtime accepts for deployment of Portal Applications. A PAR file is an archive file/standard JAR file (ZIP format) containing a Portal Application with a XML-based Portal Application Deployment Descriptor (DD) called portalapp.xml. DD describes the portal application itself and provides information required at runtime
Unit 4: Portal Applications and the Portal Runtime
EP120
Portal Applications contain two types of resources: • Web Resources – Accessible via http(s) requests to a web server – All files NOT under WEB-INF Non-Web Resources – – Not accessible via an http(s) request All files under WEB-INF
•
A Portal Application can contain: • • • several Portal Components and several Portal Services. Using several sections in DD these components and services are defined. only 1 Portal Components only 1 Portal Services
Each Portal Application can be accessed by <par file name>.<component name> Everything can be packaged in a PAR file but depending on the purpose of the objects different properties may be needed to be set.
Startup: If set to “true”, the application as a whole will be "started" (initialized) on startup of the server. In particular this means that it will be locally deployed. Releasable: Because PRT allows hot deployment, all applications are releasable and the application instance can be dropped at any time by the system. Nevertheless some critical applications may want to avoid the release of their instance when the system runs low in memory. They should then set this property to false.
Unit 4: Portal Applications and the Portal Runtime
EP120
Figure 81: Portal Application - PAR file
Portal Applications – Components Portal Applications – Components • • • This is an executable part of the Portal Application. It can be described as a Java Code or JSP defined by properties and executed in a particular mode. Three different flavours (types): – iView Code (AbstractPortalComponent, …) – System – Layout The distinction is made by the property “ComponentType” – – – iView: “JSPNative”, “none” or “servlet” System: com.sapportals.portal.system Layout: com.sapportals.portal.layout
•
Flavours, System and Layout are just a matter of configuration. There is comprehensive documentation to be found in the online help (http://help.sap.com/nw04). In the further sections we refer to the flavor “iView” when speaking about Portal Components.
Lesson: Portal Applications and the Portal Runtime
Figure 82: Portal Applications - Components
Portal Component Config The component config is a set of properties which configures the Portal Component (class name, etc.). Portal Component Profile The component profile is a set of properties (name-value pairs) representing the dynamic part of the Portal Component that could be customized/personalized to change the behavior of a Portal Application.
AuthRequirement: (new in EP6.0) A list of roles can be specified. This protection is important because the component can be launched directly (without using an iView). Cause the ACL‘s are set for iViews only, this was a protection while direct launching is possible.
Lesson: Portal Applications and the Portal Runtime
Figure 86: iView Properties and Delta Links
The Portal Component shown above is an executable component (code) which is (up-)loaded to the portal as part of an archive. It lays at the beginning of the inheritance chain. The component-profile section contains properties that make up the profile of the Portal Component as accessible from the com.sapportals.portal.prt.component.IPortalComponentProfile interface at runtime. The profile is usually abstracted in a personalizable entity, the iView. The values of properties in this section define the default values. By administrative modification or personalization, these values may be modified. Explain the inheritance using Delta Links
Unit 4: Portal Applications and the Portal Runtime
EP120
Portal Applications – Services • Portal Services bring commonly used functionality into the Portal – – – • Portal Services are a way to provide JAVA based functionality to Portal Components and other Portal Service By the handling of Portal Applications, Portal Services may enjoy separation of API and implementation Portal Services may now be accessed from outside of the Portal Framework using SOAP/Web Services Protocol
In the non-trivial case, a service provides an interface based API and an implementation. The implementatoin is non-public and will not be seen by nor interfer with using applications. – The service interface relates the service API and its implementation by offering access to implementations of API interfaces through factories. – The API should not rely on any other non-standard API. A portal service can be transfered into a Web Service. –
•
Figure 87: Portal Applications - Services
Attention please here again the separation between “config” and “profile” definition. In the config section only two important properties are set. (see next slide)
Lesson: Portal Applications and the Portal Runtime
Figure 88: Portal Applications - Service Configuration
Portal Applications – Service Profile • • • Contains properties that make up the profile of the Portal Service. Properties are accessible via the interfacecom.sapportals.portal.prt.service.IServiceProfile. In contrast to the service config, the service profile properties may be modified by administrative environment and is available at next start of the service. There are no predefined service profile properties.
Unit 4: Portal Applications and the Portal Runtime
EP120
Sharing References declare API extensions (with 6.0 policy). Private Sharing References declare APIs used by the application's private code Service-config defines essential settings for the service. The Class Loading Policy determines how definitions of this application are exported and definitions from other applications are imported. "transitive" is the default.
Lesson: Portal Applications and the Portal Runtime
Exercise 5: Portal Applications and the Portal Runtime
Exercise Objectives
After completing this exercise, you will be able to: • Explain the differences between Portal Applications, Portal Components and Portal Services • What are the essential parts of a PAR file? • What is the Deployment Descriptor?
Business Example Task:
Portal Terminology 1. 2. 3. Explain the differences between Portal Applications, Portal Components and Portal Services. What are the essential parts of a PAR file? What is the Deployment Descriptor?
Unit 4: Portal Applications and the Portal Runtime
EP120
Solution 5: Portal Applications and the Portal Runtime
Task:
Portal Terminology 1. Explain the differences between Portal Applications, Portal Components and Portal Services. a) The Portal Runtime defines and manages two kinds of objects that define a Portal Application: the Portal Components and the Portal Services.Thus a Portal Application compromises Portal Components and Portal Services. From a user point of view, a portal component can be displayed into a portal page. From an application development perspective, the portal component is a plugable component that is designed to be executed into a Portal environment. A portal service offers functionality that is globally accessible for components in the Java iView Runtime. The component accesses the service via an API. 2. What are the essential parts of a PAR file? a) The PAR file is a zip compatible format which includes at least the deployment descriptor portalapp.xml and the according implementation classes as compiled classes or as jar-libs.
Lesson: Portal Applications and the Portal Runtime
3.
What is the Deployment Descriptor? a) The Deployment Descriptor defines: • • • How a portal component is handled by the platform Which portal services and other portal components are accessed Which parameters can be personalized by the user
It is defined in the file portalapp.xml and noted as an XML definition. The root element is the application element. The application element can have an attribute alias, containing a comma-separated list of aliases on the portal application. The portal application name is defined by the name of the portal archive (par file). The attribute alias defines an additional name for the portal application. Attention: It is not recommended to use the aliases because of name clashes. This feature is meant to be used for backward compatibility reasons. Three child elements are allowed in the application element: • • • application-config: the properties defined in this section affect the portal application as a whole. components: all portal components of a portal application are declared in this element services: all portal services of a portal application are declared in this element
Unit 4: Portal Applications and the Portal Runtime
EP120
Lesson Summary
You should now be able to: • Download and review the Portal Runtime Guide • Describe what makes up a Portal Application • Describe the PAR file format and how it relates to deployment of a portal application • Describe the various properties of the deployment descriptor (portalapp.xml) • Describe Portal Components • Describe Portal Services
Unit Summary
You should now be able to: • Download and review the Portal Runtime Guide • Describe what makes up a Portal Application • Describe the PAR file format and how it relates to deployment of a portal application • Describe the various properties of the deployment descriptor (portalapp.xml) • Describe Portal Components • Describe Portal Services
Unit 5
Portal Components
Unit Overview
Use Abstract Portal components, Dynpage components and JSP Dynpage components. Leverage personalization features. Leverage internationalization features. Describe the features of HTMLB and use HTMLB in Portal components. Use JSP pages. Understand Model-View-Controller (MVC) approach to developing Portal applications.
Unit Objectives
After completing this unit, you will be able to: • • • • • • • • Understand and build abstract portal components Discuss the nature of the security zone Discuss how a Portal application uses the security zone features Discuss permissions and security zones Allow end user personalization of portal applications Write Portal Applications that are language independent and handle complex phrases in a language neutral fashion. Build Portal applications using HTMLB controls Use the Model-View-Controller (MVC) approach when developing your Portal Applications.
Lesson Objectives
After completing this lesson, you will be able to: • Understand and build abstract portal components
Business Example
Abstract Portal Components
Figure 90: The IPortalComponent Interface
possible causes for calling the destroy() method are 1. Portal is terminating or 2. The Portal runtime needs to free up some memory For example when a new version of the application is being uploaded. After the call to destroy(), the garbage collector collects the component.
-> Show documenation in Java Doc of the PDK !! doContent - Generates the content of the component. doEdit - Provides personalization dialog. doHandleEditData Default handler upon personalization according to the convention, which is that a personalization dialog presentation should use profile names as parameter names and it should contain a field “save” if the parameter set should be saved into the profile. doBeforeContent Handles the BEFORE_CONTENT event. doAfterContent Handles the AFTER_CONTENT event. doRequestEvent - Handles a client raised event that is not handled in a specific event handler. Portal Components that extend the AbstractPortalComponent class can overwrite and implement methods for content creation and request processing.
Lesson: Security Zones
Lesson Overview
In this lesson you will learn about security zones and how the portal administrator can use them to control access to portal services and components.
Lesson Objectives
After completing this lesson, you will be able to: • • • Discuss the nature of the security zone Discuss how a Portal application uses the security zone features Discuss permissions and security zones
Business Example
As a portal content developer, you have been tasked with developing a portal application to display highly sensitive information. To ensure that only those users authorized can access this application and its related portal components and portal services, this application may not be accessible directly from outside the portal. To run this application on the portal platform, you need to secure it under a security zone.
What is a Security Zone?
Security zones are used to prevent unauthorized users from accessing iViews, portal components and portal services through a direct URL used outside of the portal environment. When activated, security zones enable system administrators to control which portal components and portal services a portal user can launch. Security zones provide a means of implementing an optional, secondary layer of security to portal components and services which are accessed by a URL. URL access to portal components and services can occur directly or indirectly via an iView, and is controlled by means of progressive safety levels and permissions, which are assigned by system administrators to authorized users in the permission editor.
A security zone specifies the vendor ID, the security area, and safety level for each portal component and portal service (Web services accessed through the SOAP protocol). Access to portal components and services by authorized users is controlled by assigning portal user permissions to the hierarchical structure of vendor ID, the security area, and progressive safety levels in the portal’s security zones. Content developers assign portal components and services to a security zone during the development phase. The security zone is defined in a portal application’s descriptor XML file. Typically, it is the content or system administrator’s responsibility to provide the appropriate security zone assignment to the content developer.
After a portal application is deployed in a portal, an administrator with access to the central permission editor must assign authorized users, groups, or roles to the security zone to which the portal component or service belongs. Security zones are displayed in the Portal Catalog in a hierarchical structure. A portal component or service can belong to only one security zone; however portal components and services may share the same safety level. This allows the administrator to assign permissions to a safety level, instead of assigning them directly to each portal component or service, thus taking advantage of the permission inheritance mechanism, which passes the permissions from the safety level to any portal component or service located in it. You can control access to portal components through direct URLs or through iViews. Access controlled through direct URLs Generally, portal components are accessed through an iView. However, special cases – such as the portal logon component – require direct URL access to portal applications without an iView. A user is allowed direct access by URL at runtime under the following conditions: • • The portal component or service declares its security zone. The user (or group or role) has been assigned end-user permissions in the permission editor to the security zone defined by the portal component.
Access controlled through iViews When an iView is launched by a user at runtime, the Portal Runtime (PRT) initially determines if the user is assigned end-user permission to the role object containing the iView. If authorized, the user can view the iView’s content. Security zones offer an extra, but optional, layer of code-level security to iViews accessed through standard role-based assignment. When this functionality is activated, the PRT also checks if the user has been assigned end-user permission to the iView’s portal component in its designated security zone. Note that this check is performed after the end-user permission to the iView has been approved. The user must pass both checks to view the iView’s content. This second level of security for iViews is activated or deactivated by setting a Java VM (virtual machine) parameter using the J2EE Config Tool (for both server and instance or server only). By default, this functionality is disabled • • To activate it, set the Dcom.sap.nw.sz parameter to true. To deactivate it, set the Dcom.sap.nw.sz parameter to false. Hint: This parameter also prevents unauthorized users from accessing iViews through a direct URL used outside of the portal environment. In future release, this parameter may be deprecated; the functionality it provides will remain and operate permanently.
How to Get a Portal Application into a Security Zone
When the portal application archive is loaded in the system, zones are created if they do not exist. The entries that correspond to the portal objects are then created in the zone. When a portal object (portal component or portal service) is accessed, the portal runtime checks if the current user has the permissions required to access the zone to which the portal object belongs.
Figure 97: Example of Security Zone Entry in the Deployment Descriptor
You can specify security zones in the portal application descriptor file, portalapp.xml, in the following ways: • • Computed (preferred method) Fully specified
In the computed method, the security zone of a component is defined by creating the following properties in the portalapp.xml file in the application PAR file: • VendorID and SecurityArea: These properties are defined in the application-config section, and apply to all the components and services in the PAR. SafetyLevel: This property is defined for each component and service
•
When the portal application is deployed in the portal, the full security zone is then automatically generated by the PRT using the above properties and the names of the components and services: • • Components: VendorID/SecurityArea/SafetyLevel/portal_application_name/components/component_name Services: VendorID/SecurityArea/SafetyLevel/portal_application_name/services/service_name
In the fully specified method, the security zone is defined in the portal application descriptor with a single property, SecurityZone. The syntax of this property can be any slash-separated (/) string to define the security zone hierarchy; however, either of the following formats is recommended: • • vendor_ID/security_area/safety_level/portal_application_name/components/component_name vendor_ID/security_area/safety_level/portal_application_name/services/component_name
Rules for Creating the Zones During the deployment of the portal application in the portal, the following rules apply to creating the zones associated to the portal objects: • If the portal application specifies a SecurityZone property (fully specified method), its value will take precedence even if the portal application also specifies the VendorID and SafetyLevel properties (computed method). If no security zone is specified, the PRT computes a zone for each portal objects using the properties Vendor, SecurityArea and SafetyLevel. Any component that does not have a proper vendor, security area or safety level property are listed under an UndefinedVendor, UndefinedSecurityArea or UndefinedSafetyLevel folder in the appropriate location in the Security Zones folder in the Portal Catalog. This enables administrators to easily locate components whose PAR has been deployed without the proper security zone properties.
How Are Permissions and Security Zones Related
Security zones extend to components and services the permission model implemented in the PRT, which controls access to all portal objects: • • Portal components – either accessed from the prtroot URL or from the portal application repository. Portal services – when accessed as Web services by the SOAP connection.
In the portal, security zones are located in the root Security Zones folder within the Portal Catalog and are represented as a set of portal components and portal services, to which Access Control Lists (ACL) are attached and checked at runtime when the portal object belonging to a zone is accessed. During the development phase, the security zone allows you to abstract the security level that a portal component or a portal service will require at runtime. You do not need to know the name of the roles or the name of the users that will be present in the portal environment in which the portal application will be installed. The zone defines a logical catalog containing a set of portal objects. You have to associate the principal security of the system to that zone by creating ACLs. The ACLs define the permission required for accessing a specific zone. A safety level for a security zone enables you to group objects that belong to a zone into different categories. Within that zone, you can define different safety levels. Each of these safety levels can then be assigned to different permissions. This helps you to organize and classify objects that belong to a certain zone. The portal defines the following standard safety levels for initial portal content to which out-of-the-box groups and roles are assigned permissions (note that the description of each safety level is based on the end-user permission setting only, regardless of the administrator permission setting):
Safety Levels for Security Zones Safety Level No Safety Description Anonymous users are permitted to access portal components defined in the security zone. A user must be at least an authenticated portal user to access portal components defined in the security zone. A user must be assigned to a particular portal role that is authorized to access portal components defined in the security zone. A user must be assigned to a portal role with higher administrative rights that is authorized to access portal components defined in the security zone.
Low Safety
Medium Safety
High Safety
For information on which initial groups and roles are assigned to the standard security zones shipped with the portal, see Default Permissions section below. We highly recommend that customers use this convention and the standard safety levels when deploying custom-made applications in the portal. Hint: Problems related to accessing the portal and its content are often attributed to insufficient permissions in security zones. When troubleshooting access-related issues in the portal, it is recommended to also check the security zone permissions. Default Permissions for Maximum Security The portal comes with a minimum set of permissions assigned to its initial content. These default permissions are designed to provide maximum security for a freshly installed portal. The default permissions settings are sufficient to enable users assigned to the super administrator role to work and gain access to all initial content. They also enable the remaining standard administration roles (content, system, and user) to access tools specific to these roles, but not to initial content objects. For example, a content administrator has access to the Portal Content Studio, but is not able to gain access to any content objects, such as iViews, pages, and roles — the Portal Catalog in the Portal Content Studio is empty. This topic describes the default permissions assigned to the initial content of the portal.
Caution: The initial permissions described in this topic are only valid for a fresh and full installation of the portal. When upgrading a portal, the initial permissions script in the portal is not executed. This prevents the permissions in an existing portal from being overwritten. If you are upgrading your portal, you will however need to assign permission to the standard portal components and services shipped with the portal. These components and services reside in the Security Zones folder. It is recommended to use as a basis the initial permissions set for security zones in a fresh installation (as described in the Permissions in Security Zones section above). On one hand, iViews automatically inherit their permissions from the role to which they are used. On the other hand, portal components and services inherit their permissions from the security zone or safety level to which they are assigned. Most generic portal applications intended for standard users in an organization should apply to either the no safety or low safety levels, and no additional role-specific permissions need to be assigned to their security zones. The reason for this is that the Everyone and Authenticated Users groups are by default assigned end-user permission to the no safety and low safety levels, respectively, and thereby permit all anonymous and authorized user activity already. The medium safety and high safety levels are typically reserved for sensitive applications, which require permission assignments that are targeted to specific users, groups, or roles. Note: • Security zone functionality is only operational when the PRT security mode is set to production mode. The Located at \J2eeRoot\cluster\server0\apps\sap.com\irj\servlet_jsp\irj\root\WEBINF\portal\system\properties\prtCentral.properties The portal.runtime.security.mode=production setting must be set to "production", which does not allow portal components to start directly. Possible values are "development" or "production" or "test". • To prevent a complete lockout situation that prevents access to the portal by all users, including super users, you must make sure that all portal groups representing anonymous users (for example, the Everyone group) have end-user permission enabled for the safety level that permits anonymous access to portal components and services accessed by a URL (for example, the no safety level). Typically, you should grant end-user permission to the Everyone group in the following standard security zones that are shipped with the portal: – – security/sap.com/NetWeaver.Portal/no_safety security/sap.com/NetWeaver.UserManagement/no_safety
Exercise 6: Security Zones
Exercise Objectives
After completing this exercise, you will be able to: • Add a security zone to your portal application
Business Example
Prevent unauthorized users from running portal applications from the command line.
Task:
Add a security zone to your portal application to stop unauthorized access. 1. Open portal component 05-PersonalizationXX or the template solution. Open the portalapp.xml file and add a vendor of com.customer and a SecurityArea of portal to the application configuration section. Add a safety level of low_safety to the component configuration section to the welcome component. Deploy the component. Close all browsers down and try running the component from portalapp.xml file of NWDS. Login into the portal as user EP120.E-XX and re-test the application. Login into the portal as user EP120.D-XX and re-test the application. What are the results in each case and why?
Solution 6: Security Zones
Task:
Add a security zone to your portal application to stop unauthorized access. 1. Open portal component 05-PersonalizationXX or the template solution. Open the portalapp.xml file and add a vendor of com.customer and a SecurityArea of portal to the application configuration section. a) In the application section of the portalapp.xml file add a standard configuration property of Vendor: com.customer and SecurityArea: portal.
Add a safety level of low_safety to the component configuration section to the welcome component. a) In the component Welcome add a standard configuration property of low_safety.
Figure 99:
3.
Deploy the component. Close all browsers down and try running the component from portalapp.xml file of NWDS. Login into the portal as user EP120.E-XX and re-test the application. Login into the portal as user EP120.D-XX and re-test the application. What are the results in each case and why? a) Deploy the component. Close all browsers down and try running the component from portalapp.xml file of NWDS. You should receive an error. Login into the portal as user EP120.E-xx and password of welcome. Run the component again and this time you will receive an security error. Login to the portal as user EP120.D-XX. Run the application one more time. This should now be successful and shows you must be authorized to run a portal component from the command line. User EP120.D-xx is a super administrator and is therefore able to run all component.
Lesson Summary
You should now be able to: • Discuss the nature of the security zone • Discuss how a Portal application uses the security zone features • Discuss permissions and security zones
Personalization Aspects of personalization: • • Modifying and storing per user data of a Portal Component Displaying and handling of personalization dialogs that offer modification of iView properties
Standard Dialog: • The built-in personalization mechanism presents a standard dialog for changing personalization enabled properties in the component profile.
Custom Dialog: • Custom personalization can be implemented to present customer specific UI for the personalization dialog.
Figure 106: Attributes of Personalization Properties (1)
Figure 107: Attributes of Personalization Properties (2)
Hint: The personalization dialog can be tested directly before creating an iview. Run the portal application from the portalapp.xml file. When the browser is open append ?prtmode=edit to the end of the URL. For example http://twdf0xxx.wdf.sap.corp:50000/irj/servlet/prt/portal/prtroot/05Personalization.Welcome?prtmode=edit
Exercise 7: Personalization
Exercise Objectives
After completing this exercise, you will be able to: • Leverage the component profile to implement personalization for your Portal Component
Business Example Task:
Personalization Enhance your Portal Component by enabling the user to change your properties by a personalization feature. 1. 1. Create a new Portal Application Project within the EP perspective. Call the project 05-PersonalizationXX. 2. Add a new Portal Component named Welcome. 3. Navigate to the Outline box, bottom left, – right click on Welcome and select Add property in and component profile. Ensure that you have the PortalApp.xml displayed in the editor 4. Create a new property called colorName and assign an initial value of blue. 5. Create a new property called petsName and assign an initial value of your choice e.g. Flower 6. Create a new property called location and assign an initial value of your choice e.g. Paris. 7. Add a sub-property to colorName and assign a name of type with value select e.g. select[Red,Orange,Green,Blue,Yellow,Purple,Violet] 8. Add a sub-property to colorName and assign a name plainDescription and value of Favourite Colour or Favorite Color depending on which side of the Atlantic you reside. 9. Add a sub-property to colorName and assign a name personalization and value of dialog. 10. Add a sub-property to location and assign a name plainDescription and value of Country of Residence. Continued on next page
11. Add a sub-property to location and assign a name personalization and value of dialog. 12. Add a sub-property to petsName and assign a name plainDescription and value of Pet’s Name. 13. Add a sub-property to petsName and assign a name personalization and value of dialog. 14. Check the Portalapp.xml file to check all the added entries. 15. Within the doContent method of your AbstractPortalComponent please add the following code:IPortalComponentProfile profile =
request.getComponentContext().getProfile(); String colorName = profile.getProperty("colorName"); String petsName = profile.getProperty("petsName"); String location = profile.getProperty("location"); response.write("<table><tr></tr>"); response.write( "<tr><td> Hello. Your favorite color is </td><td bgcolor='"
+ colorName.toLowerCase().trim() + "'>" + colorName + "</td></tr>"); response.write( "<tr><td>Your pet's name is </td><td>" + petsName + "</td></tr>"); response.write( "<tr><td> You live in </td> <td>" + location + "</td> </tr>"); response.write("</table>");
16. Create an iView to test the working of your Personalization.
Solution 7: Personalization
Task:
Personalization Enhance your Portal Component by enabling the user to change your properties by a personalization feature. 1. 1. Create a new Portal Application Project within the EP perspective. Call the project 05-PersonalizationXX. 2. Add a new Portal Component named Welcome. 3. Navigate to the Outline box, bottom left, – right click on Welcome and select Add property in and component profile. Ensure that you have the PortalApp.xml displayed in the editor 4. Create a new property called colorName and assign an initial value of blue. 5. Create a new property called petsName and assign an initial value of your choice e.g. Flower 6. Create a new property called location and assign an initial value of your choice e.g. Paris. 7. Add a sub-property to colorName and assign a name of type with value select e.g. select[Red,Orange,Green,Blue,Yellow,Purple,Violet] 8. Add a sub-property to colorName and assign a name plainDescription and value of Favourite Colour or Favorite Color depending on which side of the Atlantic you reside. 9. Add a sub-property to colorName and assign a name personalization and value of dialog. 10. Add a sub-property to location and assign a name plainDescription and value of Country of Residence. 11. Add a sub-property to location and assign a name personalization and value of dialog. 12. Add a sub-property to petsName and assign a name plainDescription and value of Pet’s Name. 13. Add a sub-property to petsName and assign a name personalization and value of dialog.
14. Check the Portalapp.xml file to check all the added entries. 15. Within the doContent method of your AbstractPortalComponent please add the following code:IPortalComponentProfile profile =
request.getComponentContext().getProfile(); String colorName = profile.getProperty("colorName"); String petsName = profile.getProperty("petsName"); String location = profile.getProperty("location"); response.write("<table><tr></tr>"); response.write( "<tr><td> Hello. Your favorite color is </td><td bgcolor='"
+ colorName.toLowerCase().trim() + "'>" + colorName + "</td></tr>"); response.write( "<tr><td>Your pet's name is </td><td>" + petsName + "</td></tr>"); response.write( "<tr><td> You live in </td> <td>" + location + "</td> </tr>"); response.write("</table>");
16. Create an iView to test the working of your Personalization. a)
Lesson Objectives
After completing this lesson, you will be able to: • Write Portal Applications that are language independent and handle complex phrases in a language neutral fashion.
Business Example
Build applications that can display information in multiple languages.
Exercise 8: Internationalization
Exercise Objectives
After completing this exercise, you will be able to: • Support multiple languages in your Portal Application
Business Example Task:
Internationalization Support multiple locales in your personalized Portal Component. Extend the previous exercise and translate all labels on the screen. “Hello. Your favorite color is” → “Hallo. Ihre Lieblingsfarbe ist” “Your pet's name is” → “Der Name Ihres Haustiers ist” “You live in” → “Sie wohnen in” 1.
Open project 05-PersonalizationXX. Add the property ResourceBundleName to the component-config of welcome. Set the property to myBundle. Add the following 3 files to the directory 05-PersonalizationXX → dist → PORTAL-INF localization: • myBundle.properties containing favorite_color= Hello. Your favorite color is pet_name= Your pet's name is home= You live in • myBundle_de.propeties containing favorite_color= Hallo. Ihre Lieblingsfarbe ist pet_name= Der Name Ihres Haustiers ist home= Sie wohnen in • myBundle_en.properties containing favorite_color= Hello. Your favorite color is pet_name= Your pet's name is home= You live in
4.
Add a new component-profile property ForcedRequestLanguage with value en to easily test component through personalization option in iview. Access the string within the doContent method of the component HelloWorldComponent. Change all literals to use the translatable language tokens. Deploy and test your component
Solution 8: Internationalization
Task:
Internationalization Support multiple locales in your personalized Portal Component. Extend the previous exercise and translate all labels on the screen. “Hello. Your favorite color is” → “Hallo. Ihre Lieblingsfarbe ist” “Your pet's name is” → “Der Name Ihres Haustiers ist” “You live in” → “Sie wohnen in” 1. 1. 2. 3. Open project 05-PersonalizationXX. Add the property ResourceBundleName to the component-config of welcome. Set the property to myBundle. Add the following 3 files to the directory 05-PersonalizationXX → dist → PORTAL-INF localization: • myBundle.properties containing favorite_color= Hello. Your favorite color is pet_name= Your pet's name is home= You live in • myBundle_de.propeties containing favorite_color= Hallo. Ihre Lieblingsfarbe ist pet_name= Der Name Ihres Haustiers ist home= Sie wohnen in • myBundle_en.properties containing favorite_color= Hello. Your favorite color is pet_name= Your pet's name is home= You live in 4. Add a new component-profile property ForcedRequestLanguage with value en to easily test component through personalization option in iview. Access the string within the doContent method of the component HelloWorldComponent. Change all literals to use the translatable language tokens. Deploy and test your component Continued on next page
Lesson Summary
You should now be able to: • Write Portal Applications that are language independent and handle complex phrases in a language neutral fashion.
Lesson Objectives
After completing this lesson, you will be able to: • Build Portal applications using HTMLB controls
Business Example
Build portal applications using HTMLB controls.
HTMLB
HTMLB – What it is • • • HTMLB (HTML-Business for Java) provides a full set of easy-to-use Web controls HTMLB allows a design-oriented page layout It is designed to overcome typical servlet problems, such as: Visualization and business logic are not separate Content management consumes a lot of qualified manpower. Skills in HTML, CSS, JavaScript etc. are essential – Development has to take care of different web clients and -versions – Maintaining the corporate identity through out the whole application is hard to achieve – Namespace conflicts with form elements Also provides the technological infrastructure for easy customer branding – –
•
Although development skills are essential, there is more room for flexibility while developing the application
HTMLB Objects • • Forms Controls: – – – Layout Controls: Use to arrange elements in your interface Visible Controls: Elements with which the user has significant interaction Non-visible Controls: Container elements that hold other elements or compliment the other components • • Container Events For every button or link an event can be defined. The event that is raised can be handled in the next request.
Figure 171: HTMLB - Creating Pages in Abstract Portal Components using the class library
Figure 172: HTMLB - DynPage Approach
doInitialization: Called when the application is started. The call is made when the page is directly called per URI without parameters and no event occurred. Usually this method is used to initialize data and to set up models. Be aware of the fact that the doInitialization event is also caused when another portal component on the same page sends an event doProcessAfterInput: Called when the web client sends the form to the web server. Except on doInitialization the call is performed every time an event occurs doProcessBeforeOutput: Called before the form is sent to the web client. The call is performed every time even on doInitialization
Please notice that the highlighted code in the above example are the areas that the developer has added. The line myButton.setOnClick(click); will invoke the method onClick when the user clicks this button.
Exercise 9: HTMLB
Exercise Objectives
After completing this exercise, you will be able to: • To write a portal Application based on the DynPage approach. • Use HTMLB eventing. • Use a complex HTMLB element (dateNavigator).
Business Example Task:
Use the DynPage approach to implement an easy user interface. In this exercise we implement an HTMLB dateNavigator element. 1. 1. 2. 3. Create new Portal Application Project named 05-Basic1HTMLBXX where XX is your student number. Create a new DynPage component with the Portal Component Wizard. Name this Basic1Dynpage. Please add the following code into the doProcessingBeforeOutput method to add a new input field.myForm.addText("This is your
Basic HTMLB Application "); InputField inputField = new InputField("myInputField"); inputField.setValue("This is your inputfield text"); myForm.addComponent(inputField);
Save and correct the imports that are needed. Perform a quick par upload and test. Use events to find the day, month or year that the user selects. An example of the method for month:public
onMonthClick(Event evt) { DateNavigatorMonthClickEvent month = (DateNavigatorMonthClickEvent) evt; action = month.getMonth() + " } " + month.getYear(); void
9.
Optional: Change the number of months displayed by the DateNavigator element.
Solution 9: HTMLB
Task:
Use the DynPage approach to implement an easy user interface. In this exercise we implement an HTMLB dateNavigator element. 1. 1. 2. 3. Create new Portal Application Project named 05-Basic1HTMLBXX where XX is your student number. Create a new DynPage component with the Portal Component Wizard. Name this Basic1Dynpage. Please add the following code into the doProcessingBeforeOutput method to add a new input field.myForm.addText("This is your
Basic HTMLB Application "); InputField inputField = new InputField("myInputField"); inputField.setValue("This is your inputfield text"); myForm.addComponent(inputField);
4. 5.
Perform a quick par upload and test. Add the dateNavigator code into the doProcessBeforeOutput method:IPortalComponentRequest request
(IPortalComponentRequest) this.getRequest(); IPortalComponentContext context = request.getComponentContext(); IPortalComponentProfile profile = context.getProfile(); IPageContext pagecontext = PageContextFactory.createPageContext(request); =
Use events to find the day, month or year that the user selects. An example of the method for month:public
onMonthClick(Event evt) { DateNavigatorMonthClickEvent month = (DateNavigatorMonthClickEvent) evt; action = month.getMonth() + " } " + month.getYear(); void
9.
Optional: Change the number of months displayed by the DateNavigator element.
Lesson Objectives
After completing this lesson, you will be able to: • Use the Model-View-Controller (MVC) approach when developing your Portal Applications.
Business Example
Build applications using MVC.
MVC
Java Server Pages (JSPs) - Motivation The Java servlet approach for developing server-side web applications has some drawbacks, e.g. • • • Application logic and content creation is mixed Generation HTML output from a Java class is not comfortable (e.g. out.println(“<table name=\”table1\” width=\”100%\”>”) Developers need both Java and HTML know-how
These issues have been overcome with the introduction of Java Server Pages (JSPs). These are simple HTML (or XML, WML, …) templates, enriched with special tags for server side page processing. At runtime, the JSPs are compiled to Java Servlets.
Both the HTTPServletRequest and the IPortalComponentRequest are available Only the IPortalComponentResponse is available (no HTTPServletResponse!) Only the HTTPSession is available (no IPortalComponentSession!)
Exercise 10: JSPDynPage
Exercise Objectives
After completing this exercise, you will be able to: • Write Portal Applications that using JSPDynPages. • Add your elements to a TabStrip
Business Example Task:
Create an Application using the TabStrip HTMLB element to demonstrate the use of tags in the JSPDynPages. 1. 1. 2. 3. Create a Portal Application with the name 05-JSPTabStrip-htmlbXX where XX is your student or group number. Create a Portal Component based on a JSPDynpage with the name JSPtabstrip. Ensure that you have the following code at the top of your JSP page:
Add the basic TabStrip tags
<hbj:tabStrip id="myTabStrip1" bodyHeight="200" width="400" horizontalAlignment="CENTER" verticalAlignment="TOP" selection="1" tooltip="This is the best TabStrip ever designed" >
<hbj:tabStripItem id="myTabStripItem1" index="1" height="80" width="160" onSelect="tabItem1" title="Bananas" tooltip="Select this to find out more about bananas" > <hbj:tabStripItemBody> <hbj:textView text="Bananas are grown in tropical areas of the world." /> </hbj:tabStripItemBody> </hbj:tabStripItem>
Add more tabstrips items within the tabstrip start and end tags. These form the screens that will be displayed when a user presses the top tab.
<hbj:tabStripItem id="myTabStripItem2" index="2" height="80" width="160" onSelect="tabItem2" title="Oranges" tooltip="Oranges are orange" > <hbj:tabStripItemBody> <hbj:textView text= "The Orange is a fruit originating from South America" /> </hbj:tabStripItemBody> </hbj:tabStripItem> <hbj:tabStripItem id="myTabStripItem3" index="3" height="80" width="160" onSelect="tabItem3" title="Apples" tooltip="Apple makes mac" > hbj:tabStripItemHeader> <hbj:textView text="Apples 3" /> </hbj:tabStripItemHeader>
<hbj:tabStripItemBody> <hbj:textView text= "Apples were introduced into the UK by the Romans?" /> </hbj:tabStripItemBody> </hbj:tabStripItem> <hbj:tabStripItem id="myTabStripItem4" index="4" height="80" width="160" onSelect="tabItem4" title="Grapes" tooltip="Grapes are great" > <hbj:tabStripItemHeader> <hbj:textView text="Grapes 4" /> </hbj:tabStripItemHeader>
<hbj:tabStripItemBody> <hbj:textView text= "Grapes are the best because they are used to make wine." />
Please ensure that the following entry is included in the Deployment Descriptor
<component-profile> <property name="tagLib" value="/SERVICE/htmlb/taglib/htmlb.tld"/> </component-profile>
7. 8. 9.
Please ensure that the certain native jsp entries are deleted in the Deployment Descriptor. Perform a par upload and test. Ensure that the methods required are inserted:
public void onTabItem1(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "1"); } public void onTabItem2(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "2"); } public void onTabItem3(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "3"); } public void onTabItem4(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "4"); }
10. Please insert the variable needed at the top of the JSP page:
<% String tabselection1 = (String)componentRequest.getValue("tabselection1"); %>
11. Change the defaulted first tab to dynamically show the selection:
selection="<%=tabselection1%>"
12. Enter this code into the doInitialization method. This will enable the first tab to be selected when we first access this screen(the user has not had a chance to change). We could change this to 2 or 3 later.
// set the initial entry button to the first tab IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "1");
13. Create a par file, deploy onto your server and test. 14. Optional: Add other htmlb elements into your ‘tab screens’.
<br><br> <hbj:dropdownListBox id="myDropdownListBox1"
Solution 10: JSPDynPage
Task:
Create an Application using the TabStrip HTMLB element to demonstrate the use of tags in the JSPDynPages. 1. 1. 2. 3. Create a Portal Application with the name 05-JSPTabStrip-htmlbXX where XX is your student or group number. Create a Portal Component based on a JSPDynpage with the name JSPtabstrip. Ensure that you have the following code at the top of your JSP page:
Add the basic TabStrip tags
<hbj:tabStrip id="myTabStrip1" bodyHeight="200" width="400" horizontalAlignment="CENTER" verticalAlignment="TOP" selection="1" tooltip="This is the best TabStrip ever designed" >
<hbj:tabStripItem id="myTabStripItem1" index="1" height="80" width="160" onSelect="tabItem1" title="Bananas" tooltip="Select this to find out more about bananas" > <hbj:tabStripItemBody>
<hbj:textView text="Bananas are grown in tropical areas of the world." /> </hbj:tabStripItemBody> </hbj:tabStripItem>
Add more tabstrips items within the tabstrip start and end tags. These form the screens that will be displayed when a user presses the top tab.
<hbj:tabStripItem id="myTabStripItem2" index="2" height="80" width="160" onSelect="tabItem2" title="Oranges" tooltip="Oranges are orange" > <hbj:tabStripItemBody> <hbj:textView text= "The Orange is a fruit originating from South America" /> </hbj:tabStripItemBody> </hbj:tabStripItem> <hbj:tabStripItem id="myTabStripItem3" index="3" height="80" width="160" onSelect="tabItem3" title="Apples" tooltip="Apple makes mac" > hbj:tabStripItemHeader> <hbj:textView text="Apples 3" /> </hbj:tabStripItemHeader>
<hbj:tabStripItemBody> <hbj:textView text= "Apples were introduced into the UK by the Romans?" /> </hbj:tabStripItemBody> </hbj:tabStripItem> <hbj:tabStripItem id="myTabStripItem4" index="4" height="80" width="160" onSelect="tabItem4" title="Grapes" tooltip="Grapes are great" > <hbj:tabStripItemHeader> <hbj:textView text="Grapes 4" /> </hbj:tabStripItemHeader>
<hbj:tabStripItemBody> <hbj:textView text= "Grapes are the best because they are used to make wine." />
Please ensure that the following entry is included in the Deployment Descriptor
<component-profile> <property name="tagLib" value="/SERVICE/htmlb/taglib/htmlb.tld"/> </component-profile>
7. 8. 9.
Please ensure that the certain native jsp entries are deleted in the Deployment Descriptor. Perform a par upload and test. Ensure that the methods required are inserted:
public void onTabItem1(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "1"); } public void onTabItem2(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "2"); } public void onTabItem3(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "3"); } public void onTabItem4(Event event) throws PageException { IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "4"); }
10. Please insert the variable needed at the top of the JSP page:
<% String tabselection1 = (String)componentRequest.getValue("tabselection1"); %>
11. Change the defaulted first tab to dynamically show the selection:
selection="<%=tabselection1%>"
12. Enter this code into the doInitialization method. This will enable the first tab to be selected when we first access this screen(the user has not had a chance to change). We could change this to 2 or 3 later.
// set the initial entry button to the first tab IPortalComponentRequest request = (IPortalComponentRequest) this.getRequest(); request.putValue("tabselection1", "1");
13. Create a par file, deploy onto your server and test. 14. Optional: Add other htmlb elements into your ‘tab screens’.
<br><br> <hbj:dropdownListBox id="myDropdownListBox1"
Unit Summary
You should now be able to: • Understand and build abstract portal components • Discuss the nature of the security zone • Discuss how a Portal application uses the security zone features • Discuss permissions and security zones • Allow end user personalization of portal applications • Write Portal Applications that are language independent and handle complex phrases in a language neutral fashion. • Build Portal applications using HTMLB controls • Use the Model-View-Controller (MVC) approach when developing your Portal Applications.
Unit 6
Portal Services and Web Services
Unit Overview
Describe Portal Services. Develop and deploy Portal Services. Access Portal Services from another Portal application. Generate Web Services proxies fro a portal services. Generate proxies for a Web Service and access them from a Portal Application.
Unit Objectives
After completing this unit, you will be able to: • • • • • • Describe what Portal Services are and situations where they are typically used Develop and Deploy your own Portal Services Access Portal Services from another Portal Application Describe the basic components of Web Services and how they are used Generate Web Service Proxies for a Portal Service Generate Proxies for a Web Service and access them from a Portal Application
Unit Contents
Lesson: Portal Services ........................................................200 Exercise 11: Custom Portal Services .................................... 211 Lesson: Web Services .........................................................222
Lesson Objectives
After completing this lesson, you will be able to: • • • Describe what Portal Services are and situations where they are typically used Develop and Deploy your own Portal Services Access Portal Services from another Portal Application
Business Example
Deploy a portal service and use it in another application.
In the non-trivial case, a service provides an interface based API and an implementation. • • • The implementatoin is non-public and will not be seen by nor interfer with using applications. The service interface relates the service API and its implementation by offering access to implementations of API interfaces through factories. The API should not rely on any other non-standard API.
A portal service can be transfered into a Web Service.
Exercise 11: Custom Portal Services
Exercise Objectives
After completing this exercise, you will be able to: • Implement your own service and access this within your Portal Application
Business Example Task:
1. Create a new portal project called 06-CustomPortalServiceXX where XX is your group number. Create a service called PercentCalc with a method getPercentage. getPercentage accepts two floating point numbers and returns a floating point result which is the precentage of the two numbers passed in. Deploy this service to the portal. Create a portal application called CustomPortalServiceTestXX to call the portal service you just deployed.
Solution 11: Custom Portal Services
Task:
1. Create a new portal project called 06-CustomPortalServiceXX where XX is your group number. Create a service called PercentCalc with a method getPercentage. getPercentage accepts two floating point numbers and returns a floating point result which is the precentage of the two numbers passed in. Deploy this service to the portal. a)
Lesson Summary
You should now be able to: • Describe what Portal Services are and situations where they are typically used • Develop and Deploy your own Portal Services • Access Portal Services from another Portal Application
Lesson Objectives
After completing this lesson, you will be able to: • • • Describe the basic components of Web Services and how they are used Generate Web Service Proxies for a Portal Service Generate Proxies for a Web Service and access them from a Portal Application
Figure 257: Web Services Support in the Portal (1)
By providing a SOAP connection to the Portal Service, external components can access to the services and applications developed with the PRT technology using the SOAP protocol. The PRT provides tools and facilities to generate Proxies to external WEB Services, so that Portal Components and Portal Services can easily access to external WEB Services to build Portal Applications.
Figure 258: Web Services Support in the Portal (2)
Inqmysoap.jar: a JAXM 1.0 Implementation (based on the Java API for XML Messaging (JAXM)) which was developed as JSR067 under the Java Community Process.
Alias: is the alias name for the service in the portalapp.xml Output: is the name of the wsdl file Location import: if you want to use multiple wsdl files to describe your wsdl file, this option will write tag import in the generated wsdl (not often used) Location URL: The end of the URL to access to the portal, at runtime sth. Is added like <http://localhost:50000/> to give the service the port addess in the wsdl file.
Generate the virtual portal service client: this will generate a proxy service use in communication between two PRT with Web Service protocol. In this case a proxy will fake a true PortalService on PRT Client side. Enable the getter/setter limitation: If disable allow you to generate in wsdl/serializer signature of complex only based on getter (no need to code setter for each attribute). This should only be used for inside/out scenario, when need to give back to soap call messaeg such complex type. Enable Security: Enable security based on ACL/Portal User Management. If set true you will need to setup for each possible user right in ACL. The user are extracted from the httprequest as in the normal portal scenario: user/password/sso ticket/https.....
Lesson Summary
You should now be able to: • Describe the basic components of Web Services and how they are used • Generate Web Service Proxies for a Portal Service • Generate Proxies for a Web Service and access them from a Portal Application
Unit Summary
You should now be able to: • Describe what Portal Services are and situations where they are typically used • Develop and Deploy your own Portal Services • Access Portal Services from another Portal Application • Describe the basic components of Web Services and how they are used • Generate Web Service Proxies for a Portal Service • Generate Proxies for a Web Service and access them from a Portal Application
Unit 7
Standard Portal Services
Unit Overview
Describe available services in the Portal Runtime. Describe key components of the User Management Engine (UME) and use the UM API to work with user, group and role objects. Describe the architecture of the Connector Framework and use the Connector gateway to connect to an ABAP system and a RDBMS.
Unit Objectives
After completing this unit, you will be able to: • • • Describe the available services in the Portal Runtime Describe the key components of the User Management Engine (UME) and use the UM API to work with user, group and roles objects Describe the architecture of the Connector Framework and use the Connector gateway to connect to an R/3 system and to RDBMS
Unit Contents
Lesson: User Management....................................................238 Exercise 12: User Management ..........................................261 Lesson: Connector Framework ...............................................266 Exercise 13: JDBC Connection...........................................289
Lesson Objectives
After completing this lesson, you will be able to: • • Describe the available services in the Portal Runtime Describe the key components of the User Management Engine (UME) and use the UM API to work with user, group and roles objects
Business Example
Build applications to access standard portal services such as User Management
Public Services of the PRT
• • • • • • • • • • • • • User Agent Service Logging Service Connector Framework JCo client service HTML Business for Java (HTMLB) User Management User Mapping Navigation System Console EPCF Toolbox System Landscape Admin Logviewer ...
Client eventing: The Client Framework enables portal components to communicate easily on the client. Several features like automatic relaxing of the JavaScript Origin Policy, Client Eventing and Client Data-Bag simplifies the integration and cooperation of different portal components from different servers. Logger: This service is used to diagnose problems and to return detailed information about the problems identified. Depending on the target user, it is possible to define simple or more complex logging. The logger provides a set of convenient methods for generating log messages.
JCo client service: This service defines all the actions needed to connect to an SAP system through RFC connections. HTML Business for Java: HTML Business for Java provides the user with an efficient set of controls, similar to JavaSwing. The controls are based on servlets and JSP pages. The developer uses bean-like components or JSP tags. Renderer classes translate the components into HTML commands. User Mapping: Map the user id, if the user has diffrent ids in diffrent systems User Management: Get user information (for example, role assignment) from portal user management Navigation: Create custom navigation iViews or custom navigation hierarchies System Console: Administration console to load PARs, monitor Cluster Landscape, and manage Portal Applications Xsltransform: Provides API to apply XLS transformation toXML document jcoclient: Manage JCO Client access by implementing pooling and session timeout/logoff detection Application Contentconverter: Generic XSL Converter providing factories to convert RSS to HTML and XML to HTML. Application Contentconversion: The Content Type Conversion Service offers API to add content converter capabilities to the response process. Admin Logviewer: search, filter, browser, download log files of the Platform. Admin Logadmin: manage logger configuration of the Platform. EPCF Toolbox: Java classes for EPCF integration Useragent: User-Agent (Browser) detection plus affiliation checker System Landscape: Get information about the system landscape iView Service: iViews/Pages/Systems semantic layer
Figure 278: Architecture Overview User Management Engine
UME is the central storage place for user and role information for all Java and ABAP applications that use UME. As such, the individual services do not have to rely on their own UM and the user is confronted with only one central user management service. Persistence Manager: Responsible for reading the data from or writing the data to the correct data source. The data source to which the persistence manager writes is transparent to the application. Specific user sets or attributes can be distributed across different repositories. Persistence Adapters Data source specific implementation for data storage and retrieval. The persistence manager consults the persistence adapters when creating, reading, writing, and searching user management data. Persistence adapters for the following types of repositories are available: Database Lightweight Directory Access Protocol (LDAP) directory SAP R/3 System 6.20 You can configure UME to use one or more of these persistence devices in parallel. Users can also be stored in several different physical LDAP directory servers, or in different branches of the same LDAP directory server.
The application programming interface (API): Layer on top of the persistence manager. In the persistence manager, you configure which data is written to or read from which data source, so that the applications using the API do not have to know any details about where user management data is stored Replication Manager The replication manager replicates UME data to external systems. User data that is written to the persistence manager is also written to the replication manager. The replication manager generates XML documents and sends them to the external systems which process them and perform the corresponding actions. For example, if you are using UME with SAP Enterprise Portal and want an SAP Customer Relationship Management (CRM) system to work with the same user base as the portal, you can configure UME to replicate all user data from the portal to the CRM system.
Figure 280: User Management Access in Portal Components
How do I determine which JAR file contains the API I want to use? -> A utility is available from the Alphaworks (IBM) website which plugs into the Eclipse IDE and provide a useful means of determining which JAR files need to be referenced. Download the free utility from the Alphaworks website http://www.alphaworks.ibm.com/aw.nsf/reqs/jarclassfinder (registration required). Unzip it into your NWDS eclipse\plugins directory. Restart NWDS.
The examples illustrate various objects returned: USER.CORP_LDAP.uid=i802895,ou=people,dc=sap,dc=corp (User from CORP_LDAP server) GRUP.CORP_LDAP_2.cn=developers,ou=groups,dc=sap,dc=corp (Group from a different LDAP server) GRUP.SUPER_GROUPS_DATASOURCE.EVERYONE (Special group "Everyone") ROLE.PCD_ROLE_PERSISTENCE.VvlvkEGjiW9zPFaxR/4pd2/bX5Q= (Role "super_admin") USER.PRIVATE_DATASOURCE.un:admin (User from database PRIVATE_DATASOURCE)
The IUser object contains most the information that you probably need regarding a user. Information about the name of the user, their unique ID, LDAP attributes, display name, role membership, etc are available from the IUser object. If you
have a user object (either from the authenticated user or any other user), you can use that object to query the user’s profile using the respective get() - methods. It is also possible to edit the corresponding profile data with the interface IUserMaint.
Figure 288: IUser Methods
IUser is read-only. In order to modify a user, use IUserMaint
Figure 290: Obtaining Information about another User
This example illustrates how to obtain information about a user using the Logon ID as a key. The exception checks to see if a nested exception such as NoSuchUserAccountException occurred
Figure 291: Obtaining Information about another User (2)
This example illustrates how to obtain information about a user using the Unique ID as a key. The exception checks to see if a nested exception such as NoSuchUserException occurred
Different applications or iViews which want to store application-specific data for the same principal object might cause inconsistencies by overwriting or deleting the data written by another application or iView. To prevent inconsistencies of this type, UME configuration files support namespaces, where each application can store its application-specific data in a separate namespace. In this way, custom attributes that have the same name are stored in a different namespace and do not clash with each other. Example: A user, USER.CORP_LDAP.uid=testuser,ou=research,o=sap, has three email addresses, one in it’s master data (in the UME default namespace com.sap.security.core.usermanagement), one for application1 and another for application2. Additional Custom Attributes can be added by editing the dataSourceConfiguration_xxx file. A mapping (logical to physical) needs to be performed for each attribute Use getAttribute() to retrieve the value of the required custom LDAP attribute
Figure 294: Attribute Mapping Configuration
In this example the LOGICAL attribute "lastname" is mapped to the PHYSICAL attribute "sn" The attribute mappings are defined in the dataSourceConfiguration_xxx.xml file for the appropriate LDAP vendor. See the How-To Guide
The namespace corresponds to the namespace defined in the XML configuration file. The name of the default (SAP standard) namespace is IPrincipal.DEFAULT_NAMESPACE
Users can be created with the UserFactory newUser() method. IUserMaint represents a modifiable user object. You must issue a commit() in order to actually create the user. An associated account needs to be created for the User with newUserAccount() using the UniqueID of the new User. Take care to delete the user if an error occurs (catch the appropriate exception and handle it).
Exercise 12: User Management
Exercise Objectives
After completing this exercise, you will be able to: • Access your account’s details through the IPortalComponentRequest object • Access further information like role assignments through the UMFactory
Business Example Task:
User Management Service Develop an iView that displays personal attributes belonging to your user account, i.e. the email address, first and last name. In addition find out what roles are assigned to your user account. 1. 2. 3. 4. Open the in Exercise 3 generated project 03-FirstPortalProject. Create a new AbstractPortalComponent named com.sap.training.portal.UserInfoComponent Add a sharing reference to the usermanagement service to the component-config section in the portalapp.xml Get access to your user account attributes and print them. Use the IPortalComponentRequest object to perform this task. See course material for details. Find and add the necessary imports by the “Source → Organize Imports” wizard. 5. 6. Iterate through all roles available in the portal. Print roles assigned to current user. Use the UMFactory resp. the IRoleFactory to perform this task. Deploy and test your component.
Solution 12: User Management
Task:
User Management Service Develop an iView that displays personal attributes belonging to your user account, i.e. the email address, first and last name. In addition find out what roles are assigned to your user account. 1. 2. Open the in Exercise 3 generated project 03-FirstPortalProject. a) Open the in Exercise 3 generated project FirstPortalProject Create a new AbstractPortalComponent named com.sap.training.portal.UserInfoComponent a) Click on the icon of the Portal Application Object wizard. Select Portal Component → Abstract Portal Component as template. Enter UserInfoComponent into the name field. Enter com.sap.training.portal into the package name field. Click finish. 3. Add a sharing reference to the usermanagement service to the component-config section in the portalapp.xml a) Add a sharing reference to the new component. Double click on the portalapp.xml in FirstPortalProject → dist → PORTAL-INF → portalapp.xml. Click on More in the application section and then on Add... → Add Standard. Choose PrivateSharingReference and enter usermanagement into the value field. Finish the wizard. (This reference is only necessary for step 5)
4.
Get access to your user account attributes and print them. Use the IPortalComponentRequest object to perform this task. See course material for details.
Find and add the necessary imports by the “Source → Organize Imports” wizard. a) Add the coding for your details to the doContent() method. This could look as follows:
IUser user = request.getUser(); String userName = user.getDisplayName(); String depName = user.getDepartment(); String phone = user.getTelephone(); String email = user.getEmail();
Iterate through all roles available in the portal. Print roles assigned to current user. Use the UMFactory resp. the IRoleFactory to perform this task. a) In order to list all roles you have to get a search filter from the roleFactory and search using the wildcard *. The coding may look like this:
response.write("<br><B>Your roles:</B><BR>"); IRoleFactory roleFactory = UMFactory.getRoleFactory(); IRoleSearchFilter rFilter; try { rFilter = roleFactory.getRoleSearchFilter(); rFilter.setDescription("*", ISearchAttribute.LIKE_OPERATOR, false); ISearchResult result; result = roleFactory.searchRoles(rFilter); if (result.getState() == ISearchResult.SEARCH_RESULT_OK) { while (result.hasNext()) { String uniqId = (String) result.next(); if (user.isMemberOfRole(uniqId, true)) { IRole aRole = roleFactory.getRole(uniqId); response.write(aRole.getDescription() + "<BR>"); } } } } catch (UMException e) { // TODO Auto-generated catch block e.printStackTrace(); }
6.
Deploy and test your component. a) Deploy and test your component.
Lesson Summary
You should now be able to: • Describe the available services in the Portal Runtime • Describe the key components of the User Management Engine (UME) and use the UM API to work with user, group and roles objects
Lesson Objectives
After completing this lesson, you will be able to: • Describe the architecture of the Connector Framework and use the Connector gateway to connect to an R/3 system and to RDBMS
Business Example
Build reports from RFC, BAPI or SQL Queries.
Connector Framework
Figure 305: JCA (J2EE Connector Architecture)
JCA/J2EE Connector Architecture is not API: it's the name of the architecture, as the name implies. The goal of JCA is to provide the pluggable connector architecture between J2EE Application Servers and EIS/Enterprise Information Systems (ex. ERP, RDBMS). JCA 1.0 defines set of system level contracts between J2EE Application Servers and EIS:
Connection management The J2EE Connector Architecture provides support for efficient connection management by relying on application connection pooling. Connections with EIS data and services are established, configured, cached, and reused automatically by application servers that are compliant with J2EE 1.3 technology. Rather than create and destroy EIS connections on an as-needed basis -- an inefficient approach at best -- J2EE Connector Architecture calls on Java technology application servers to monitor and manage them intelligently, in an effort to maximize runtime performance and scalability on the fly. The Java application server manages the EIS connection pool automatically and transparently, so no additional programming is required by either EIS or Java technology developers. Transaction management Transactional integrity is another thorny EIS integration issue elegantly solved by the J2EE Connector Architecture. The J2EE Connector Architecture prescribes "transaction management contracts" between application servers and EIS connectors. Third-party EIS vendors simply encapsulate transaction support within EIS connectors that are compliant with J2EE 1.3 technology to make them available to Java technology developers. For EIS vendors, this can range from no transaction support at all (for legacy systems), to support for one or all three types of enterprise transactions: local or XA (with either single- or two- phase commit). Conversely, Java technology application server vendors have no say in the matter of transaction support. The J2EE Connector Architecture specification requires them to deliver products to the market that uphold all EIS transaction types. Security The J2EE Connector Architecture defines portable "security contracts" that don't rely on platform- or implementation- specific technologies. The scope of these generic security contracts depends upon the particular back-end EIS system. For example, it could require password user-authentication, or an end-to-end environment, in addition to specific security requirements of the EIS. As with connection pooling and transactional support, it's up to the individual EIS connector vendors to roll in full support for their platform's security requirements. A J2EE Application Server vendor is responsible for shipping a set of Java API called "CCI/Common Client Interface". On the other hand, An EIS vendor is responsible for shipping "Resource Adapter", which is wrapped by CCI API. Resource Adapter may contain platform specific native libraries. You can think that the relationship of CCI and Resource Adapter is similar with the one we have in JDBC API and vendor specific database drivers. In theory, by using the JCA, EIS vendors no longer need to customize their product for each J2EE Application Server.
SAP has partnered with I-Way software to provide a number of RAs (they have over 250) Implements both CCI and uses the EIS's proprietary APIs for integration Shields the developer from complexities of the EIS APIs
Using the SAP Connector
Figure 306: Connector Framework (for SAP Connector)
Figure 309: How ABAP implements interface with RFM?
"Function Modules" are the routines of ABAP program.Theyhave well-defined interfaces called "Import parameters" and "Export parameters". ABAP has 3 data types - Scalar, Structure and Table values. SAP developed it's proprietary communication protocol called "RFC/Remote Function Call", which is originally based on the standard RPC/Remote Procedure Call. We call a RFC-enabled Function Module a "RFM/Remote Function Module". CCI/Common Client Interface API is a Java wrapping layer ofRFM.
Figure 310: Connector Framework (for SAP Connector)
Use the Connector Gateway Service to obtain connections to back end systems Use the Connection Properties object to facilitate SSO Create an Executable Interaction interact to describe the interaction with the back end system (Function Module, BAPI call, etc) Create an Interaction Spec (IInteractionSpec) to specify function module to call Create an input record (MappedRecord) describing input parameters Execute the interaction Spec with the input record
If you access ABAP data via JCA, the Java data type you need is only "Mapped Record type. MappedRecord is a collection of Record instances ordered by key-value pairs. We'll put respective scalar values, structure values, and table values on this MappedRecord instance. MappedRecord belongs to javax.resource.cci.* package.
Use the Connector Gateway Service to obtain connections to back end systems Use the Connection Properties object to facilitate SSO Obtain a connection to the back end system Create a Query object to describe the query you wish to execute on the back end system Execute the query and check the return status Obtain the output - usually returns an IRecordset object Iterate through the record set and deal with the data
Lesson Summary
You should now be able to: • Describe the architecture of the Connector Framework and use the Connector gateway to connect to an R/3 system and to RDBMS
Unit Summary
You should now be able to: • Describe the available services in the Portal Runtime • Describe the key components of the User Management Engine (UME) and use the UM API to work with user, group and roles objects • Describe the architecture of the Connector Framework and use the Connector gateway to connect to an R/3 system and to RDBMS
Unit 8
Enterprise Portal Client Framework
Unit Overview
Understand the architecture and features of EPCF. Use the Client Framework to raise and subscribe to events. Understand the Client Data Bag and pass data to receiving components using the Client Data Bag. Understand the different Navigation features and use the Navigation API. Understand the Work Protect feature.
Unit Objectives
After completing this unit, you will be able to: • • • • • Understand the architecture and features of the EPCF Use the Client Framework to raise and subscribe to events Understand the Client Data Bag and pass data to receiving components using the Client Data Bag Understand the different Navigation features and use the Navigation API Understand the WorkProtect feature and implement Portal Applications that handle unsaved data
Lesson Objectives
After completing this lesson, you will be able to: • • • • • Understand the architecture and features of the EPCF Use the Client Framework to raise and subscribe to events Understand the Client Data Bag and pass data to receiving components using the Client Data Bag Understand the different Navigation features and use the Navigation API Understand the WorkProtect feature and implement Portal Applications that handle unsaved data
Business Example
Enterprise Portal Client Framework
• • • Eventing Send and receive events without server involvement. Data Bag Store and load data on the client side. Navigation with Navigation Target Navigate to any portal page or iView inside a role through by URL Cross-navigate: use links within any portal application and the navigation nodes are automatically updated. WorkProtect Handle unsaved data in stateful applications.
getInstanceID: This method returns an unique EPCF instance as type String. The method is used by the EPCF core to distinguish the pages after a page refresh. getUniqueWindowId(): You can use this method to append the returned iFrame identifier string to the name you use to define a client data bag. This creates a client data bag that can only be accessed by a specific IFrame.
Figure 361: Client Eventing API
Namespaces: Compliant to W3C specification (RFC2141, RFC1630) reserved Namespaces SAP Core Development: urn:com.sap.* , urn:com.sapportals.* , urn:com.sapportals.portal.*
Provides the infrastructure for handling unsaved data in stateful applications. Preconditions for a portal application that wants to take advantage of the WorkProtect feature must maintain a special status: the “Dirty” flag EPCM.setDirty(flag) EPCM.getDirty() The Client Framework monitors the current “Dirty” state of all applications on the portal page. If one or more apps are marked as “Dirty” - navigation target is executed in a new window Navigation performed with browser links (Back/Forward, entering URL, etc.) always destroy the unsaved data. Navigation performed with browser lnhiks (Back/Forward/URL) always destroys the unsaved data because such links cannot be adapted. In a typical scenario, the application sets the “Dirty” flag when the user enters a new value in the entry field and resets the “Dirty”“ flag when The user saves it, i.e. clicks on the save/submit button in the portal application. Back, Forward, URL in the location bar always destroy the unsaved data. Links that use the doNavigate method are workprotect save. Links that open in a new window are save, but links with a target will lose the unsaved data.
Display the properties of that iView or Page Select and copy the PCD Location property value Replace the pcd: PREFIX with the PREFIX ROLES://
Figure 369: Start with NavigationTarget / Navigation by URL
Figure 370: Absolute Navigation
A navigation is considered to be absolte of the full path – starting from the navigation hierarchy root down to the navigation target, is known to the invoker of the navigation.
For navigation through the portal, when the absolute location of the navigation target is known. The function must get the navigation target parameter. All the rest of the parameters are optional.
Possibility to navigate to a location, relative to current location. For Example: < A HREF="myLink2" onclick="return EPCM.doRelativeNavigate('ROLES://portal_content/WebDynproTests/WebDynproRolle/Level1/Level2/Level3/Level4', 2, '{WebDynproPage}')">This is a portal link using doRelativeNavigate<A> PCDUrl of the current node folder Levels up Name of the Page to which to navigate.
Exercise 14: Eventing
Exercise Objectives
After completing this exercise, you will be able to: • Write portal applications which make use of the EPCF to subscribe to and raise events
Business Example Task:
To demonstrate Client Side Eventing we will import the par file 08_ClientEventing_Exercise.par. This consists of a simple JSP application compromising two JSP files: One to raise an event and one to subscribe to this specific namespace. Modify the displayInfo2.jsp component by following the TODO items in the code to include the following things: 1.
A client row selection handler has been registered with the Tableview. The code below is used to cause the Javascript function ‘radioSelect()’ to be called when the user clicks on a user:
srTV.setOnClientRowSelection( "JavaScript:radioSelect(htmlbevent.obj.getClickedRowKey());");
2.
Locate the function radioSelect() in the JSP file and register a client side event handler for the row selection event. The event handler should raise the following event: namespace: com.customer.training.UMEExample event: userSelected data: userID of selected user.
3.
Modify the UserInfo component (actually – userDetails.jsp) to register for an event handler that listens for the event raised by the search component. The event handler should retrieve the data from the event and then repost back to itself with the user ID as the parameter. The data from the event can be obtained by using the property event.dataObject. The value should be stored in the “uid” form element (e.g. document.forms[0].uid.value) After storing the value from the event, repost (submit) the form back to the server (e.g. documents.forms[0].submit()) Please follow the detail solutions.
Solution 14: Eventing
Task:
To demonstrate Client Side Eventing we will import the par file 08_ClientEventing_Exercise.par. This consists of a simple JSP application compromising two JSP files: One to raise an event and one to subscribe to this specific namespace. Modify the displayInfo2.jsp component by following the TODO items in the code to include the following things: 1. 1. A client row selection handler has been registered with the Tableview. The code below is used to cause the Javascript function ‘radioSelect()’ to be called when the user clicks on a user:
srTV.setOnClientRowSelection( "JavaScript:radioSelect(htmlbevent.obj.getClickedRowKey());");
2.
Locate the function radioSelect() in the JSP file and register a client side event handler for the row selection event. The event handler should raise the following event: namespace: com.customer.training.UMEExample event: userSelected data: userID of selected user.
3.
Modify the UserInfo component (actually – userDetails.jsp) to register for an event handler that listens for the event raised by the search component. The event handler should retrieve the data from the event and then repost back to itself with the user ID as the parameter. The data from the event can be obtained by using the property event.dataObject. The value should be stored in the “uid” form element (e.g. document.forms[0].uid.value) After storing the value from the event, repost (submit) the form back to the server (e.g. documents.forms[0].submit()) Please follow the detail solutions.
Lesson Summary
You should now be able to: • Understand the architecture and features of the EPCF • Use the Client Framework to raise and subscribe to events • Understand the Client Data Bag and pass data to receiving components using the Client Data Bag • Understand the different Navigation features and use the Navigation API • Understand the WorkProtect feature and implement Portal Applications that handle unsaved data
Unit Summary
You should now be able to: • Understand the architecture and features of the EPCF • Use the Client Framework to raise and subscribe to events • Understand the Client Data Bag and pass data to receiving components using the Client Data Bag • Understand the different Navigation features and use the Navigation API • Understand the WorkProtect feature and implement Portal Applications that handle unsaved data
Unit 9
Introduction to Web Dynpro
Unit Overview Unit Objectives
After completing this unit, you will be able to: • • • • • Understand the basic concepts behind Web Dynpro Understand the basic architecture of a Web Dynpro Component Understand the structure of the context Navigate between views Understand the WebDynpro Architecture
Unit Contents
Lesson: Introduction to Web Dynpro .........................................326 Lesson: Web Dynpro Context and Navigation ..............................332 Lesson: Web Dynpro Architecture ............................................338 Exercise 15: Creating a Java Web Dynpro Component...............343
Lesson: Introduction to Web Dynpro
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • • Understand the basic concepts behind Web Dynpro Understand the basic architecture of a Web Dynpro Component
Business Example
What is Web Dynpro? • A Programming Model for User Interfaces – • Defines a standard structure for user interface applications – Derived from the MVC (“model-view-controller”) design pattern A Set of Tools for User Interface Design – Focus on graphical modelling – Code is generated from meta-model declarations – Integrated in SAP NetWeaver Developer Studio and the ABAP Workbench A Runtime Environment for Applications – Framework running on SAP Web AS server offers common services A Technology for Software Modularization – Components help structure applications and support pattern-based UIs
• •
What is Web Dynpro? From a technological point of view, SAPs Web Dynpro for Java and ABAP is a revolutionary step in the development of web-based user interfaces. It is completely unlike any design paradigm ever used by SAP before and represents a quantum leap in the development of web-based, ERP applications. What is the Design Philosophy Behind Web Dynpro? Web Dynpro applications are built using declarative programming techniques based on the Model View Controller (MVC) design paradigm. That is, you specify which user interface elements you wish to have on the client, and where those elements will get their data from. All the code to create the user interface is then
generated automatically within a standard runtime framework. This relieves you from the repetitive coding tasks involved in writing HTML and then making it interactive with JavaScript.
Figure 388: Web Dynpro Main Benefits
Web Dynpro Main Benefits Web Dynpros main goal is to enable application developers to create powerful Web applications with a minimum of effort using descriptive tools in a structured design process. One guiding principle in the Web Dynpro philosophy is: the fewer lines of hand-written code there are in the UI, the better. Web Dynpro pursues this goal in two ways. Web Dynpro uses a declarative, language-neutral metamodel for defining a user interface. From this abstract definition, the development environment generates the required Java/ABAP code. Hand-written code still has its place, but is confined to that required to manipulate the business data, not the user interface. Web Dynpro provides technical features such as support for internationalization, flicker-free interaction and a clean separation of the business logic and the user interface. This separation is achieved through a modified implementation of the Model-View-Controller (MVC) design paradigm. MVC was invented by Trygve Reenskaug in the late seventies and first implemented in the Smalltalk-80 language. Since the repetitive tasks of UI coding have been all but eliminated, the developer can focus their attention on the flow of business data through the application.
Web Dynpro applications can run on a range of devices and on various types of network an important feature for collaboration scenarios.
Figure 389: Meta-model Declarations vs. Custom Coding
Metamodel Concept and Declarative Programming A Web Dynpro application is developed using a declarative programming approach. Within the SAP NetWeaver Developers Studio or the ABAP Workbench there are special tools that allow you to build and abstract representation of your
application in the form of a Web Dynpro metamodel. The necessary source code is then generated automatically and conforms to a standard architecture known as the Web Dynpro Framework (WDF). • The WDF allows each controller within a component to have a set of standard hook methods. It is within these hook methods that any required custom coding can be placed. In addition to the events provided by the WDF, you can also define your own events for a Web Dynpro application. All Web Dynpro applications are constructed from the same basic units. However, through the use of custom coding in the standard hook methods, the standard framework can be extended to supply any required business functionality. Not all implementation decisions need to be made at design time. It is perfectly possible to implement a Web Dynpro application in which the appearance of the user interface is decided at runtime. This allows a highly flexible application to be written without requiring the need to directly write any HTML or JavaScript.
A Web Dynpro Model Object can be supplied with information from the following types of backend system: • • • RFC Modules such as BAPIs in an SAP ABAP backend system. This interface is provided by the Adaptive RFC Layer (aRFC). Enterprise JavaBeans (EJBs) which encapsulate application logic. Web Services
Lesson Summary
You should now be able to: • Understand the basic concepts behind Web Dynpro • Understand the basic architecture of a Web Dynpro Component
Context Mapping Context mapping allows a context node in one controller to be supplied automatically with data from a corresponding context node in another controller. This is the primary mechanism for sharing data between controllers. Mapping Terminology When two controllers within the same component share data through a mapping relationship, this is known as Internal Mapping. The context node that acts as the data source is known as the Mapping Origin Node, and the context node that is mapped is known as the Mapped Node. Prerequisites In order for a mapping relationship to be established, the following steps must first be performed: • • • A node must exist in the context of the controller acting as the mapping origin. This node need not have any declared child nodes or attributes. The mapping origin controller must be a custom controller. The controller containing the mapped node must declare the use of the mapping origin controller as a required controller.
Figure 394: Putting data on the screen: Data Binding
Data Binding Data binding is the means by which data is automatically transported from a view controllers context to a UI element in its layout. You may not bind UI elements to context nodes or attributes that occur in some other controller. UI elements are private to the view controller within which they are declared. The data binding process decouples the UI element object from the application code within the view controller. Therefore, in order to manipulate UI element properties, the application code in the view controller needs only manipulate the values of context nodes and attributes to which the UI elements are bound. The Web Dynpro Framework then manages the following two tasks: • • The transport of data from the context to the UI element during the screen rendering process. Repopulating the context from the UI element after data is entered by the user.
Navigation with Web Dynpro
Figure 395: Navigation between views
Calling an outbound plug method causes a navigation event to be raised. Navigation events are special, asynchronous events that are placed into a navigation queue. Only when all the outbound plugs have been called by all the views in the current view assembly, will the Web Dynpro Framework enter its navigation processing phase. Outbound plugs should be named according to the action that caused navigation away from the current view. Inbound Plugs Inbound plugs are special event handler methods that subscribe to navigation events raised when outbound plugs are fired. Inbound plug methods are called only when the navigation queue is processed. This will only take place once all the views in the current view assembly have fired their outbound plugs and no validation errors have occurred that would cause navigation to be cancelled. Inbound plugs should be named according to the reason for which the view being displayed. Links Outbound and inbound plugs are joined together using navigation links.
Figure 396: Navigation between views - Java
The Navigation Modeller gives a graphical representation of the navigation links that exist between the different views in a window. The Web Dynpro Explorer shows the same information as a hierarchy. Links: Select the Navigation Link tool from the graphical editor, then draw a line from the outbound plug to the inbound plug. This causes the event handler method represented by the inbound plug to subscribe to the navigation event raised by the outbound plug.
Figure 397: Windows, View Sets and View Areas
Windows, View Sets and View Areas When create a Window, you define three things: • • • All the possible views that could exist in the components visual interface. The layout and position of those views within view sets and view areas The navigation links that exist between different views
You can embed either a single view, or one or more view sets into a window. Each view set in turn is divided into view areas, each of which can have one or more views or view sets embedded within it. A view area can only display one view at a time. Navigation links must be defined between views in order for the contents of a view area to be replaced.
View areas can be blanked out by creating an empty view whose inbound plug responds to an appropriate navigation event.
Figure 398: View Assembly
View Assembly Special asynchronous navigation events are the triggers that cause a view area to contain a particular view. For a given window definition in which multiple views are embedded into view areas, there could be many permutations of views visible. The permutation that is visible depends on which navigation links the user follows. The subset of views visible at anyone time is known as a View Assembly.
Figure 399: View Assembly
View Assembly Special asynchronous navigation events are the triggers that cause a view area to contain a particular view. For a given window definition in which multiple views are embedded into view areas, there could be many permutations of views visible. The permutation that is visible depends on which navigation links the user follows. The subset of views visible at anyone time is known as a View Assembly.
Lesson Objectives
After completing this lesson, you will be able to: • Understand the WebDynpro Architecture
Business Example
Figure 400: Web Dynpro Component Architecture I
The architecture of a Web Dynpro Component can be divided into two parts externally and internally visibility: • The horizontal dotted line separates the entities that are visible from outside the component, from those that are only visible from within the component.
A view consists of a view layout and the corresponding view controller. A view can contain navigation plugs, methods and a context. A window embeds one or more views and has a corresponding window controller. A window can contain navigation plugs, methods and a context.
The component controller acts as a component wide controller. Notice that Web Dynpro Models stand outside the Component. Models are reusable across multiple components.
Custom controller can act as a local controller for some views. This allows to reduce the content of the component controller by populating sub functions.
Figure 403: Web Dynpro Component Architecture IV
A Web Dynpro Component can declare the use of another Web Dynpro Component. A specific component usage is then created and the parent component accesses the functionality of the child component via its component interface controller. The only parts of a Web Dynpro Component that are visible to the outside world, are the interface controller and the interface view(s). • • • All Web Dynpro components have only one Interface Controller. There is a one to one relationship between a Window and an Interface View. If the component has no views, then it will have no Windows, which in turn, means that it will not implement an interface view. Such components have no visual interface and are known as faceless components.
Web Dynpro Application A Web Dynpro Application is an entry point into a Web Dynpro Component and is the only Web Dynpro entity that can be addressed via a URL. There is often (but not always) a one to one relationship between an interface view and an application. In the same way that the functionality in an ABAP module pool can be accessed by defining multiple transaction codes, so the functionality of a single Web Dynpro component can be accessed by defining multiple applications. Application definition In order to define a Web Dynpro application, you must specify • • • The component to be invoked. This component is then known as the root component, Which interface view of the root component will be used as the initial view assembly, Which inbound plug will act as the entry point for the nominated interface view (this inbound plug must have the Startup check box selected)
Exercise 15: Creating a Java Web Dynpro Component
Exercise Objectives
After completing this exercise, you will be able to: • Create a simple Java Web Dynpro • Set the J2EE engine for correct deployment • Create a Java Web Dynpro Application.
Business Example Task:
1. Development Objectives This exercise has the following objectives: - Introduce the student to the Java Web Dynpro development environment. - Use the Web Dynpro tools and wizards to create a Java Based Web Dynpro. - Create an application to deploy and test the component. A simple Web Dynpro “Hello World” component will be created to familiarise the student with a component, a window, a view and an application. The corresponding .ear file is deployed to the J2EE server and not just the Portal server as with the Portal environment. 2. Result The result of this exercise will be display of a simple text within a browser window.
Template Solution: WD01_Basics_00 3. Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. 4. Overview: Developing 1. 2. 3. Set the J2EE settings by following the menu path: Windows → Preferences → SAP J2EE Engine Open the Net Weaver Developers Studio. Open the Web Dynpro Perspective much the same as the Enterprise Portal was opened earlier. Create a new Web Dynpro project by following the menu path. File → Project → Web Dynpro. Give the project a name: WD01_Basics_XX where XX is your given student number. Create a Web Dynpro Component by expanding the node WD01_Basics_XX. Then expand node Web Dynpro before right clicking the Web Dynpro Component to create. Create the component with the name Exc_Intro. Assign the package com.sap.training, Exc_intro_Window as the window name, and StartView as the View name. Save all Metadata. Open the Web Dynpro Component Structure and double click the view StartView by following the path Web Dynpro → Components → Exc_into → Views → StartView. Continued on next page
Navigate to the ‘Outline’ View. This is normally in the bottom left corner of the Web Dynpro editor screen. Beneath the RootUIElementContainer the DefaultTextView must be selected. Select the Layout tab (normally middle right view) then the Properties tab (normally lower right tab). Change the design to header1 and the text to ‘This is my first WD’. Navigate to Web Dynpro → Applications. Right click to create an application with the name WD01_basics_XX. Save all metadata.
9.
10. Right click the new application and select ‘Deploy New Archive and Run’. 11. Check the result from the Browser.
Solution 15: Creating a Java Web Dynpro Component
Task:
1. Development Objectives This exercise has the following objectives: - Introduce the student to the Java Web Dynpro development environment. - Use the Web Dynpro tools and wizards to create a Java Based Web Dynpro. - Create an application to deploy and test the component. A simple Web Dynpro “Hello World” component will be created to familiarise the student with a component, a window, a view and an application. The corresponding .ear file is deployed to the J2EE server and not just the Portal server as with the Portal environment. 2. Result The result of this exercise will be display of a simple text within a browser window.
Figure 406: WebDynproArchitecture Screenshot 1
Template Solution: WD01_Basics_00 3. Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. Continued on next page
4. Overview: Developing 1. Set the J2EE settings by following the menu path: Windows → Preferences → SAP J2EE Engine a)
Figure 407: WebDynproArchitecture Screenshot 2
Change your J2EE settings if you have to show your allocated server. Windows → Preferences → SAP J2EE Engine e.g.twdf0265.wdf.sap.corp Message Server Port e.g. 3601 or 3622 depending on the instance number 2. Open the Net Weaver Developers Studio. Open the Web Dynpro Perspective much the same as the Enterprise Portal was opened earlier. a) Open NWDS.
Create a new Web Dynpro project by following the menu path. File → Project → Web Dynpro. Give the project a name: WD01_Basics_XX where XX is your given student number. a)
Create a Web Dynpro Component by expanding the node WD01_Basics_XX. Then expand node Web Dynpro before right clicking the Web Dynpro Component to create. a)
Figure 414: WebDynproArchitecture Screenshot 9
Create a Web Dynpro Component. Expand node WD01_Basics_XX. Expand node Web Dynpro. Right click Web Dynpro Component to create.
Create the component with the name Exc_Intro. Assign the package com.sap.training, Exc_intro_Window as the window name, and StartView as the View name. a)
Figure 415: WebDynproArchitecture Screenshot 10
Component name Exc_Intro. Package com.sap.training. Exc_intro_Window as the window name. View name: StartView Finish.
Open the Web Dynpro Component Structure and double click the view StartView by following the path Web Dynpro → Components → Exc_into → Views → StartView. a)
Figure 417: WebDynproArchitecture Screenshot 12
Open the Web Dynpro → Components → Exc_intro → Views → StartView. Double click this StartView.
Navigate to the ‘Outline’ View. This is normally in the bottom left corner of the Web Dynpro editor screen. Beneath the RootUIElementContainer the DefaultTextView must be selected. Select the Layout tab (normally middle right view) then the Properties tab (normally lower right tab). Change the design to header1 and the text to ‘This is my first WD’. a)
Figure 418: WebDynproArchitecture Screenshot 13
Go to the View ‘Outline’. Ensure that DefaultTextView is selected. Ensure Layout tab(middle right view). Select Properties tab(bottom right view). Change design to header1. Change text to ‘This is my first WD’. 9. Navigate to Web Dynpro → Applications. Right click to create an application with the name WD01_basics_XX. Save all metadata. a)
Unit Summary
You should now be able to: • Understand the basic concepts behind Web Dynpro • Understand the basic architecture of a Web Dynpro Component • Understand the structure of the context • Navigate between views • Understand the WebDynpro Architecture
Unit 10
Web Dynpro Controllers
Unit Overview Unit Objectives
After completing this unit, you will be able to: • • • • • • • • Understand the MVC Model Understand the different controllers used with Web Dynpro. Understand the different kinds of Web Dynpro controller and what they are used for Perform navigation between views Start a Web Dynpro components with an application Understand the different kinds of Web Dynpro controller and what they are used for Perform navigation between views Start a Web Dynpro components with an application
Unit Contents
Lesson: Model, View Controller ...............................................362 Exercise 16: Navigating between Views.................................375 Lesson: Web Dynpro Controllers .............................................398 Exercise 17: Navigating between Views.................................409
Lesson Objectives
After completing this lesson, you will be able to: • • • • • Understand the MVC Model Understand the different controllers used with Web Dynpro. Understand the different kinds of Web Dynpro controller and what they are used for Perform navigation between views Start a Web Dynpro components with an application
SAPs Web Dynpro is built on the foundation of the Model-View-Controller (MVC) design paradigm originally invented by the Norwegian software designer Trygve Reenskaug (pronounced TRIG-vuh RAINS-cow) whilst working at Xerox PARC in the late seventies. The first implementation of this design paradigm was with the release of the Smalltalk-80 programming language. MVC was a revolutionary design paradigm because it was the first to describe software components in terms of: • • The functional responsibilities each should fulfil. The message protocols to which each component should respond.
SAP has modified and extended the original MVC specification in order to create the Web Dynpro toolset.
Figure 423: Web Dynpro Component Architecture
Web Dynpros use of the MVC design paradigm SAP has made several important changes to the standard MVC design paradigm: • • • Standard MVC allows a model to directly notify a view that it has changed. This has not been implemented in Web Dynpro. Standard MVC allows for nested view controllers. This is not permitted in Web Dynpro. SAP has extended the design concept by adding an aggregation unit known as a component. The component is both the unit of application development and application reuse.
Common features for all controllers: Required Controllers In order for information to be shared between different controllers, one controller must declare the use of another controller. The most frequent requirement for this kind of data sharing is when you wish the create a mapped context node. This is where a context node in one controller references the data in the context node of another controller. General points on controller usage A view controller can declare the use of a custom controller and a custom controller can declare the use of another custom controller. You may not specify the name of a view controller as a required controller as this would violate good MVC design principles. A view controller should be written such that it is responsible for nothing more than the display of data and user interaction. A view controller is not responsible for generating the data it displays: that is the role of a custom controller. Accessing business logic Business logic (Models) like function modules, BAPIs or calling methods in helper classes can be accessed. Common features for all controllers: Component Usage
The Web Dynpro component is the unit of application reuse. Therefore, if you want to make use of the functionality within another component, you can declare the use of that component. Lifespan The lifespan of a component usage instance cannot exceed the lifespan of the parent component. Three types of controller • Custom / Component controller Each Web Dynpro component has at least one global controller – the component controller (default) – Custom controllers are a kind of additional global controllers to capsulate sub function from the component controller – typically to structure bigger components – They do not have a visual interface View controller Each view has exactly one view controller, which processes the actions performed by the user in the view Window controller Only WD-ABAP – Each window has exactly one window controller. It behaves like a view controller (plugs) and is usable from other controllers (like a custom / component controller) – –
•
•
Web Dynpro controller principles Two types of controller exist within a Web Dynpro component: custom/component and view/window. • • • • • • Custom/component controllers have no visual interface, whereas view controllers do. At runtime, all controller instances are singletons with respect to their parent component. All controllers are independent programs yet none function in isolation from the other controllers in the component. All controllers store their runtime data in a hierarchical data storage area known as the Context. Unless an explicit controller usage is declared, all the data in a controllers context is private. A Custom/component controller may share the data in its context, but a view controller may not.
Figure 425: Where are the Component / Custom Controller?
Custom controllers These are the internal building blocks of a Web Dynpro component and have no user interface. They are only to be used when some unit of functionality is required by several other controllers. Do not create a custom controller simply because you can! Only use one where its presence will simplify or optimize the components architecture. Component Controller The component controller is a special custom controller that is automatically created when a component is created. The lifespan of a component is defined by, and equal to, the lifespan of the component controller. Lifespan All custom controller instances exist for as long as their parent component exists and are instantiated automatically by the Web Dynpro framework. After the component controller has been instantiated, the order in which any subsequent custom controllers are instantiated is undefined. An Interface controller exists for as long as the component usage instance exists.
Web Dynpro Custom Controllers Custom controllers are the active parts of a Web Dynpro component that do not need any direct interaction with the user. Such controllers therefore have no visual interface. When a Web Dynpro component is created, a special custom controller is created called the Component controller. It is this controller that drives the functionality of the entire component. All custom controllers are instantiated as singletons with respect to their parent component. Custom controllers are instantiated automatically by the Web Dynpro Framework and the instantiation order is undefined! Therefore, the coding in a custom controller should make no assumptions about the existence of any other custom controller. Controller Events Using your design time declarations, the Web Dynpro Framework will automatically manage the definition, triggering and handler subscription to such events for you. You also have the additional option of dynamic event subscription at runtime. A typical use of such events is the invocation of processing in a view controller after processing in the component controller has been completed. This can be achieved when a method in the view controller subscribes to an event raised by the component controller.
Important: If two or more methods subscribe to the same event, then the order in which they will be executed is undefined. Events can only be defined in Component/Custom controllers.
Figure 427: Where are the View Controllers?
View controllers A view controller is visual building block of a WD component and is designed to handle all aspects of data display and user interaction. Lifespan A view controllers lifespan parameter can have the values When Visible or Framework Controlled. A view instance will be created either because it is the default view in a view area; or when the first navigation request to that view is encountered. There are three situations is which the view instance can be deleted. • If When Visible is selected, then the view will be deleted when a navigation event replaces the current view area with some other view, and the view is no longer part of the current view assembly. If Framework Controlled is selected, then the view will be deleted when there is no further use for the view. This will never occur whilst the view is part of the current view assembly. Finally, a view controller will never exist for longer than the lifespan of its parent component controller.
Web Dynpro View Controllers View controllers are the active parts of a Web Dynpro component that handle all aspects of user interaction. Only view controllers have a visual interface. The lifespan of a view controller is determined by its presence in (or absence from) the current window (The term “View Assembly” may also be used instead of the term “Window”). As soon as a view controller instance is no longer part of the current view assembly, the Web Dynpro Framework will automatically garbage collect it. View controllers are always instantiated as singletons with respect to their parent component. Therefore, if the same view is embedded multiple times in a view assembly, you will see the same data in each view. View Controller Actions An action is conceptually the same as an event, however there are some specific implementation differences: • • An action can only be defined in a view controller An action is an event that originates on the client, initiates an HTTP round trip, and is then handled on the server side by a special event handler found only in a view controller. Many different UI elements are able to trigger an action, e.g, the onAction event of a button UI element.
View Controller Navigation Plugs In order for navigation to take place between different Web Dynpro view controllers, special navigation events and navigation event handlers have been created called plugs. Outbound plugs A navigation event is raised when an outbound plug is fired. Using the generic name sing the generic name <Outbound Plug> for an outbound plug, its declaration will cause a method to be generated in the view’s component controller called FIRE_<Outbound Plug>PLG or wdFirePlug<Outbound Plug>(). This method is only visible for the WD framework and not visible for the developer.
Navigation Modeller The Navigation Modeller is a Web Dynpro specific, graphical editor in which you can define the navigation links that exist between the different views of your Web Dynpro Component. The view that displays the work area of the Navigation Modeller, and within which the individual elements are displayed, is called the Diagram View. The navigation modeller allows you to manipulate the following entities: • • • • View Sets Views Inbound and Outbound Plugs Navigation Links
Opening the Navigation Modeller Start the Navigation Modeller either by choosing the context menu entry Open Navigation Modeller for the window name in the Web Dynpro Explorer or by double clicking on the window name.
Outbound Plugs Calling an outbound plug method causes a navigation event to be raised. Navigation events are special, asynchronous events that are placed into a navigation queue. Only when all the outbound plugs have been called by all the views in the current view assembly, will the Web Dynpro Framework enter its navigation processing phase. Outbound plugs should be named according to the action that caused navigation away from the current view. Inbound Plugs Inbound plugs are special event handler methods that subscribe to navigation events raised when outbound plugs are fired. Inbound plug methods are called only when the navigation queue is processed. This will only take place once all the views in the current view assembly have fired their outbound plugs and no validation errors have occurred that would cause navigation to be cancelled. Inbound plugs should be named according to the reason for which the view being displayed. Links Outbound and inbound plugs are joined together using navigation links created in the Navigation Editor. Select the Navigation Link tool from the graphical editor, then draw a line from the outbound plug to the inbound plug. This causes the event handler method represented by the inbound plug to subscribe to the navigation event raised by the outbound plug.
Figure 432: Application: entry point into a Web Dynpro component
Web Dynpro Application A Web Dynpro Application is an entry point into a Web Dynpro Component and is the only Web Dynpro entity that can be addressed via a URL. There is often (but not always) a one to one relationship between an interface view and an application. In the same way that the functionality in an ABAP module pool can be accessed by defining multiple transaction codes, so the functionality of a single Web Dynpro component can be accessed by defining multiple applications. Application definition In order to define a Web Dynpro application, you must specify • • • The component to be invoked. This component is then known as the root component, Which interface view of the root component will be used as the initial view assembly, Which inbound plug will act as the entry point for the nominated interface view (this inbound plug must have the Startup check box selected)
Exercise 16: Navigating between Views.
Exercise Objectives
After completing this exercise, you will be able to: • Use Navigation with the Java Web Dynpro to navigate to another view • Assign Actions to Plugs
Business Example Task:
Development Objectives This exercise has the following objectives: - Introduce the student to Navigation Plugs, Events and Navigation Links and how they work to navigate to a different View. - Use the solution from the previous exercise to continue with this development.
The result of this exercise will be the display of a view that will be able to navigate to the second view. Result Template Solution: WD01_Basics_00 – from previous exercise Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. Overview: Developing 1. Follow the path Web Dynpro → Web Dynpro Components → Exc_intro → Windows → Exc_intro_Window → StartVIew and double click.(You may not need to do this as it could be open). We will now include a new view. Click on the Icon Embed a View. Position the cursor within the diagram pane and drag a rectangle to the required size. The diagram pane displays two areas representing the two views. In this case, the first view you created, the StartView is displayed as the active view. When the Web Dynpro application is launched, the active view is always accessed. Select the StartView, right click and choose Create Outbound Plug. Continued on next page
Give the Outbound plug the name ToResultView and press the Finish button. Select the second View: ResultView and create an Inbound plug by right clicking and selecting Create Inbound Plug. Give this the name FromStartView and leave the defaults. Press the Finish button. You have thus created the exit and corresponding entry point for navigation from the (active) StartView to the ResultView. Create Outbound Plug from ResultView called ToStartView and create an Inbound Plug called FromResultView. The result should look like the diagram below. Create a navigation link by pressing the navigation link button. Connect the StartView outbound – (red) to the ResultView inbound (blue). Connect the StartView outbound – (red) to the ResultView inbound (blue).
6. 7.
8. 9.
10. Create a new Action for the StartView. 11. Create the Action by entering the Name and Text. Select the Fire Plug to be associated with this action. 12. Create an Action for the ResultView. 13. Enter the Name Back with the text Back and select the Fire Plug as to StartView. 14. Check that the relevant code has been generated. Go to StartView and select the implementation tab. Scroll almost to the end of the code and find the method onActionNavigate. Check the method wdThis.wdFirePlugToResultView(); Also check the ResultView with the method onActionBack with the code wdThis.wdFirePlugToStartView(); 15. Create a button to navigate from the StartView to the ResultView. 16. Assign the Navigate Action to the onAction of your button. The text from the Action is automatically displayed on the button. 17. Navigate to the ResultView. Create a new button to navigate back to the StartView using the same process completed above. 18. Deploy the New Archive and Run.
Solution 16: Navigating between Views.
Task:
Development Objectives This exercise has the following objectives: - Introduce the student to Navigation Plugs, Events and Navigation Links and how they work to navigate to a different View. - Use the solution from the previous exercise to continue with this development.
The result of this exercise will be the display of a view that will be able to navigate to the second view. Result Template Solution: WD01_Basics_00 – from previous exercise Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. Overview: Developing 1. Follow the path Web Dynpro → Web Dynpro Components → Exc_intro → Windows → Exc_intro_Window → StartVIew and double click.(You may not need to do this as it could be open). We will now include a new view. Click on the Icon Embed a View. Position the cursor within the diagram pane and drag a rectangle to the required size. a) The starting position of this exercise is the result from the previous exercise.
Follow the path Web Dynpro -> Web Dynpro Components -> Exc_intro -> Windows -> Exc_intro_Window -> StartVIew and double click.(You may not need to do this as it could be open) We will now include a new view. Click the Icon Embed a View. Position the cursor within the diagram pane and drag a rectangle area to the required size.
Figure 438: WebDynproControllers Screenshot 4
Drag the embed View icon onto the screen. Continued on next page
The diagram pane displays two areas representing the two views. In this case, the first view you created, the StartView is displayed as the active view. When the Web Dynpro application is launched, the active view is always accessed. a) The diagram pane displays two areas representing the two views. In this case, the first view you created, the StartView is displayed as the active view. When the Web Dynpro application is launched, the active view is always accessed. Select the StartView, right click and choose Create Outbound Plug.
3.
Select the StartView, right click and choose Create Outbound Plug. a)
Select the second View: ResultView and create an Inbound plug by right clicking and selecting Create Inbound Plug. Give this the name FromStartView and leave the defaults. Press the Finish button. a) Select the second View: ResultView and create an Inbound plug by right clicking and selecting Create Inbound Plug. Give this the name FromStartView and leave the defaults. Press the Finish button.
You have thus created the exit and corresponding entry point for navigation from the (active) StartView to the ResultView. a) You have thus created the exit and corresponding entry point for navigation from the (active) StartView to the ResultView. These two plugs are displayed as shown:
Figure 444: WebDynproControllers Screenshot 10
7.
Create Outbound Plug from ResultView called ToStartView and create an Inbound Plug called FromResultView. The result should look like the diagram below. a) Create Outbound Plug from ResultView called ToStartView and create an Inbound Plug called FromResultView. The result should look like the diagram below.
Figure 445: WebDynproControllers Screenshot 11
Create another Outbound Plug and an Inbound Plug with the names ToStartView and FromResultView.
Create a navigation link by pressing the navigation link button. a) Create a navigation link by pressing the navigation link button. Connect the StartView outbound – (red) to the ResultView inbound (blue). Connect the StartView outbound – (red) to the ResultView inbound (blue). a) Connect the StartView outbound – (red) to the ResultView inbound (blue). Similarly, to create the navigation link back from the second to the first view. It should look like this. An event handler with the name onPlug<Name of Plug>has been automatically generated for each inbound plug.
Figure 446: WebDynproControllers Screenshot 12
Connect the Plugs using the navigation link. Save all metadata.
11. Create the Action by entering the Name and Text. Select the Fire Plug to be associated with this action. a) Create the Action by entering the Name and Text. Select the Fire Plug to be associated with this action.
Figure 448: WebDynproControllers Screenshot 14
Enter Navigate for the Name and ‘Navigate to Result View’ for the Text. Please ensure that you have selected the Fire plug ToResultView. Finish.
13. Enter the Name Back with the text Back and select the Fire Plug as to StartView. a) Enter the Name Back with the text Back and select the Fire Plug as to StartView.
Figure 450: WebDynproControllers Screenshot 16
Enter the Name as Back. Enter the Text as Back. Select ToStartView. Finish. Save all metadata
14. Check that the relevant code has been generated. Go to StartView and select the implementation tab. Scroll almost to the end of the code and find the method onActionNavigate. Check the method wdThis.wdFirePlugToResultView(); Also check the ResultView with the method onActionBack with the code wdThis.wdFirePlugToStartView(); a) Check that the relevant code has been generated. Go to StartView and select the implementation tab. Scroll almost to the end of the code and find the method onActionNavigate. Check the method wdThis.wdFirePlugToResultView(); Also check the ResultView with the method onActionBack with the code wdThis.wdFirePlugToStartView();
Figure 451: WebDynproControllers Screenshot 17
Press implementation tab. Navigate to the onActionNavigate method. Check both views.
16. Assign the Navigate Action to the onAction of your button. The text from the Action is automatically displayed on the button. a) Assign the Navigate Action to the onAction of your button. The text from the Action is automatically displayed on the button.
Figure 453: WebDynproControllers Screenshot 19
Highlight the button. Go to the Properties View. Use the dropdown to select Navigate for the onAction for the button. The button should look like this. 17. Navigate to the ResultView. Create a new button to navigate back to the StartView using the same process completed above. a) Navigate to the ResultView. Create a new button to navigate back to the StartView using the same process completed above.
Double Click ResultView. Insert a child in the Root Container. Select Button.
Figure 455: WebDynproControllers Screenshot 21
Highlight the button and assign Back to the onAction. The text ‘Back’ gets displayed automatically from the Action. Save all metadata. 18. Deploy the New Archive and Run. a) Deploy the New Archive and Run. Continued on next page
Lesson Summary
You should now be able to: • Understand the MVC Model • Understand the different controllers used with Web Dynpro. • Understand the different kinds of Web Dynpro controller and what they are used for • Perform navigation between views • Start a Web Dynpro components with an application
Lesson Objectives
After completing this lesson, you will be able to: • • • Understand the different kinds of Web Dynpro controller and what they are used for Perform navigation between views Start a Web Dynpro components with an application
Business Example
Figure 459: Common Features for all Controllers
Common features for all controllers: Required Controllers
In order for information to be shared between different controllers, one controller must declare the use of another controller. The most frequent requirement for this kind of data sharing is when you wish the create a mapped context node. This is where a context node in one controller references the data in the context node of another controller. General points on controller usage A view controller can declare the use of a custom controller and a custom controller can declare the use of another custom controller. You may not specify the name of a view controller as a required controller as this would violate good MVC design principles. A view controller should be written such that it is responsible for nothing more than the display of data and user interaction. A view controller is not responsible for generating the data it displays: that is the role of a custom controller. Accessing business logic Business logic (Models) like function modules, BAPIs or calling methods in helper classes can be accessed. Common features for all controllers: Component Usage The Web Dynpro component is the unit of application reuse. Therefore, if you want to make use of the functionality within another component, you can declare the use of that component. Lifespan The lifespan of a component usage instance cannot exceed the lifespan of the parent component. Three types of controller • Custom / Component controller Each Web Dynpro component has at least one global controller – the component controller (default) – Custom controllers are a kind of additional global controllers to capsulate sub function from the component controller – typically to structure bigger components – They do not have a visual interface View controller Each view has exactly one view controller, which processes the actions performed by the user in the view Window controller Only WD-ABAP – Each window has exactly one window controller. It behaves like a view controller (plugs) and is usable from other controllers (like a custom / component controller) – –
Web Dynpro controller principles Two types of controller exist within a Web Dynpro component: custom/component and view/window. • • • • • • Custom/component controllers have no visual interface, whereas view controllers do. At runtime, all controller instances are singletons with respect to their parent component. All controllers are independent programs yet none function in isolation from the other controllers in the component. All controllers store their runtime data in a hierarchical data storage area known as the Context. Unless an explicit controller usage is declared, all the data in a controllers context is private. A Custom/component controller may share the data in its context, but a view controller may not.
Figure 460: Where are the Component / Custom Controller?
Custom controllers These are the internal building blocks of a Web Dynpro component and have no user interface. They are only to be used when some unit of functionality is required by several other controllers. Do not create a custom controller simply because you can! Only use one where its presence will simplify or optimize the components architecture.
Component Controller The component controller is a special custom controller that is automatically created when a component is created. The lifespan of a component is defined by, and equal to, the lifespan of the component controller. Lifespan All custom controller instances exist for as long as their parent component exists and are instantiated automatically by the Web Dynpro framework. After the component controller has been instantiated, the order in which any subsequent custom controllers are instantiated is undefined. An Interface controller exists for as long as the component usage instance exists.
Web Dynpro Custom Controllers Custom controllers are the active parts of a Web Dynpro component that do not need any direct interaction with the user. Such controllers therefore have no visual interface. When a Web Dynpro component is created, a special custom controller is created called the Component controller. It is this controller that drives the functionality of the entire component. All custom controllers are instantiated as singletons with respect to their parent component.
Custom controllers are instantiated automatically by the Web Dynpro Framework and the instantiation order is undefined! Therefore, the coding in a custom controller should make no assumptions about the existence of any other custom controller. Controller Events Using your design time declarations, the Web Dynpro Framework will automatically manage the definition, triggering and handler subscription to such events for you. You also have the additional option of dynamic event subscription at runtime. A typical use of such events is the invocation of processing in a view controller after processing in the component controller has been completed. This can be achieved when a method in the view controller subscribes to an event raised by the component controller. Important: If two or more methods subscribe to the same event, then the order in which they will be executed is undefined. Events can only be defined in Component/Custom controllers.
Figure 462: Where are the View Controllers?
View controllers A view controller is visual building block of a WD component and is designed to handle all aspects of data display and user interaction. Lifespan
A view controllers lifespan parameter can have the values When Visible or Framework Controlled. A view instance will be created either because it is the default view in a view area; or when the first navigation request to that view is encountered. There are three situations is which the view instance can be deleted. • If When Visible is selected, then the view will be deleted when a navigation event replaces the current view area with some other view, and the view is no longer part of the current view assembly. If Framework Controlled is selected, then the view will be deleted when there is no further use for the view. This will never occur whilst the view is part of the current view assembly. Finally, a view controller will never exist for longer than the lifespan of its parent component controller.
•
•
Figure 463: View Controllers Action Handlers
Web Dynpro View Controllers View controllers are the active parts of a Web Dynpro component that handle all aspects of user interaction. Only view controllers have a visual interface. The lifespan of a view controller is determined by its presence in (or absence from) the current window (The term “View Assembly” may also be used instead of the term “Window”). As soon as a view controller instance is no longer part of the current view assembly, the Web Dynpro Framework will automatically garbage collect it.
View controllers are always instantiated as singletons with respect to their parent component. Therefore, if the same view is embedded multiple times in a view assembly, you will see the same data in each view. View Controller Actions An action is conceptually the same as an event, however there are some specific implementation differences: • • An action can only be defined in a view controller An action is an event that originates on the client, initiates an HTTP round trip, and is then handled on the server side by a special event handler found only in a view controller. Many different UI elements are able to trigger an action, e.g, the onAction event of a button UI element.
•
Figure 464: View Controllers Navigation Plugs
View Controller Navigation Plugs In order for navigation to take place between different Web Dynpro view controllers, special navigation events and navigation event handlers have been created called plugs. Outbound plugs A navigation event is raised when an outbound plug is fired.
Using the generic name sing the generic name <Outbound Plug> for an outbound plug, its declaration will cause a method to be generated in the view’s component controller called FIRE_<Outbound Plug>PLG or wdFirePlug<Outbound Plug>(). This method is only visible for the WD framework and not visible for the developer.
Figure 465: Navigation
Navigation Modeller The Navigation Modeller is a Web Dynpro specific, graphical editor in which you can define the navigation links that exist between the different views of your Web Dynpro Component. The view that displays the work area of the Navigation Modeller, and within which the individual elements are displayed, is called the Diagram View. The navigation modeller allows you to manipulate the following entities: • • • • View Sets Views Inbound and Outbound Plugs Navigation Links
Opening the Navigation Modeller Start the Navigation Modeller either by choosing the context menu entry Open Navigation Modeller for the window name in the Web Dynpro Explorer or by double clicking on the window name.
Outbound Plugs Calling an outbound plug method causes a navigation event to be raised. Navigation events are special, asynchronous events that are placed into a navigation queue. Only when all the outbound plugs have been called by all the views in the current view assembly, will the Web Dynpro Framework enter its navigation processing phase. Outbound plugs should be named according to the action that caused navigation away from the current view. Inbound Plugs Inbound plugs are special event handler methods that subscribe to navigation events raised when outbound plugs are fired. Inbound plug methods are called only when the navigation queue is processed. This will only take place once all the views in the current view assembly have fired their outbound plugs and no validation errors have occurred that would cause navigation to be cancelled. Inbound plugs should be named according to the reason for which the view being displayed. Links Outbound and inbound plugs are joined together using navigation links created in the Navigation Editor. Select the Navigation Link tool from the graphical editor, then draw a line from the outbound plug to the inbound plug. This causes the event handler method represented by the inbound plug to subscribe to the navigation event raised by the outbound plug.
Figure 467: Application: entry point into a Web Dynpro component
Web Dynpro Application A Web Dynpro Application is an entry point into a Web Dynpro Component and is the only Web Dynpro entity that can be addressed via a URL. There is often (but not always) a one to one relationship between an interface view and an application. In the same way that the functionality in an ABAP module pool can be accessed by defining multiple transaction codes, so the functionality of a single Web Dynpro component can be accessed by defining multiple applications. Application definition In order to define a Web Dynpro application, you must specify • • • The component to be invoked. This component is then known as the root component, Which interface view of the root component will be used as the initial view assembly, Which inbound plug will act as the entry point for the nominated interface view (this inbound plug must have the Startup check box selected)
Exercise 17: Navigating between Views.
Exercise Objectives
After completing this exercise, you will be able to: • Use Navigation with the Java Web Dynpro to navigate to another view • Assign Actions to Plugs
Business Example Task:
Development Objectives This exercise has the following objectives: - Introduce the student to Navigation Plugs, Events and Navigation Links and how they work to navigate to a different View. - Use the solution from the previous exercise to continue with this development.
The result of this exercise will be the display of a view that will be able to navigate to the second view. Result Template Solution: WD01_Basics_00 – from previous exercise Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. Overview: Developing 1. Follow the path Web Dynpro → Web Dynpro Components → Exc_intro → Windows → Exc_intro_Window → StartVIew and double click.(You may not need to do this as it could be open). We will now include a new view. Click on the Icon Embed a View. Position the cursor within the diagram pane and drag a rectangle to the required size. The diagram pane displays two areas representing the two views. In this case, the first view you created, the StartView is displayed as the active view. When the Web Dynpro application is launched, the active view is always accessed. Select the StartView, right click and choose Create Outbound Plug. Continued on next page
Give the Outbound plug the name ToResultView and press the Finish button. Select the second View: ResultView and create an Inbound plug by right clicking and selecting Create Inbound Plug. Give this the name FromStartView and leave the defaults. Press the Finish button. You have thus created the exit and corresponding entry point for navigation from the (active) StartView to the ResultView. Create Outbound Plug from ResultView called ToStartView and create an Inbound Plug called FromResultView. The result should look like the diagram below. Create a navigation link by pressing the navigation link button. Connect the StartView outbound – (red) to the ResultView inbound (blue). Connect the StartView outbound – (red) to the ResultView inbound (blue).
6. 7.
8. 9.
10. Create a new Action for the StartView. 11. Create the Action by entering the Name and Text. Select the Fire Plug to be associated with this action. 12. Create an Action for the ResultView. 13. Enter the Name Back with the text Back and select the Fire Plug as to StartView. 14. Check that the relevant code has been generated. Go to StartView and select the implementation tab. Scroll almost to the end of the code and find the method onActionNavigate. Check the method wdThis.wdFirePlugToResultView(); Also check the ResultView with the method onActionBack with the code wdThis.wdFirePlugToStartView(); 15. Create a button to navigate from the StartView to the ResultView. 16. Assign the Navigate Action to the onAction of your button. The text from the Action is automatically displayed on the button. 17. Navigate to the ResultView. Create a new button to navigate back to the StartView using the same process completed above. 18. Deploy the New Archive and Run.
Solution 17: Navigating between Views.
Task:
Development Objectives This exercise has the following objectives: - Introduce the student to Navigation Plugs, Events and Navigation Links and how they work to navigate to a different View. - Use the solution from the previous exercise to continue with this development.
The result of this exercise will be the display of a view that will be able to navigate to the second view. Result Template Solution: WD01_Basics_00 – from previous exercise Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. Overview: Developing 1. Follow the path Web Dynpro → Web Dynpro Components → Exc_intro → Windows → Exc_intro_Window → StartVIew and double click.(You may not need to do this as it could be open). We will now include a new view. Click on the Icon Embed a View. Position the cursor within the diagram pane and drag a rectangle to the required size. a) The starting position of this exercise is the result from the previous exercise.
Follow the path Web Dynpro -> Web Dynpro Components -> Exc_intro -> Windows -> Exc_intro_Window -> StartVIew and double click.(You may not need to do this as it could be open) We will now include a new view. Click the Icon Embed a View. Position the cursor within the diagram pane and drag a rectangle area to the required size.
Figure 473: WebDynproControllers Screenshot 4
Drag the embed View icon onto the screen. Continued on next page
The diagram pane displays two areas representing the two views. In this case, the first view you created, the StartView is displayed as the active view. When the Web Dynpro application is launched, the active view is always accessed. a) The diagram pane displays two areas representing the two views. In this case, the first view you created, the StartView is displayed as the active view. When the Web Dynpro application is launched, the active view is always accessed. Select the StartView, right click and choose Create Outbound Plug.
3.
Select the StartView, right click and choose Create Outbound Plug. a)
Select the second View: ResultView and create an Inbound plug by right clicking and selecting Create Inbound Plug. Give this the name FromStartView and leave the defaults. Press the Finish button. a) Select the second View: ResultView and create an Inbound plug by right clicking and selecting Create Inbound Plug. Give this the name FromStartView and leave the defaults. Press the Finish button.
You have thus created the exit and corresponding entry point for navigation from the (active) StartView to the ResultView. a) You have thus created the exit and corresponding entry point for navigation from the (active) StartView to the ResultView. These two plugs are displayed as shown:
Figure 479: WebDynproControllers Screenshot 10
7.
Create Outbound Plug from ResultView called ToStartView and create an Inbound Plug called FromResultView. The result should look like the diagram below. a) Create Outbound Plug from ResultView called ToStartView and create an Inbound Plug called FromResultView. The result should look like the diagram below.
Figure 480: WebDynproControllers Screenshot 11
Create another Outbound Plug and an Inbound Plug with the names ToStartView and FromResultView.
Create a navigation link by pressing the navigation link button. a) Create a navigation link by pressing the navigation link button. Connect the StartView outbound – (red) to the ResultView inbound (blue). Connect the StartView outbound – (red) to the ResultView inbound (blue). a) Connect the StartView outbound – (red) to the ResultView inbound (blue). Similarly, to create the navigation link back from the second to the first view. It should look like this. An event handler with the name onPlug<Name of Plug>has been automatically generated for each inbound plug.
Figure 481: WebDynproControllers Screenshot 12
Connect the Plugs using the navigation link. Save all metadata.
11. Create the Action by entering the Name and Text. Select the Fire Plug to be associated with this action. a) Create the Action by entering the Name and Text. Select the Fire Plug to be associated with this action.
Figure 483: WebDynproControllers Screenshot 14
Enter Navigate for the Name and ‘Navigate to Result View’ for the Text. Please ensure that you have selected the Fire plug ToResultView. Finish.
13. Enter the Name Back with the text Back and select the Fire Plug as to StartView. a) Enter the Name Back with the text Back and select the Fire Plug as to StartView.
Figure 485: WebDynproControllers Screenshot 16
Enter the Name as Back. Enter the Text as Back. Select ToStartView. Finish. Save all metadata
14. Check that the relevant code has been generated. Go to StartView and select the implementation tab. Scroll almost to the end of the code and find the method onActionNavigate. Check the method wdThis.wdFirePlugToResultView(); Also check the ResultView with the method onActionBack with the code wdThis.wdFirePlugToStartView(); a) Check that the relevant code has been generated. Go to StartView and select the implementation tab. Scroll almost to the end of the code and find the method onActionNavigate. Check the method wdThis.wdFirePlugToResultView(); Also check the ResultView with the method onActionBack with the code wdThis.wdFirePlugToStartView();
Figure 486: WebDynproControllers Screenshot 17
Press implementation tab. Navigate to the onActionNavigate method. Check both views.
16. Assign the Navigate Action to the onAction of your button. The text from the Action is automatically displayed on the button. a) Assign the Navigate Action to the onAction of your button. The text from the Action is automatically displayed on the button.
Figure 488: WebDynproControllers Screenshot 19
Highlight the button. Go to the Properties View. Use the dropdown to select Navigate for the onAction for the button. The button should look like this. 17. Navigate to the ResultView. Create a new button to navigate back to the StartView using the same process completed above. a) Navigate to the ResultView. Create a new button to navigate back to the StartView using the same process completed above.
Double Click ResultView. Insert a child in the Root Container. Select Button.
Figure 490: WebDynproControllers Screenshot 21
Highlight the button and assign Back to the onAction. The text ‘Back’ gets displayed automatically from the Action. Save all metadata. 18. Deploy the New Archive and Run. a) Deploy the New Archive and Run. Continued on next page
Lesson Summary
You should now be able to: • Understand the different kinds of Web Dynpro controller and what they are used for • Perform navigation between views • Start a Web Dynpro components with an application
Unit Summary
You should now be able to: • Understand the MVC Model • Understand the different controllers used with Web Dynpro. • Understand the different kinds of Web Dynpro controller and what they are used for • Perform navigation between views • Start a Web Dynpro components with an application • Understand the different kinds of Web Dynpro controller and what they are used for • Perform navigation between views • Start a Web Dynpro components with an application
Unit 11
The Adaptive RFC Layer
Unit Overview
Models encapsulate the business objects that care for reading and writing data, setting database locks. In addition, data format conversion and data checks are implemented in the models. Thus, the WD only cares about the program flow and the UI presentation, but not about the issues related to a model. Different kind of models are supported, however, the most important one is the aRFC model, which connects data and business logic available in an ABAP based backend system to the presentation layer. Defining and using such a model is described here, however, the client proxies for all kind of models have a common interface to be used by Web Dynpro, so the concepts explained here can be applied to all other kinds of models.
Unit Objectives
After completing this unit, you will be able to: • • • • • • • • • • Understand the background technology for the adaptive RFC (aRFC) layer Understand the basic requirements of a remote function callable ABAP function module (RFM) Create aRFC models that allow to access RFMs from your Web Dynpro application Explain what kind of JAVA objects are created as a result of generating an aRFC model Create model objects in a development component, so they can be reused in other Web Dynpro projects Use aRFC model objects in a Web Dynpro application Check the installed software catalog Import a software catalog if necessary Define technical systems in the SLD Define JCo destinations
Unit Contents
Lesson: Remote Invocation of ABAP Functionality ........................435
Lesson: The Adaptive RFC (aRFC) Model Object .........................441 Exercise 18: Creating and using an aRFC model object..............461 Lesson: Configuring SLD and JCo Connections ...........................486 Exercise 19: Configure SLD and JCo Destinations ....................497
Lesson: Remote Invocation of ABAP Functionality
Lesson Overview
ABAP function module can be used as models objects by calling them via RFC.
Lesson Objectives
After completing this lesson, you will be able to: • • Understand the background technology for the adaptive RFC (aRFC) layer Understand the basic requirements of a remote function callable ABAP function module (RFM)
Business Example
Your Web Dynpro application needs to display and change data, which is stored on database tables of an ABAP based SAP system. You heard that remote enabled ABAP function modules exist, that can be used to access the database tables. Thus you decide to learn about ABAP function modules and how these modules can technically be accessed from your Web Dynpro application.
Invoke ABAP functionality from a JAVA application via RFC
Figure 494: A brief history of remote function calls into SAP
Figure 495: The original RFC interface architecture
The original implementation of the JCo layer contained functionality to adapt to changes in the interface structure, but at that time, no applications required this functionality, so it was not implemented in the earlier API’s such as the Enterprise Connector. Regardless of language, all external programs that wish to invoke functionality within an SAP system will ultimately use the RFC layer.
Figure 496: The Adaptive RFC Layer architecture
Only Web Dynpro makes use of the Adaptive RFC layer.
Every time an RFC enabled function module is called in an SAP system, the metadata describing its interface is checked. If the interface has changed since the last invocation, the new metadata data is obtained from the SAP system. The application program should then check the dictionary for changes and react appropriately. The aRFC layer will automatically update the dictionary with any metadata changes, but it is up to you to design your Web Dynpro application to react to these changes!
ABAP function modules and BAPIs
Figure 497: The interface of an ABAP function module
All ABAP function modules have the following interface architecture: Import parameters Scalar or structured parameters used only on the inbound side of the interface having a cardinality of 0..1. Export parameters Scalar or structured parameters used only on the outbound side of the interface having a cardinality of 0..1. Changing Parameters Bi-directional scalar or structured parameters having a cardinality of 0..1. RFC enabled function modules tend not to use CHANGING parameters.
Tables Bi-directional structured parameters having a cardinality of 0..n. Exceptions Text labels used to identify an unexpected termination of processing within the function module. Exceptions can only be invoked by means of the ABAP statement RAISE. RFC enabled function modules should avoid the use the RAISE statement! The reason for this will be explained later.
Figure 498: What is a BAPI?
Only SAP delivered coding can comply with criteria 1 to 3. During a Web Dynpro implementation that uses an SAP system as its business back-end, it is likely that your Web Dynpro program will need to call some custom written ABAP function modules. In this situation, it is essential that your function modules comply with criteria 4 to 7 above! Further clarification for custom written remote modules: Point 4: Don’t forget to switch on the Remote Enabled flag! Point 5: If any attempt is made to invoke a SAPGUI screen of any sort, the RFC connection will be terminated immediately! Point 6: A remote module must run to completion irrespective of any errors that occur. This means that when control is passed back to Web Dynpro, the data in the interface will accurately reflect the success or failure of execution.
The use of the ABAP statement RAISE must be avoided because it will terminate the function module immediately, leaving the interface in a potentially undefined state. Point 7: Important: Do not use any ABAP statement that would cause the current logical unit of work (LUW) within the SAP User Roll Area to terminate! This has an impact on the RFC connection and will interfere with your ability to manage transactional data in the SAP system.
Lesson Summary
You should now be able to: • Understand the background technology for the adaptive RFC (aRFC) layer • Understand the basic requirements of a remote function callable ABAP function module (RFM)
Lesson: The Adaptive RFC (aRFC) Model Object
Lesson Overview
In order to use an ABAP function module in a Web Dynpro application, a related aRFC model object has to be generated. This is guided by a wizard. This lesson explains how to create and how to use an aRFC model object in a Web Dynpro application. In addition it is explained, how development components are used to create model objects, that can be used in multiple Web Dynpro projects.
Lesson Objectives
After completing this lesson, you will be able to: • • • • Create aRFC models that allow to access RFMs from your Web Dynpro application Explain what kind of JAVA objects are created as a result of generating an aRFC model Create model objects in a development component, so they can be reused in other Web Dynpro projects Use aRFC model objects in a Web Dynpro application
Business Example
The data, you want to display with your Web Dynpro application has to be read using an ABAP function module. Your colleague told you, that you have to create an aRFC model object to be able to call the ABAP function module. This concept is not known to you, so you have to learn about how to create highly reusable aRFC models.
Please observe the SAP naming convention for model objects: {nm} = {m}Model. Where {nm} is the actual model object name and {m} is the desired model name Always ensure that you create an individual Java package per model object! The package name should conform to a pattern such as {pkg1}.{pkg2}.{pkg3}.models.{m}. See the SAP recommended naming convention listed in the Appendix.
If you have two model objects that share the same data structure (e.g. the structure BAPIRET2 that defines the RETURN parameter of many BAPI’s), then placing the model objects in different packages avoids any runtime ambiguity that could occur.
Figure 501: Creating an aRFC model object (3)
Logical system names can be any meaningful names you desire. However, please avoid creating names that contain the SAP system name, as this will create confusion once the application is transported out of the development environment. E.G.: If you wish to call some HR Payroll remote modules in the SAP system called DEV, then HR_PAYROLL_DATA and HR_PAYROLL_METADATA are much better logical system names than DEV_PAYROLL_DATA and DEV_PAYROLL_METADATA.
As for the SAP GUI for Windows, the information displayed by the drop down list on the Load Balancing tab is obtained from the saplogon.ini file, which is located in the Windows directory.
Figure 503: Creating an aRFC model object (5)
When this screen initially appears, it will be empty! This is a deliberate design decision because the average SAP contains around 9,500 remote callable function modules. It would be highly inefficient to present a list of all such remote modules, from which only a few will actually be required! You will only see a list of function modules after a search criterion has been entered and the Search button has been pressed.
Figure 505: What has the aRFC model wizard created?
Dedicated Model Dictionary A dedicated dictionary is created for each model object. Each dictionary contains a set of Simple Types and a set of Structures Simple Types
The Simple Types are the dictionary definitions for the individual fields in the interface. Structures These are the dictionary entities that describe all the structured interface parameters. Every Structure listed here is built from the Simple Types shown in the same dictionary. Model Class Hierarchy A hierarchy of model classes is constructed to represent the entire interface of each RFM in the model object. For each remote function module {rfm}, an {rfm}_Input and an {rfm}_Ouput class will always be created. The additional classes are named according to the structure name found in the ABAP data dictionary, not the parameter name in the RFM’s interface. For instance, if the RFM has an EXPORTING parameter called RETURN that is based on the dictionary structure BAPIRET2, then you will see the name BAPIRET2 listed and not RETURN.
Figure 506: Java Dictionary Simple Types
Simple Types Simple Types for aRFC interface fields are defined using Web Dynpro Built-In Types (date, string, integer etc). These are not the same as the namesake Java classes!
All aRFC model classes have an RFC part type associated with them; this describes the function played by the class in the RFC interface.
Figure 509: The Model Class Hierarchy (2)
Scalar parameters A scalar parameter is any value that can be described as a single field. These are not shown directly in the model class hierarchy, but can be displayed by double clicking on the model class name, and then selecting the Properties tab from the editor window.
Relationship between model classes All RFC model classes are arranged in a hierarchical structure that, taken together, represents the entire interface of function module {rfm}. The controlling class in this hierarchy is always {rfm}_Input. This class must be instantiated first, and it is the only RFC model class to possess an execute() method. Once the method {rfm}_Input.execute() has been called, an instance of class {rfm}_Output will be available. All structures used to type IMPORTING, EXPORTING, CHANGING or TABLES parameters to {rfm} will be represented by the classes of RFC type structure.
Figure 511: The Model Class Hierarchy (4)
Bi-directional parameters Important: Due to the fact that CHANGING and TABLES parameters of an RFM are bi-directional, it is necessary to preserve an “input” and “output” image of these parameters. This means that you will see the same parameters listed under both the {rfm}_Input and {rfm}_Output classes. At runtime, these classes become separate instances that hold the “before execution” and “after execution” images of the parameter values. This important fact that must be understood because it has a significant impact when binding context model nodes to model objects.
Executing an aRFC model object and handling the output data If an RFM requires input parameters, these must be supplied to the instance of class {rfm}_Input. Then the {rfm}_Input.execute() method can be called. Once the RFM has executed, and instance of {rfm}_Output will be available as a child of {rfm}_Input.
Model Object Management
Figure 513: Principles of model object management (1)
Figure 514: Principles of model object management (3)
Having one RFM per model is inefficient from a connection management point of view. Having all your RFMs in one big model object is inefficient from a reuse point of view.
Reusable model objects in development components
Figure 515: Model object management: SAP Recommendations (1)
It is most important, that once you have built your DC’s, you should perform a DC Build. This is done by right mouse clicking on the DC name itself, then selecting Development Component and then Build from the side-bar menu. This build process is different from the Rebuild Project option. Each Public Part becomes a separate JAR file, and the DC Build process rebuilds these public part JAR files. This is a separate build process from the normal project build process.
Using aRFC model objects in Web Dynpro applications
The Data Modeler Tool provides a wizard to create not only the binding between the controller context and the model object, but also most of the source code necessary to execute the model and handle possible errors.
Figure 521: General architecture for RFM invocation (1)
Data passes from the model object to the screen using this chain of connections: The context of the component controller is bound to the model object. The view controller context is mapped to the component controller context.
The UI elements are bound to the view controller’s context.
Figure 522: General architecture for RFM invocation (2)
Preparing the controllers context includes the creation of a model object and the binding of this instance to a model node in the context. For each non-scalar import parameter of the RFM, it is necessary to create a related object and add this object to the model instance. The object has to be an instance of the generated model class, that has the name of the import parameters structure type.
Figure 523: General architecture for RFM invocation (3)
Figure 524: General architecture for RFM invocation (4)
To access a method of the component controller from within a method of the view controller, the self reference wdThis is used. E.G. To call the method {nm} in the component controller of component {nc}, the following expression is used: wdThis.wdGet{nc}Controller.{nm}()
Figure 525: General architecture for RFM invocation (5)
Once the above coding has been executed, the BAPI_FLIGHT_GETLIST function module will be able to receive input values in the structured parameters DESTINATION_TO and DESTINATION_FROM. It is useful to create the executable model object as a class variable. That way it can be accessed by any method in the custom controller. It is also useful to create a class variable to refer to the component’s message manager.
Figure 528: Using model objects at runtime (2)
The call to any particular RFM should always be placed within a dedicated method in the custom controller. Using the wizard in the Data Modeller Tool, this method is created automatically including the complete source code. The RFM functionality is being invoked by directly calling the models execute() method. However, it is also possible to invoke the RFM via the context model node. For reasons of coding legibility, the SAP recommendation is to interact directly with the model object. Once the invalidate() method has run against the model object’s Output node, the data returned by the RFM will be available in the context.
Figure 529: Generic use of model objects at runtime
In its generic form, the coding to use a model object requires three main steps, the second of which is optional, depending on the individual requirements of the RFM being called. Create an instance of the RFM class. By default, the class will be called {rfcm}_Input. Create any structured parameters that the RFM may require and add them to the instance of the {rfcmin}_Input class. This step is dependent upon the individual requires of the RFM you are using. Bind the {rfcmin}_Input instance to the appropriate controller model node.
Exercise 18: Creating and using an aRFC model object
Exercise Objectives
After completing this exercise, you will be able to: • Create an aRFC model object allowing to call one or more ABAP RFMs • Describe, what kind of objects are generated by the model wizard and how these objects are related to the interface of the ABAP RFM • Know how Development Components (DCs) can be used to encapsulate reusable Web Dynpro objects • Know how DCs can be reused by other DCs • Know how an aRFC model can be accessed from a Web Dynpro Controller
Business Example
You want to read data, stored on the database of an ABAP based SAP system. You know, that there is a remote enabled function module (RFM), that can be used to read the data from the database. In addition, this RFM can be called from Java programs using the JCo protocol. For Web Dynpro, there is the possibility to let a wizard create all objects necessary to access the RFM.
Task:
1. Create a new Web Dynpro Development Component called models. Select File → New → Development Component Project, then select Local Development → MyComponents from the tree structure. Enter a vendor name of training.sap.com. The Name of the Development Component must be specified in lower case letters; enter models here. Enter some descriptive caption and select Web Dynpro from the Type tree. Repeat exactly the same DC creation process, but now, call the DC components. It is vitally important that you are consistent with the language in which all your DCs are created. DCs of different languages will not interact with each other correctly. Open the models DC hierarchy, and select Create Model from the right mouse click menu under Web Dynpro → Models. Select Import Adaptive RFC Model and then press Next. Remember that the model name should end in the word Model, and that each model object must live in its own package. In the screen, enter FlightListModel as the model name, and com.sap.training.models.flightlist as the model package name. The logical Continued on next page
system names (JCo Destinations) entered here do not yet need to exist in the J2EE engine. Remember that the logical system names should not contain the name of the system from which you are obtaining the data. Rather, they should describe the type of data being obtained. The Logical Dictionary name should be allowed to default to the same name as the model object. 5. Specify the name of the SAP system you wish to connect to. Your instructor will be able to supply the connection details for you. Press Next. Enter bapi_flight* in the Function Name field and press the search button. Tick the checkbox next to BAPI_FLIGHT_GETLIST and press Next. The Model wizard will now extract the details of the function module’s interface and present you with a log file. Press Finish. All that is necessary to complete the models DC is to add the model object FlightListModel to the DC’s public part. In order to do this, right mouse click on the model object name FlightListModel, and select New Public Part. Since this is the very first public part defined for this DC, we must specify the name of the public part to which this model object will be added. Enter a public part name of FlightListModel and press Finish. The last step needed for the models DC is to build the entire project, and then to perform a DC build. It is most important that a DC Build is performed, otherwise, the DC’s public parts (which are each separate JAR files) will not be constructed properly. Firstly, click on the entire models DC, and select Rebuild Project. This will only take a few seconds. Now right mouse click again on the DC name and select Build from the Development Component side menu. Since development components can declare the use of other development components, it is possible that a set of dependencies can exist between these DCs. This particular case, the models has no dependencies on any other DCs, so this next screen only shows a list of one DC. Select OK. Now open the following branch in the components DC: DC MetaData → DC Definition → Used DCs. At the moment, the components DC only requires the use of standard Web Dynpro DCs. You must add to this list and declare that the models DC is also a Used DC. Right mouse click on Used DCs and select Add Used DC. Expand the branch LocalDevelopments → MyComponents and select models. Press Finish. Now all the public parts of DC models are accessible within the DC components In the components DC, open the Web Dynpro branch of the hierarchy, and create a new Web Dynpro Component called FlightListComp. Use a package name of com.sap.training.flightlist and don’t forget to remove the characters Comp from the view name.
6.
7.
8.
9.
10. In the Used Models node of component FlightList, add the usage of model FlightListModel.
11. The information in the model object FlightListModel must now be made available to component controller of FlightListComp. The easiest way to do this is to open the diagram editor of component FlightListComp. This is done by double clicking on the component name itself. Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel. This will now open the Model Binding window. Select the Bapi_Flight_Getlist_Input model class and drop it directly onto the Context root node. Now the Context Mapping window opens. It is here that we decide which parts of the BAPI’s interface are needed by the component controller. It is at this point that you will need to know which parts of the BAPI interface are used for input, which for output and which are bidirectional. In this case, we are going to use the two scalar parameters Airline and Max_Rows, and the two structured parameters Destination_To and Destination_From. Since the parameters Date_Range, Extension_In, Extension_Out, Flight_List and Return are TABLES parameters, they will appear on both the input and output sides of the interface. We will not be sending any data into the function module via these tables, so they can be omitted from the input side of the interface. However, Flight_List and Return have to be selected at the output side, because we want to display the data the BAPI sends back. 12. The previous step has made the information in the model object available to the component controller. Now we need to make the data available to the view controller. This is done by creating another data link starting at the view controller and going across to the component controller. As in the creation of the previous data link, you will need to drag the model node from the component controller context across to the view controller context. Select all the nodes in the context hierarchy and then click OK and then Finish. 13. Now that the model data has been mapped all the way through to the view controller, we can start building the view’s user interface. 14. Select the RootUIElementContainer and change its layout property to MatrixLayout 15. In the Outline view, right mouse click on RootUIElementContainer and select Insert Child. Add a Tray UI element with the name ParentTray and change the text property of its child Caption UI element to Input Parameters. If you find that your Tray UI element is called something like Tray0 or Tray1, then you can rename it by changing the value of its id property. 16. Select the ParentTray UI element from the Outline view and choose Apply Template from the right mouse click menu. Choose the Form template and press Next. Select Max_Rows and Airline from the Template Wizard window and press Finish
17. You now need to insert two further Group UI elements as the children of ParentTray. Select the ParentTray UI element in the Outline view and choose Insert Child. Create two child Group UI elements called ChildGroupTo and ChildGroupFrom. 18. Each Group UI element has a child Caption UI element. Change the text properties of these child Caption UI elements to To and From respectively 19. For each Group UI element, apply a form template to the Group UI element ChildGroupFrom for all the attributes of node Destination_From, and another form template for Group UI element ChildGroupTo for all the attributes of Destination_To. 20. Change the layoutData property of ChildGroupFrom to MatrixHeadData 21. Next, select the Actions tab from the view controller editor and create a new Action. Give the Action the name Search and the text Start search. Use the default event handler. Press Finish 22. Go back to the Layout tab and insert a Button UI element as a child of the Tray UI element ParentTray. Change its layoutData property to MatrixHeadData and its onAction property to Search. Notice that as soon as the Search action is assigned to the onAction event of the button, the button immediately inherits the text description of the action. 23. The last step is to create a table in which the BAPI output results will be displayed. Select the RootUIElementContainer, and select Apply Template from the right mouse-click menu. This time, select a Table template and press next. Under the Output context node, there will be a child node called FlightList. Select this check box, and all the child attribute checkboxes will be selected automatically. Press Finish and press the Save Metadata button on the toolbar. 24. Now we need to add some coding into the component controller. Double click on the Component Controller node underneath FlightListComp in the Web Dynpro Explorer. Select the Implementation tab 25. Scroll right down to the bottom of the file, and between the //@@begin others and //@@end comment markers, declare an instance of executable model class called bapiInput, and an instance of the message manager called msgMgr. 26. Now locate method wdDoInit() and assign the message manager variable to the component’s message manager instance, and assign to the bapiInput object a new instance of the BAPI class.
27. Now create an instance of each of the structure input parameters DESTINATION_TO and DESTINATION_FROM. The class that needs to be instantiated can be found by switching to the Context tab, selecting the corresponding model node, and then looking at the value of the ModelClass property. In this case, the class is Bapisfldst Once these two parameter instances have been created, they must be added as structured parameters to the main bapiInput object The last step for method wdDoInit() is to bind the BAPI input object to the corresponding model node in the component controller’s context 28. Next, it is necessary to add the coding that will call the BAPI. This coding will be placed into its own method, so go to the Methods tab and create a new method. In the pop-up window, select a method type of Method (Don’t select Event Handler, it won’t work!), press Next, and then enter a name of callBAPI and then press Finish 29. Go back to the Implementation tab, and locate the callBAPI() method. In this method, the execute() method of the BAPI object must be called from within a try/catch clause. If the execution fails, then a simplistic error message will be issued, otherwise the BAPI’s Output model node needs to be invalidated 30. Now that the component controller has a separate method for calling the BAPI, this method must be called when the view controller’s action Search is processed. This is done by going back to the Implementation tab of the view controller FlightListView and adding a line of code to method onActionSearch() that calls method callBAPI() in the component controller. 31. The final stage is to create an application called FlightListApp placing it into package com.sap.training.flightlist. 32. Save Metadata and do a DC Build. This time, the DC Build screen will show that a dependency exists between DC components and DC models. Since the public part of DC models has not been changed, it is not necessary to rebuild this DC. Therefore, leave the check box against models unchecked. Press OK 33. Since the components DC is dependent upon the models DC, it is necessary to deploy the models DC first. Select the root node of the models DC from the Web Dynpro Explorer window and choose Deploy from the right mouse-click menu. If this is the first time you have deployed anything to your J2EE server since starting the NetWeaver Developer Studio, then you will be asked for the SDM password. The default value is sdm 34. Now choose FlightListApp from the applications menu, and select Deploy new archive and run from the right mouse-click menu. If you have forgotten to create the two JCo destinations FlightList_Data and FlightList_Metadata, then when you run the application, you will get a Java stack trace. This is due to the fact that the J2EE engine is attempting to use a pair of JCo destinations that have not yet been configured! Continued on next page
Solution 18: Creating and using an aRFC model object
Task:
1. Create a new Web Dynpro Development Component called models. Select File → New → Development Component Project, then select Local Development → MyComponents from the tree structure. a) Select File → New → Development Component Project, then select Local Development → MyComponents from the tree structure. Press Next
Enter a vendor name of training.sap.com. The Name of the Development Component must be specified in lower case letters; enter models here. Enter some descriptive caption and select Web Dynpro from the Type tree. a) The Name of the Development Component must be specified in lower case letters; enter models here. Enter some descriptive caption and select Web Dynpro from the Type tree. Press Next then Finish.
Figure 531:
3.
Repeat exactly the same DC creation process, but now, call the DC components. It is vitally important that you are consistent with the language in which all your DCs are created. DCs of different languages will not interact with each other correctly. a) Repeat step 4-2 giving the component the name components. You should now have two Web Dynpro DCs and your workspace should look like this:
Figure 532:
4.
Open the models DC hierarchy, and select Create Model from the right mouse click menu under Web Dynpro → Models. Select Import Adaptive RFC Model and then press Next. Remember that the model name should end in the word Model, and that each model object must live in its own package. In the screen, enter FlightListModel as the model name, and com.sap.training.models.flightlist as the model package name. The logical system names (JCo Destinations) entered here do not yet need to exist in the Continued on next page
J2EE engine. Remember that the logical system names should not contain the name of the system from which you are obtaining the data. Rather, they should describe the type of data being obtained. The Logical Dictionary name should be allowed to default to the same name as the model object. a) Open the models DC hierarchy, and select Create Model from the right mouse click menu under Web Dynpro → Models. Select Import Adaptive RFC Model and then press Next Remember that the model name should end in the word Model, and that each model object must live in its own package. In the screen, enter FlightListModel as the model name, and com.sap.training.models.flightlist as the model package name.
Figure 533:
5.
Specify the name of the SAP system you wish to connect to. Your instructor will be able to supply the connection details for you. Press Next. Enter bapi_flight* in the Function Name field and press the search button. Tick
the checkbox next to BAPI_FLIGHT_GETLIST and press Next. The Model wizard will now extract the details of the function module’s interface and present you with a log file. Press Finish. a) Enter bapi_flight* in the Function Name field and press the Search button. You should see some search results similar to the image on the left. Tick the checkbox next to BAPI_FLIGHT_GETLIST and press Next. The Model wizard will now extract the details of the function module’s interface and present you with a log file. Press Finish.
Figure 534:
b)
The Model wizard creates an XML description of the RFM’s interface. After pressing Finish, you will notice that the IDE now spends a few seconds generating the actual Java source code. Your models DC should now as displayed on the left:
Figure 535:
6.
All that is necessary to complete the models DC is to add the model object FlightListModel to the DC’s public part. In order to do this, right mouse click on the model object name FlightListModel, and select New Public Part. Continued on next page
Since this is the very first public part defined for this DC, we must specify the name of the public part to which this model object will be added. Enter a public part name of FlightListModel and press Finish. a) Right mouse click on the model object name FlightListModel, and select New Public Part. Since this is the very first public part defined for this DC, we must specify the name of the public part to which this model object will be added. Enter a public part name of FlightListModel and press Finish.
Figure 536:
b)
FlightListModel listed as an Entity belonging to the public part called FlightListModel.
Figure 537:
7.
The last step needed for the models DC is to build the entire project, and then to perform a DC build. It is most important that a DC Build is performed, otherwise, the DC’s public parts (which are each separate JAR files) will not Continued on next page
be constructed properly. Firstly, click on the entire models DC, and select Rebuild Project. This will only take a few seconds. Now right mouse click again on the DC name and select Build from the Development Component side menu. Since development components can declare the use of other development components, it is possible that a set of dependencies can exist between these DCs. This particular case, the models has no dependencies on any other DCs, so this next screen only shows a list of one DC. Select OK. a) Firstly, click on the entire models DC, and select Rebuild Project. This will only take a few seconds. Now right mouse click again on the DC name and select Build from the Development Component side menu. Since development components can declare the use of other development components, it is possible that a set of dependencies can exist between these DCs. This particular case, the models has no dependencies on any other DCs, so this next screen only shows a list of one DC
Figure 538:
b)
Check models and press OK. The DC build process takes around 30 seconds to complete the first time it runs. The models DC is now complete
Figure 539:
8.
Now open the following branch in the components DC: DC MetaData → DC Definition → Used DCs. At the moment, the components DC only requires the use of standard Web Dynpro DCs. You must add to this list and Continued on next page
declare that the models DC is also a Used DC. Right mouse click on Used DCs and select Add Used DC. Expand the branch LocalDevelopments → MyComponents and select models. Press Finish. Now all the public parts of DC models are accessible within the DC components a) Now open the following branch in the components DC: DC MetaData → DC Definition → Used DCs. At the moment, the components DC only requires the use of standard Web Dynpro DCs. You must add to this list and declare that the models DC is also a Used DC. Right mouse click on Used DCs and select Add Used DC. Expand the branch LocalDevelopments → MyComponents and select models. Press Finish
Figure 540:
b)
Now all the public parts of DC models are accessible within DC components
In the components DC, open the Web Dynpro branch of the hierarchy, and create a new Web Dynpro Component called FlightListComp. Use a package name of com.sap.training.flightlist and don’t forget to remove the characters Comp from the view name. a) Use a package name of com.sap.training.flightlist and don’t forget to remove the characters Comp from the view name
10. In the Used Models node of component FlightList, add the usage of model FlightListModel. a) If you cannot see FlightListModel when you try to add a used model to component FlightListComp, then one of the following problems could exist: You have not exposed the model object FlightListModel correctly through a public part of DC models. You have forgotten to build the public part of DC models. DC components does not have a correct usage declaration for DC models.
Figure 543:
11. The information in the model object FlightListModel must now be made available to component controller of FlightListComp. The easiest way to do this is to open the diagram editor of component FlightListComp. This is done by double clicking on the component name itself. Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel. This will now open the Model Binding window. Select the Bapi_Flight_Getlist_Input model class and drop it directly onto the Context root node. Now the Context Mapping window opens. It is here that we decide which parts of the BAPI’s interface are needed by the component controller. It is at this point that you will need to know which parts of the BAPI interface are used for input, which for output and which are bidirectional. In this case, we are going to use the two scalar parameters Airline and Max_Rows, and the two structured parameters Destination_To and Destination_From. Since the parameters Date_Range, Extension_In, Extension_Out, Flight_List and Return are TABLES parameters, they will appear on both the input and output sides of the interface. We will not be sending any data into the function module via these tables, so they can be omitted from the input side of the interface. However, Flight_List and Return have to be selected at the output side, because we want to display the data the BAPI sends back.
Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel. Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel.
Figure 544:
b)
This will now open the Model Binding window. Select the Bapi_Flight_Getlist_Input model class and drop it directly onto the Context root node.
Figure 545:
c)
Use the two scalar parameters Airline and Max_Rows, and the two structured parameters Destination_To and Destination_From from the input side. Also select Flight_List and Return from the output side. Press OK and then press Finish.
12. The previous step has made the information in the model object available to the component controller. Now we need to make the data available to the view controller. This is done by creating another data link starting at the view controller and going across to the component controller. As in the creation
of the previous data link, you will need to drag the model node from the component controller context across to the view controller context. Select all the nodes in the context hierarchy and then click OK and then Finish. a) Creating another data link starting at the view controller and going across to the component controller
Figure 547:
b)
Select all the nodes in the context hierarchy and then click OK and then Finish.
Figure 548:
13. Now that the model data has been mapped all the way through to the view controller, we can start building the view’s user interface. a) Double click on FlightListView under Web Dynpro Components → FlightListComp → Views. Delete the default TextView UI element.
14. Select the RootUIElementContainer and change its layout property to MatrixLayout a)
15. In the Outline view, right mouse click on RootUIElementContainer and select Insert Child. Add a Tray UI element with the name ParentTray and change the text property of its child Caption UI element to Input Parameters. If you find that your Tray UI element is called something like Tray0 or Tray1, then you can rename it by changing the value of its id property. a) 16. Select the ParentTray UI element from the Outline view and choose Apply Template from the right mouse click menu. Choose the Form template and press Next. Select Max_Rows and Airline from the Template Wizard window and press Finish a) The UI layout should now look like shown on the left
Figure 549:
17. You now need to insert two further Group UI elements as the children of ParentTray. Select the ParentTray UI element in the Outline view and choose Insert Child. Create two child Group UI elements called ChildGroupTo and ChildGroupFrom. a) 18. Each Group UI element has a child Caption UI element. Change the text properties of these child Caption UI elements to To and From respectively a) 19. For each Group UI element, apply a form template to the Group UI element ChildGroupFrom for all the attributes of node Destination_From, and another form template for Group UI element ChildGroupTo for all the attributes of Destination_To. a)
20. Change the layoutData property of ChildGroupFrom to MatrixHeadData a)
Figure 550:
21. Next, select the Actions tab from the view controller editor and create a new Action. Give the Action the name Search and the text Start search. Use the default event handler. Press Finish a)
Figure 551:
In the New Action pop-up window, enter the following values (see left). Press Finish 22. Go back to the Layout tab and insert a Button UI element as a child of the Tray UI element ParentTray. Change its layoutData property to MatrixHeadData and its onAction property to Search. Notice that as soon as the Search action is assigned to the onAction event of the button, the button immediately inherits the text description of the action. a) 23. The last step is to create a table in which the BAPI output results will be displayed. Select the RootUIElementContainer, and select Apply Template from the right mouse-click menu. This time, select a Table template and Continued on next page
press next. Under the Output context node, there will be a child node called FlightList. Select this check box, and all the child attribute checkboxes will be selected automatically. Press Finish and press the Save Metadata button on the toolbar. a)
Figure 552:
Select the RootUIElementContainer, and select Apply Template from the right mouse-click menu. This time, select a Table template and press next. Under the Output context node, there will be a child node called FlightList. Select this check box, and all the child attribute checkboxes will be selected automatically. Press Finish and press the Save Metadata button on the toolbar. This completes the UI layout for view FlightListView. 24. Now we need to add some coding into the component controller. Double click on the Component Controller node underneath FlightListComp in the Web Dynpro Explorer. Select the Implementation tab a) 25. Scroll right down to the bottom of the file, and between the //@@begin others and //@@end comment markers, declare an instance of executable model class called bapiInput, and an instance of the message manager called msgMgr. a) … //@@begin others Bapi_Flight_Getlist_Input bapiInput; IWDMessageManager msgMgr; //@@end
26. Now locate method wdDoInit() and assign the message manager variable to the component’s message manager instance, and assign to the bapiInput object a new instance of the BAPI class. a) public void wdDoInit() { //@@begin wdDoInit() msgMgr = wdComponentAPI.getMessageManager(); bapiInput = new Bapi_Flight_Getlist_Input(); //@@end wdDoInit() }
27. Now create an instance of each of the structure input parameters DESTINATION_TO and DESTINATION_FROM. The class that needs to be instantiated can be found by switching to the Context tab, selecting the corresponding model node, and then looking at the value of the ModelClass property. In this case, the class is Bapisfldst Once these two parameter instances have been created, they must be added as structured parameters to the main bapiInput object The last step for method wdDoInit() is to bind the BAPI input object to the corresponding model node in the component controller’s context a) public void wdDoInit() { //@@begin wdDoInit( .. . Bapisfldst destTo = new Bapisfldst(); Bapisfldst destFrom = new Bapisfldst(); bapiInput.setDestination_To(destTo); bapiInput.setDestination_From(destFrom); wdContext.nodeBapi_Flight_Getlist_Input().bind(bapiInput); //@@end wdDoInit() } 28. Next, it is necessary to add the coding that will call the BAPI. This coding will be placed into its own method, so go to the Methods tab and create a new method. In the pop-up window, select a method type of Method (Don’t select Event Handler, it won’t work!), press Next, and then enter a name of callBAPI and then press Finish a)
29. Go back to the Implementation tab, and locate the callBAPI() method. In this method, the execute() method of the BAPI object must be called from within a try/catch clause. If the execution fails, then a simplistic error message will be issued, otherwise the BAPI’s Output model node needs to be invalidated a) public void callBAPI( ) { //@@begin callBAPI() try { bapiInput.execute(); wdContext.nodeOutput().invalidate(); } catch(Exception e) { wdContext.nodeReturn().invalidate(); String msgText = wdContext .nodeReturn() .currentReturnElement() .getMessage(); if (msgText.length()==0) { msgMgr.raiseException("BAPI call failed", false); } else { msgMgr.raiseException(msgText, false); } } //@@end } 30. Now that the component controller has a separate method for calling the BAPI, this method must be called when the view controller’s action Search is processed. This is done by going back to the Implementation tab of the view controller FlightListView and adding a line of code to method onActionSearch() that calls method callBAPI() in the component controller. a) public void onActionSearch(IWDCustomEvent wdEvent) { //@@begin onActionSearch(ServerEvent) wdThis.wdGetFlightListCompController().callBAPI(); //@@end } Continued on next page
31. The final stage is to create an application called FlightListApp placing it into package com.sap.training.flightlist. a) 32. Save Metadata and do a DC Build. This time, the DC Build screen will show that a dependency exists between DC components and DC models. Since the public part of DC models has not been changed, it is not necessary to rebuild this DC. Therefore, leave the check box against models unchecked. Press OK a) 33. Since the components DC is dependent upon the models DC, it is necessary to deploy the models DC first. Select the root node of the models DC from the Web Dynpro Explorer window and choose Deploy from the right mouse-click menu. If this is the first time you have deployed anything to your J2EE server since starting the NetWeaver Developer Studio, then you will be asked for the SDM password. The default value is sdm a) 34. Now choose FlightListApp from the applications menu, and select Deploy new archive and run from the right mouse-click menu. If you have forgotten to create the two JCo destinations FlightList_Data and FlightList_Metadata, then when you run the application, you will get a Java stack trace. This is due to the fact that the J2EE engine is attempting to use a pair of JCo destinations that have not yet been configured! a)
Figure 553:
Result
After deploying and running the application, you should see results similar to this.
Lesson Summary
You should now be able to: • Create aRFC models that allow to access RFMs from your Web Dynpro application • Explain what kind of JAVA objects are created as a result of generating an aRFC model • Create model objects in a development component, so they can be reused in other Web Dynpro projects • Use aRFC model objects in a Web Dynpro application
Lesson: Configuring SLD and JCo Connections
Lesson Overview
In order to use an aRFC model, the corresponding JCo destinations have to be defined first. JCo destinations point on ABAP based systems, which in turn have to be defined in the System Landscape Directory (SLD) before. This lesson explains the steps incorporated in defining both, technical systems and JCo destinations.
Lesson Objectives
After completing this lesson, you will be able to: • • • • Check the installed software catalog Import a software catalog if necessary Define technical systems in the SLD Define JCo destinations
Business Example
You start your Web Dynpro application, which includes an aRFC model. However, you get a runtime error, since JCo destinations have not been defined yet. Thus, you have to learn, how to create JCo destinations and what other technical preparations have to be made before your application can be started successfully.
Figure 554: Importing and Displaying the Software Catalog
Importing the software catalog is the first step in configuring technical systems in the SLD. The software catalog contains technical information to all possible SAP products and software components. To check, if the technical information for the type of system you want to connect to (to obtain model data) has already been imported, open the software catalog of your SLD: http://<host>:<port>/skl →Link Software Catalog If the SAP product or software component is not displayed, you have to import the newest software catalog to your SLD: http://<host>:<port>/skl →Link Administration →Link Content Import →Button Browse For a standard J2EE Installation, the software catalog is provided by a .zip file, which is located at <root>/usr/sap/<J2EE System Name>/SYS/global/sld/model
Figure 555: Defining Technical Systems (1)
Before any JCo connection can be defined, a new technical system has to be defined in the SLD. A technical system is a logical object, that contains all metadata to a certain SAP system, like the system ID (SID), the names of all application servers, the message server name, logon groups and so on. To define a new technical system, open the following page: http://<host>:<port>/sld → Link Technical Landscape
Proceed as follows: On the first screen press New Technical System. Select Web AS ABAP and press Next. Enter the SID of the SAP system, the installation number and the name of the DB host. After having logged on the SAP system, the installation number can be found on the popup appearing when choosing the menu System →Status. Press Next.
Proceed as follows: Enter the message server host, application server host, the instance number, the message server port and all logon groups. Important: By default, the logon group PUBLIC is entered in the list of logon groups. This does not need to be correct. If none of the allowed logon groups is entered by you in the list of logon groups, you will not be able to set up JCo connections using load balancing. Press Next. On the next screen you can add the name of all application server hosts (and their instance numbers) belonging to the same SAP system. Press Next. Now enter all clients, you want to use with the JCo connections. At least one client has to be defined. Press Next.
Figure 558: Defining Technical Systems (4)
Proceed as follows: Select the technical product, describing your SAP system. This is, where the software catalog imported before comes into play! Check the list of software components. Uncheck all components, that are not installed on your SAP system. Press Finish. Result: A new Technical System has been defined, which can be used to define JCo connections to the underlying SAP system.
At the time a model object is created, the logical system names do not yet need to exist in the J2EE engine. The Web Dynpro application can be fully built and deployed to the J2EE engine before it becomes necessary to create the logical system names. Logical system names are also known as “JCo Destinations”. To define the JCo Destinations, the Web Dynpro Content Administrator Tool is used. The creation of JCo destinations is a one-time configuration process per J2EE engine.
The System Landscape Directory (SLD) Server must be started & configured. Start the Web Dynpro Content Administrator application by entering the URL http://<host>:<port>/webdynpro/welcome → Link Content Administrator You will need to log on with a user id that has administrative authority.
Figure 561: Defining logical system names (2)
It does not matter in which order you do the following steps:
Defining the model object to use a given pair of logical destinations Creating the logical destinations in the J2EE engine What is important is that the logical system names have been successfully created in the J2EE engine before the Web Dynpro application is run. There is no particular standard for JCo destination names, other than following: Do not hard code the SAP system name Use a name that describes the type business information being used. All JCo destinations for all deployed applications will be listed in this screen. The red icon indicates that the JCo destination is required by an application, but has not yet been defined. Click on the link named Create in order to set up the JCo Destination.
Figure 562: Defining logical system names (3)
Step 1: Enter the client of the system, the JCo connection is pointing to Press Next. Maximum Pool Size: The parameter Pool Size is used to specify how many connections should be left open for the current user, even if they are not being used actively. A pooled RFC connection is allocated much faster than a new connection, therefore, increasing the pool size will optimize the time needed to get a new connection. On the other hand, if a connection is pooled, it is not available for other users. Maximum Connections: Maximum amount of connections per user. This needs to be determined for each Application Data destination (also called logical system). Connection Timeout: Defines how long the pool waits (in seconds) before a destination, which is in the range between 1 and the maximum pool size, is closed by the pool. This allows closing pooled connections after a certain amount of time, if the user is no longer active. A typical value here is 10 - 30 seconds.
Maximum Wait Time: Defines how long you can wait (in seconds) before you get an exception after trying to get an destination although the maximum destinations are open. In a high user load scenario, it makes sense to increase this number appropriately (20-60), in low user load scenarios, this number can typically be reduced to a very low number (1-5 seconds).
Figure 563: Defining logical system names (4)
Step 2: Select which J2EE cluster you wish the JCo destination to be assigned. Press Next. Step 3: Select the connection type Application Data or Dictionary Meta Data. When Application Data is selected, you can choose between direct connection to a distinct application server of the technical system or using load balancing. When Dictionary Meta Data is selected, load balancing is pre-selected and can not be changed. Press Next.
Step 4.1 / 4.2: You may only select Servers and / or Logon Groups from the drop down list that have first been defined as technical Systems in the SLD. Press Next. Message Server The SAP system to which Application Data JCo destination is connected must have at least one logon group defined! If this has not been done, then you will be unable to proceed beyond this screen. If your SAP has no logon groups, then use transaction SMLG in the SAP system to create one.
If you select a connection type of Application Data, then when you get to the Security screen, you will have a choice of 4 different user authentication techniques: User/Password Client Certificate (X.509) Ticket (SSO2 Cookie) User Mapping (Requires the use of the User Mapping Engine in the J2EE engine) For development and testing scenarios, it is acceptable to use the User/Password authentication method. However, for productive use, you should always choose a method that allows user specific authorisations to be employed within SAP. This will help provide an application level audit trail of user activity. If you select User/Password for you productive system, then all users using this JCo connection will appear to be the same user within SAP. Thus, you will loose any audit trail capability. Step 5 (Dictionary Meta Data): If you select a connection type of Dictionary Metadata, then when you get to the Security screen, you will only be able to use a named user id and password for connection to the SAP system. This is because no audit trail is required for the transfer of metadata. Therefore, the same user id (SAP user is of type SYSTEM) can be used irrespective of the identity of the end user. Press Next.
Figure 566: Defining logical system names (7)
Step 6: Check your configuration data on the Summary screen. Press Finish. The icon next to the JCo destination now turns green.
Finally, press the Test button to ensure that your JCO connection works. You must scroll to the bottom of the browser window to see the success/failure message. Important: You must repeat this process for the second JCo destination! Once both JCo destinations have been successfully created, you are ready to run your Web Dynpro application.
Exercise 19: Configure SLD and JCo Destinations
Exercise Objectives
After completing this exercise, you will be able to: • Display the Software Catalog • Import a Software Catalog, if necessary • Define Technical Systems • Define Logical System Names (JCo Destinations)
Business Example
You have created a Web Dynpro application, which accesses an RFM by using an aRFC model object. The ABAP system is referred to by logical system names, that are stored with the model object. However, these logical system names have not been mapped yet to a real ABAP system. In order to do this, you have to define JCo destinations. When doing this, you will be asked for a technical description for the system. This information has to be defined before in the SLD.
Task 1:
Development Objectives This exercise has the following objectives: - Separate Web Dynpro Model objects and Components in different Development Components. - Use the functionality defined in one development component within another development component. - Use the aRFC model object to call a function module in an SAP system and then display the results. The aRFC model object will be created in a development component (DC) called “models”. This DC will expose the model object functionality via its public part. There will then be a second web Dynpro DC called “components” that makes use of the models DC. Thus, we can separate model objects from the Web Dynpro components that use them. This improves the overall application architecture, and helps reduce the Java compile time. Result The result of this exercise will be that you have an application that will call JA310_WD_Ex10 using parameters supplied on the input screen. Continued on next page
The results of the BAPIs execution will be displayed in a table.
Figure 567:
Template Solution: Development Component containing Model: Development Component containing WD Application: WD Project: Application: Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. JA310_Models JA310_Components Ex10Comp Ex10App
Task 2:
Overview: Developing 1. Create a new Web Dynpro Development Component called models. Select File → New → Development Component Project, then select Local Development → MyComponents from the tree structure. Enter a vendor name of training.sap.com. The Name of the Development Component must be specified in lower case letters; enter models here. Enter some descriptive caption and select Web Dynpro from the Type tree.
Repeat exactly the same DC creation process, but now, call the DC components. It is vitally important that you are consistent with the language in which all your DCs are created. DCs of different languages will not interact with each other correctly. Open the models DC hierarchy, and select Create Model from the right mouse click menu under Web Dynpro → Models. Select Import Adaptive RFC Model and then press Next. Remember that the model name should end in the word Model, and that each model object must live in its own package. In the screen, enter FlightListModel as the model name, and com.sap.training.models.flightlist as the model package name. The logical system names (JCo Destinations) entered here do not yet need to exist in the J2EE engine. Remember that the logical system names should not contain the name of the system from which you are obtaining the data. Rather, they should describe the type of data being obtained. The Logical Dictionary name should be allowed to default to the same name as the model object. Specify the name of the SAP system you wish to connect to. Your instructor will be able to supply the connection details for you. Press Next. Enter bapi_flight* in the Function Name field and press the search button. Tick the checkbox next to BAPI_FLIGHT_GETLIST and press Next. The Model wizard will now extract the details of the function module’s interface and present you with a log file. Press Finish. All that is necessary to complete the models DC is to add the model object FlightListModel to the DC’s public part. In order to do this, right mouse click on the model object name FlightListModel, and select New Public Part. Since this is the very first public part defined for this DC, we must specify the name of the public part to which this model object will be added. Enter a public part name of FlightListModel and press Finish. The last step needed for the models DC is to build the entire project, and then to perform a DC build. It is most important that a DC Build is performed, otherwise, the DC’s public parts (which are each separate JAR files) will not be constructed properly. Firstly, click on the entire models DC, and select Rebuild Project. This will only take a few seconds. Now right mouse click again on the DC name and select Build from the Development Component side menu. Since development components can declare the use of other development components, it is possible that a set of dependencies can exist between these DCs. This particular case, the models has no dependencies on any other DCs, so this next screen only shows a list of one DC. Select OK. Now open the following branch in the components DC: DC MetaData → DC Definition → Used DCs. At the moment, the components DC only requires the use of standard Web Dynpro DCs. You must add to this list and declare that the models DC is also a Used DC. Right mouse click on Used DCs and select Add Used DC. Expand the branch LocalDevelopments → MyComponents and select models. Continued on next page
Press Finish. Now all the public parts of DC models are accessible within the DC components. 9. In the components DC, open the Web Dynpro branch of the hierarchy, and create a new Web Dynpro Component called FlightListComp. Use a package name of com.sap.training.flightlist and don’t forget to remove the characters Comp from the view name.
10. In the Used Models node of component FlightList, add the usage of model FlightListModel. 11. The information in the model object FlightListModel must now be made available to component controller of FlightListComp. The easiest way to do this is to open the diagram editor of component FlightListComp. This is done by double clicking on the component name itself. Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel. This will now open the Model Binding window. Select the Bapi_Flight_Getlist_Input model class and drop it directly onto the Context root node. Now the Context Mapping window opens. It is here that we decide which parts of the BAPI’s interface are needed by the component controller. It is at this point that you will need to know which parts of the BAPI interface are used for input, which for output and which are bidirectional. In this case, we are going to use the two scalar parameters Airline and Max_Rows, and the two structured parameters Destination_To and Destination_From. Since the parameters Date_Range, Extension_In, Extension_Out, Flight_List and Return are TABLES parameters, they will appear on both the input and output sides of the interface. We will not be sending any data into the function module via these tables, so they can be omitted from the input side of the interface. However, Flight_List and Return have to be selected at the output side, because we want to display the data the BAPI sends back. 12. The previous step has made the information in the model object available to the component controller. Now we need to make the data available to the view controller. This is done by creating another data link starting at the view controller and going across to the component controller. As in the creation of the previous data link, you will need to drag the model node from the component controller context across to the view controller context. Select all the nodes in the context hierarchy and then click OK and then Finish. 13. Now that the model data has been mapped all the way through to the view controller, we can start building the view’s user interface. Double click on FlightListView under Web Dynpro Components → FlightListComp → Views. Delete the default TextView UI element. 14. Select the RootUIElementContainer and change its layout property to MatrixLayout. Continued on next page
15. In the Outline view, right mouse click on RootUIElementContainer and select Insert Child. Add a Tray UI element with the name ParentTray and change the text property of its child Caption UI element to Input Parameters. If you find that your Tray UI element is called something like Tray0 or Tray1, then you can rename it by changing the value of its id property. 16. Select the ParentTray UI element from the Outline view and choose Apply Template from the right mouse click menu. Choose the Form template and press Next. Select Max_Rows and Airline from the Template Wizard window and press Finish. 17. You now need to insert two further Group UI elements as the children of ParentTray. Select the ParentTray UI element in the Outline view and choose Insert Child. Create two child Group UI elements called ChildGroupTo and ChildGroupFrom. 18. Each Group UI element has a child Caption UI element. Change the text properties of these child Caption UI elements to To and From respectively. 19. For each Group UI element, apply a form template to the Group UI element ChildGroupFrom for all the attributes of node Destination_From, and another form template for Group UI element ChildGroupTo for all the attributes of Destination_To. 20. Change the layoutData property of ChildGroupFrom to MatrixHeadData. 21. Next, select the Actions tab from the view controller editor and create a new Action. Give the Action the name Search and the text Start search. Use the default event handler. Press Finish. 22. Go back to the Layout tab and insert a Button UI element as a child of the Tray UI element ParentTray. Change its layoutData property to MatrixHeadData and its onAction property to Search. Notice that as soon as the Search action is assigned to the onAction event of the button, the button immediately inherits the text description of the action. 23. The last step is to create a table in which the BAPI output results will be displayed. Select the RootUIElementContainer, and select Apply Template from the right mouse-click menu. This time, select a Table template and press next. Under the Output context node, there will be a child node called FlightList. Select this check box, and all the child attribute checkboxes will be selected automatically. Press Finish and press the Save Metadata button on the toolbar. 24. Now we need to add some coding into the component controller. Double click on the Component Controller node underneath FlightListComp in the Web Dynpro Explorer. Select the Implementation tab.
Scroll right down to the bottom of the file, and between the //@@begin others and //@@end comment markers, declare an instance of executable model class called bapiInput, and an instance of the message manager called msgMgr.
Solution 19: Configure SLD and JCo Destinations
Task 1:
Development Objectives This exercise has the following objectives: - Separate Web Dynpro Model objects and Components in different Development Components. - Use the functionality defined in one development component within another development component. - Use the aRFC model object to call a function module in an SAP system and then display the results. The aRFC model object will be created in a development component (DC) called “models”. This DC will expose the model object functionality via its public part. There will then be a second web Dynpro DC called “components” that makes use of the models DC. Thus, we can separate model objects from the Web Dynpro components that use them. This improves the overall application architecture, and helps reduce the Java compile time. Result The result of this exercise will be that you have an application that will call JA310_WD_Ex10 using parameters supplied on the input screen. The results of the BAPIs execution will be displayed in a table.
Template Solution: Development Component containing Model: Development Component containing WD Application: WD Project: Application: Prerequisites You have launched the SAP NetWeaver Developer Studio. You have selected the Web Dynpro perspective. JA310_Models JA310_Components Ex10Comp Ex10App
Task 2:
Overview: Developing 1. Create a new Web Dynpro Development Component called models. Select File → New → Development Component Project, then select Local Development → MyComponents from the tree structure. a) Select File → New → Development Component Project, then select Local Development → MyComponents from the tree structure. Press Next.
Enter a vendor name of training.sap.com. The Name of the Development Component must be specified in lower case letters; enter models here. Enter some descriptive caption and select Web Dynpro from the Type tree. a) The Name of the Development Component must be specified in lower case letters; enter models here. Enter some descriptive caption and select Web Dynpro from the Type tree. Press Next then Finish.
Figure 570:
3.
Repeat exactly the same DC creation process, but now, call the DC components. It is vitally important that you are consistent with the language in which all your DCs are created. DCs of different languages will not interact with each other correctly. a) Repeat step 4-2 giving the component the name components. You should now have two Web Dynpro DCs and your workspace should look like this:
Figure 571:
4.
Open the models DC hierarchy, and select Create Model from the right mouse click menu under Web Dynpro → Models. Select Import Adaptive RFC Model and then press Next. Remember that the model name should end in the word Model, and that each model object must live in its own package. In the screen, enter FlightListModel as the model name, and Continued on next page
com.sap.training.models.flightlist as the model package name. The logical system names (JCo Destinations) entered here do not yet need to exist in the J2EE engine. Remember that the logical system names should not contain the name of the system from which you are obtaining the data. Rather, they should describe the type of data being obtained. The Logical Dictionary name should be allowed to default to the same name as the model object. a) Open the models DC hierarchy, and select Create Model from the right mouse click menu under Web Dynpro → Models. Select Import Adaptive RFC Model and then press Next. Remember that the model name should end in the word Model, and that each model object must live in its own package. In the screen, enter FlightListModel as the model name, and com.sap.training.models.flightlist as the model package name.
Figure 572:
5.
Specify the name of the SAP system you wish to connect to. Your instructor will be able to supply the connection details for you. Press Next. Enter bapi_flight* in the Function Name field and press the search button. Tick
the checkbox next to BAPI_FLIGHT_GETLIST and press Next. The Model wizard will now extract the details of the function module’s interface and present you with a log file. Press Finish. a) Enter bapi_flight* in the Function Name field and press the Search button. You should see some search results similar to the image on the left. Tick the checkbox next to BAPI_FLIGHT_GETLIST and press Next. The Model wizard will now extract the details of the function module’s interface and present you with a log file. Press Finish.
Figure 573:
The Model wizard creates an XML description of the RFM’s interface. After pressing Finish, you will notice that the IDE now spends a few seconds generating the actual Java source code. Your models DC should now as displayed on the left:
All that is necessary to complete the models DC is to add the model object FlightListModel to the DC’s public part. In order to do this, right mouse click on the model object name FlightListModel, and select New Public Part. Since this is the very first public part defined for this DC, we must specify the name of the public part to which this model object will be added. Enter a public part name of FlightListModel and press Finish. a) Right mouse click on the model object name FlightListModel, and select New Public Part. Since this is the very first public part defined for this DC, we must specify the name of the public part to which this model object will be added. Enter a public part name of FlightListModel and press Finish. Now that this has been done, you will see the FlightListModel listed as an Entity belonging to the public part called FlightListModel.
The last step needed for the models DC is to build the entire project, and then to perform a DC build. It is most important that a DC Build is performed, otherwise, the DC’s public parts (which are each separate JAR files) will not be constructed properly. Firstly, click on the entire models DC, and select Rebuild Project. This will only take a few seconds. Now right mouse click again on the DC name and select Build from the Development Component side menu. Since development components can declare the use of other development components, it is possible that a set of dependencies can exist between these DCs. This particular case, the models has no dependencies on any other DCs, so this next screen only shows a list of one DC. Select OK. a) Firstly, click on the entire models DC, and select Rebuild Project. This will only take a few seconds. Now right mouse click again on the DC name and select Build from the Development Component side menu. Since development components can declare the use of other development components, it is possible that a set of dependencies can exist between these DCs. This particular case, the models has no dependencies on any other DCs, so this next screen only shows a list of one DC. Check models and press OK. The DC build process takes around 30 seconds to complete the first time it runs.
Figure 577:
Figure 578:
The models DC is now complete. Continued on next page
Now open the following branch in the components DC: DC MetaData → DC Definition → Used DCs. At the moment, the components DC only requires the use of standard Web Dynpro DCs. You must add to this list and declare that the models DC is also a Used DC. Right mouse click on Used DCs and select Add Used DC. Expand the branch LocalDevelopments → MyComponents and select models. Press Finish. Now all the public parts of DC models are accessible within the DC components. a) Now open the following branch in the components DC: DC MetaData → DC Definition → Used DCs. At the moment, the components DC only requires the use of standard Web Dynpro DCs. You must add to this list and declare that the models DC is also a Used DC. Right mouse click on Used DCs and select Add Used DC. Expand the branch LocalDevelopments → MyComponents and select models. Press Finish.
Figure 579:
Now all the public parts of DC models are accessible within DC components.
In the components DC, open the Web Dynpro branch of the hierarchy, and create a new Web Dynpro Component called FlightListComp. Use a package name of com.sap.training.flightlist and don’t forget to remove the characters Comp from the view name. a) Use a package name of com.sap.training.flightlist and don’t forget to remove the characters Comp from the view name.
10. In the Used Models node of component FlightList, add the usage of model FlightListModel. a) If you cannot see FlightListModel when you try to add a used model to component FlightListComp, then one of the following problems could exist: You have not exposed the model object FlightListModel correctly through a public part of DC models. You have forgotten to build the public part of DC models. DC components does not have a correct usage declaration for DC models.
Figure 582:
11. The information in the model object FlightListModel must now be made available to component controller of FlightListComp. The easiest way to do this is to open the diagram editor of component FlightListComp. This is done by double clicking on the component name itself. Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel. This will now open the Model Binding window. Select the Bapi_Flight_Getlist_Input model class and drop it directly onto the Context root node. Now the Context Mapping window opens. It is here that we decide which parts of the BAPI’s interface are needed by the component controller. It is at this point that you will need to know which parts of the BAPI interface are used for input, which for output and which are bidirectional. In this case, we are going to use the two scalar parameters Airline and Max_Rows, and the two structured parameters Destination_To and Destination_From. Since the parameters Date_Range, Extension_In, Extension_Out, Flight_List and Return are TABLES parameters, they will appear on both the input and output sides of the interface. We will not be sending any data into the function module via
these tables, so they can be omitted from the input side of the interface. However, Flight_List and Return have to be selected at the output side, because we want to display the data the BAPI sends back. a) Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel. Select the Create a data link button from the diagram editor’s tool bar, and starting at the Component Controller, drag a line to the model object FlightListModel.
Figure 583:
This will now open the Model Binding window. Select the Bapi_Flight_Getlist_Input model class and drop it directly onto the Context root node.
Figure 584:
Use the two scalar parameters Airline and Max_Rows, and the two structured parameters Destination_To and Destination_From from the input side. Also select Flight_List and Return from the output side. Press OK and then press Finish. Continued on next page
12. The previous step has made the information in the model object available to the component controller. Now we need to make the data available to the view controller. This is done by creating another data link starting at the view controller and going across to the component controller. As in the creation
of the previous data link, you will need to drag the model node from the component controller context across to the view controller context. Select all the nodes in the context hierarchy and then click OK and then Finish. a) Creating another data link starting at the view controller and going across to the component controller.
Figure 586:
Select all the nodes in the context hierarchy and then click OK and then Finish.
Figure 587:
13. Now that the model data has been mapped all the way through to the view controller, we can start building the view’s user interface. Double click on FlightListView under Web Dynpro Components → FlightListComp → Views. Delete the default TextView UI element. a) 14. Select the RootUIElementContainer and change its layout property to MatrixLayout. a)
15. In the Outline view, right mouse click on RootUIElementContainer and select Insert Child. Add a Tray UI element with the name ParentTray and change the text property of its child Caption UI element to Input Parameters. If you find that your Tray UI element is called something like Tray0 or Tray1, then you can rename it by changing the value of its id property. a) 16. Select the ParentTray UI element from the Outline view and choose Apply Template from the right mouse click menu. Choose the Form template and press Next. Select Max_Rows and Airline from the Template Wizard window and press Finish. a) The UI layout should now look like shown on the left.
Figure 588:
17. You now need to insert two further Group UI elements as the children of ParentTray. Select the ParentTray UI element in the Outline view and choose Insert Child. Create two child Group UI elements called ChildGroupTo and ChildGroupFrom. a) 18. Each Group UI element has a child Caption UI element. Change the text properties of these child Caption UI elements to To and From respectively. a) 19. For each Group UI element, apply a form template to the Group UI element ChildGroupFrom for all the attributes of node Destination_From, and another form template for Group UI element ChildGroupTo for all the attributes of Destination_To. a)
20. Change the layoutData property of ChildGroupFrom to MatrixHeadData. a)
Figure 589:
21. Next, select the Actions tab from the view controller editor and create a new Action. Give the Action the name Search and the text Start search. Use the default event handler. Press Finish. a) In the New Action pop-up window, enter the following values (see left). Press Finish.
Figure 590:
22. Go back to the Layout tab and insert a Button UI element as a child of the Tray UI element ParentTray. Change its layoutData property to MatrixHeadData and its onAction property to Search. Notice that as soon as the Search action is assigned to the onAction event of the button, the button immediately inherits the text description of the action. a) 23. The last step is to create a table in which the BAPI output results will be displayed. Select the RootUIElementContainer, and select Apply Template from the right mouse-click menu. This time, select a Table template and press next. Under the Output context node, there will be a child node called Continued on next page
FlightList. Select this check box, and all the child attribute checkboxes will be selected automatically. Press Finish and press the Save Metadata button on the toolbar. a) Select the RootUIElementContainer, and select Apply Template from the right mouse-click menu. This time, select a Table template and press next. Under the Output context node, there will be a child node called FlightList. Select this check box, and all the child attribute checkboxes will be selected automatically.
Figure 591:
Press Finish and press the Save Metadata button on the toolbar. This completes the UI layout for view FlightListView. 24. Now we need to add some coding into the component controller. Double click on the Component Controller node underneath FlightListComp in the Web Dynpro Explorer. Select the Implementation tab. a) 25. Scroll right down to the bottom of the file, and between the //@@begin others and //@@end comment markers, declare an instance of executable model class called bapiInput, and an instance of the message manager called msgMgr. a) //@@begin others Bapi_Flight_Getlist_Input bapiInput; IWDMessageManager msgMgr; //@@end
Lesson Summary
You should now be able to: • Check the installed software catalog • Import a software catalog if necessary • Define technical systems in the SLD • Define JCo destinations
Unit Summary
You should now be able to: • Understand the background technology for the adaptive RFC (aRFC) layer • Understand the basic requirements of a remote function callable ABAP function module (RFM) • Create aRFC models that allow to access RFMs from your Web Dynpro application • Explain what kind of JAVA objects are created as a result of generating an aRFC model • Create model objects in a development component, so they can be reused in other Web Dynpro projects • Use aRFC model objects in a Web Dynpro application • Check the installed software catalog • Import a software catalog if necessary • Define technical systems in the SLD • Define JCo destinations
Unit 12
Visualising the Java Web Dynpro through the SAP Portal
Unit Overview Unit Objectives
After completing this unit, you will be able to: • • • • • • • • • Create an iView from the Web Dynpro Application. Enable communication between iViews using Portal Eventing and Java Web Dynpro. Understand Absolute, Relative, Object-based Navigation, WorkProtect and the Portal theme using Java Web Dynpro. Build a WebDynpro IView Create an iView from the Web Dynpro Application. Communication between iViews using Portal Eventing is achieved using the raise, subscribe and unsubscribe methods with Java Web Dynpro. Absolute, Relative, Object-based Navigation can easily be coded for the portal in Java Web Dynpro. WorkProtect can be used to prevent losing unsaved data in the Portal using Java Web Dynpro. The Portal theme can be utilised or overwritten using Java Web Dynpro.
Unit Contents
Lesson: Introduction ............................................................522 Lesson: Creating a Web Dynpro iView.......................................525 Lesson: Portal Eventing, Navigation and WorkProtect ....................531 Exercise 20: Creating and using Portal Eventing with Java Web Dynpro .......................................................................539
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
Lesson: Introduction
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • • • Create an iView from the Web Dynpro Application. Enable communication between iViews using Portal Eventing and Java Web Dynpro. Understand Absolute, Relative, Object-based Navigation, WorkProtect and the Portal theme using Java Web Dynpro.
Business Example
Introduction: SAP Portal and Java WD • • Java Web Dynpro is used to create interactive Web-based user interfaces for specific business applications. The SAP Enterprise Portal allows the role-based and secure access to different kinds of information, services and applications using a Web Browser
The SAP Enterprise Portal and Web Dynpro are both the strategic user interface technologies of SAP and are based on the SAP Web Application Server. The SAP Enterprise Portal supports the WD application development with functions like: • • • Event handling of portal events Navigation between any portal content WorkProtect mode.
Ways to Integrate Web Dynpros into the Portal 1. 2. 3. 4. 5. Create a Web Dynpro iView with a Template Access Web Dynpro Admin tools Configure Client Side Eventing Create Single Sign on between Portal, WD and the back-end applications Prevent loss of data using WorkProtect mode.
Create a Web Dynpro iView by using the standard delivered iView.
By using Web Dynpro administration tools: the Web Dynpro Content Administrator for Portal content administration. Client Side Eventing can be configured between Web Dynpro Applications (ABAP WD or/and Java WD) to other Portal Content Single Sign on can be created between the Portal, Web Dynpro and back-end applications By using the WorkProtect mode in the Web Dynpro Application to prevent data loss in the Portal.
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
Lesson Summary
You should now be able to: • Create an iView from the Web Dynpro Application. • Enable communication between iViews using Portal Eventing and Java Web Dynpro. • Understand Absolute, Relative, Object-based Navigation, WorkProtect and the Portal theme using Java Web Dynpro.
Lesson: Creating a Web Dynpro iView
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • Build a WebDynpro IView
Business Example
Figure 592: Creating Web Dynpro based Portal Content 1
Create a folder to structure the Web Dynpro-based portal content and ensure that the portal application has been deployed onto the server. Create a Single Full Page iView by following the menu Content Administration → Portal Content → (Folder). Use the context menu and select New iView.
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
Figure 593: Creating Web Dynpro Based Portal Content 2
Choose the iView type. Select the option “Create a single full-page iView from each application variant”. iView types: Single full-page iView: The Web Dynpro application becomes a single iView. Single full-page iViews can be personalised and can use services from the service factory, but the portal will know nothing of the internal strucure of the application. Multiple iViews: The Web Dynpro application is divided into several iViews. Multiple iViews are necessary when the application has to provide role-based or end-user based customising of the layout or when features, for instance printing, should only be provided for certain parts of the application.
Figure 594: Creating Web Dynpro Based Portal Content 3
Modify the iView properties if needed. The generic iView settings, e.g. iView name or the technical iView name, can be changed. An optional task allows you to create a Web Dynpro page with the single full-page iView.
Figure 595: Creating Web Dynpro Based Portal Content 4
Select finish to create the view – you will be shown a summary of the created portal objects.
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
By opening the iView for testing, it allows the user to enter a variety of properties specific to Web Dynpro.
Figure 596: Web Dynpro iView Specific Properties
The property “Show Debug Screen” enables the definition of your Web Dynpro iView so that the SAP Application Integrator displays the relevant debug information when the Web Dynpro Application starts. Please note that this Yes / No setting in the iView is used only if ‘on demand’ has been selected as a global setting. This means that this property determines which Web Dynpro iViews will allow the SAP Application Integrator to display the debug information. The advantage is that this will not affect other Web Dynpro iViews without this setting. This is an improvement on the global debugging. In the future debugging will be permitted on a specific user. The property “Hand over Portal Stylesheet” is also a Yes / No setting. If you have selected “Yes”, this will cause the Web Dynpro Application, when started within the Portal environment, to use the selected Portal theme. In other words, the Web Dynpro will have the same ‘look and feel’ as the Portal. Problems could occur if you don’t run your Web Dynpro application directly on the SAP NetWeaver Portal installation, but on a different installation. The two installations could contain different versions of the selected portal theme. In these cases you could prevent the transfer of the portal theme for individual iViews via the Hand over Portal Stylesheet property. The theme from the portal can be suppressed and ignored by the entire Web Dynpro runtime environment and a specific theme can be configured to be used for the display of you Web Dynpro applications. The property ‘Don’t forward these Parameters to Web Dynprp’ enables you to define explicitly which transfer parameters for a Web Dynpro iView are not to be forwarded to the Web Dynpro application. Examples are parameters like ClientWindowID, Command, DebugSet etc.
The size of the Web Dynpro iView can be set by selecting appearance -> size property category. A fixed size or an automatic sizing can be selected. It is recommended that the automatic sizing is adopted to ensure that no space is wasted and the correct size will be displayed even if the Web Dynpro component is changed in size. The Web Dynpro iView is different to other iView types, as the height of the is adapted after each user interaction.
Figure 597: Testing the Web Dynpro iView
Testing the iView can quickly be achieved by using the Preview button. The iView could also be placed into a page, assigned to a role which has been assigned as an entry point and displayed within the Portal area.
Lesson: Portal Eventing, Navigation and WorkProtect
Lesson: Portal Eventing, Navigation and WorkProtect
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • • • • • Create an iView from the Web Dynpro Application. Communication between iViews using Portal Eventing is achieved using the raise, subscribe and unsubscribe methods with Java Web Dynpro. Absolute, Relative, Object-based Navigation can easily be coded for the portal in Java Web Dynpro. WorkProtect can be used to prevent losing unsaved data in the Portal using Java Web Dynpro. The Portal theme can be utilised or overwritten using Java Web Dynpro.
Business Example
Figure 598: Portal Eventing using Java Web Dynpro.
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
Please note that it may be advisable not to use Portal Eventing when communications are on a frequent basis between Java Web Dynpro iViews. It would be better to implement a “full-screen” Web Dynpro application containing all the relevant components. The communication between iViews is based on EPCF that uses JavaScript to allow iView communication and also provides an API for the Portal application developer. Web Dynpro applications have to use a set of Java Wrapper methods to implement client-side eventing. All Portal servers and servers that are used must be in the same domain when EPCF is used.
Figure 599: Raising a Portal Event
The first parameter – the namespace and the second parameter – the event name must be unique to your event. The Third parameter is the Web Dynpro action that is mapped to the portal event. The event handler is called when the Web Dynpro application receives the specified portal event on the client. The Web Dynpro HTML Client handles the mapping between a portal event and a Web Dynpro action and is absolutely transparent for the Web Dynpro application developer. The Web Dynpro action can be reused for several Portal events. If you want to receive the transported data of the portal event, you can define the following parameters for your Web Dynpro action: dataObject – contains the parameter of the portal event, Namespace – contains the name space of the received portal event and Name – contains the name of the received portal event. You can fire a portal event at any time in your Web Dynpro application. The event is transported with the next response to the client. More than one portal event can be raised in a request- response cycle.
Lesson: Portal Eventing, Navigation and WorkProtect
Figure 600: Subscribing to an Event in Java Web Dynpro.
If a number of parameters need to be passed – need the EventHelper help class which allows multiple parameters to be bundled and read out. The EventHelper help class is part of the Utils public part of the tc~utils development component. The Web Dynpro application is registered as an event listener via the subscribe() method which should be called from the view controller and normally in the wdDoInit() method. To access any event parameters that may have been transferred, a dataObject parameter of the type String must be declared for the specified action.
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
Figure 601: Unsubscribing to an Event in Java Web Dynpro.
The unsubscribe() method of the WDPortalEventing help class is used to deregister the Web Dynpro application from a particular portal event. Please ensure that every single Web Dynpro view is unsubscribed, as the subscription and unsubscription is valid only for the current view. Absolute Navigation
Lesson: Portal Eventing, Navigation and WorkProtect
There could be a number of problems with Absolute navigation, especially when the target is moved to a new location. Object based navigation and relative navigation are a lot more stable and reliable. It would be a good decision to make the target addresses configurable by using the WDConfiguration service
Figure 603: Relative Navigation
Relative addressing for example if you want to navigate between two portal pages that are both defined in the same directory in the PCD. The relative addresses continue to remain the same even if the entire directory is moved within the PCD. To trigger relative navigation, use one of the navigateRelative() methods of the WDPortalNavigation utility class.
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
Figure 604: Object Based Navigation
Object-based navigation (OBN) enables developers to specify navigation based on business objects and operations, without identifying a specific navigation target. Portal administrators can later assign specific navigation targets to these business objects and operations.
Figure 605: WorkProtect with Java Web Dynpro
To avoid losing unsaved data when navigating to another iView, the portal provides a WorkProtect mode that, when activated, provides the user an opportunity to save any changes before navigating.
Lesson: Portal Eventing, Navigation and WorkProtect
Figure 606: Setting the Theme to the Web Dynpro Theme
Web Dynpro applications in the portal automatically use the currently selected portal theme, and any user or role-based personalization of the theme. If the portal and a Web Dynpro application in the portal are running on different systems with different releases, style sheet compatibility problems can occur when the portal version is older than the Web Dynpro runtime. In such cases, the problem can be solved by having the Web Dynpro application use the Web Dynpro theme. You can set the default Web Dynpro theme by modifying the sap.theme.default property, which is also located in the Propertysheet default folder.The following is an example of a valid URL: http://localhost:50000/irj/portalapps/com.sap.portal.themes.lafservice/themes/portal/sap_chrome.
Lesson: Portal Eventing, Navigation and WorkProtect
Exercise 20: Creating and using Portal Eventing with Java Web Dynpro
Exercise Objectives
After completing this exercise, you will be able to: •
Business Example Task:
1. Create a new Web Dynpro project the same as the first exercise: WD_Events_XX where XX is your student number or continue working with WD01_Basics_XX. Navigate to the RootUIElementContainer and insert a child element. Select a button type and use your own ID. Press finish Add a text for your button e.g. Sporting Event. Create an Event. Create the Action with the name SportButtonClicked. Press Finish. Repeat steps 2, 3, 4 and 5 to create a new button. Change the layout of the RootUIElementContainer from FlowLayout to MatixLayout and the Sporting Event Button to MatrixHeadData to ensure a neater display. Raise the EPCF event by adding the code into the View Controllers Implementation in the methods starting with onActionSportButtonClicked then onActionConcertButtonClicked. Right click to organise imports to remove the error.
2. 3. 4. 5. 6. 7.
8.
9.
10. Repeat the step for the concert method. No need to organise imports. (Also we could have changed the event name rather than passing the parameters concert and sport.) 11. Deploy the changed project and run. The fire event Web Dynpro should look like this. 12. Create a new Web Dynpro project that will subscribe to this event. 13. Call the Project WD01_Subscribe_XX where XX is your student number. Press Finish to create. Continued on next page
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
14. Create a Web Dynpro Component. 15. Enter the Component Name e.g. SubscribingWD and enter a Package e.g. com.sap.training. Name the view e.g. SubscribeView. Press finish. 16. Double click the SubscribeView. Press the Context tab to display the Context. 17. Create a new Value Node by using the context menu and selecting Value Node. 18. Give the Value Node a name e.g. Eventing. Please ensure that the cardinality is 1:1 for the Value node. Complete by pressing finish. 19. Create a new Value Attribute. 20. Give the Value Attribute the name Text. Finish. 21. Now for the important part. We will create an Action. This Action will be called by the subscribe event when the event is raised / fired. Press Action tab – then New. Enter the name e.g. ConcertorSport and some text. NB press Next not finish as we need to enter the parameters. 22. Create three parameters by pressing New. dataObject, name and namespace, all type string. 23. Navigate to the View Controller implementation tab. Scroll down the code until the wdDoInit is reached. Please ensure that some text is defaulted into the text that will appear on the screen. Access the node, then it’s element and set it’s text.
IEventingNode node = wdContext.nodeEventing(); IEventingElement elem = node.currentEventingElement(); elem.setText("Start Value");
24. Enter the Subscribe method to listen for the event when raised / fired from the other Web Dynpro project. Please use your editor to find your method after wdThis.
WDPortalEventing.subscribe( "urn:com.sap.tc.webdynpro.test", "TestWDEvent", wdThis.wdGetConcertorSportAction());
25. Enter the code that will analyse the parameter passed. This is placed into the method called when an event is raised.
if (dataObject.equals("sport")) { IEventingNode node = wdContext.nodeEventing();
Lesson: Portal Eventing, Navigation and WorkProtect
IEventingElement elem = node.currentEventingElement(); elem.setText("You have chosen to attend a sporting event."); } else if (dataObject.equals("concert")) { IEventingNode node = wdContext.nodeEventing(); IEventingElement elem = node.currentEventingElement(); elem.setText("You would prefer a concert."); } else { IEventingNode node = wdContext.nodeEventing(); IEventingElement elem = node.currentEventingElement(); elem.setText("Parameter not sport or concert, maybe surfing?"); }
Remember to save. 26. Create a new textView to hold the changed Text. Finish. 27. Change the RootUIElementContainer to MatrixLayout. Change the new TextView to design of header1, Layout of MatrixHeadData. Please select the drop down select Text from the Value Attribute in the Context. 28. Select Text. 29. Create an Application and deploy to the portal server. 30. Result should look like the following: 31. Create an iView from both of these and display them on a page. The results show the initial values. No button has been selected. The second shows that a sporting event button has been selected. The third shows that Rock concert event button has been selected.
Lesson: Portal Eventing, Navigation and WorkProtect
Solution 20: Creating and using Portal Eventing with Java Web Dynpro
Task:
1. Create a new Web Dynpro project the same as the first exercise: WD_Events_XX where XX is your student number or continue working with WD01_Basics_XX. a)
Change the layout of the RootUIElementContainer from FlowLayout to MatixLayout and the Sporting Event Button to MatrixHeadData to ensure a neater display. a)
Raise the EPCF event by adding the code into the View Controllers Implementation in the methods starting with onActionSportButtonClicked then onActionConcertButtonClicked. a)
10. Repeat the step for the concert method. No need to organise imports. (Also we could have changed the event name rather than passing the parameters concert and sport.) a)
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
21. Now for the important part. We will create an Action. This Action will be called by the subscribe event when the event is raised / fired. Press Action tab – then New. Enter the name e.g. ConcertorSport and some text. NB press Next not finish as we need to enter the parameters. a)
23. Navigate to the View Controller implementation tab. Scroll down the code until the wdDoInit is reached. Please ensure that some text is defaulted into the text that will appear on the screen. Access the node, then it’s element and set it’s text. Continued on next page
24. Enter the Subscribe method to listen for the event when raised / fired from the other Web Dynpro project. Please use your editor to find your method after wdThis.
WDPortalEventing.subscribe( "urn:com.sap.tc.webdynpro.test", "TestWDEvent", wdThis.wdGetConcertorSportAction());
25. Enter the code that will analyse the parameter passed. This is placed into the method called when an event is raised.
if (dataObject.equals("sport")) { IEventingNode node = wdContext.nodeEventing(); IEventingElement elem = node.currentEventingElement();
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
elem.setText("You have chosen to attend a sporting event."); } else if (dataObject.equals("concert")) { IEventingNode node = wdContext.nodeEventing(); IEventingElement elem = node.currentEventingElement(); elem.setText("You would prefer a concert."); } else { IEventingNode node = wdContext.nodeEventing(); IEventingElement elem = node.currentEventingElement(); elem.setText("Parameter not sport or concert, maybe surfing?"); }
Lesson: Portal Eventing, Navigation and WorkProtect
27. Change the RootUIElementContainer to MatrixLayout. Change the new TextView to design of header1, Layout of MatrixHeadData. Please select the drop down select Text from the Value Attribute in the Context. a)
31. Create an iView from both of these and display them on a page. The results show the initial values. No button has been selected. The second shows that a sporting event button has been selected. The third shows that Rock concert event button has been selected.
Unit 12: Visualising the Java Web Dynpro through the SAP Portal
EP120
Lesson Summary
You should now be able to: • Create an iView from the Web Dynpro Application. • Communication between iViews using Portal Eventing is achieved using the raise, subscribe and unsubscribe methods with Java Web Dynpro. • Absolute, Relative, Object-based Navigation can easily be coded for the portal in Java Web Dynpro. • WorkProtect can be used to prevent losing unsaved data in the Portal using Java Web Dynpro. • The Portal theme can be utilised or overwritten using Java Web Dynpro.
Unit Summary
You should now be able to: • Create an iView from the Web Dynpro Application. • Enable communication between iViews using Portal Eventing and Java Web Dynpro. • Understand Absolute, Relative, Object-based Navigation, WorkProtect and the Portal theme using Java Web Dynpro. • Build a WebDynpro IView • Create an iView from the Web Dynpro Application. • Communication between iViews using Portal Eventing is achieved using the raise, subscribe and unsubscribe methods with Java Web Dynpro. • Absolute, Relative, Object-based Navigation can easily be coded for the portal in Java Web Dynpro. • WorkProtect can be used to prevent losing unsaved data in the Portal using Java Web Dynpro. • The Portal theme can be utilised or overwritten using Java Web Dynpro.
Unit 13
ABAP Web Dynpro
Unit Overview Unit Objectives
After completing this unit, you will be able to: • • • • • • Understand System Architecture and ABAP Program Create a simple ABAP WebDynpro application Integrate a WebDynpro application into the portal Use Portal Eventing Use Portal Navigation Use Portal Workprotect
Unit Contents
Lesson: Introduction to ABAP Web Dynpro .................................562 Lesson: Creating an ABAP Web Dynpro ....................................569 Lesson: Integrating an ABAP Web Dynpro into the Portal ................575 Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro............................................................................578 Exercise 21: Create a simple Web Dynpro Application ...............585 Exercise 22: Extract data from the SAP system and display in a simple table format..................................................................595
Lesson: Introduction to ABAP Web Dynpro
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • Understand System Architecture and ABAP Program
Business Example
Figure 640: Decision to use ABAP or Java Web Dynpro
When to use Java Web Dynpro and when to use ABAP Web Dynpro? This is a vital question asked by many development projects. The first question to ask is: where is the needed data stored. If the predominant data is found in the SAP system it will be a lot easier for an SAP developer to access the information via the ABAP Web Dynpro. If most of the relevant data is found via the Java Dictionary, it would be prudent to access the information using Java Web Dynpro. What release strategy does your company follow. Java Web Dynpro has been available for a lot longer than the ABAP Web Dynpro and it may not be on the plans to upgrade to allow ABAP Web Dynpro to be used.
What is the skill set of a company’s developers. If there are predominantly Java developers and no ABAP skills, it would add weight to developing Java Based Web Dynpros. If ABAP skills are more prevalent then there is more of an argument to use ABAP Web Dynpro. How much ABAP Data Dictionary information is needed. ABAP Web Dynpro components can be completed significantly faster by incorporation of numerous Data Dictionary functionality for example: search helps, F1 help documentation and field labels. An SAP dictionary structure can be copied to the Java Dictionary. Will there be a need for new features available with ABAP Web Dynpro for example ALV grid and Adobe forms incorporated into the ABAP Web Dynpro Views. Adobe Forms designed in the Form Builder (transaction: SFP), can be integrated into ABAP Web Dynpro views.
Figure 641: System Architecture and ABAP Program
The SAP Web Application Server has a modular architecture that follows the software-oriented client/server principle. In the SAP Web Application Server, presentations, application logic, and data storage can be assigned to different systems. This serves as the basis for the scalability of the system. The lowest level is the database level. Here data is managed with the help of a relational database management system (RDBMS). This data includes, apart from application data, the programs and the metadata that the SAP System requires for self-management.
The ABAP programs run at the application server level, that is, both the applications provided by SAP and the ones you develop yourself. The ABAP programs read data from the database, process the data, and possibly store data. The third level is the presentation server level. This level contains the user interface where each user can access the program, enter new data, and receive the results of a work process. The technical distribution of software is independent of its physical location on the hardware. Vertically, all levels can be installed on top of each other on one computer or each level on a separate computer. Horizontally, the presentation and application servers can be divided among any number of computers. The horizontal distribution of database components, however, depends on the type of database installed.
Figure 642: Excerpt for an ABAP Program
ABAP programs are processed on the application server. The design of user dialogs and database accesses is of particular importance when writing application programs.
The Repository is subdivided according to application components. Within an application component (e.g., MM) there are several packages containing relevant objects for a more detailed logical subdivision. Whenever a Repository object is created, it must be assigned to a package. Repository objects are often made up of sub-objects that are also referred to as Repository objects.
Figure 644: Working with the ABAP Workbench tools.
The ABAP Workbench includes all tools required for creating and editing
Repository objects. These tools cover the entire software development cycle. The most important tools are: The ABAP Editor for editing source code The ABAP Dictionary for editing database table definitions, central data types, and so on The Screen Painter for configuring screens (screens together with functions for user dialogs) The Menu Painter for designing user interfaces (menu bar, standard toolbar, application toolbar, function key settings) The Function Builder for maintaining function modules The Class Builder for maintaining global classes and interfaces You can call each of these tools explicitly and then load a Repository object for processing. But it is much more elegant and convenient to access them using the Object Navigator. You can have the requested Repository objects listed in this central development tool. All you have to do to edit one of them is to double-click to select it. The corresponding tool is called automatically and includes the selected Repository for displaying or editing.
Figure 645: Transporting Development Objects
Development projects are carried out in a development system. The development objects edited or created in a project are transported to subsequent systems (test and/or production system) on project completion. At the start of a development project the project manager creates a change request, in which he or she names
the employees of this project, in the Transport Organizer or directly in the ABAP Workbench. The Transport Organizer then creates a task for each project employee in the change request. When a development object is edited or created, the relevant employee assigns this to the change request. The object is entered into the task of the employee. Thus, all repository objects that an employee works on during a development project are collected within his or her task.
Lesson: Creating an ABAP Web Dynpro
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • Create a simple ABAP WebDynpro application
Business Example
Figure 646: Creating an ABAP Web Dynpro - logon.
Access the SAP logon icon. Select the SAP system that you would like to access. Enter the client, your user, password and language. Either enter SE80 into the command line or follow the menu path Tools -> ABAP Workbench -> Overview, then click the Object Navigator to access the Object Navigator.
Figure 647: Creating an ABAP Web Dynpro - Package + Request
Select Package from the drop down. Press the create button. Enter a name for your package. Please remember that this must start with a z or a y otherwise this could be overwritten during an upgrade. Enter a short description for your package and optionally an Application Component e.g. MM for material management. Enter an existing transportable workbench request or create one. This creates a Request number that is needed to transport this development object to the QA or Production System.
Figure 648: Creating an ABAP Web Dynpro - Create component.
Right click the Package that you have created. Select Create -> Web Dynpro -> Web Dynpro Component. Give the ABAP Web Dynpro a name beginning with z or y. Enter a meaningful description, select Web Dynpro Component and give the Window a name. Open the navigation menu and select Create -> View. To create the view. (did I need to say that?).
Press the Activate button – select all the entries and press enter. Open the menu path on the left and double click on the Window e.g. MAIN. On the right – select the Window – alternate click (right click) and select Embed View. Select the view that you would like to add. Select enter – green tick on the bottom left to continue.
Figure 651: Creating an ABAP Web Dynpro - create application.
Create a Web Dynpro application by right clicking the component. Enter some exciting and descriptive text and continue – green tick. Accept the defaults and press save. Right click this newly created application and select test. Check that your browser starts and displays the view.
Figure 653: Integrating an ABAP Web Dynpro Component into the Portal 2
Enter the System Alias and specify the namespace (sap) and name of the Web Dynpro application. The name of the ABAP Web Dynpro can be found in the SAP system. The iView size can be altered by opening the iView and Choose Appearance -> size. It is advisable to change the size to automatic when using large and complex applications.
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Lesson Overview
Lesson Objectives
After completing this lesson, you will be able to: • • • Use Portal Eventing Use Portal Navigation Use Portal Workprotect
Business Example
Figure 654: Portal Eventing using ABAP Web Dynpro.
Please note that it may be advisable not to use Portal Eventing when communications are on a frequent basis between Java Web Dynpro iViews. It would be better to implement a “full-screen” Web Dynpro application containing all the relevant components.
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
The communication between iViews is based on EPCF that uses JavaScript to allow iView communication and also provides an API for the Portal application developer. Web Dynpro applications have to use a set of Java Wrapper methods to implement client-side eventing. All Portal servers and servers that are used must be in the same domain when EPCF is used. Portal eventing functions only between iViews that are on the same browser window. Events between iViews in different browser windows cannot be transported.
Figure 655: Raising a Portal Event with ABAP Web Dynpro
The first parameter, must start with urn, – the namespace and the second parameter – the event name must be unique to your event. The Third parameter is the Web Dynpro action that is mapped to the portal event. The event handler is called when the Web Dynpro application receives the specified portal event on the client. The Web Dynpro HTML Client handles the mapping between a portal event and a Web Dynpro action and is absolutely transparent for the Web Dynpro application developer. The Web Dynpro action can be reused for several Portal events. If you want to receive the transported data of the portal event, you can define the following parameters for your Web Dynpro action: dataObject – contains the parameter of the portal event, Namespace – contains the name space of the received portal event and Name – contains the name of the received portal event. You can fire a portal event at any time in your Web Dynpro application. The event is transported with the next response to the client. More than one portal event can be raised in a request- response cycle. You can trigger such a portal event from anywhere in your Web Dynpro application. The event is sent with the
next response to the client. You can even trigger several portal events in one request-response cycle. However, it is usual to trigger a portal event in an action handler of a Web Dynpro application. This could be the case, for example, with an action handler of a UI element (for example, a button). When a portal event is triggered, an internal application event is first passed from the iView to the portal and can e handled within one or several other iViews.
Figure 656: Subscribing to an Event in ABAP Web Dynpro.
Enter the namespace and the name of the event. The combination of namespace and event name must be unique. In addition, enter the name of the action that is to be triggered if exactly this portal event is to be received. The corresponding action handler is then called automatically. The action, in this case GET_EVENT, is not created automatically. Therefore, create the action explicitly on the tab page Actions in the view. The parameters of a portal event are passed to the action parameter WDEVENT using its method GET_STRING. With the help of the optional parameter PORTAL_EVENT_PARAMETER, you can have application-dependent information passed to the handler method. In the following example, this is the field whose value is passed to the XYZ method of the component controller called afterwards.
method ONACTIONGET_EVENT. data: EVT_NAME type STRING, field type dictionarytable-field. EVT_NAME = WDEVENT->GET_STRING( NAME = 'PORTAL_EVENT_NAME' ).
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
if EVT_NAME = ' TestWDEvent '. field = WDEVENT->GET_STRING( NAME = 'PORTAL_EVENT_PARAMETER' ). WD_COMP_CONTROLLER->XYZ( methodparameter = field ). endif. endmethod.
Figure 657: Absolute Navigation with ABAP Web Dynpro 1
There could be a number of problems with Absolute navigation, especially when the target is moved to a new location. Object based navigation and relative navigation are a lot more stable and reliable. It would be a good decision to make the target addresses configurable by using the WDConfiguration service
Figure 658: Absolute Navigation with ABAP Web Dynpro 2
With the absolute navigation tool, you must know the name of the page to be displayed in order to pass it to the method. The navigation target is the only parameter required here. It stands for an absolute address in the portal. The other parameters are used for controlling the navigation and are optional. You can set business parameters and parameters for the respective application launcher in the portal. To transport business parameters correctly to the target application, you have to set the parameter USE_SAP_LAUNCHER. If it is an SAP application (for example, BSP Web Dynpro, and so on), you have to set the switch to TRUE.
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Figure 659: Relative Navigation in ABAP Web Dynpro
Relative addressing for example if you want to navigate between two portal pages that are both defined in the same directory in the PCD. The relative addresses continue to remain the same even if the entire directory is moved within the PCD. Parameters are used in the same way as Absolute Navigation.
Figure 660: Object Based Navigation
Object-based navigation (OBN) enables developers to specify navigation based on business objects and operations, without identifying a specific navigation target. Portal administrators can later assign specific navigation targets to these business objects and operations.
In many cases it is sufficient to use either relative or absolute navigation to navigate to a specific iView or page. However, sometimes more flexibility is required. For this purpose, you have Object-Based Navigation, which allows you to define navigation steps at a higher semantic level. Instead of defining a concrete target URL, you call a particular operation of a particular business-object. You configure in the portal which concrete iView (or which page) is to be used for executing this operation. This configuration can be role-specific or user-specific. The Web Dynpro application itself passes on solely the name of the business object and the operations linked to it. In Web Dynpro for ABAP, the integration of object-based navigation is very similar to the integration of portal eventing. To trigger the navigation itself, the Web Dynpro Framework provides a service that can be called from the application. This service, like Portal Eventing, is part of the portal manager. You can activate object-based navigation of the portal in Web Dynpro ABAP by calling the method NAVIGATE_TO_OBJECT of the portal manager (interface IF_WD_PORTAL_INTEGRATION)
Figure 661: WorkProtect with ABAP Web Dynpro
To avoid losing unsaved data when navigating to another iView, the portal provides a WorkProtect mode that, when activated, provides the user an opportunity to save any changes before navigating.
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Exercise 21: Create a simple Web Dynpro Application
Exercise Objectives
After completing this exercise, you will be able to: • Create and run a simple Web Dynpro application
Business Example
The first exercise is a version of the popular “Hello World” program.
Task 1:
You will place a UI element onto the view layout that contains the hard coded value of “Welcome to Web Dynpro!”. This text will then be displayed in the browser. Create a new Web Dynpro Component called ZWD_##_HELLO_WORLD. Change the proposed window name to MAIN. After this exercise is complete, you should see the result shown on the left.
Figure 662: ABAPWebDynpro Screenshot 1
1.
Developing Create a new Web Dynpro Component called ZWD_##_HELLO_WORLD. Change the proposed window name to MAIN.
2.
Create a view called HELLOWORLD and navigate to the view’s layout tab. Open the context menu of the ROOTUIELEMENTCONTAINER Continued on next page
choose Element einfügen (Insert Child) Enter the name TEXT. From the Type drop down list, select TextView. Press Confirm Enry. 3. Now select the newly created element TEXT and change the design property from standard to header1. Enter “Welcome to Web Dynpro!” in the text property. Press Save. Double-click on the window main. Right mouse click on the only element MAIN and choose embed view from the context menu. Choose helloworld as view to be embedded and click on continue. Save and activate your new Web Dynpro component. Lastly, we must create an application so that we can access the Web Dynpro component via a URL. - Right mouse click on the component node - Select Create → Web Dynpro Anwendung (Web Dynpro Application) from the context menu. Create the application having the following attributes: Name: Decription: (accept default) Hello World
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Solution 21: Create a simple Web Dynpro Application
Task 1:
You will place a UI element onto the view layout that contains the hard coded value of “Welcome to Web Dynpro!”. This text will then be displayed in the browser. Create a new Web Dynpro Component called ZWD_##_HELLO_WORLD. Change the proposed window name to MAIN. After this exercise is complete, you should see the result shown on the left.
Create a new Web Dynpro Component called ZWD_##_HELLO_WORLD. Change the proposed window name to MAIN. a)
Figure 664: ABAPWebDynpro Screenshot 2
2.
Create a view called HELLOWORLD and navigate to the view’s layout tab. Open the context menu of the ROOTUIELEMENTCONTAINER choose Element einfügen (Insert Child) Enter the name TEXT. From the Type drop down list, select TextView.
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Press Confirm Enry. a)
Figure 665: ABAPWebDynpro Screenshot 3
b)
Navigate to the view’s Layout tab Open the context menu of the ROOTUIELEMENTCONTAINER choose Element einfügen (Insert Child) Enter the name TEXT. From the Type drop down list, select TextView. Press Confirm Enry.
Now select the newly created element TEXT and change the design property from standard to header1. Enter “Welcome to Web Dynpro!” in the text property. Press Save. a)
Figure 667: ABAPWebDynpro Screenshot 5
4.
Double-click on the window main. Right mouse click on the only element MAIN and choose embed view from the context menu. Choose helloworld as view to be embedded and click on continue. a)
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
5. 6.
Save and activate your new Web Dynpro component. a) Save and activate your new Web Dynpro component. Lastly, we must create an application so that we can access the Web Dynpro component via a URL. - Right mouse click on the component node - Select Create → Web Dynpro Anwendung (Web Dynpro Application) from the context menu. Create the application having the following attributes: Name: Decription: (accept default) Hello World
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Task 2:
Running 1. Start the application. a) Right mouse click on the newly created application zwd_##_hello_world and select Test. Your browser should now display the following screen:
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Exercise 22: Extract data from the SAP system and display in a simple table format
Exercise Objectives
After completing this exercise, you will be able to: • Use the ABAP Web Dynpro to create a useful component. • Extract data from the database. • Display the data in a table • Create nodes and attributes based on a dictionary structure • Create mapping and binding between context nodes and the view elements.
Business Example
Development Objectives This exercise has the following objectives: • • • Show the simplicity of data extraction from the SAP system Show the automatic search helps and f1 helps when using the ABAP stack Use the mapping and binding with the help of the dictionary structure.
Task:
The result of this exercise will be that you have an application that will select data from the SAP transactional system and display this data in a table format.
Figure 672: ABAPWebDynpro Screenshot 10
Prerequisites You have logged onto the correct client in the SAP system. You have completed the Hello World exercise for practice. 1. Developing Navigate to the Object Navigator – SE80 and select the Web Dynpro dropdown. Create a Web Dynpro component with the name ZWD_XX_select_into_table where XX is your student number. 2. Navigate to the ComponentController in change mode and create a Context node with the name carriers. Enter a Dictionary structure of SCARR and 0..n cardinality. Next, press the button to add attributes from this structure. Select the fields that you want to use: CARRID, CARRNAME, CURRCODE and URL. Please note that the field URL is 255 characters. Press the Methods tab – select the WDDOINIT method and add the code to select the data from table scarr into internal table itab. Access the context node called CARRIERS and bind the internal table data to this node. Save and activate all components. Create a View with the name Carrier_display. Continued on next page
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
7.
Select the View, before selecting the Context tab. Drag the Carriers node to the View Controllers Context. Data from the Component Controller context should be now available in the View Controller and visa versa. Save and Activate. Select the Layout tab, highlight the RootUIElementContainer and Insert an Element of type table with the name Carrier_table. Right click the carrier_table and select Create Binding. Press the Context button and then the CARRIERS node. Select the fields that you wish to bind and add a Caption to the table.
8. 9.
10. Embed your View onto the Window. 11. Create a Web Dynpro application and activate. 12. Right click and test the Web Dynpro component.
Solution 22: Extract data from the SAP system and display in a simple table format
Task:
The result of this exercise will be that you have an application that will select data from the SAP transactional system and display this data in a table format.
Figure 673: ABAPWebDynpro Screenshot 10
Prerequisites You have logged onto the correct client in the SAP system. You have completed the Hello World exercise for practice. 1. Developing
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
Navigate to the Object Navigator – SE80 and select the Web Dynpro dropdown. Create a Web Dynpro component with the name ZWD_XX_select_into_table where XX is your student number. a)
Navigate to the ComponentController in change mode and create a Context node with the name carriers. Enter a Dictionary structure of SCARR and 0..n cardinality. Next, press the button to add attributes from this structure. a)
Press the Methods tab – select the WDDOINIT method and add the code to select the data from table scarr into internal table itab. Access the context node called CARRIERS and bind the internal table data to this node. a)
Select the View, before selecting the Context tab. Drag the Carriers node to the View Controllers Context. Data from the Component Controller context should be now available in the View Controller and visa versa. Save and Activate. a)
Lesson: Portal Eventing, Navigation and WorkProtect with ABAP Web Dynpro
8.
Select the Layout tab, highlight the RootUIElementContainer and Insert an Element of type table with the name Carrier_table. a)
Figure 688: ABAPWebDynpro Screenshot 25
Figure 689: ABAPWebDynpro Screenshot 26
9.
Right click the carrier_table and select Create Binding. Press the Context button and then the CARRIERS node. Select the fields that you wish to bind and add a Caption to the table. a)
Unit Summary
You should now be able to: • Understand System Architecture and ABAP Program • Create a simple ABAP WebDynpro application • Integrate a WebDynpro application into the portal • Use Portal Eventing • Use Portal Navigation • Use Portal Workprotect
Course Summary
You should now be able to: • • • • Use Visual Composer Use SAP NetWeaver Development Studio Develop NetWeaver Portal components and services Use and Understand NetWeaver Portal APIs and services
Glossary
security zone Means of implementing an additional layer of security to portal components and services which are accessed by a URL. Access is controlled by means of progressive safety levels and portal permissions, which are assigned to authorized users.
Feedback
SAP AG has made every effort in the preparation of this course to ensure the accuracy and completeness of the materials. If you have any corrections or suggestions for improvement, please record them in the appropriate place in the course evaluation.