Visual Composer Build Process

Transcription

1 Applies to: Visual Composer for Composition Environment 7.1 Summary This paper explains how Visual Composer builds & creates its applications, and what are the dependencies and naming consideration a modeler should consider when modeling his application. Author: Giora Saar Company: SAP Created on: 26 June 2008 Author Bio Giora Saar member in CE infrastructure team in Visual Composer development group 2008 SAP AG 1

2 Table of Contents Introduction...3 Visual Composer Deployment Process...4 Building Models with Dependencies...5 How does Visual Composer build your Application? Transformation of Models from GML to XGL DC Dependency calculation DC Build Application Definition...7 Troubleshooting...8 How can two users override each others content in the runtime?...8 Related Content...8 Copyright SAP AG 2

3 Introduction Visual Composer is a modeling tool that enables the execution of its models in multiple runtime environments. Visual Composer models are saved in a GML format. When the models are deployed, the GML is compiled and executed into XGL format, and then deployed into the corresponding runtime repository. The XGL (Executable GUI Language) is a generic, executable and declarative specification of graphical user interfaces for business applications. It serves as a connector between the Visual Composer models and a variety of UI runtime frameworks. To support multiple runtime environments, Visual Composer provides an infrastructure for converting XGL format into runtime-specific formats. So far, Visual Composer has supported the SAP Web Dynpro, Adobe Flash Player and Voice XML-compliant third-party voice gateway as runtime clients for its applications. With Visual Composer for SAP NetWeaver 7.0, the applications can run one Web Dynpro for Visual Composer HTML and Flex runtimes. With Visual Composer for SAP NetWeaver CE 7.1, the applications can run on Web Dynpro for Visual Composer HTML and Flex, Voice and portal. To view all registered runtime provider in SAP NetWeaver CE 7.1 go to Tools --> Options --> Compiler. Picture 1: Dropdown list of all available runtime providers 2008 SAP AG 3

4 Visual Composer Deployment Process SAP NetWeaver CE 7.1 can have more than one Runtime Provider plugged in (Web Dynpro, Voice, Portal and others). That leads to the following question: When a user creates a new Visual Composer model, which of the current runtime providers will compile (transform the model from Visual Composer language into the runtime environment language) it? The runtime provider chosen by the user in the default runtime providers dropdown list (picture 1) is be the runtime provider that will be attached by the system for each newly created model. This indicates to the system which runtime provider will be triggered during the build process. The attached runtime provider can be changed manually by the user from the Configure task panel, but be aware that changing the runtime provider can affect other models that reuse this model each runtime provider needs all referenced models (composite view, coded services and other components) to be stores in its runtime environment in order to run the application properly. If a user changes one model s runtime provider ID within the dependency chain, this model will not be deployed to the previously defined runtime environment, which can lead to a runtime exception due to a missing reference. Picture 2: Changing runtime provider for Composite View 2008 SAP AG 4

5 Picture 3: Changing runtime provider for Coded Service Building Models with Dependencies In the world of composition development, an application can be built from more than one model, each model encapsulating its implementation and exposing its input and output ports. When an application is deployed with the Include dependencies option turned on, all building blocks (dependencies) of the application are deployed and stored in the runtime environment. Thus, if a user modifies one model (after deploying all the application dependencies at least once) there is no need to re-deploy the entire group of the application s building blocks again, as they already stored in the runtime environment SAP AG 5

6 How does Visual Composer build your Application? In order to answer this question, let's assume that the Include dependencies check box is selected (the other case is simpler and can be concluded from the steps that described below) and our application is built from four models located in three different development components (DCs). Our application dependencies can be represented as follows: When a user builds the application within Visual Composer and M1 is the starting entry point of its application (Main application), the following synchronized steps occur: 1. Transformation of Models from GML to XGL Visual Composer transforms the focused (M1) model and all its dependencies recursively (M3, M4, M5) from an internal structure (GML) to an external protocol (XGL). On the client side, the transformation from GML into XGL is performed on the model dependencies. Other models that are located in the same DC are ignored. 2. DC Dependency calculation A DC dependencies calculation process determines which DCs need to be built based on the dependencies of the focused model and the dependent models dependencies recursively. The place of each DC in the build stack is determined based on the number of DCs dependent on it. In our case, the build stack is: DC B, DC C and DC A. 3. DC Build In the runtime environment, each DC is equivalent to one deployable unit, which forces Visual Composer to build and deploy all of the contents of the DC and not only part of it (the model dependencies). Thus, Visual Composer traverses the DC contents and forwards each XGL to the appropriate runtime provider. The implication in this case is that even if models M2 and M6 are not part of the model (M1) dependency chain, if they already have an XGL file, they will be compiled and deployed to the runtime environment. After all XGLs within the DC are built, the results are packed into an Enterprise Archive, also known as an EAR file (a zip file based on J2EE format) and deployed to the server (to the runtime environment). This process is executed for each DC within the build stack SAP AG 6

7 4. Application Definition Each unit within the DC marked as main unit is displayed as a link in the Deploy task panel 2008 SAP AG 7

8 Troubleshooting How can two users override each others content in the runtime? Since this version of Visual Composer is server-based and all users deploy to the same server, certain situations can allow a user to inadvertently override other user s content. a) If a user works in the local repository, it is guaranteed that no other users can see or change his/her application. The problem occurs in the Shared Repository or DTR repositories, in which all users share the same content/sources. For instance, let s look a the following case: User A has a reference from his/her model to model M1, which is located in the Shared Repository. User B is modifying M1. The changes made by user B are not visible to user A until user B submits his/her changes. Now if user B deploys the application in order to test the latest changes, the modified version of M1 will be deployed in the runtime environment. However, when user A deploys his/her models (including M1, which does not contain user B's changes), User B s changes are overridden. b) If two different users (working on the same server) create a DC of the same name, each of his/her in local repository, when they deploy their models, both DCs are deployed to the same runtime environment. Because the granularity of a deployment unit is an entire DC and because the runtime environment stores the deployed DC base according to DC name, the last deployed DC will override the first one. Related Content Visual Composer for Composition Environment page on SDN Visual Composer White Paper How does SAP NetWeaver Visual Composer for CE 7.1 differ from the previous version? For more information, visit the User Interface Technology homepage SAP AG 8

9 Copyright 2008 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 AG 9