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“.
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
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:
- intuitive applications
- multiple transactions
- hybrid interfaces
- next interfaces
It follows an example for each category.
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.
Example: An Elegant Web Dynpro Application supports users during the creation of Purchase Requisitions (Services Procurement).
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.
Example 1: Google Maps integrated in a Web Dynpro Application
Example 2: Flex Component integrated in a Web Dynpro Application
Example: 1 a Flex Application that consumes Enterprise Services.
Example 2: Adobe Interactive Form that is sent via eMail to create a Sales Order
Nowadays everything is composition but when a guy called the transaction SQ02 (SAP Query) Composition Environment it was really too much !