Application Modeling

Application modeling is a method of defining application functionality without writing lines of code. Instead, you manipulate visual elements (such as controls, forms, and tables) on your workspace and create connections between them to create a reusable component that can be used in one or more applications.

Unlike classical UML modeling tools, which model programming code and then later compile that code into the application execution format, Visual Composer uses requirements modeling, which defines the application behavior using requirement terminology.

In Visual Composer, you model an application component by:

When modeling with Visual Composer, the modeling process is independent from the selected runtime environment, meaning that you can model an application once and then deploy the same application to multiple runtime environments if required. After you define the elements and their relationships, Visual Composer compiles and deploys the application component to the selected runtime environment. Components modeled using this method are more standardized and simplified, thereby requiring less effort to enhance and maintain than standard coded applications.

For example, suppose you are a manager who wants to create an application that displays the monthly sales totals for each member in your sales team. In Visual Composer, you locate the data service of the required sales information and drag it onto your workspace. You define the required input to the data service (and the UI means for entering the data) and then define the means to output the required information fields from the database to a display table. No coding is required to model this application. You simply drag and drop elements onto your workspace, define their properties, and define the application logic and information flow.

Visual Composer enables you to quickly and efficiently design and implement a modeled application that meets specific business requirements. Access to the analytic and transactional data is direct and intuitive, resulting in a fast response from the structured data. After deploying the application, you can view and use the running version of the application that you modeled. You can then return to the "drawing board" to make subsequent modifications, until you are satisfied with the results.

You can use Visual Composer to create modeled components from scratch, or you can adapt existing applications to your specific needs. For analytic applications with standard features, it is significantly faster to customize an existing application by replacing data services with the required queries, for example, and making other minor adjustments. Whether you are creating a new model, or modifying an existing one, you should define the information needed to perform the required actions, detail the target functionality, and locate or prepare all required data services ahead of time.

Models and Components

A model is an object created in Visual Composer Storyboard. It contains a single top-level component (composite view or service component), which may contain references to other (nested) components. A model contains your definition of an application, and you deploy it to the relevant runtime environment. You save the model in a development component, which is a location (like a folder) for saving your models, located within a software component hierarchy.

A component is a basic unit of modularity, reusability and execution within a model. It contains the UI elements of part of your application, and the relationships between the different elements. Each component can be reused in multiple models. When you create a component, Visual Composer bundles the resulting code, together with its component dependencies, as a model.

Reusable components can also be built from other reusable components. Rather than building an all-encompassing application component, a component can be assembled from multiple smaller components. These smaller components can then be used later in additional models.

Design Time and Runtime

Visual Composer is a design-time software tool in which you develop an application component and then deploy it. After deployment, you can use the actual application in the runtime environment to check its runtime functionality.

When you model a component, you define all the runtime attributes of the UI elements, 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.

Models designed in Visual Composer can be deployed to run in one or more environments, for example, Web Dynpro. The same model can be deployed to more than one runtime environment.

Visual Composer implements a proprietary XML-based 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. This process provides "model once - run anywhere" capability.

Data Services

At the heart of Visual Composer modeled applications are the data services, which can be standard RFCs and BAPIs (business APIs) from SAP data systems, SAP enterprise services, Web services, other Visual Composer components, and so on.

You can create a data service from scratch, or you can take an existing service component, customize it to meet your needs, and then save it as a new data service. Data service components can be reused in multiple models.

One 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 operation.

Controls and Fields

Controls are UI-based items that can be placed in a UI element (a form, table, chart, and so on). Controls are visible items: for example, a checkbox, an input field, or a combo box. You add controls by dragging them to the required location in a UI element in the workspace. You can modify the appearance, characteristics and behavior of UI elements and controls.

Fields hold data that is retrieved from one entity and transferred to another, for example, retrieved from a BAPI data service or Web service and transferred to an input form or displayed in a table. To display the data from those fields, you "bind" each field to a visible control. Depending on how you create a UI element, Visual Composer may automatically create the relevant control that is needed to display the data in the field. Otherwise, you can manually add the required control by dragging it to the UI element and binding it to a selected field.

You can also add virtual fields to a UI element. Virtual fields are fields that are not connected to a data service - you add them manually when you design a model. Virtual fields enable you to add information and to correct mismatches between data services. For example, suppose that certain information is expected in the entity to which data is being transferred, but the data (and corresponding field) does not exist in the original data service. In this case, you can create a virtual field with a bound control, so that the runtime user can enter the required data into the bound control before transferring the field to the target entity.

Life Cycle Management and Source Control

Management of the different Visual Composer component life cycle aspects - such as versioning, packaging, dependencies, and compatibility - relies on the NWDI infrastructure and component hierarchy, which is based on the software component and development component concepts.

According to the NWDI hierarchy, models are organized within software components and development components into a nested structure:

Since Visual Composer models are persisted and managed in NWDI as components, they are arranged according to the software and development components, and thus made available for reuse. One of the benefits provided by this arrangement is the possibility to deploy a complex model along with all its dependent models.

Visual Composer integrates with the SAP Design Time Repository (DTR) to provide life cycle management for models. If you do not have a source control system installed and configured to work with Visual Composer, a shared repository is provided by default. The shared repository provides basic check-in and check-out functionality (without version control) for models stored in a shared location. For more information about the DTR, see Using DTR as Development Repository.

The DTR provides source code management for versioning control of resources. Implementing Visual Composer together with the DTR enables you to track component versions and track and control component modification by different modelers who may be using the same reusable components. A different version of a model is created each time you check the model into the DTR. Associated with each version of the model is an activity, which describes the logical change made to the checked-out model.