Expand +



Visual Composer — A Model-Driven Development Tool for Enterprise Portal iViews

by Karl Kessler | SAPinsider

October 1, 2004

by Karl Kessler, SAP AG SAPinsider - 2004 (Volume 5), October (Issue 4)

Karl Kessler,

There are a variety of tools out there if you're looking to develop content for SAP Enterprise Portal. But options like Java programming with the help of the Portal Development Kit (PDK) are code-heavy and can be cumbersome when all you want to do is get a simple little iView deployed and into the hands of your Enterprise Portal users. What's more, people are looking for yet another option for creating iViews — one that also allows business users without Java skills to model and design their own iViews for SAP Enterprise Portal. They now have a graphical design tool for just that purpose — the Visual Composer.

Without any coding, you can design a straightforward iView with this new tool. Visual Composer eases development of iViews — the interactive, Web-based applications running inside the portal — with a model-driven approach, so you avoid all coding effort. You have access to backend systems like SAP R/3, mySAP ERP, and mySAP CRM with connectivity based on Web services. And you can connect to those services via SAP Enterprise Portal. Visual Composer allows business users to compose an iView that accesses data from various data sources (e.g., BAPIs from SAP backend systems such as CRM) without actually writing code. You are in a pure modeling environment, one that not only lets you model the layout of the user interface, but also the flow of control between different user interface elements, as well as the access to backend data and the binding of data to UI elements.

So how do you create a simple iView with Visual Composer? This article will take you through the basics of the process and offer a view of how Visual Composer will fit into the range of options for bringing dynamic and interactive content to your Enterprise Portal.

Creating a New iView

In this example, we'll create a simple iView, shown in Figure 1, that will allow users to search for flights by city, as well as to drill down to specific details on selected flights.

Figure 1
The Flight iView

To begin to build this iView, you can call it directly from your browser. The initial screen of the Visual Composer provides a list of existing models to choose from. However, to create a new iView, choose "Create Blank Model" and give that model a name.

The Visual Composer's modeling pane then provides a palette with an array of modeling elements — Page, iView — and a toolbar for building the foundation of your iView — Fields, Properties, Elements (see Figure 2).

Figure 2
Start by Creating the iView Module

To create the model, you start with three basic steps:

  • Creating the module — which is the package for all the elements needed to create an iView

  • Creating the page — which models the portal page and serves as a container for multiple, related iViews

  • Creating the iView — which is the pane we will focus on in this example since it contains the metadata, including input forms, output results, data sources, etc.

First, in the upper right corner, enter the URL of the portal you want to access. The portal manages a connector framework that provides access to backend systems (BAPIs, for example). Hit the traffic light icon to log on to the portal where the iView will appear. To create the module, simply drag the Module icon from the "Model Elements" pane and drop it onto the modeling pane. This is all that's needed to ensure the iView represents content to your portal.

Simply double-click the module to open an empty FlightModel pane, which contains the elements that are contained in the module. Then, drag the Page symbol and drop it in. Double-clicking on the newly created FlightPage will create another empty pane for the page; here you can drag the iView icon.

Choosing the Data Source

In the toolbar, select the Data icon to access available data sources for your iView (see Figure 3), which are then listed in a dropdown menu under "Connect to System." Once you have selected the correct SAP system (in this case, the SAP R/3 system), you can then browse and select from available BAPIs, which will serve as data sources for your iView.

Figure 3
Adding the BAPI to the iView

To add the BAPI to the iView, double-click on the iView; then simply drag the BAPI and drop it to the empty iView pane. It now displays the BAPI with all its underlying metadata: input parameters, output parameters, and tables.

The Visual Composer is running in the browser, so you can immediately do some testing due to the live connection to the portal. Perhaps, as you're building your iView, you want to check out a particular BAPI you've selected and make sure it produces the information you need. Just right-click on the GetList container and find a context menu with a test function. You can immediately input a few parameters into the fields, and see the BAPI's results (see Figure 4).

Figure 4
Testing the BAPI Directly from the Visual Composer

Developing the iView's User Interface

Now that the iView has access to its data source, we want to model the user interface. This iView needs an Input Form, which will allow end users to specify their search parameters and a result, Flightlist Table, which will display the flights that meet their criteria.

To create the input form, select "Input" in the BAPI model and drag it, which will produce a context menu to create an input form (see Figure 5). Likewise, you can drag the parameter "Flightlist" and attach a corresponding table view. A "Define Fields" window automatically appears in the right-hand pane to allow you to select fields when creating the input form or output table.

Figure 5
Defining the Input Form and a Complete iView with Input and Output

To view and select search fields and result columns, simply click "Input," for example, and this will open the field list on the right (shown in the second screen in Figure 5). Check off the fields you need as input criteria (or, in the case of the output table, define the columns). For the updated iView, I checked off all fields.

I could also easily add a custom field. For example, I could include a new field that would compute the number of seats available by including a formula that subtracts SEATS MAX from SEATS OCC once the table is filled with data.

The Visual Composer also creates a default layout for your input and output field specifications, which you can view and edit by selecting the Layout tab (Figure 6). Here you resize the fields and their containers, modify label properties, and align the fields following an interaction pattern — all with simple diagramming tools that have the familiarity of formatting tools in almost any PC application.

Figure 6
Customizing the Layout

Test Driving Your iView

Believe it or not, your iView is now ready to start working!

For a taste of how it will work, switch to the Preview tab, and a sample page will appear just as it will look in the iView. Specify some sample search criteria (see Figure 7). If you hit the Submit button, the BAPI is called and the output table below is filled with records found from the flight database that match the search criteria. If you get lost for whatever reason, you can open the outline of your current Visual Composer project directly from the toolbar.

Figure 7
Previewing Your iView

Adding Additional Functions to the iView

For a slightly more sophisticated iView, you can add additional BAPIs and model additional interactions. The BAPIs we selected earlier could also allow users to drill down to individual details of the selected flights, as a second step in the same iView.

To build additional features into the iView, the overall procedure is simple. Return to the Design tab, select Data from the toolbar, and drag BAPI_SFLIGHT_GET_DETAIL to the modeling pane, where your iView appears. In this case, again, you simply make the connections. Here, connect the "out" port of the Flightlist table with the Input parameter of the newly added BAPI. The arrow will be marked with the label "select" to indicate that the selected row is fed into the input parameter of BAPI_SFLIGHT_GET_DETAIL. (You'll see an example of this in the Deploy view discussed below.)

It will also automatically map the columns of the selected row to the fields of the input parameter of the BAPI. I also added a form to display the details, and once again the layout editor is used to make some of the fields visible.

Again, you can edit it in Layout and preview the iView. The last step is to deploy it to the portal.

Deploying the iView to the Enterprise Portal

Figure 8 gives you a sense of the possibilities of the Visual Composer, and just four of the perspectives during the design of any single iView — including the Layout view, the Preview, the automatically generated Java code, and the model that makes up the final iView which includes drilldown to specific flight numbers. The Deployer tool in the toolbar offers compile-time features, which check whether the model that you have developed so far is valid.

Figure 8
Layout, Java, Preview, and Deploy Views of a Single iView

If your model is valid, you can deploy the whole application to the Enterprise Portal; simply select the "Deploy" button and launch the iView in the Enterprise Portal.

Architecture and Technical Requirements of Visual Composer

Now that we've seen what it can do, let's have a look under the hood of the Visual Composer.

In terms of technical requirements for the deployment of your new iView, you need access to Enterprise Portal 6 SP2, which is based on SAP Web Application Server 6.20, or SAP NetWeaver, which contains SAP Web Application Server 6.40.

As a browser-based designtime environment, Visual Composer requires Windows 2000 and XP, as well as the MS XML parser and the SVG plugin from Adobe for Internet Explorer.

Figure 9 shows the overall architecture of the Visual Composer and its environment.

Figure 9
Designtime and Runtime Architecture of the Visual Composer

The Visual Composer has a server-side designtime environment running on IIS and storing all modeling data in a SQL server-based repository. The client side of the Visual Composer is made of a bunch of Java script, which is downloaded when you connect to the Visual Composer designtime. The Java script drives the SVG plugin, therefore all user interaction is carried out in a browser session. The server-side designtime environment can be installed on the portal server if the used platform allows you to do so. The designtime environment accesses the metadata of the underlying backend systems to provide typed modeling elements such as BAPI parameters.

If you develop an iView with the help of Visual Composer, the htlmb-based iView1 is deployed to the portal runtime for execution — as if you had written it by hand using PDK. The portal then executes your iView on the Visual Composer runtime, which in turn accesses backend data through the Connector Framework of the Enterprise Portal.

From a platform perspective, Visual Composer is quite different from Web Dynpro, as the output generated is based on htmlb (see sidebar below). But in the future, these tools will take an approach that highly skilled Web Dynpro programmers as well as business users can benefit from.

A Look Ahead: Building iViews with Both Web Dynpro and Visual Composer

In future releases, Web Dynpro and Visual Composer will come more closely together in their development approaches and architectures in two ways:

  • First, since Visual Composer is purely model-driven, its compiler backend can easily be redirected to generate code that is executed on the Web Dynpro runtime.

  • The ongoing pattern orientation in Web Dynpro will certainly require highly model-driven tools that make it as easy as possible to model sophisticated user interface scenarios based on configurable Web Dynpro components. Visual Composer, with its rich graphic support, is an ideal candidate to prototype and deploy these scenarios.

By starting to use both Web Dynpro and Visual Composer for creating portal content and capitalizing on their respective strengths — and bringing business users into design processes — you'll be well prepared for a scenario where these two development approaches will converge.

Comparing Web Dynpro and Visual Composer

Visual Composer is designed for business users who want to design portal content that is relatively straightforward in design and quickly executable.

For Java and business application developers, Web Dynpro offers a greater amount of flexibility, control of data flow, screen design, navigation models, and dictionary support. At the same time, Web Dynpro's model-based approach also supports hard-core coding, with a dedicated development environment based on Eclipse and all the design-time resources of the SAP NetWeaver Developer Studio at hand.

In contrast, Visual Composer is lightweight, Web-based, and accessed via the portal, supporting a less complex program model with respect to navigation and data flow. In designing with Visual Composer, you must specify everything that will occur during runtime — which makes Visual Composer strong for applications that do not rely heavily on dynamic invocation and dynamic creation of objects at runtime.

Design Options Based on Programming Skills and Complexity


As you can see, developing content with Visual Composer is fairly easy. Without actually knowing technical details of the portal platform, you can quickly develop models that are generated into executable code that can be deployed to SAP's Enterprise Portal. What's more, the designtime environment is server-based, allowing you to develop the code wherever a browser is available that lets you connect to the model repository.

The Visual Composer is a powerful tool for developing dynamic content when coding skills are not available. While a business user must be able to think in technical terms (e.g., understand data sources such as BAPIs), they won't necessarily need Java development skills to design an iView. Visual Composer is just one of many tools for content creation and content development for the Enterprise Portal. Depending on the user's ability, this is a simple end-user based tool to create and customize more or less static content.

For more information and to download Visual Composer, see the SAP Developer Network at

1 htmlb is the standard UL tag library of the PDK.
Karl Kessler joined SAP in 1992. He is the Product Manager of the SAP NetWeaver foundation including SAP Web Application Server, Web Dynpro, ABAP Workbench, and SAP NetWeaver Developer Studio, and is responsible for all rollout activities. You can reach him via email at


An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!