SAP NetWeaver Visual Composer

SAP NetWeaver Visual Composer: Technical White Paper SAP NetWeaver Visual Composer: Technical White Paper Applies to: Visual Composer for SAP NetWeaver Composition Environment 7.1 Summary The purpose of this white paper is to help technical decision makers and influencers, such as CTO and IT or R&D managers at customer companies, as well as internal SAP stakeholders, gain a clear understanding of Visual Composer and generate a strong interest in adopting the tool. The paper provides background information on the industry context in which Visual Composer exists, and a technical overview of the product architecture, its underlying technologies, capabilities and benefits. Author(s): Anne Tarnoruder, SAP NetWeaver Product Management Company: SAP Created on: September 2007 Author Bio Anne Tarnoruder is a part of the Knowledge Management & Enablement team of SAP NetWeaver Product Management in SAP Labs Israel, active in the areas of Visual Composer and .NET interoperability. Prior to joining SAP in 2004, she held a number of positions in software development, team management, system architecture and technical communications in various high-tech companies. Anne holds an M.S. degree in Applied Mathematics. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1 SAP NetWeaver Visual Composer: Technical White Paper Table of Contents Applies to: ........................................................................................................................................ 1 Summary.......................................................................................................................................... 1 Author Bio ........................................................................................................................................ 1 Background...................................................................................................................................... 3 Model-Driven Development.......................................................................................................... 3 Model Driven Architecture (MDA)............................................................................................. 4 Domain-Specific Modeling (DSM) ............................................................................................ 4 Summary .................................................................................................................................. 5 Application Composition and SOA............................................................................................... 5 SAP Enterprise SOA and Visual Composer ................................................................................ 6 Target Audience ....................................................................................................................... 6 Development and Release History........................................................................................... 6 Technical Overview ......................................................................................................................... 7 Terminology ................................................................................................................................. 7 Architecture and Workflow ........................................................................................................... 9 Design-Time Workflow ............................................................................................................. 9 Runtime Workflow .................................................................................................................. 10 Modeling Framework.................................................................................................................. 10 Storyboard .............................................................................................................................. 10 GML DOM and Modeling Language....................................................................................... 12 XGL Specification....................................................................................................................... 14 XGL Document ....................................................................................................................... 14 How It Works .......................................................................................................................... 17 Lifecycle Management ............................................................................................................... 18 Reusability and Componentization......................................................................................... 18 Persistence, Source Control, and Model Management.......................................................... 18 Summary of Capabilities and Benefits ....................................................................................... 19 Application Modeling/Composition ......................................................................................... 19 Execution................................................................................................................................ 19 Extensibility............................................................................................................................. 19 Copyright........................................................................................................................................ 20 SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 2 SAP NetWeaver Visual Composer: Technical White Paper Background This section provides some background information about the industry context and the market needs that are addressed by Visual Composer. Model-Driven Development Software modeling has been around since the 1980s, when the CASE (Computer-Aided Software Engineering) tools were first introduced. CASE tools are automated tools that assist in the development and maintenance of software, such as design, data and process modeling, or version control. The first generation of CASE tools mostly supported isolated tasks such as diagramming or document production. With the advent of object-oriented programming in the mid-1990s, Rational Software introduced UML (Unified Modeling Language), whose first specification was submitted to OMG (Object Management Group, a computing industry consortium) in 1997. This brought about the next generation of CASE tools, which enabled integrated iterative development process by supporting round-trip engineering: forward engineering by diagramming and code generation, and reverse engineering of the compiled code by extracting its object model and mapping it to a diagram. Although the CASE tools of that early period created considerable interest, they did not quite deliver the expected boost of productivity, because they addressed only certain aspects of software development lifecycle, did not provide an integrated environment, and were difficult to use. In the following years, the approach to modeling shifted to viewing a model not just as a design aid used only at the start of a development cycle and discarded later, but as an integral and iterative part of a development process. This shift led to the advent of Model-Driven Development (MDD), which is a method for fast, efficient, and low-cost software development based on modeling rather than coding. It can be viewed as the next evolutionary step from Rapid Application Development (RAD, the method enabled by visual tools that accelerate creation of application UI and business logic, such as Visual Basic or Delphi). Recent modeling and development tool innovations are making MDD a feasible approach to software engineering. The IDC (International Data Corporation) study Worldwide Model-Driven Development Software 2005-2009 Forecast and 2004 Vendor Shares includes the following quote from Stephen D. Hendrick, Group Vice President, Application Development and Deployment Research, at IDC. "The model-driven development market is now poised to realize sustained higher growth than any time in its recent history. Today's emphasis on a more structured approach to application development and deployment is providing modeling tools with a unique opportunity to become the primary focal point for application development activities." The motivation for MDD is to reach the following goals: • • Achieve a major increase in software development productivity, surpassing the 400% increase achieved with the transition from assembly languages to algorithmic languages in the 1980s. Lower the total cost of ownership (TCO) of software lifecycle phases, such as creation, evolution and maintenance, by aggregating, standardizing, and automating the majority of programming tasks, thereby decreasing software complexity. Eliminate or minimize the need for coding, enabling domain experts to bring their expertise directly into the software development process, thus narrowing the gap between application definition and implementation. Detach from a specific runtime platform or implementation, and allow optimizing or even replacing the complete runtime without reimplementing any of the modeled applications. • • However, it would not be realistic to expect these goals to be achieved quickly - rather, it would happen gradually over an extended period of time, with progress made rapidly in some areas and slowly in others. Currently the two main trends in model-driven development are Model Driven Architecture (MDA) and Domain-Specific Modeling (DSM). SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 3 SAP NetWeaver Visual Composer: Technical White Paper Model Driven Architecture (MDA) Officially launched in 2001 by OMG, MDA represents the domain-independent general- purpose approach that separates the specification of system functionality from the specification of its implementation on a specific technology platform. With this approach, system functionality is defined in a number of related platform-independent models, which cover different aspects of the system. These models are then transformed into platform-specific models or generated code targeted at the corresponding platforms, such as .NET or Java EE. These transformations are usually performed by automated tools that are compliant with the OMG standard QVT (Queries/Views/Transformations). A range of MDA tools is currently offered by multiple vendors and open source projects, such as IBM Rational Software Modeler, Sparx Systems’ Enterprise Architect, No Magic’s MagicDraw and Borland Together. However, as of now, there is no major MDA tool vendor in the industry. Unlike UML, which is an established industry standard, the MDA general purpose approach has yet to gain mainstream industry acceptance because of a number of concerns, such as incompleteness of the standards, low vendor interoperability, complexity, and requirement for a high level of user skills. . However, the core MDA standard, OMG's Meta-Object Facility (MOF), has been implemented as the foundation for a number of domain-specific languages, such as Eclipse Modeling Framework (see the following section). Domain-Specific Modeling (DSM) Domain-specific modeling tools and languages (DSL) are designed to raise the level of abstraction for specific domains and/or technologies, such as the user interface of a mobile phone, or an ecommerce site. Domain-specific modeling raises the level of abstraction beyond programming by creating high-level specifications of the solution using domain-specific concepts and automatically generating executable code from these specifications. Most domain-specific modeling tools are supported on existing DSM frameworks or through DSM environments, such as: • Open Source Eclipse platform o Eclipse Modeling Framework (EMF) is a Java framework and code generation facility for building tools and other applications based on a structured model. The metamodel of EMF, Ecore, is a compact Java implementation of a core subset of the API of OMG's Meta-Object Facility (MOF). o Graphical Editing Framework (GEF) allows developers to take an existing application model and quickly create a rich graphical editor. o Eclipse Graphic Modeling Framework (GMF) provides a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF. o Generic Eclipse Modeling System (GEMS) is a tool for rapidly specifying graphical DSM languages using a visual metamodeling language and generating Eclipse plug-ins for editing the DSM. MetaCase MetaEdit+ MetaEdit+ is a DSM environment that provides not only modeling, but also interactive metamodel (modeling language) definition tools. It is designed to be platform independent and supports major platforms, such as Windows, Linux, Mac, and Solaris. MetaEdit+ supports automatic code generation for multiple programming languages, such as C++, Java, SQL, and Delphi. The MetaEdit+ environment consists of two main components: o o MetaEdit+ Workbench is a graphical tool for defining a domain-specific modeling language, including its concepts, rules, notations, and generators. MetaEdit+ uses the given modeling language definition and automatically provides full modeling tool functionality, such as diagram editors, browsers, and generators. • SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 4 SAP NetWeaver Visual Composer: Technical White Paper • Microsoft Software Factories Conceptually, a software factory is a paradigm of an assembly line that enables the automation of software development. This is made possible by configuring extensible development tools with packaged content and guidance, designed for building specific types of applications. Microsoft Software Factories, first introduced in 2003, is a strategy of integrating model driven development, development by assembly, systematic reuse, and process frameworks into an approach that enables organizations with domain expertise to implement domain-specific models, patterns, frameworks, and tools required to automate development in their specific domains. For example, Visual Studio 2005 Team Edition for Software Architects provides a set of custom model-driven DSL tools, which target the design of distributed applications. The Distributed System Designers, code-named Whitehorse, is a suite of four design tools that together make up an environment for designing, developing, and validating a deployment of a distributed system: o o o o Application Designer allows developers and architects to define applications that are configured into systems for deployment. Logical Datacenter Designer is used to create diagrams of interconnected hosts that represent the logical structure of a datacenter in the target deployment environment. System Designer is used to compose applications into systems. Deployment Designer is used to bind applications within a system to logical servers (application hosts) modeled in the Logical Datacenter Designer. Summary Both MDA and DSM approaches have gained vendor support and are represented in today’s software industry. However, according to Grady Booch, Chief Scientist of IBM Rational since 1981 and one of the original developers of UML, “the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts." (Grady Booch, Alan Brown, Sridhar Iyengar, Jim Rumbaugh, Bran Selic, MDA Journal, May 2004). By definition, DSM is focused on a specific narrow domain and thus can closely fit its needs; therefore it can be applied to a wide variety of domains. Industrial experiences with DSM consistently show it to be 5-10 times faster than other current practices, including today’s UML-based implementations of MDA. Application Composition and SOA As modeling tools and standards have evolved, they have played an increasingly prominent role in modern application design and development in complex distributed business environments. In recent years, we have witnessed a shift in focus from application modeling to application composition, especially in the context of service-oriented architecture (SOA). SOA is a software architecture based on protocol-independent distributed applications composed from well-defined, self-contained, loosely coupled resources accessible as services in a standardized way across the extended enterprise. The distributed applications, known also as composite applications, are built or rather composed from building blocks that draw their functionality from a variety of components within SOA. These components may be individual Web services, selected functions from other applications, or entire systems whose outputs are available as Web services, characterized by functional focus, fine granularity, high level of encapsulation and reusability, and robustness. Composite applications, assembled from the components, focus on business processes rather than on specific functions, which are provided by these components. These composite applications are characterized by high flexibility and customizability, coarse granularity, and short development time. According to the most recent IDC study “Worldwide Model -Driven Development Software 2006.2010 Forecast and 2005 Vendor Shares“ (IDC, December 2006), “SOA is a key step in the evolution of software toward componentization and composite applications. Advantages of SOA include loose coupling, reuse, standardization, and infrastructure centricity. Modeling tools will rapidly evolve to support SOA.” SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 5 SAP NetWeaver Visual Composer: Technical White Paper SAP Enterprise SOA and Visual Composer SAP enterprise SOA is a foundation for an adaptable and open IT architecture used to develop servicebased, enterprise-scale business solutions. This foundation is enabled by SAP enterprise services, which are collections of closely related Web services that together support a particular business process, and composition tools. As part of its enterprise SOA offering, SAP provides a number of application development and composition tools, including SAP Composite Applications Framework (CAF) and SAP NetWeaver Visual Composer. Visual Composer is a visual domain-specific tool for business application modeling, which in conjunction with the SAP business process platform constitutes a powerful business application composition tool in SAP enterprise SOA. Visual Composer: • • • • • Eliminates the need to write code by producing applications in a declarative form, and enables their execution in multiple runtime environments Provides application development lifecycle support in the modeling environment by maintaining a model as the primary development artifact Has an open architecture that allows developers to extend its design-time environment and the modeling language, as well as integrate external services and components Enables a major productivity gain in application development, reducing development effort from weeks and months to single days Provides domain experts with the tools to express their requirements directly, thus narrowing the gap between application definition and implementation However, development with Visual Composer is not entirely code-free. In situations where its modeling tools do not cover certain application development needs, Visual Composer allows integration of custom components and services, created with other tools. Target Audience Visual Composer is being developed as a tool that can be used by business process experts (BPX) with no coding skills, as well as by application developers or architects who have sufficient knowledge of the business domain and requirements they need to implement. Its learning curve is short and its toolset is flexible enough to serve a range of users with different skill levels, enabling a user with basic skills to become productive relatively quickly, and an advanced user to create complex and powerful applications. Development and Release History Visual Composer was initially developed by Yuval and Rinat Gilboa in their startup company GUIMachine, acquired by SAP in 2004. Having undergone intensive development since then, the tool has the following release history: Visual Composer for SAP NetWeaver 7.0. (formerly Visual Composer for SAP NetWeaver 2004s Freestyle) was released in 2006, and is used by: • • SAP xApp Analytics who created a package of ~200 analytic dashboard composite applications Over 250 customers, such as Metro, PetroBras and Coca Cola, who create dashboards and transactional applications Visual Composer for SAP NetWeaver Composition Environment 7.1 is scheduled to be released in 2007 as part of the SAP NetWeaver Composition Environment. This version of Visual Composer has many new capabilities, such as componentization, lifecycle management integration, layout design, and more. The following technical overview applies to the latter version. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 6 SAP NetWeaver Visual Composer: Technical White Paper Technical Overview This section provides a high-level overview of the product architecture and underlying technologies, focusing on the following topics: • • • • • Terminology Architecture Modeling framework XGL standard Lifecycle management Terminology The following section briefly introduces the terms used in this overview and explains the roles and relationships of all parts of the Visual Composer architecture, many of which are described in detail further on. Model (Component) A collection of interconnected visual elements representing the UI and business logic of an application. Models are created, packaged and maintained as reusable components; therefore, in terms of lifecycle management and usage, they are also referred to as components. For more information, see Reusability and Componentization. GML Generic Modeling Language, a proprietary XML-based format in which models are persisted. Visual Composer uses GML to describe and process models. For more information, see GML DOM and Modeling Language. XGL Executable GUI Language, a generic, executable and declarative specification of graphical user interfaces for business applications. Visual Composer models are compiled from GML format into XGL format for runtime execution. For more information, see XGL Specification. Visual Composer Storyboard The browser-based design-time environment of Visual Composer, which provides a set of interactive tools for application modeling. For more information, see Storyboard. Application Server Java (AS Java) SAP NetWeaver Application Server based on Java EE 5 standard, an SAP platform for developing, executing and running applications and Web services, including Visual Composer. Visual Composer Server A service within AS Java that is the direct server-side counterpart of Visual Composer Storyboard. It provides a number of important services for the modeling framework, such as persistence, source control and model management, and deployment. Its open architecture allows developers to extend Visual Composer clientside and server-side functionality using custom plug-ins. NetWeaver Development Infrastructure (NWDI) An SAP development infrastructure that, together with the SAP NetWeaver Developer Studio, makes up a complete Java development platform. This infrastructure, located centrally on an SAP Application Server (AS Java), provides developers, testers, and administrators with everything they need for the software creation process, such as central design-time source control, component build service and change (landscape and transport) management, as well as Web-based administrative tools. Design-Time Repository At design time, models are persisted either locally, in the user’s private workspace, or in a central repository shared by all users. This repository may have source control capabilities, such as NWDI DTR (Design-Time SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 7 SAP NetWeaver Visual Composer: Technical White Paper Repository) or may merely serve as a shared workspace. For more information, see Persistence, Source Control and Model Management. Data Services Services that enable access to various data sources, such as databases, back-end systems or Web services. Connector Framework An SAP infrastructure that enables applications to access a range of data services. The connector framework is based on the Java EE 5 and Java EE Connector Architecture (JCA) standards. The connector framework allows users to plug in custom connectors that implement connectivity to specific data services and provide a generic API to applications. Currently, Visual Composer provides connectivity to SAP R/3 back-end systems, SAP Enterprise Services Repository, SAP Business Information Warehouse, databases, and Web services. Runtime Repository A repository in the runtime domain, or deployment container that stores the deployed models in their executable format. The repository is a part of the AS Java infrastructure, which enables different runtime engines to deploy applications to their own repositories, and then retrieve and execute their applications from there. Each runtime engine has its own repository and uses a specific executable format. Runtime Client Applications created with Visual Composer can run in different runtime clients. Currently, supported runtime clients are SAP Web Dynpro,Adobe Flash Player and VoiceXML-compliant third-party voice gateway. Runtime Engine A service running in the AS Java, which processes models and renders applications into the runtime client. For example, the Flex Presentation Server together with supporting tools renders applications into the Adobe Flash Player. Web Dynpro An SAP technology and toolset used to develope user interfaces for business applications. Its model-driven approach minimizes manual coding and uses visual tools to design and reuse UI components. Web Dynpro is based on a powerful and flexible Model-View-Controller architecture that ensures a clear separation of user interfaces and backend services. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 8 SAP NetWeaver Visual Composer: Technical White Paper Architecture and Workflow The following diagram depicts the Visual Composer high-level architecture and workflow. Design-Time Workflow At design time, a user performs the following steps in Visual Composer Storyboard: 1. Creates or modifies a model: a. Discovers appropriate data services and adds them to the model. b. Selects necessary UI elements and adds them to the model. c. Connects model elements to define the model logic and data flow. d. Defines the layout of the UI elements. 2. Saves the model in GML format to the available design-time repository. 3. Deploys the model. At this step, the model is compiled from GML format to XGL format, and business logic integrity is validated. To support multiple runtime environments, Visual Composer provides an infrastructure for converting XGL format into runtime-specific formats. This conversion can be executed by either compilers or interpreters. A compiler is a custom plug-in integrated with Visual Composer infrastructure that compiles model from XGL into the runtime-specific format, packages and deploys it into the appropriate runtime repository. The runtime engine retrieves the package and renders the application into its client. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 9 SAP NetWeaver Visual Composer: Technical White Paper An interpreter in the runtime environment retrieves the model deployed directly in XGL format, reads and interprets XGL, rendering it into the runtime client. Runtime Workflow The runtime engine performs the following actions: 1. Retrieves a model in either XGL or runtime-specific format from the runtime repository. 2. Renders the application into the actual runtime client. 3. Establishes connection with the data services in the model to retrieve or store data. Modeling Framework The modeling framework is the underlying infrastructure of Visual Composer. It is comprised of Storyboard, XGL compiler, GML DOM, and the Visual Composer server. Storyboard Storyboard is the design-time environment of Visual Composer. It provides a set of AJAX (Asynchronous JavaScript and XML)-based interactive tools for application modeling, which ensure efficient and responsive user interaction. Storyboard runs in the browser. Storyboard has two boards for different work modes: • • Design board for defining the model logic Layout board for positioning the UI elements With the wide collection of model elements provided by Storyboard, you can design your application UI, data flow, events and process flow by dragging and dropping these elements onto the Design board, and defining their properties, relationships, and connections. Afterwards, you preview and adjust the positions and sizes of the UI elements on the Layout board. Storyboard allows users to search for and browse through data services in the available repositories, and integrate the selected services into models. When services retrieve clusters of aggregated data, Visual Composer provides tools that enable the user to view the nested data structure and select a subset of this data required for your application. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 10 SAP NetWeaver Visual Composer: Technical White Paper The following figure shows a model on the Design board of Visual Composer Storyboard. On the Layout board, users can preview, adjust and refine their application UI in an almost WYSIWYG manner. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 11 SAP NetWeaver Visual Composer: Technical White Paper GML DOM and Modeling Language Document Object Model (DOM), defined by the World Wide Web Consortium (W3C), is a platform- and language-independent standard object model for representing HTML, XML, and related formats that enables programs and scripts to dynamically process the content, structure, and style of documents in these formats. GML (Generic Modeling Language) is an XML-based language, compliant with the DOM standard that Visual Composer uses to describe, persist, and process models. GML DOM is the underlying object model of GML, which is implemented in Storyboard as a collection of visual elements available for application modeling. This collection includes approximately 50 predefined elements, such as form, table, chart, tabstrip, wizard and various UI controls, such as button, radio buttons group, and calendar. Also, it contains connectors for modeling application dynamics and data flow, such as signals and data store, as well as operators, such as sort and filter, used to manipulate data retrieved from data sources without the need to modify the original data services. The following is a GML language sample that describes a composite view component that retrieves a list of banks from a BAPI/RFC data service, and displays it in a table in an output form. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 12 SAP NetWeaver Visual Composer: Technical White Paper The following figure shows a fragment of the GML DOM class diagram. It shows the hierarchy of the controls that includes simple controls (such as the input control, the range control, and the selection control) and group controls (such as the group box and the toolbar). SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 13 SAP NetWeaver Visual Composer: Technical White Paper XGL Specification Visual Composer uses two XML-based languages to describe its models: GML, a language in which models are persisted at design time, and XGL (Executable GUI Language), into which models are compiled for runtime. XGL, one of the most significant features of Visual Composer, forms the foundation of its execution infrastructure. XGL is a declarative specification language designed to serve as the common ground between user interface modeling tools and a variety of UI runtime frameworks. It provides a self-contained, closed and deterministic definition of all aspects of a graphical user interface in a device- and programming language-independent manner. XGL makes it possible to define the behavior of a GUI almost completely declaratively, eliminating the need to code this behavior with programming tools. As a build-time language, XGL does not need to cover the design-time concerns, so its constructs are less complex and numerous than that of GML. The XGL semantics are defined using an abstract model of a GUI framework. To enable a GUI framework execute an XGL specification, framework-specific code generators or interpreters are needed to convert an XGL specification into executable runtime code. The design of XGL specification ensures that XGL can be implemented on most GUI frameworks. This has already been verified through implementation of specific XGL compilers and interpreters for representative classes of GUI frameworks, such as the Flex compiler for Adobe Flash Player. SAP is considering the possibility of launching an initiative to make XGL an industry standard. XGL Document An XGL application is a collection of reusable XGL components, which render user interfaces, perform data services, and control processes and workflows. Components can invoke, embed, or navigate to other components. Each XGL component is written in a separate XGL document, which is a valid XML file conforming to the XGL schema. The XGL document is self-contained and provides all the information required to generate and execute the component. Other components can be referenced from within a component's XGL document. A complete application can be packaged as a collection of XGL documents with cross-references, compiled, if necessary, into a format recognized by the runtime framework, and deployed to the corresponding runtime repository. The framework will retrieve the package and run the application. The body of an XGL document consists of one or more declaration sections. Each declaration section declares a certain aspect of the application, such as UI, data and operations on the data, flow control, or resources. The distribution of elements by declaration sections is as follows: • Data o o Data types, fields, operators and expressions Infoshapes (simple and complex data structures, such as records, arrays, clusters), infosets (snapshots of application data), infoviews (updatable infosets); infoactors (application data services) Operators (elements that transform input data into output data); enumerations (discrete lists of value-text items) o • Window Controls, interactors (forms, views), containers (UI areas containing interactors), application windows. • Controller o o Actions (UI commands for performing UI-related tasks and executing application services, such as an action on a button click) Relays (points where execution flows and/or data flows cross XGL component boundaries) SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 14 SAP NetWeaver Visual Composer: Technical White Paper o • Execution plans (represent a single event and the sequence of execution steps it triggers) Embedded images, color palettes, and translation texts Systems (represent connections to back-end systems that provide access to application data services References to reusable components used by this XGL component Resources o o o The following sample illustrates the structure of an XGL document. It includes all declaration sections: data, window, controller and resources. data-section-decl: infoshapes-section infosets-section infoactors-section operators-section enumerations-section window-section-decl: container-declnested interactor-declmany control-declmany controller-section-decl: actions-section relays-section execution-plans-section resources-section-decl: images-section palettes-section translations-section systems-section references-section SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 15 SAP NetWeaver Visual Composer: Technical White Paper The following sample XGL file specifies a composite view component that retrieves a list of banks from the BAPI_BANK_GETLIST data service, and displays it in a table in an output form. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 16 SAP NetWeaver Visual Composer: Technical White Paper How It Works During deployment, a model is compiled from GML into XGL. If a compiler is used, the model is compiled and packaged into the runtime-specific format; otherwise it is packaged in XGL, and then deployed into the corresponding runtime repository. The runtime engine retrieves the package from the repository and renders the application either directly, if it is compiled, or with the help of an XGL interpreter. The following figure illustrates this workflow in configurations with XGL compilers and interpreters. An XGL interpreter is a little harder to implement than an XGL compiler, but offers more power and flexibility. An interpreter is also simpler in terms of software logistics, since there are no generated components that need to be packaged and deployed. In terms of performance, both approaches are almost equivalent. Currently, SAP provides the following XGL compilers and interpreters: • Shipped with Visual Composer for SAP NetWeaver 7.0 • • Web Dynpro for Visual Composer interpreter for HTML Flex compiler • Shipped with Visual Composer for SAP NetWeaver CE 7.1 • • Web Dynpro for Visual Composer interpreters for HTML and Flex VoiceXML interpreter SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 17 SAP NetWeaver Visual Composer: Technical White Paper Lifecycle Management One of the important aspects of Visual Composer modeling is lifecycle management, which encompasses the areas of componentization, packaging, storage, source control, and maintenance. Reusability and Componentization To ensure reusability of models created with Visual Composer, they are packaged and maintained as components with clearly defined interfaces. Components created outside of Visual Composer can also be reused in models. Management of the different component lifecycle aspects – such as versioning, packaging, dependencies, and compatibility – relies on the existing NWDI infrastructure and SAP component model, which is based on the software component (SC) and development component (DC) concepts. According to this scheme, development projects are organized by components into a nested structure: • • • Development objects are created in the context of development components and stored as versioned files in the Design Time Repository (DTR). They provide public interfaces of the component, accessible by other components. Development components (DC) are development and build units that group development objects without overlapping. Software components (SC) are delivery and installation units that group development components. Since Visual Composer models are persisted and managed in NWDI as components, they are arranged according to software and development components, and made available for reuse. One of the benefits provided by this arrangement is the possibility to deploy a complex model together with all its dependent models. Components are reused by reference, which means that one does not create a copy of the component but rather creates a reference to it. If a reused component is modified, all other models that reuse it are affected. Modelers can use the search mechanism of Visual Composer to locate reusable components in a local or shared repository, and then drag-and-drop the selected component onto the currently opened model. Next, they define and configure connections between the model and the component. It is possible to nest the reference to the reused component inside the model so that at runtime it opens in the same window, or link it with a navigation connector so that it opens in a new window. Persistence, Source Control, and Model Management The Visual Composer modeling framework supports persistence and model lifecycle management through source control services. Source control capabilities for a shared development environment are enabled by one of the following solutions: • NWDI Design-Time Repository (DTR) A part of NWDI that enables shared storage and version control of the models and components. It can optionally be integrated with Visual Composer. • Third-Party Source Control System Although this option is not currently supported, Visual Composer has an infrastructure for integrating an alternative third-party source control system. Such system can be physically located outside the Visual Composer domain. If no source control system is available, models can be stored in the shared repository in the AS Java server database, which serves as a basic design-time repository with limited source control capabilities, meaning that only the last model version is saved, replacing the previous one. In all cases, Visual Composer accesses a repository through a uniform API provided by the NWDI, which hides the actual repository implementation details. Storyboard includes a model management UI that exposes a subset of source control functionality provided by NWDI, which enables basic source control operations, such as check-in and check-out. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 18 SAP NetWeaver Visual Composer: Technical White Paper Summary of Capabilities and Benefits The benefits of Visual Composer encompass the areas of application modeling and composition, execution, and extensibility. Application Modeling/Composition • Modeling (composing) complex application UI Enabled by a rich graphical toolset and standardized aggregated UI blocks that minimize the development effort by producing a uniform and consistent user interface and application flow. • External data services and components Visual Composer enables the discovery, integration and consumption of external data services through SAP Connector Framework, as well as integration of external components created with other technologies. • Componentization and reusability Models created with Visual Composer are packaged and maintained as components with public interfaces, which enables them to be reused in other models. Integration with an existing NWDI infrastructure provides management capabilities for different aspects of the component lifecycle, including versioning, packaging, and dependencies. • Application lifecycle support The connection between an application and its model is maintained throughout its lifecycle, so the only way to modify an application is to modify the model. No manual coding and code maintenance is required, which significantly reduces the overall maintenance effort. Execution Generation of declarative executables is based on the Executable GUI Language (XGL) specification that provides a comprehensive coverage and formalization of all aspects of application UI and flow, and enables execution of applications in multiple runtime environments. Extensibility To enable functionality that is not present or sufficient in its core version, Visual Composer allows developers to programmatically extend the tool’s design-time environment and core modeling language. This is achieved by creating custom plug-ins – either client-side or server-side – that add new capabilities and tools or enhance existing ones, such as UI elements and controls, menus, toolbars, task panels, dialog boxes and wizards, as well as change certain design-time behaviors. All these capabilities represent a unique combination that makes Visual Composer a powerful solution for business application composition. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 19 SAP NetWeaver Visual Composer: Technical White Paper Copyright © Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C 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. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent. SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 20