Skip to Content

Coming back from the TechEd’08 in Berlin I was thinking about the most used and abused words.

For sure in the TOP 10 there were Composite, Composer and Composition.

Composite Application was one of the most stressed concept and I like to give a contribution to help beginners approaching this interesting new world.

You can easly find good definitions in Internet that basically define Composite Applications as applications that reuse services published by existing ones.

But we know that beginners like pictures and comparisons…

First let’s see a picture related to “classic Applications“.

/wp-content/uploads/2008/10/sergioca_classic_applications_01_84443.jpg

In a PC based environment each Window cointains a classic Application, it’s up to the operating system to combine more applications on the monitor and to the user to jump from them and copy and paste informations.
In a SAP Portal environment each iView cointains a classic Application, it’s up to the Portal to combine more applications in the browser window (Portal page) and to transfer informations between them (Portal eventing)

Now a picture of “Composite Applications” follows

/wp-content/uploads/2008/10/sergioca_composite_applications_01_84444.jpg

The Composite Application is contained in a PC Window or in a Portal iView and it has the total control of the back-end logic and datas.

Sometimes Composite Applications are integrated to the back-ends by the Service Hub (SAP PI) and sometimes they are directly plugged. Probably due to performance constrains, there is not yet a clear statement.

What’s your opinion about this? should Composite Application access directly the back-ends or be intermediate by the Service Hub?

It would also be very useful to agree on a classification of Composite Applications.

I already realized some Composite Applications and I share with you the categories I created:

  • multi-backends
  • intuitive applications
  • multiple transactions
  • hybrid interfaces
  • next interfaces

It follows an example for each category.

multi-backends

Example: A powerful Web Dynpro Application supports users to ask for and approve  changes to the pricing in system SAP ECC (SD) comparing fresh data coming from SAP ECC SD with historical values read from SAP BI (CO-PA) and calculating delta fields before the approval.

/wp-content/uploads/2008/10/sergioca_multi_backend_01_84445.jpg

intuitive applications

Example: An Elegant Web Dynpro Application supports users during the creation of Purchase Requisitions (Services Procurement).

/wp-content/uploads/2008/10/sergioca_intuitive_application_01_84449.jpg

multiple transactions

Example: When a user press a button in a Web Dynpro Application three SAP ECC (SD Consignment Stock) transactions are performed in sequence. Sales Order->Delivery->Good Issues. In other environment transactions could be executed also in different back-ends.

/wp-content/uploads/2008/10/sergioca_multiple_transaction_01_84450.jpg

hybrid interfaces

Example 1: Google Maps integrated in a Web Dynpro Application

/wp-content/uploads/2008/10/sergioca_hybrid_interfaces_01_84451.jpg

Example 2: Flex Component integrated in a Web Dynpro Application

/wp-content/uploads/2008/10/sergioca_hybrid_interfaces_02_84452.jpg

next interfaces

Example: 1 a Flex Application that consumes Enterprise Services.

/wp-content/uploads/2008/10/sergioca_next_interfaces_01_84453.jpg

Example 2: Adobe Interactive Form that is sent via eMail to create a Sales Order

/wp-content/uploads/2008/10/sergioca_next_interfaces_02_84454.jpg

Nowadays everything is composition but when a guy called the transaction SQ02 (SAP Query) Composition Environment it was really too much !

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Dipankar Saha
    Hi,
    In my opinion using SAP PI or any ESB for integrating backend services into composite applications should be followed as an ideal approach as it provides the backend abstraction and brokered integration. However, when the backend interfaces are pretty stable and SAP PI if not available in the landscape or not considered due to licensing/operating cost factors it can be bypassed in some scenarios. Still we can implement a backend abstraction layer in composite applications which may enable backend abstraction from the composite application and changing of backend service interfaces (e.g. from BAPI to ES) as and when required without affecting the composite application itself. Nevertheless, in scenarios such as shared-service application where multiple interfaces are present for the same functionality and needs to be chosen dynamically at runtime based on business data using SAP PI may be mandatory which provides dynamic routing and multi-mapping. My colleagues are myself shall take a few lecture sessions on these topics in TechEd Bangalore and Community Day there. I’ll also write articles and blogs in SCN on these topics after TechEd.
    Best Regards,
    Dipankar
    (0) 
    1. Sergio Ferrari Post author
      Thank you for your important contribution Dipankar.
      So we can say that the main decision factors include performances, licensing and operating cost and probably the kind of Composite Application to be realized (see the classification I proposed).
      Sergio

      (0) 

Leave a Reply