Here we are going to see one of the new and important concepts which we had already seen in the first part. I am talking about the new Component concept of the Interaction Center (IC) UI framework. CRM Developers and technical consultants would have already seen the CRM 2005 based one UI component; CRM_UI_FRAME embedding all application-specific views and controllers and just a single runtime repository. You will now be in for a more simplified approach.
We all know about the famous Model-View-Controller (MVC) design pattern for web applications. The presentation layer in all IC based applications is also modeled on MVC architecture. Any application in CRM (be it business partner, service contract or sales order) now is made up of ideally more than one UI components (may be one for some).
- A component then is a logical collection of viewsets, views and controllers. It too has its own runtime repository.
- It is a self-contained and self-sufficient unit which can be reused. The interface of a component can be kept exposed to the outside world (more like a web service if not exactly). This is where the USP of scalability comes to the fore.
- On the same lines, the same component can have multiple instances of itself running together at runtime.
- UI component = BSP application. A UI component created using the new workbench is technically a BSP application in the background; very much accessible from the ABAP workbench and part of a package. This means you can now implement and unit test your UI components independently before you integrate and test your entire business scenario as a team.
Let us see in more details how we can get a black box which at the same time can become friends with other applications.
A component can be re-used by one or more other components. The embedding component defines a component usage in its runtime repository (by the way, the new workbench has now a runtime repository editor) which actually declares this inter-dependency. At runtime, each component usage gets a handler to its own instance and makes these available to the embedding or parent component. The embedding component can then get data shared using the embedded or child components' interfaces.
Now, a component has to have one or more windows which can host the views contained in it. This is where the new concept of a window comes into picture.
Besides hosting the views, a window can also serve as the mediator or interface between a embedding and the embedded component during runtime. A window can be visualized as an interface view which exposes all the underlying views being hosted by the same window. So, it has the character of a single view to the outside world. With the use of the inbound and outbound plugs (as entry and exit points), navigation and sharing of data context is possible.
From this blog, we see that to run a complete CRM business scenario; be it a marketing, service or sales, what you will see is one application (read component) talking or sharing data with another application seamlessly. This definitely makes so many things simpler than the earlier versions of just one component or runtime repository doing everything.
Consultants familiar with Web DynPro will already be aware of this concept. Either way, once a CRM consultant begins to start using the new UI workbench, grasping Web DynPro UI technology will be a piece of cake.
To complement this discussion, take a peek at the video grab of what I have already illustrated in the above block diagram both in the UI workbench (BSP_WD_CMPWB) as well as a working example.
Please note that this video is based on a CRM 2006s/2 (or 5.2) system.
4 Comments
