There is a very interesting article “SAP NetWeaver Visual Composer and Web Dynpro Java – FAQ UI and Modeling Recommendations with CE” that was just released on SDN and I think has some relevance for BPXs and developers in general as well as providing some indication about how these two roles will interact with one another in the future. Not only does the article provide some excellent tips on when to use each tool, it also shows the direction in which SAP is moving regarding BPX-developer interaction and how the involved tools will better support this interaction.
The summary of the article may seem a little dry but the good stuff is inside:
This FAQ provides guidance on when and how to use SAP NetWeaver Visual Composer and Web Dynpro Java. It shows the relationship between the two UI modeling tools that are delivered with SAP NetWeaver Composition Environment (CE) in the short and midterm.
I’m not going to rehash the article but wish to focus on those sections that are most relevant for BPXs. I found especially useful the tables in the article’s appendix which provide distinctions between the two environments based on various criterion (“What are the required services?”, “Which action do you want to perform?”, “Does your Visual Composer prototype contain all the needed UI elements? “, etc.). These tables are more relevant for technically-oriented BPXs who are involved in UI prototypes and other more technical tasks.
In the section “What are SAP’s guidelines for creating custom application UIs using these two tools?”, there is a good description of the usefulness of Visual Composer (VC) for the non-programmer “aka” BPX. I like the idea of using Visual Composer to simulate the process and then moving on to WD when the application in question encounters VC limits.
Also of interest is the description of what is coming up in Composition Environment (CE) 7.1.1 , especially the fact that Visual Composer will be integrated within Eclipse and will enable access to the models from the NetWeaver Developer Studio (NWDS). Another related new feature is the ability to import WD components directly into VC. Thus, there will be a much tighter possible integration between VC and Web Dynpro. This doesn’t mean that the browser-based VC will disappear but the two environments, in my opinion, may serve different purposes (and perhaps will be used by different roles in the typical process improvement project)
What is the impact on the BPX of this new feature? The main question revolves around the choice of which tool is to be used in which context. The ability of the BPX to first work in the browser-based environment and then move to the Eclipse-based approach later is definitely one option. In my opinion, however, this Eclipse-based environment is more for developers who are enhancing existing VC models. This tendency is depicted in a paragraph below from the article.
Double-clicking on the WD component from the Visual Composer model, will open the Web Dynpro perspective allowing you to code the needed functionality. Once the coding is done, closing and saving the component will enable the programmer to return to the VC model and combine the Web Dynpro component with the other UI elements of the Visual Composer model.
If you assume that the Eclipse-based environment is more for developers, it is easy to imagine a simple UseCase as described below.
Activity | VC Environment | Role |
Creates initial User Interface (UI) depicting existing functionality | Browser | BPX |
Extends initial UI with WebDynPro based functionality | Eclipse | Developer |
Checks extended UI with WebDynPro based functionality and continues modeling with browser-based components | Browser | BPX |
What isn’t described is the communication between BPX regarding which functionality, or UI element is missing and must be implemented by the developer. For example, what is the manner in which the BPX describes the missing functionality? Does he create some sort of dummy UI that must be filled with a WD component – similar to how he creates a dummy service? Maybe, such information could be stored in the model somehow or maybe connected to particular UI elements. Irregardless of what this description contains, I’d like to have this communication take place somehow in the same environment rather than being exchanged email or other means. I’d also be curious to see if BPX creates the entire model with all the missing UI elements and then hands over the model to the WD developer or whether there is more of a ping-pong interaction where there is hand-over based on single UI elements.
Another interesting facet is to consider how this interaction will take place in scenarios where the BPX is using VC on a project that is focused on application development vs. a process improvement project. The fact that a process is broken down into bite-sized tasks (many of which usually can be created in VC without Web Dynpro extensions) would probably mean that BPX-developer interaction would be rather limited and would occur indirectly via the Guided Procedures design-time environment.
Conclusion
Some may consider such points rather trivial and unimportant in the scope of an entire process improvement project. However, I have often found that it is exactly the points of interaction between the BPX and other roles – process expert or developer – that the most misunderstandings occur. Thus, it is critical that such interactions be supported in an optimal manner.
Of course, the current restriction of being unable to load the VC-created components in WD is still a problem. If somehow solved in the future, this would provide even more benefits by allowing for an evolutionary path for VC-based prototypes (not only in terms of their UI design and service selection but their coding as well) for the WD development process that sometimes follow.
