SAP component model support in Visual Composer 7.1...

former_member198222 · ‎01-03-2008

Hi all,

My name is Rachel Ebner, and I am a Visual Composer architect, responsible for infrastructure topics.

It gives me pleasure, mixed with some excitement, to write a blog that describes some of the architecture topics in Visual Composer for CE. In this blog, I hope to describe some "under the hood" structures and behaviors of Visual Composer for CE.

I will do my best to provide with what I consider "the big picture", and give links to other articles or the official help pages where further details are needed.

If some details do not exist - then this is the place I hope you'll find them.

Introduction

In my first blog post, I want to explain some things about the shift in model structure from Visual Composer 7.0 to Visual Composer for CE.

Most of the details (what was changed) were explained in detail by Guy Kirschbaum in his article "How does SAP NetWeaver Visual Composer for CE 7.1 differ from the previous version".

In his article, Guy describes the differences between the model structure in Visual Composer 7.0 and Visual Composer for CE, and at the end of the article he lists the advantages of the new model structure, as follows:

Lifecycle management of models is integrated with SAP tools
Reusing model parts between different models is now possible
Integration with different SAP technologies (such as WebDynpro Foundation and CAF) becomes feasible and intuitive (will be part of the next versions)
Model size is now reduced to manageable levels
The ability to use a finer model granularity enables Visual Composer to provide greater simplicity and modeling efficiency

In this blog, I'll go into more detail about the first bullet: Lifecycle management of models is integrated with SAP tools.

What tools does SAP provide for product lifecycle management?

The SAP tool for lifecycle management is NetWeaver Development Infrastructure (also known as NWDI), included as part of NetWeaver 7.0.

SAP NetWeaver Development Infrastructure (NWDI) is a set of server-side services, which centrally provides the development teams with a consistent development environment and supports software development during the entire lifecycle of a product.

(Note that you can configure your NetWeaver CE installation to work with NWDI 7.0. If you do not have NWDI, you can use the Visual Composer shared repository for source control with basic check-in and check-out capabilities instead of NWDI.)

NWDI includes the following services:

Design Time Repository (DTR): Provides versioning source code management, enables distributed development of software in teams and transport and replication of sources.
Component Build Service (CBS): Provides a central build based on the component model.
Change Management Service (CMS): Enables central administration of the Java development landscape and the transports covering the entire software lifecycle.

All these services assume that your software is structured in a specific way, called the SAP component model, and that the NetWeaver Developer Studio also supports development in the SAP component model structure.

Visual Composer supports using the SAP component model structure for development of modeled applications. Using this structure enables development teams to use the above NWDI services for applications modeled in Visual Composer, and not only for applications created by coding.

So, what does the SAP component model consists of?

Development objects: Files containing content as part of software development using a given technology.

Examples for development objects are java files, descriptor files, resources such as images, string tables, Web Dynpro models, and also Visual Composer models. All these development objects are understood by specific development technology.

Development Components (also known as DCs): Development and build units that group development objects.

If development objects are files, then you can think of development components as a folder structure, with some limitations on the structure and some additional descriptor files. The top level folder represents the development component, and a build operation can compile all its content.

Software Components (also known as SCs): The grouping of development components. Software components are units of delivery and installation; when you install or deliver your software, you want to handle entities larger than individual development components.

I strongly recommend to those of you who'd like more details, to read this documentation, describing these concepts in more details.

How does Visual Composer support the SAP component model?

Visual Composer models are stored in the structure of DCs and SCs, even when you develop models locally (not using source control). We maintain this structure to allow for easier integration throughout the SAP development infrastructure.

Once you check in models in Visual Composer into DTR, they are handled by NWDI like any other DC type: they are built using the CBS, and can be managed and transported using CMS.

Visual Composer hides a lot of details of the DC structure, to simplify working with the tools. For example, DC dependencies, DC public parts, and details of the DC folder structure, are not visible from Visual Composer.
In many cases this is helpful. Sometimes to understand how things really work behind the scenes, you will need to understand more details about the model structure inside the DCs. In future blog-posts I will elaborate on this.

To conclude, I tried to give some pointers on the topic of the SAP component model to those of you who are new to this subject, and explain the advantages of structuring Visual Composer models in DCs and SCs.
I hope that I answered some questions, but I am sure that I raised some more
I will be happy to read your comments!

All the best,

Rachel