developing custom applications for sap enterprise portal

Developing Custom Applications for SAP Enterprise Portal — Starting with the “Right” Options in Light of SAP NetWeaver

For site licenses and volume subscriptions, call 1-781-751-8799. 81

Patrick Dixon is a managerwith Deloitte specializing inSAP Enterprise Portal andWeb integration. He hasmore than five years of experience Web-enabling and integrating SAP systemswith SAP Enterprise Portal,SAP Internet TransactionServer, SAP ExchangeInfrastructure, and PlumtreeSoftware solutions. Patrickwas a key speaker at SAPBW and Portals 2004 andSAP Portals 2003.

(complete bio appears on page 112)

In my previous SAP Professional Journal articles,1 we explored how touse the standard iView wizards within SAP Enterprise Portal (SAP EP) to integrate data, transactions, and content from SAP, non-SAP, and Web-based systems. We also explored how to use the SAP Connector iView toautomatically generate iViews from a function module or BAPI in an SAPsystem. These standard options will work in the majority of cases, suchas when you want to quickly provide access to SAP transactions or data.

But what if you want to customize or simplify the user interface or call more than one function module in sequence? In these cases (and others), you’ll have to develop a custom application. For most SAP teams, developing custom applications has always meant writing a custom ABAP report or module pool on one of their SAP systems (e.g., SAP R/3 or SAP BW).

With the advent of SAP NetWeaver, however — and its broadsupport for Java and .NET, as well as SAP technologies — the menu of languages, tools, and approaches from which SAP teams must choosehas increased dramatically. Each option has important pros, cons,prerequisites, and strategic implications that will affect your long-termcosts and the lifetime of your code, and each yields an important lesson:All modern SAP teams need to define a deliberate development strategyto avoid ending up with an inventory of disparate applications thatcannot be easily maintained or upgraded. Unfortunately, few companieshave found time to do a true apples-to-apples comparison to serve as thebasis for developing this strategy.

Developing Custom Applications for SAP Enterprise Portal — Starting with the “Right” Options in Light of SAP NetWeaverPatrick Dixon

1 “Integrating SAP Transactions, Reports, and Data into Your SAP Enterprise Portal — A GuidedTour of Your Options, Which to Use, and When” (July/August 2004) and “Integrating Non-SAPData and Web Content into Your SAP Enterprise Portal — A Guided Tour of Your Options, Whichto Use, and When” (January/February 2005).

SAP Professional Journal March/April 2005

82 www.SAPpro.com ©2005 SAP Professional Journal. Reproduction prohibited. All rights reserved.

Over the course of this two-part article series, I will compare your eight main options for develop-ing custom content and applications for delivery via SAP EP:

1. Write a custom SAP function module and deployit via the SAP Visual Composer.

2. Write a custom SAP transaction or report anddeploy it via an SAP Transaction (SAPGUI) iView.

3. Write a custom Business Server Pages (BSP)application and deploy it via an SAP BSPiView.

4. Write a custom Web Dynpro for Java applicationand deploy it via an SAP Web Dynpro iView.

5. Write a custom Web Dynpro for ABAP applica-tion and deploy it via an SAP Web Dynpro iView(future option).

Figure 1 Custom Development Options Overview

��

��

��

��

�

��

��

��

��

��

��!�

�

��

��

"��

"��

#$�

"��

#$�

%&�'

()��*� �+�&��!�&��+�� ,�� -� ��!��-�� .

�� /��/�� /��!�� /��/�� /��-��/�-��!��!��&��

� ��!�� /��+��!��-�� 0��#12��-��#��+�� !��-��2� ��!�� !��33��

��!�� 4��/��+��!��-�� 0��#12��-��#�/��+��!��-��2�� !�� ,��

! ��+�� !��-��2� ��!� ��%-��3�� +��

��!��+��-�� +��-��5��!��!� ��-��)��67/��!��3�+�� 3�� !��

"�87

"�87

9#7��

(��:��

3��#

��

�� 4��2��)�+��4��!

#$�

��'9&3��4��

��'9&3��

�!��

��'9&3��4��

��

�4��

�!��

��&��#$�.��!$�� 8�!��

#$�4��14��

4��

#$�

#$�

9#7��

2

;

<

<�

�=

"��

��!��&��.&�� +�&��!

&��

%&�'>

�� 4��'9&��

��'9&3��"�87� �'9&�

��#��/8�!��/��6��-

��-��

�� 4�� %-��

�%-��4��

��2�#$�

,

"��

4��

��<�

? �

%-��

$��

��1�(��

�(��

�� '9&��

�� '9&��

(continued on next page)



6. Write a custom portal component in Java anddeploy it via a PAR-based iView.

7. Write a custom J2EE application and deploy it viaa generic URL iView.

8. Write a custom ASP or .NET application anddeploy it via a generic URL iView.

Figure 1 provides a graphical overview of theseoptions and how they fit into an SAP EP landscape.This first installment of this article series coversoptions 1-5, which are the easiest to implement; the

remaining options (6-8) are covered in the secondinstallment. Since the most effective way to under-stand a technology is to see it used in practice,throughout the article series we will use each technol-ogy to build the same simple application so you canclearly see how each of the options differs in terms ofplatform and skill set requirements, level of effort, andease of coding.

Let’s get started by describing the application thatwe will develop.

Three Custom Development Habits of Successful IT Teams

In my experience, the most successful IT teams do three key things with regard to custom development:

They choose a small number of options that are easy to administer, easy to maintain, integratedwith their backend data, security, etc., and have a relatively predictable future. For example, they useABAP for SAP development, Web Dynpro for Web-based SAP applications, and JavaServer Pages(JSP) for non-SAP Web development.

At the other extreme, trying to mandate a single development approach almost always has disastrousresults — i.e., an excessive amount of code to accomplish easy tasks, inefficient performance, orattempts to circumvent the standard. A common example is the mandate that SAP developers arenot permitted to make modifications to standard SAP code (a.k.a. “core mods”) under any conditions.

�

Note!

My previous articles2 included a paralleldiscussion for customers running SAP EP 5.0 SP5.Since most customers have by now upgraded, Iwill limit the discussion to SAP EP 6.0. Most ofthe discussion still applies to SAP EP 5.0, but themenu paths and iView types will differ.

Note!

While it sounds obvious that IT teams shoulddevelop a company-wide menu of approveddevelopment options, and evaluate which of theseoptions is most appropriate for each developmentrequest, few do so in practice. Instead,development requests are met with whicheveroption is most familiar or most convenient, insteadof most strategic. Hopefully this article will helpchange this way of thinking (see the sidebar belowfor some additional pointers on the characteristicsof successful IT teams).

2 See the July/August 2004 and January/February 2005 issues of SAPProfessional Journal.



In some cases, unique, company-wide business requirements can be met most strategically bychanging a line of code in an SAP program.* SAP’s Modification Assistant, Modification Browser, and automated adjustment tools make tracking these changes — and adjusting them during upgradesor hot package applications — easy.** In most cases, this approach is less costly and less risky thancopying an SAP program and then making the modifications to the copy, which means you mustmanually apply all hot packages and upgrades.

They encourage their developers to learn aboutand experiment with new technologies, even if they don’t use them. Programming is aninteresting thing — concepts and techniquescross-pollinate. Only by gaining experience with multiple languages and technologies candevelopers really master their craft. A goodworking knowledge of multiple technologies alsogets developers used to change — if a developerhas been writing ABAP interfaces for 15 years, andyou want to shift to Web Dynpro, you will inevitablymeet with resistance.

They avoid custom development whenever possible — a wise man once said “every additionalthing I own is another noose around my neck,” and the same is true for custom code, which must be administered, maintained, enhanced, upgraded, tracked, and eventually migrated or retired.If your custom development is spread across multiple systems and languages, and has differentdependencies (e.g., platform settings, configuration, etc.), the situation is exacerbated. If this soundslike your company, the road to recovery starts by implementing defined initiatives to reduce thenumber of platforms and technologies you use and to consolidate and harmonize your existingcustom code.

�

�Caution!

An industry-wide pitfall is to let developers try out new technologies on actual projects to gain practice.While it’s true that you can’t know the true limitationsof a technology until you kick the tires a bit, it iscatastrophic to end up with an arsenal of “one-off”applications developed with different technologies.Instead, isolate learning to building test projects orprototypes, and if a technology seems promising,seek to have it officially added to your company’sstrategic list of development options.

Note!

Choosing the “best” option requires careful consideration of the predominant skills of the team members withinyour organization, the platforms you have available (or plan to upgrade to), the systems you need to access, andhow your landscape (and available technology) will evolve in the future. Indeed, custom code tends to live longerthan most people think, and which options are strategic can change over time.

* You do this by requesting a modification key from the SAP Service Marketplace (http://service.sap.com). This is a simple, painless procedure that many mistakenly fear more than a root canal.

** See the article “The Basics and Beyond: Manage Modifications Effectively with the SAP Modification Assistant, ModificationBrowser, and Object Adjustment Tools” in the May/June 2003 issue of SAP Professional Journal.

(continued from previous page)



Example Application OverviewConsider the following scenario: A user knows theaddress of a company and wants to look up the com-pany name. The user logs on to SAP EP and clicks ona link to a directory lookup application. On the searchpage that appears, the user enters the street address,city, and ZIP code for the company and clicks on theSearch button; the application then retrieves a list ofcompanies with that address from the SAP R/3 data-base. This is the example application we will build toillustrate the options discussed in the article.

The flow of the application is illustrated in Figure 2, where you can clearly see the examplesequence of actions play out. You’ll notice that theroot of the application is a function module in SAP R/3 called ZEPO_ADDRESS_LOOKUP, whichtakes in the values in the search fields and returns atable of matching company names. It is up to ourapplication to generate the search HTML page, parse

the address values submitted by the user, call the func-tion module, and generate the results page. SAP EP isresponsible for managing the navigation details, com-municating with the user’s Web browser, and loadingthe search and results HTML pages into the appropri-ate iPanel on the user’s portal page.

Figure 2 Example Application Flow

7��3� ��-��

��

��

��

#��

� ��

� �� -

� �� @&�

��

��

��

��#12��-��

$�� 8�!��

��

�� 3��

�� ! ��

�� "

�� #��#��

�� !��$%&�� ' ��(��

��!�� "

��

��!

&��0��

)��*�� +� ,

�� +��

� �� A

� �� !��-A

� �� @&�A

%�-�� .(��

�� +

��

��

��

��

��

��

��

��

� ��

!��

� ��

��

��

!��

��

"��

!��

��

Note!

When contemplating the demos to build for thisarticle, I felt it was important that the demoprograms provide three fundamental functions:accepting data from the user, interacting with abackend database, and displaying databaseinformation to the user. These are characteristicsof enterprise applications and will provide a usefulillustration of the differences between thedemonstrated portal development options.



Figure 3 shows the code for function moduleZEPO_ADDRESS_LOOKUP. Whether you are adeptat ABAP or not, the code is pretty self-explanatory.After some initial declarations and preparation, thefunction checks whether any asterisks (*) wereentered as wildcard values. If so, three dummy company names are added to the return tableEPOCOMPANY. If not, the function tries to match the input address information to some hard-coded values, and returns the appropriate company name. If no matches are found, a “no matches found” message is inserted into the return table, along with a reminder that you can retrieve a list of all company names by entering asterisks for all threeinput fields.

Note that the search is not case-sensitive becausewe translate the input values to uppercase beforedoing any comparisons.

Note!

Given that the function module is written in ABAPand resides in an SAP system, I could have codedit to retrieve the company name from an SAP table.I chose to hard-code the values instead to keep thecode simple and to ensure that it works the samefor those who choose to create the demo codethemselves.

Developing the ExamplesNow that you understand the target design and thefunction module we’ll call, it’s time to start develop-ing the examples. As I mentioned earlier, in this first

FUNCTION ZEPO_ADDRESS_LOOKUP.*"-------------------------------------*"*"Local interface:*" IMPORTING*" VALUE(STREET) TYPE STRING*" VALUE(CITY) TYPE STRING*" VALUE(ZIP) TYPE STRING*" TABLES*" EPOCOMPANY STRUCTURE ZCOMPNAMES OPTIONAL*"-------------------------------------

DATA: A TYPE STRING, B TYPE STRING,C TYPE STRING.

A = 'NO ORGANIZATION NAME FOUND FOR YOUR INPUTS. PLEASE TYPE '.B = ' * AS WILDCARD FOR ALL THE INPUT FIELDS'.

CONCATENATE A B INTO C.

TRANSLATE STREET TO UPPER CASE.TRANSLATE CITY TO UPPER CASE.TRANSLATE ZIP TO UPPER CASE.

IF STREET EQ '*' and CITY EQ '*' AND ZIP EQ '*'.EPOCOMPANY-COMPANYNAME = ' DELOITTE USA LLP '.

Figure 3 SAP R/3 Address Lookup Function Each Example Will Call



installment of the article series, we will build theexample using the following five techniques, in orderof ease to most SAP teams (options 6-8 will be dis-cussed in the second installment):

1. Write a custom SAP function module and deployit via the SAP Visual Composer.

2. Write a custom SAP transaction or report and deploy it via an SAP Transaction (SAPGUI) iView.

3. Write a custom Business Server Pages (BSP)application and deploy it via an SAP BSP iView.

4. Write a custom Web Dynpro for Java applicationand deploy it via an SAP Web Dynpro iView.

5. Write a custom Web Dynpro for ABAP applica-tion and deploy it via an SAP Web Dynpro iView(future option).

For your reference, the pros and cons of eachoption are summarized in a download available atwww.SAPpro.com.

Option #1: Write a Custom SAPFunction Module and Deploy itvia the SAP Visual ComposerFor SAP teams with in-house ABAP developmentskills, the easiest way to create an application thataccesses data in an SAP system is to write one ormore custom function modules and deploy them using the SAP Visual Composer tool (option ➊ inFigure 1). The Visual Composer provides a Web-based WYSIWYG design tool for building customiViews based on one or more function modules in an

INSERT TABLE EPOCOMPANY.EPOCOMPANY-COMPANYNAME = ' MICROSOFT USA '.INSERT TABLE EPOCOMPANY.EPOCOMPANY-COMPANYNAME = ' HEWLETT AND PACKARD '.INSERT TABLE EPOCOMPANY.

ELSEIF STREET EQ 'VANENBURG' AND CITY EQ 'HYDERABAD' AND ZIP EQ'500082'.

EPOCOMPANY-COMPANYNAME = 'DELOITTE CONSULTING INDIA PVT LTD'.INSERT TABLE EPOCOMPANY.EPOCOMPANY-COMPANYNAME = 'BAAN INDIA PVT LTD'.INSERT TABLE EPOCOMPANY.

ELSEIF STREET EQ 'HITECH' AND CITY EQ 'HYDERABAD' AND ZIP EQ '500082'.EPOCOMPANY-COMPANYNAME = 'MICROSOFT INDIA PVT LTD'.INSERT TABLE EPOCOMPANY.

ELSEIF STREET EQ 'USA' AND CITY EQ 'USA' AND ZIP EQ '50000'.EPOCOMPANY-COMPANYNAME = 'SUN MICRO SYSTEMS'.INSERT TABLE EPOCOMPANY.ELSE.EPOCOMPANY-COMPANYNAME = C.INSERT TABLE EPOCOMPANY.ENDIF.

ENDFUNCTION.

Figure 3 (continued)



SAP system and gives you basic control over theiView’s appearance (e.g., labels, layout, graphics, andcolors). The Visual Composer design tool automati-cally generates the Java code an iView needs to createits HTML user interface, accept user input, call anSAP function module, and load results into screenfields. All of the design is done using visual tools —you need to write ABAP code only if you can’t find anexisting function module to provide or post the datayou need, so non-programmers can build customiViews from existing function modules without muchdifficulty. The Visual Composer user interface alsoshares the same native portal look and feel as otherstandard SAP EP iViews. All of these capabilitiesmakes the Visual Composer a fast, affordable way tobuild custom portal content.

As a maturing visual tool, the Visual Composerdoes have its limitations, however. For example, you can’t chain a series of function modules insequence — if you want to call one function moduleto validate values and then another to post the data, for example.3 Your iView can also have only a singlescreen — i.e., the search page and the results page in our example application must share a single screen, so the results fields will always be visible,even when they contain no values. In addition, expect to run into a few quirks here and there — forexample, the names of the columns in grid views aredependent on the SAP R/3 technical field names,which we all know are not always meaningful, even if you speak German. There are often workarounds to these issues.4

Figure 4 summarizes the installation, develop-ment, and deployment steps involved in writing a cus-tom function module and deploying it via the VisualComposer (note that the steps in gray are executedonly once):

1. Download and install the Visual Composeron your portal server. The Visual Composer is available from the SAP Service Marketplace at http://service.sap.com and consists of a set of design-time and runtime components you need to install on a Microsoft IIS server. As mentioned previously, you’ll also need aMicrosoft SQL Server available to complete the installation. Once you’ve installed the tool according to the instructions, test your setup by navigating to the URLhttp://<myIISserver>/vcserver, where <myIISserver> is the IP address or host name of the Microsoft IIS server hosting the Visual Composer design-time components.

2. Build and test the function module you’ll call on your SAP system. Our application will call one function module, as shown in Figure 3. Function modules are built and tested on the target SAP system using theFunction Builder (transaction SE37). All ABAP developers know how to create and

3 To be more specific, you can’t pass the value of an input field to morethan one function module, nor can you pass the output of one functionmodule to another. You can, however, place input and output fieldsfrom multiple function modules in your iView layout.

4 To work around the one-function-call-only limitation, just write a cus-tom function module that, in sequence, accepts the input values andcalls the set of function modules you want to call. To work around thetable label issue, make a copy of the table and rename the fields.

Note!

Another key consideration is the awkward platformrequirements for the Visual Composer’s designtool, which runs only on Microsoft InternetInformation Server (IIS) and requires access to aMicrosoft SQL Server database to store design-time data. So you’ll need to set up a separateserver and database if your portal doesn’t alreadyuse Microsoft Windows and Microsoft SQL Server.The good news is that Visual Composer iViews canbe deployed to and run on any SAP EP 6.0 SP3 orhigher server without modification. These SAP EPreleases have the required Visual Composerruntime support classes built in. If you have anearlier SAP EP release, you need to installadditional components on your portal serverbefore you can run your Visual Composer iViews.See the Visual Composer documentation for moredetails.



test function modules, so I will not discuss how in further detail.

3. Launch the Visual Composer on yourMicrosoft IIS server. In your Web browser, navi-gate to the URL http://<myIISserver>/vcserver asdescribed in step 1.

Note!

While you don’t need a user ID and password tolaunch the Visual Composer design tool, you will need a portal administrator user ID andpassword to start using it productively. The toolprompts you for logon information when you startdesigning an iView — specifically, when youattempt to look up a function module to use as thebasis of your iView. This is because the VisualComposer looks in your portal landscape directoryto build the list of potential SAP systems that canbe used as a target.

4. Create and name the iView. Simply drag theiView icon from the Logic Elements pane on theright onto the workspace, and overtype the defaultiView name that appears. See the VisualComposer online help if you have any trouble.

Figure 4 Writing and Deploying a Custom SAP Function Module (Option 1)

/�,�� +��(�� 011� �2�! ��!��

�� +��(�� (�� !�� (�� 2 �� #�� #��(!�� 2 ��#�� '�3��

!�� 2 �� 4�!�� 2 ��

/ 2 �� (��(�!��(� ��(� �"�� ' ��-�� (��'

��!��56�

)�(�! �� +��(�� '�� 011�� 2 ��12!� �2 ��

�� ,��+� ,��''��'�� +� ,��!�� ,��*��! �

7�� / ��'��#�� !� ��#��(�!��(� �!��#�� ,�� , ��

7�� )��(��#�2��(�� (�� ! ��!��!� ��

�� (�!��(� �(��'��-��#�� +� ,�(��'

��1 ��

��2 �� +� ,��2��'�� +� ,�� +��(�� (��!��

�� 2 ��

5 “Integrating SAP Transactions, Reports, and Data into Your SAPEnterprise Portal — A Guided Tour of Your Options, Which to Use, and When” (SAP Professional Journal, July/August 2004).

Note!

Remember to RFC-enable your function modules;otherwise, they cannot be called from the VisualComposer.

Note!

Recall from my first article5 that if you don’t needdetailed control over the user interface, an eveneasier way to generate an iView for a functionmodule is to use an SAP EP 6.0 SAP ConnectoriView (depicted as option in Figure 1). TheiView creation wizard asks for the name of thefunction module you’d like to call and the namesof the input and output fields you want to display,and it then creates a rudimentary user interface foryou — that’s it!

<�



5. Visually define the application’s screens, func-tion module calls, and flow. This is very easy todo. Just navigate to the Design tab within theVisual Composer (Figure 5), drag-and-drop screen and function module “objects” from the

pane on the right to the workspace, and connectthem with connectors to define the order of execution. Single-click on each object to modifyits properties — e.g., the screen names, the function module connection parameters, etc.

Figure 5 Modeling an iView Using the Visual Composer

Note!

For a more detailed demo on how to use the Visual Composer, see my article in the July/August 2004 issue of SAPProfessional Journal.



As you can see in Figure 5, I’ve added and con-nected the search screen, the function module, and the results screen.

6. Visually define the layout of each applicationscreen. To do this, switch to the Layout tab (see Figure 6) by clicking on it. As I mentionedpreviously, all screens defined on the Design tab will share a single iView, so you’ll have to add all of the fields and buttons you’ll need here.Adding fields is simply a matter of clicking on the Fields button in the right-hand toolbar anddragging fields from the displayed list to the

layout area.6 Figure 6 shows our example iView— as you can see, I’ve added the search fields andinserted a grid control to display the companynames returned by the function module.

7. Save and test the iView. Deploying and testingVisual Composer iViews is easy since the VisualComposer does most of the work for you. All you have to do is click on the Deployer button inthe right-hand toolbar (see Figures 5 and 6) and

Figure 6 Defining the Consolidated Layout of the iView

6 That is, the list of input and output fields for all function modulesdefined in the workspace.



execute the compile and deploy functions in theCode Compiler pane that appears. If the toolreports that the objects were deployed success-fully, the iView will be added to your list ofiViews in the portal administration tool, and you

can add it to a portal page, test it, and use it justlike any other iView. Figure 7 shows the com-pleted example iView at runtime in a portal page,after a wildcard search for all companies has beenperformed.

Figure 7 Visual Composer iView at Runtime in a Portal Page

Note!

As you can see in the right-hand toolbar in Figures 5 and 6, the Visual Composer includes a debugger, but it has a bit of a learning curve. If your iView doesn’t work as expected, go back and retest the function module in theFunction Builder (transaction SE37).



8. Transport the application. Two pieces need to be transported for the application to work in test and production: the backend function module using standard SAP transport tools (i.e., the SAP Change and Transport System), and the iView using standard portal import/exporttools. Ask your SAP Basis and portal administra-tors, respectively, how to do this.

In summary, developing custom iViews with the Visual Composer is great when you need a fast,simple, one- or two-screen user interface for display-ing or entering a limited amount of SAP data from one or more function modules, and you don’t need sophisticated frontend processing, flow control, or layout requirements.

Note!

SAP has indicated plans to enhance the VisualComposer to enable access to non-SAP systems viatechnologies including JDBC and XML. Detailson this solution are forthcoming. Checkhttp://sdn.sap.com for the latest developments.

Option #2: Write a Custom SAPTransaction or Report and DeployIt via an SAP Transaction(SAPGUI) iViewFor teams with ABAP expertise, the most familiarway to build a custom application that accesses data in an SAP system will be to write a traditional SAPtransaction, report, or query using ABAP (option ➋ inFigure 1). Benefits of this approach include a familiardevelopment environment, accessibility by traditional(non-portal) SAPGUI users, and tight integration withSAP security and administration tools. The ABAPruntime also automates many tedious tasks, such asvalue formatting (e.g., removing leading zeros) andvalidating date formats.

The drawbacks are that SAPGUI-based applica-tions lack a Web look and feel, may require you totrain and support new SAPGUI users, and may requireadditional licensing costs to provide access to non-SAP users. SAPGUI also tends to consume a lot ofscreen real estate, and — unlike Visual ComposeriViews — SAP Transaction iViews do not use the por-tal style sheets, which sometimes makes the iViewlook like an alien application. Finally, if your strategyis to consolidate all of your custom portal applicationsonto a central application server (e.g., your portalserver), then distributing your applications across SAPsystems can be counterproductive.

As shown in Figure 8, the key steps in thisapproach are:

1. Develop and test your module pool, report, orquery on the target SAP system.7 ABAP devel-opers are very familiar with the procedure and theABAP Workbench tools required to do this, so Iwill not go into the details here. Module pools arecreated with the Object Navigator (transaction

Figure 8 Writing and Deploying a Custom SAP Transaction or Report (Option 2)

/ 2 �� (��(� ��#�� #��.( �� ' ��-��

�� ,��-��!��+� ,�� (��

�� !��#�� #��.( ��(��'��-��#��

�+� ,�(��'��1 ��

� �� +� ,��' �

7 Module pools are screen-based programs and are commonly referred toas “SAP transactions.” Technically, however, SAP transactions are anyprograms that can be launched by a transaction code, including modulepools, reports, and even queries.



SE80), reports with the ABAP Editor (transactionSE38), and queries with SAP Query or InfoSetQuery (transaction SQ01). Since the program will be accessed with SAPGUI, there are no special development requirements other than to keep the application as simple and stand-alone as possible and to design your screens to fit the available real estate on your portal page. Since it is the easiest option, I have developed the example application as an ABAP report.

2. Create a new SAP Transaction iView using the portal administration tool. In SAP EP 6.0,all that’s required is to log on to the portal

administration tool, navigate to the Portal Content Studio (menu path Content

Figure 9 Creating an SAP Transaction iView

Note!

I covered how to deploy an SAP Transaction iViewvia SAPGUI for Windows (WinGUI), SAPGUI for Java (JavaGUI), and SAPGUI for HTML(WebGUI) extensively in my July/August 2004article. Refer to that article for further details andtips, including how to have SAPGUI launch in itsown window instead of embedded within thebrowser window.



assign the iView to a portal page, and access thepage by logging on as a test user. Keep in mindthat since SAP Transaction iViews consume significant screen real estate, they should almostalways be isolated to their own portal page. You can then provide a link to that page from some conspicuous point. Figure 10 shows thesearch page for our example application, and

Administration → Portal Content), and create a new iView by right-clicking on the folder inwhich you want to store the new iView. The wizard shown in Figure 9 appears, asking for the target system, SAPGUI, and transaction code you wish to use.

3. Test the iView. Testing is straightforward: Just

Figure 10 The Example Search Page Rendered as an SAP Transaction iView

Note!

If your target SAP system does not appear in the system dropdown list in the SAP Transaction iView wizard, haveyour system administrator register the system in your portal’s System Landscape Directory.



Figure 11 shows the results page; both are ren-dered as an SAP Transaction iView using SAPGUIfor Windows (WinGUI).

4. Transport the application. Your transaction,report, or query is transported using standard SAPtransport tools, and the iView is transported usingthe standard portal import/export tools.

Figure 11 The Example Results Page Rendered as an SAP Transaction iView

Tip

Users often get confused when SAPGUI is broughtup within a Web browser since they see multiplesets of navigation controls — one set for thebrowser and one for SAPGUI. Some usersaccidentally hit the browser’s back button, thinkingit will do the same thing as the SAPGUI backbutton, causing their SAPGUI iView to disappear(i.e., the browser navigates to the previous portalpage). It is therefore a good idea to place SAPTransaction iViews on a single page that launchesin a separate window. Since this new window has no history, the browser’s back button will bedisabled. Another solution is to launch SAPGUI instandalone mode. See my July/August 2004 articlefor more on how to do this.

Note!

Because the iView accesses data that resides in anSAP system, users will have to log on to the SAPsystem when they access the iView. Considerimplementing single sign-on to avoid thisinconvenience.



In summary, writing and deploying traditionalABAP reports, module pools, and queries is an excel-lent choice when building complex, SAP-centricapplications that you’ll roll out to experienced SAPusers. Consider one of the other options when writingless-complex, portal-only applications that will beaccessed by SAP and non-SAP users, when small realestate consumption and a native Web look and feel areimportant, or if your iView will draw heavily fromnon-SAP systems.

Option #3: Write a CustomBusiness Server Pages (BSP)Application and Deploy It via anSAP BSP iViewFor teams with ABAP expertise and an available SAPWeb Application Server (SAP Web AS) 6.10 or highersystem (ABAP or ABAP+Java version8), writing a

custom Business Server Pages (BSP) application(option ➌ in Figure 1) is an excellent choice foraccessing data in an SAP system. BSPs are very simi-lar to JavaServer Pages (JSPs) and Active ServerPages (ASPs) with three major differences:

1. You can write most of the application code inABAP (or JavaScript).

2. The BSP runtime includes a library of HTMLBusiness tags that automatically generate complexuser interface elements like shaded tables, lists,and graphs.9

3. BSPs offer a high level of integration with SAPprogramming, security, and administration tools.

With respect to development, writing and debug-ging complex BSP applications can take a bit longerthan writing traditional SAP applications (see the side-bar below for more on the reasons why), but it isalmost always significantly quicker than using .NETor Java (more on these options in the second install-ment of this article series).

The BSP Learning Curve

ABAP developers will find BSP programming difficult at first, because the programming paradigm is verydifferent from traditional module pools and reports, and you need a good working knowledge of HTMLand JavaScript to build effective applications.

As an example, consider the code for the BSP versions of our search and results pages (shown in Figures 13 and 14, respectively). In traditional ABAP programming, nearly all programming is on theserver side. When a user clicks on a button, the request is passed to the application server for processingby the ABAP code. There is no division between processing that happens on the client and what happenson the server.

8 SAP Web AS is available in three flavors: SAP Web AS Java, SAP WebAS ABAP, and SAP Web AS ABAP+Java. Since BSPs need an ABAPruntime, they can run only on SAP Web AS ABAP or SAP Web ASABAP+Java systems. Unlike most SAP systems, SAP EP 6.0 has noABAP runtime — it runs on SAP Web AS Java. You already have SAPWeb AS if you have SAP R/3 Enterprise, mySAP ERP 2003 or 2004,SAP BW 3.0 or higher, or SAP SCM 4.0, for example. You can also setup and run SAP Web AS as a standalone system for running customBSP, Java, or Web Dynpro applications that access backend SAP sys-tems via RFC.

(continued on next page)

9 SAP extended the set of standard HTML tags with specialized HTMLBusiness tags to make building professional-looking user interfaces eas-ier for BSP developers. The ABAP Workbench features a Tag Browserthat enables you to explore HTML Business tags for elements like SAP grids, fields, and labels and then drag and drop them into your BSP code.



Note!

Keep in mind that BSP applications do not offermany of the niceties of SAPGUI, such as pop-uplists for choosing values. Unless you can find anHTML Business tag for the desired function, you’llhave to code all of these yourself.

The process for developing and deploying BSPapplications for SAP EP is outlined in Figure 12:

1. Develop your BSP application. You can developthe application either on the target SAP systemrunning SAP Web AS or on your standalone SAP Web AS system.10 Like module pools, BSP applications are written within the ABAPWorkbench Object Navigator (transaction SE80).Figure 13 lists the code for our BSP search page,and Figure 14 lists the code for the results page. Even if you’re not familiar with HTML or ABAP,

you can probably tell what’s going on. The companysearch.htm search page (Figure 13)contains a single form with our three input fields.The form’s action tag is set to process.htm,which tells the browser to pass the field values to

BSP (and all Web) programming is different — some code runs on the application server, and some coderuns on the client. In Figure 14, the code between the <% and %> markers is called “server-side” code.This code runs on the server each time the page is requested by the Web browser and is written in ABAPor JavaScript. The HTML tags and any other JavaScript code outside these markers are treated simply as text and passed to the browser without being executed on the server. When the browser receives thistext, it “runs” it. When the browser encounters HTML tags, it uses them to render the user interface.When it encounters JavaScript, it executes it. JavaScript can also be embedded within predefined“hooks,” so when a user places the mouse over an image, for example, the browser runs a JavaScriptfunction that substitutes a different image.

For a detailed introduction to BSP programming, see the article “A Developer’s Guide to Creating Powerfuland Flexible Web Applications with the New Web Application Builder” in the January/February 2002 issueof SAP Professional Journal.

Figure 12 Writing and Deploying a Custom BSP Application (Option 3)

/ 2 ��(��8��!�� ' ��-�� (��'��-��9 ��-��(�� -��9 ��-��

�� (�!��(� �� 8��!��(��'��-��#�� +� ,�(��'��1 ��

� ��(��8��!��!! ��'�� !��9 ��,� ��

�� ,��-��8��+� ,��(��!�� (��

� �� +� ,��' �

10 For a detailed introduction to developing BSP applications, see the article “A Developer’s Guide to Creating Powerful and FlexibleWeb Applications with the New Web Application Builder” (SAPProfessional Journal, January/February 2002).

(continued from previous page)



<%@page language="abap" %><html>

<head><link rel=stylesheet href="../public/bc/bsp/styles/sapbsp.css">

</head><h2> Company Name Search </h2><br><h3>Search Form</h2><form method="POST" action="process.htm">STREET: <input name="street" type=text value=""> <br>CITY: <input name="city" type=text value=""> <br>ZIP: <input name="zip" type=textvalue =""> <br><input type="submit" name="sbutton" value="Search"></form></html>

Figure 13 BSP Code for the Search Page (companysearch.htm)

<%@page language="abap"%><html> <h2><b>Company Name List </b></h2><table border=3><%

TYPES ITAB1 TYPE STANDARD TABLE OF ZCOMPNAMES WITH DEFAULT KEY.DATA ITAB type ITAB1.DATA WA type line of ITAB1.CALL FUNCTION 'ZEPO_ADDRESS_LOOKUP'EXPORTING

STREET = streetCITY = cityZIP = zip

TABLESEPOCOMPANY = ITAB.

LOOP AT ITAB into WA.%><tr> <td> <%=WA-COMPANYNAME%> </td></tr><%ENDLOOP.%></table></html>

Figure 14 BSP Code for the Results Page (process.htm)



our process.htm results page (Figure 14)when the user presses the Search button. Theprocess.htm page contains server-side code,written in ABAP, that passes the input values tothe function module ZEPO_ADDRESS_LOOKUPand accepts the return values into a temporarytable called ITAB. The code then loops throughthe table, outputting each company name as a rowin the HTML table. This code illustrates howserver-side code can be intermixed with HTMLtags to produce a final HTML page for thebrowser to render.

Figure 15 The Search Page Generated by the BSP Code

Note!

If you are running your BSP applications on astandalone SAP Web AS system, append the phraseAT DESTINATION <destination> to the CALLFUNCTION statement in order to execute thefunction module on the desired (remote) SAPsystem, where <destination> is the logical systemname of your remote backend SAP system, asdefined in transaction SM59 (RFC Destinations).



2. Test your BSP by accessing it directly from aWeb browser. It is best to test your applicationson their own before integrating them into the por-tal (so there are fewer potential failure points incase something doesn’t work properly). The URLused to access your BSP application directly willdepend on how your system is configured. Askyour SAP Web AS administrator for details.

3. Create a new SAP BSP iView using the portaladministration tool. As explained in my firstarticle in the July/August 2004 issue, the Portal

Content Studio offers a special iView template forBSP applications. While you can technically alsointegrate your application as a generic URL iView,the SAP BSP iView option provides additionalBSP-specific settings that ease deployment. Seemy July/August 2004 article for specifics on howto create different types of iViews.

4. Test the iView. Assign the iView to a portal page,and access it by logging on. Figure 15 shows thesearch page generated by the code in Figure 13,and Figure 16 shows the results page generated

Figure 16 The Results Page Generated by the BSP Code



by the code in Figure 14. When users first accessthe iView, they will be presented with a logonpage in order to log on to the system (if singlesign-on has not been implemented). Users mustenter a valid user ID and password for the back-end system, not their portal user ID and password.

Note!

Knowing which user ID and password to enter is a common source of confusion and error amongportal users, and requires them to keep track ofwhich backend system is generating the iView inquestion. This is why single sign-on is a “must-have” for most SAP EP teams.

5. Transport the function module, the BSP appli-cation, and the iView. The BSP application istransported using standard SAP transport tools.Since BSP applications are built with the ABAPWorkbench, all associated objects are added to the transport automatically and can be trans-ported just like any other SAP object. The iView is transported using the standard portalimport/export tools.

In summary, writing a BSP application is an excel-lent option for SAP teams with extensive ABAP expe-rience writing custom ABAP-based Web applications.The extensive library of HTML Business tags greatlysimplifies the effort required to produce highly func-tional, professional-looking interfaces that share thelook and feel of other SAP EP content. On the otherhand, with the exception of HTML Business tags, userinterfaces must be coded entirely from scratch and canbe accessed only from the Web, and developers mustlearn the BSP programming model and tools plus a bitof HTML and JavaScript to be effective. Web Dynprofor ABAP (discussed in an upcoming section) promisesto be an even easier option for ABAP developers, butBSP development will remain your best option whenyour needs cannot be met with Web Dynpro (e.g.,when you need more granular control over the userinterface than Web Dynpro provides).

Option #4: Write a Custom WebDynpro for Java Application andDeploy It via an SAP Web DynproiViewOur next option (option ➍ in Figure 1) brings us intothe Java world. Web Dynpro is a relatively new fea-ture built into all SAP Web AS Java 6.30 and higherplatforms. It is essentially a Web-native version of thetraditional Dynpro programming model that ABAPprogrammers have been using for years: You build anapplication as a set of screens and write code that exe-cutes either before the screen is displayed or upon auser event. The difference is that with Web Dynpro,the code must be written in Java, and you can onlyaccess SAP data by calling function modules via theSAP Java Connector (JCo). You build and deployWeb Dynpro applications using SAP NetWeaverDeveloper Studio.11

Note!

Web Dynpro resembles Visual Basic in many ways:You draw screens visually and then insert logicinto predefined event handlers. You never see (or get to modify) the code that actually generatesthe screens.

If you have SAP EP 6.0 SP312 or higher, you canhost your Web Dynpro for Java applications locally onyour portal server. Regardless of where they arehosted, however, Web Dynpro for Java applicationscan be integrated into your portal using the SAP WebDynpro iView template provided with SAP EP 6.0(SAP EP 5.0 does not offer this option).

11 SAP NetWeaver Developer Studio is a rebranded version of the EclipseIDE that bundles Eclipse together with plug-ins for SAP Web Dynpro,Web services, etc. For a detailed introduction to using this tool, see thearticle “Get Started Developing, Debugging, and Deploying CustomJ2EE Applications Quickly and Easily with SAP NetWeaver DeveloperStudio” in the May/June 2004 issue of SAP Professional Journal.

12 Now officially called “SAP Enterprise Portal 6.0 running on SAP WebApplication Server 6.40.”



Compared to the other Java options — writing aportal component (option ➏), a J2EE application(option ➐), or an ASP or .NET application (option ➑),each of which will be covered in the next installmentof this article series — Web Dynpro is the easiest wayto write a Java application that accesses data in bothSAP and non-SAP systems. The Web Dynpro runtimedoes many things for you — from drawing the userinterface, to flow control, to field formatting — thatyou would otherwise have to code yourself. WebDynpro also automatically gives you the standard SAPlook and feel and provides a more “ABAP-like” pro-gramming model. For example, each screen has aProcessBeforeOutput method and a ProcessAfterInputmethod into which you insert each screen’s logic, justas in ABAP. In fact, there are only a few drawbacksthat might cause you to forego Web Dynpro:

• You are not permitted extensive control over theHTML and JavaScript generated for each screen.You are pretty much stuck with whatever HTMLand JavaScript the SAP Web Dynpro iView com-ponent generates for the layout you draw. Thiscan be an issue if you want to insert HTMLhooks or JavaScript code into your HTML — e.g., to send messages to other iViews via SAP EP’s “eventing” framework (more on this in the next article).13

• Web Dynpro applications can run only on SAPWeb AS Java 6.30 and higher systems, so youcan’t run them on a non-SAP J2EE server.

• The product is still in beta release, so you maywish to avoid using it for mission-critical applica-tions until it has established a solid track record.

• Web Dynpro applications do not run as fast asspecialized Java applications (the generic platformintroduces some overhead).

• Web Dynpro applications cannot access the portalruntime user variables. These runtime variablesare useful for user-specific applications and areavailable when developing portal componentswith the Portal Development Kit (PDK). Portal

component development (option ➏) is discussedin the next installment of this article series.

The development process for building WebDynpro for Java applications is summarized in Figure 17:

1. Download and install SAP NetWeaverDeveloper Studio. SAP NetWeaver DeveloperStudio is SAP’s strategic tool for Java develop-ment for the SAP NetWeaver platform and isbased on Eclipse, just like the PDK. SAPNetWeaver Developer Studio offers built-in toolsfor developing J2EE components, such as servlets,Enterprise JavaBeans (EJBs), Web Dynpro forJava applications, and Web services.

Figure 17 Writing and Deploying a Custom Web Dynpro for Java Application (Option 4)

�� ,�9 ��/��:�2��; !��

+��(�� #�2� ,�#��!�� (��!�� /��'��

2� ,�

/ ��'�� (�� ! ��(��+� ,��

�� 2� ,� 2 �� !��!�� 2� ,��:�2��

+��(�� , �� !�� #�2� ,�#� �!�

/�,��-�� 9 �2 ��/ 2 �� (�� 011��!��

�� (�!��(� �(��'��-��#�� +� ,�� -<�� (��'�� 1 ��

��

/ �� ; !��-<�� (�� 2 �#�� ('��,�� -�� 9 �2 �

/ 2 �� (�� ('' ��

/ �� ,��-��9 ��/��+� ,��(��!��,��

��(��#�� ' �

13 Since you can’t modify the HTML code, this also means that you can-not use HTML Business tags in your Web Dynpro code.



2. Create a new Web Dynpro for Java project.Creating a project is easy — in SAP NetWeaverDeveloper Studio, simply navigate to File → NewProject, choose the Web Dynpro category, selectWeb Dynpro Project, and follow the wizardinstructions. The tool generates a starter project

with all the necessary project files, Java deploy-ment descriptor files, etc.

3. Visually define the models, views, and con-trollers that make up your application. One of the advantages of developing with Web Dynpro is that the process is highly visual, and the tool handles as much of the coding for you as possible. The key is to understand that WebDynpro applications consist of three components:views (the screens users interact with), models(the backend function modules or tables that

Note!

Despite these drawbacks, teams should stronglyconsider Web Dynpro if they are determined to useJava, since Web Dynpro applications involvesignificantly less coding than the other Javaoptions, are much more maintainable, and willbenefit from future SAP enhancements to theprogramming model. Teams with ABAPexperience should wait for the release of WebDynpro for ABAP (option ➎), which I’ll discuss inthe next section.

Figure 18 Model-View-Controller Design of the Example Application

Note!

The instructions in this section provide a briefoverview of how the example application works. A more detailed walkthrough, and a complete codelisting, is available at www.SAPpro.com.



serve as the data source/target), and controllers(the Java code that defines the business logic).14

Of these components, only the controllers arecoded using Java. The views and models in your application are designed using visual toolsand wizards, and the Java code for them is gener-ated automatically by SAP NetWeaver DeveloperStudio. Figure 18 shows the Model-View-Controller (MVC) architecture diagram for ourexample application, which consists of two views (CompanySearchView andCompanyNameList), one controllerZCOMPModelController), and one model(ZCOMPMODEL). The function of the views isobvious. Model ZCOMPMODEL is bound to ourbackend function module — ZEPO_FUNCTION_MODULE — and provides a

Java API for accessing input and output parame-ters, executing the call, etc. ControllerZCOMPModelController will be invokedwhen the user submits the search page, the func-tion module call is executed via the model, andcontrol is passed to the CompanyNameListview to display the results.

4. Draw the views in your application. Views aredesigned with a tool that functions much like theScreen Painter within the ABAP Workbench.Figure 19 shows the view design for our search

Note!

In addition to views and models, the data handoffsand control transfers between components aredefined visually as well. An example of this isprovided in step 6.

14 This architecture is known as the Model-View-Controller (MVC) archi-tecture, which is used heavily in the Java development world. For moreon the MVC architecture, see the SAP Professional Journal articles“Build More Powerful Web Applications in Less Time with BSPExtensions and the MVC Model” (March/April 2003) and “DevelopMore Extensible and Maintainable Web Applications with the Model-View-Controller (MVC) Design Pattern” (January/February 2004).

Figure 19 Drawing the Search View in SAP NetWeaver Developer Studio



page. The view design for our results page isshown in Figure 20.

5. Code the view event handlers and applicationcontrollers in Java. I mentioned previously thatwhen the user clicks on the Search button on thesearch page, control passes toZCOMPModelController to call our functionmodule via our model — as you can see in Figure 19, the value aNEWButton is entered forthe onAction event of the search page’s Searchbutton. When a user clicks on the Search button,the system calls the onActionaNEWButton()event handler, which we’ve defined in Figure 21.The first statement calls a method(executeZEPO_ADDRESS_LOOKUP_INPUT)on our controller class to execute our businesslogic (make the RFC call toZEPO_ADDRESS_LOOKUP) — the code for this method is shown in Figure 22. The

second statement fires a plug15 that tells the system to navigate to the results page to displaythe results.

Figure 20 Drawing the Results View in SAP NetWeaver Developer Studio

Note!

For more details on designing models, views, andcontrollers, download SAP’s comprehensive WebDynpro tutorials from https://sdn.sap.com/sdn/developerareas/webdynpro.sdn?page=webdynpro_tutorials.htm.

15 Plugs are symbolic objects that represent a particular navigation path — i.e., from one view to another. Plugs are defined visually, which lets you change your application flow without having to recom-pile your code.



Figure 21 Coding the Event Handler for the Search View

Figure 22 The Controller Code

public void executeZepo_Address_Lookup_Input( ){

//@@begin executeZepo_Address_Lookup_Input()//$$begin Service Controller(-676183145)IWDMessageManager manager = wdComponentAPI.getMessageManager();try{

wdContext.currentZepo_Address_Lookup_InputElement().modelObject().execute();

wdContext.nodeOutput().invalidate();} catch(WDDynamicRFCExecuteException ce) {

manager.reportException(ce.getMessage(), false);}//$$end//@@end

}



6. Visually map the data handoffs between con-trollers, views, etc. So far, we’ve described howcontrol passes from the search view, to the con-troller, to the model, back to the controller, andthen to the results view. Since the views, con-troller, and model are separate, loosely coupledcomponents, however, you may be wonderinghow data gets passed between them. After all, the

Note!

You may wonder where the RFC call is made in the code in Figure 22. In Web Dynpro, database accesses like RFCcalls are performed by the model, which is defined visually. So the call towdContext.currentZepo_Address_Lookup_InputElement().modelObject().execute() executes the RFC call and loadsthe results into memory. Recall that models are built visually, meaning we don’t have to write any code at all.

Figure 23 Mapping the Controller Context and the Results Table in Our Results View

Note!

A more detailed walkthrough of how the WebDynpro for Java example works is available fordownload at www.SAPpro.com.



7. Deploy the application to your SAP Web ASserver, and debug it with the SAP NetWeaverDeveloper Studio debugger. Like most IDEs,deployment involves generating the code anddeploying it to a central server. For Web Dynpro,SAP NetWeaver Developer Studio creates anEnterprise Archive (EAR) file containing the associated application files and deploys it to thetarget SAP Web AS server (e.g., your portalserver). A debugger lets you step through and perfect the code. Consult the SAP NetWeaverDeveloper Studio documentation for specifics onthese procedures.

8. Define a new SAP Web Dynpro iView for yourapplication and test it. You can deploy yourWeb Dynpro application either as an SAP WebDynpro iView or as a generic URL iView. TheSAP Web Dynpro iView template is preferablesince it provides more specific parameters andguidance in deploying your iView. Figure 24

call to our context methodexecuteZEPO_ADDRESS_LOOKUP_INPUTpasses no parameters to the controller, so howdoes the controller have access to the field valuesentered by the user in the view? Similarly, how isthe results view passed the table of return valuesfrom our RFC?

While a complete discussion is well beyond thescope of this article, the short answer is that thevalues are passed automatically, provided we tellthe system how to do so (an activity known ascontext mapping). It might not surprise you tolearn that SAP NetWeaver Developer Studio provides a visual tool with which to do this.Figure 23 shows the mapping between the outputof our function module call — the table of com-pany names — and the target field in the resultsview. Having done this, the system handles thedetails of the transfer, and our results view appearswith the data loaded into the appropriate fields.

Figure 24 The Search Page Deployed as an SAP Web Dynpro iView



shows the search page generated by our WebDynpro for Java application and deployed as anSAP Web Dynpro iView. Figure 25 show theresults page in the same format.

9. Transport the application. In addition to thebackend SAP function module, which is trans-ported with standard SAP transport tools, the Web Dynpro EAR file and iView definition must be transported using the standard portalimport/export tools.

In summary, Web Dynpro for Java is a great

option for SAP teams with Java experience16 who are looking for a fast and easy way to develop Web applications that leverage data from SAP andnon-SAP systems. Web Dynpro applications are easy to create and maintain and involve much lesscode than other Java options since many items — such as views, models, plugs, and context mappings— are defined using visual tools. You’ll want toforego Web Dynpro for Java for now, however, if you cannot live with the standard view output,

Figure 25 The Results Page Deployed as an SAP Web Dynpro iView

16 ABAP teams will find Web Dynpro for Java very difficult to learn and use.



since you cannot currently interject your own HTMLor JavaScript into the automatically generated output. Also, if portability is important to you, beaware that Web Dynpro for Java applications run only on SAP Web AS — they do not run on third-party J2EE servers.

Option #5: Write a Custom WebDynpro ABAP Application(Future Option)In the not-too-distant future, the SAP Web AS WebDynpro programming model will be expanded toallow coding in ABAP (option ➎ in Figure 1), not justJava. This will make writing Web applications verysimple for ABAP programmers, and promises tobecome the de facto choice for teams with ABAPexpertise and an SAP Web AS capable of runningthese applications.17

Since much of the application is created visually,Web Dynpro for ABAP applications will be much eas-ier to write than BSP applications. For example,developers won’t have to know any HTML, HTMLBusiness, or JavaScript to create the user interfaces(i.e., views), and RFC calls can be “programmed”visually (i.e., by creating models). Connectivityoptions for using Web Dynpro for ABAP should besimilar to BSP applications — i.e., the application willbe able to access a local SAP database via regularABAP SQL commands or a remote system via remotefunction calls — and you won’t need to use the SAPJava Connector (JCo) as you do now with WebDynpro for Java. Like writing ABAP transactions andBSPs, Web Dynpro for ABAP will also offer tightintegration with your existing SAP security andadministration tools.

For all of these reasons, I recommend that all SAP

teams take a close look at Web Dynpro for ABAPwhen it emerges.

ConclusionThis article has hopefully provided you with a solid apples-to-apples understanding of how youravailable custom content and application develop-ment and deployment options differ in terms of prerequisites, development process, flexibility, and code complexity.

My recommendation for teams with extensiveABAP experience is to (for now) continue to developcomplex, SAP-centric applications using traditionalSAP module pools and reports — and deploy them viaSAPGUI for HTML (WebGUI) — until Web Dynprofor ABAP is released and matures. Web Dynproshould then be strongly considered for Web-onlyapplications,18 since it will offer a much more nativelook and feel.

Java teams should strongly consider using Web Dynpro for Java whenever possible but will probably find the lack of customizability over the user interface (HTML) frustrating. In this case, developing portal components using HTML Businessfor Java classes is preferable to developing traditionalJ2EE applications (I’ll go into more detail on theseoptions in the next installment of this article series).While these options sacrifice application portability,the benefits far exceed the costs in most cases (e.g., applications require significantly less code, are more maintainable, and gain a standard SAPlook and feel; portal components also offer access to portal runtime variables and feature enhanced performance due to hosting within the portal server itself).

My next article will cover the remaining options

17 Most teams will still want to use Business Server Pages for more com-plex applications, however, where they need a high level of control overthe user interface (i.e., the ability to use HTML and JavaScript).

18 That is, applications that don’t need to be accessed by SAPGUI users as well.



introduced at the beginning of this article — devel-oping portal components with or without HTMLBusiness tags, developing J2EE applications thatleverage the SAP Java Connector (JCo), and developing .NET applications using the PDK for.NET and the .NET Connector — to provide you with a complete resource of your available options so you can make the right decision for integrating custom content and applications into your own SAP EP implementation.

Patrick Dixon is a manager with Deloittespecializing in SAP Enterprise Portal and Webintegration. He has more than five years ofexperience Web-enabling and integrating SAPsystems with SAP Enterprise Portal, SAP InternetTransaction Server, SAP Exchange Infrastructure,and Plumtree Software solutions. Patrick was akey speaker on portal implementation and contentintegration at the SAP BW and Portals 2004 andSAP Portals 2003 events. Before moving to the USin 1996, he was a freelance consultant in GreatBritain. Patrick graduated from Bath University in 1983 with a master’s degree in computersimulation, and he subsequently obtained an MBAfrom City University, London. You can reach himat [email protected].

developing custom applications for sap enterprise portal

Technology

sap bw

sap exchange

sap systemsprerequisites

sap technologies

websap application

standalone sap web

sap enterprise portal

custom sap transaction