Guiding Principles for Designing Composite Applications 

Reuse of Components

An essential part of the composite application idea is the reuse of available assets to implement new business processes.

To support reuse, composite applications must integrate into existing system landscapes without the back-end systems requiring composite-related upgrades. For this reason, composite applications should be loosely-coupled to the components on which they are based, resulting in a new logical application tier with its own lifecycle.

Loosely-coupled means:

·        Unidirectional communication of composite applications with components used via Web services.

In exceptional cases, where Web services are not available, other well-defined APIs may be used. In these cases, we recommend that you use Web service wrappers to remain independent of back-end systems.

●      Every call creates its own transaction in the back end and there is no locking between invocations.

Model-Driven Development

The model-driven approach and the reuse of as many existing functions as possible, result in:

●      Less manual coding

●      Increase in configured or modeled parts, which leads to an increase in overall productivity and quality

Model-driven development should be used on all layers of a composite application by taking advantage of the following technologies:

●      Visual Composer, Web Dynpro, and SAP Composite Forms by Adobe for the UI

More information: User Interface Layer

●      Guided Procedures for the process logic

More information: Process Layer

●      Composite Application Framework (CAF) for the business logic

More information: Business Logic and Abstraction Layer

Enterprise SOA Compliance

Composite applications should be enterprise SOA compliant. The advantage of this is that service providers and consumers are decoupled. They share the service definition, but require no knowledge of the service implementation. As a result, services can be implemented and provided without making assumptions about consumers. Additionally, service consumers can call services without making assumptions about the service implementation.

Composite applications are designed to:

●      Integrate with the back end via Enterprise Services.

The goal is back-end independency, that is, to be able to integrate the composite applications easily with different systems as long as they have implemented the required services.

●      Have separated layers

When defining different layers of a composite application and the communication between those layers, composite applications must have decoupled business Logic, UI and process Logic and must be loosely-coupled to the back end.

User Orientation

Composite applications are user-oriented applications supporting cross-system collaboration. They have a user interface, although they might contain automated process steps without user interaction.

One of the main propositions of composite applications is to streamline processes available in the back end and to make them accessible in a role-based, user-friendly, and process-oriented way. The processes exist virtually in the back end as a set of transactions to be used in a particular order. Composite applications can turn them into real processes.

Composite applications should:

●      Provide instant usability to their users.

●      Combine services from different back ends and those developed in the composite application to homogeneous processes and user interfaces.

●      Have user interfaces that are task-oriented, so only provide the information or require data entry relevant to the user’s current task.

●      Have user interfaces that are process-oriented guiding the user through the relevant process steps.