Design Time and Runtime

Visual Composer is a design-time software tool in which you can develop an application and then deploy it. After deployment, you can run the actual application in the portal to check its runtime functionality. During model creation and configuration, you define all the runtime attributes of the model components, such as the frame of a table, the size and types of toolbar buttons and the format of an output form. You can also define a range of properties of the actual Visual Composer design-time tools, such as the use of a background grid or the placement of the various toolboxes used with each board.

Runtime Environments

Models designed in Visual Composer can be deployed to run in one or more technology engines, including Web Dynpro and Flex. The same model can be deployed to more than one environment, although not all components and controls are fully supported in each. Models deployed to Flex can run on a range of browsers, including Microsoft Internet Explorer, Netscape and Firefox.

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.

Creating and Adapting Applications

In Visual Composer, you can create modeled applications from scratch, or else adapt an existing application to your specific needs. For analytic applications with standard features, it is many times significantly faster to customize an existing application by replacing data services with the required queries, for example, and making other minor adjustments. In either case, when planning to create or adapt an application, you should define the actionable information, detail the target functionality, and locate or prepare all required data sources ahead of time.

Data Services

At the heart of any of the modeled applications are the sources of the analytic and transactional data: these can be standard SAP RFCs (remote function calls) and BAPIs (business APIs), Business Warehouse info cubes, BI queries, JDBC-compliant stored procedures, Web services and others. A main strength of Visual Composer is that models can be built around any number of disparate data services and then finely tuned to display only the exact subset of data needed for the specific transaction or function.

Storyboard

You use Visual Composer to create and adapt applications, through a graphical user interface called Storyboard. This is your "work desk," on which you organize and configure components of the application into a logical flow, or model. You build the application model by defining the data services and model components, assembling and connecting them into a task flow that answers the needs of the application. You place the model elements in a screen layout that reflects the actual look-and-feel of the application in runtime. Storyboard contains a number of different boards, on which you can compose the model, lay out its components and view its source code.

Workflow

As you build your model in Storyboard, you drill down from upper-level model entities down to the lowest-level elements and controls. Usually, experts most familiar with their actual business needs will perform the initial modeling of the task flow and screen layout. Subsequent modification and configuration can be performed by other modeling experts and developers. A model is deployed to the portal in a two-stage process, in which the graphical model is first compiled into code and then deployed as an archive package to the portal.

Events

In Visual Composer, an "event" is used to signal that an action has occurred in the workflow. At that point, the system then performs the actions assigned to the event. Certain model elements - such as data flow lines - are modeled to respond to these events. For example, Visual Composer assigns names such as *evt1, submit (used with input form buttons) or *next (for layers) to data mapping lines or transition lines, indicating the action that invokes the event. These names can be changed, and they can be used for defining controls that invoke the action.

A standard event, such as submit or close, occurs when the specific control connected to the line is activated to invoke the event. For example, in the following model, two submit lines have been defined:

(Standard Event)

The use of the asterisk (*) before an event name indicates that if any event of the same name (without the asterisk) is raised, all events of the name with the asterisk will respond. In this case, if the button in Input Form 2 is pressed (raising the event), both events (actions defined for both forms) will respond. If the button in Input Form 1 is pressed, only that event will respond.

In transitions between layers, if the transition line is given the same name as the event lines within the layer, and is prefixed with an asterisk, raising the event in either form within the layer will activate the transition to the next layer. For example, a layer may contain two forms in which the user enters information, as follows:

(Transition)

If the user inputs data in Input Form 1 and clicks Submit, the transition to Layer 2 will occur. If the user inputs data into Input Form 2 and clicks Submit, the transition will occur as well.