This blog will give you an introduction about the architecture and the core concepts of the SAP Web Channel Experience Management platform. This knowledge should provide a valuable basis for implementing of the extension concepts, which allow our partners and customers to extend the solution to their needs.
In general, the SAP Web Channel Experience Management platform is based on a typical 3-layer architecture:
- UI and interaction layer
- Business object layer
- Back-end object layer
The intention of the 3-layer architecture is the logical process separation of a Web-based application. All 3 layers communicate with each other through well-defined interfaces. This allows a high degree of extensibility and reusability. That means, for example, that a particular business object can be replaced or extended by a custom implementation,without adjusting the dependent UI and interaction layer or the back-end object layer.
Besides this, flexible configuration data and module management are available to support extensibility and reuse of already implemented business processes. To enable business users and administrators to easily manage the deployed application with their modules, a Web-based application, called Web Channel Builder, is available. In addition, several common services such as search framework and user management are part of the framework, and can be used in each implemented module.
The following picture shows the high-level overview of the SAP Web Channel system architecture, and outlines a simplified view of all involved components:
Web Channel Core Framework
The Web Channel framework is build on the Web Container of SAP NetWeaver AS Java. Web Container allows clients to execute request-/response-oriented programming code based on the servlet technology, so that a servlet receives a request in the form of an HTTPServletRequest and returns a response in the form of an HTTPServletResponse. This technology is the basis for Java Server Faces (JSF), which is a Java standard framework for building server-side Web applications. By using JSF, the UI development is driven by Facelets, which apply a component-driven pattern.
The UI and interaction layer is based on JSF 2.1 and represents the highest level of the Web application with focus on the user interface to render the requested content. Several extensions were implemented by SAP on top of JSF to provide suitable functionality for state-of-the-art Web applications. Because the framework integrates deeply the JSF technology, we recommend strongly to get familiar with the standard JSF to get better understanding of this layer and the programming model.
The architecture of JSF implements the model-view-controller design pattern, where the views and controllers are contained in the UI and interaction layer, but the model is contained in the business object layer. That means that the business object layer represents and holds the processed business data within a user session, and provides business functionality that is not connected to any back-end system details. If business objects have to communicate with a back end, they will never access them directly from their level but instead using well-defined interfaces provided by corresponding back-end objects.
The back-end object layer implements these interfaces to provide multi-back-end functionality. Although these implementations are backend-specific, the interfaces themselves are not. The back-end objects are mainly responsible for exchanging data from/to a back-end system like SAP ERP or SAP CRM. On this level only, specific logic related to these back-end systems is implemented, for example, the call of an ABAP function module.
To summarize, the UI and interaction layer typically communicates with the business object layer to receive the requested data. Then the business object layer communicates with the back-end object layer to access business data that is not yet available, persisted in an underlying back-end system.
All business functionality built upon the Web Channel framework is based on the modularization paradigm. Modules, as encapsulated building blocks of SAP Web Channel Experience Management, provide reusable units of functionality, which can be assembled into an application at runtime, using the Web Channel Builder tool.
Technically, the module concept provides an encapsulated development approach at design time, and a decoupled deployment model at runtime. The main advantages are:
- a high degree of interchangeability and technical decoupling
- improvement of maintainability
- optimized development-deployment cycle
- well-defined reusability parts
This approach is intended for any kind of modifications as well, so that by extending SAP modules again, partner modules or customer modules need to be created. These modules then inherit, and so reuse, the standard functionality.
Each module has a unique module ID and a standardized structure modeled by module parts. Each part contains different aspects of a module, and each part contains certain information or pieces of functionality that are available to other modules or the runtime framework. The following parts are available:
MD part (metadata)
Metadata related to the entire module is stored within the MD part. As well as some fundamental data like module ID or module type, references to other configuration files and dependencies on other modules are also defined in this part.
UI part (UI implementation)
The UI and interaction layer of a module is developed in the UI part, and certain view components and pages can be made public to other modules. The UI part itself does not contain business functionality, but only implements the presentation layer and uses view component handlers that are defined in the UI repository and managed by the Web Channel framework.
BO part (business and back-end implementation)
All the modules’ business and back-end object layer functionality is developed within the BO part. Business objects can be made available to other modules by defining and implementing interfaces.
INTF part (interfaces)
The INTF part owns all module interfaces related to the functionality offered by a module that can be used by other modules. Other modules may only define references to the INTF parts, but never directly reference the UI part or the BO part.
DPU part (deployment unit)
Each module has its own deployment unit, which is achieved by the DPU (deployment unit) part. As a build result, an EAR or SDA file will be created that contains one JAR file per module part (MD, UI, BO, INTF). Since each module has its own deployment unit, modules can be deployed decentrally and independently of each other.
Configuration Data Management
Configuration data management (CDM) is a framework component that provides the functionality of creating, maintaining, reading, and persisting Web Channel-related settings. CDM is used by the administration tool Web ChannelBuilder to create and store settings, and it is also accessed by the modules during runtime to read the module settings.
The following CDM entities have a hierarchical relationship to each other:
An application represents a long-term-focused frame with only a few global settings, such as back-end type (SAP CRM or SAP ERP) or user storage system. Each application has a stable ID, which is used when accessing the Web site to determine the current active configuration.
Each application contains one or more configurations. One of the most important pieces of information on configuration header level is the “valid on” date and time, where the starting point of productive availability is defined. Additionally, each configuration has its own settings such as UI themes, pages with layouts, and most importantly, the selected modules as a basis for the available business functionality.
In general there are three groups of configurations:
Either configurations in preparation which are not yet completely set up, or already completed configurations that are not yet approved or not yet active (relating to the “valid on” entry).
Completely set up configuration that is active (relating to the “valid on” entry). Only one configuration may be active at one time.
Completely set up configurations that were displaced by another active configuration, and therefore expired.
Each configuration defines which modules are part of it. Each module can have again module-specific settings, which contain all the Customizing data for a specific customer scenario.
The following picture illustrates the hierarchical CDM entities: application (“B2C Shop”), configuration (“Easter”), and module configuration (“Marketing”, “Catalog”, …). Additionally, the three kinds of configurations are shown: pending, active, and expired:
This overview of the Web Channel Experience Management framework architecture with some more details relating Module Management and Configuration Data Management should provide first starting point for a successful extension or implementing of a web-based application. Additional study of the standard JSF framework should intensify the knowledge and is highly recommended.
As already indicated, this framework offers some more technical aspects which are not part of this blog. It’s planned in the next time to cover such topics in other blogs which will be referenced here as well.