Before I started working with Guided Procedures (GP), I was involved in many SAP Portal projects where the focus was on Knowledge Management and Collaboration (KMC) technology. After starting to work with Guided Procedures, I saw that there some parallels between the areas. I would like to look at two areas in detail and try and apply the KMC technology / tools to GP.
Collaboration Room Extensions
One important tool in KMC is the idea of a collaboration room which enables users that have certain common characteristics to work together in virtual rooms. There are room templates that contain certain functionalities and room instances that are based on these templates. Room templates include chunks of functionality, called room parts, which can be removed or added to a particular collaboration instance. This metaphor is very similar to that in GP with its process templates and process instances.
During their life cycle, rooms and room parts pass through defined points like the creation or deletion of the room or the adding of a room part to the room. Such points in the lifecycle of a room or room part can be used to plug in and execute specific code. This code can be written according to company-specific needs. It is called extension (or room extension) and the points in the life cycle are called extension points. For example, extensions can be used for further purposes, like for example to connect to backend systems, to set permissions or to provide or
There are design time and runtime extensions and there is an administrative User Interface (UI) to determine which extensions are called at which extension points. There is also a UI to deal with parameter-mapping issues.
There are standard room extensions from SAP that are available to all and then there is an excellent API to develop your own extensions via JAVA. The developer creates code that should be useful for more than one particular collaboration room instance
Examples of the extension points for collaboration rooms are:
My proposal is to have something similar in GP based on the lifecycle of processes. For example, you might have the following extension points
Thus, it would be possible, for example, to track changes in the design-time. A Business Process Expert (BPX) who is working in a team on a large process could set an extension to the ON_CHANGE_PROCESS_TEMPLATE extension point that sends an email when another team member changes part of the process.
Furthermore, it would no longer be necessary to add monitoring code directly to processes but this would be placed in an abstraction layer that is available for all processes. This might be useful for quality metrics that are interested in the GP run-time environment.
At some point, I saw a series of threads in the Composite Application Framework forum dealing with changing the GP the design- and run-time UI. Although there is an API to change some of this environment, it is actually quite difficult. I would like to propose a solution that is based on the Flex-UI concept that is so critical in the KMC environment. Inasmuch as the GP design-time environment is also based on an Explorer-like UI, I think the lessons learned from KMC would be quite useful.
A Caveat: Flex UI is not always easy to use but it is incredibly powerful and allows an administrator to change the UI to include menu items, column entries, etc.
Flex UI is based on a Configuration UI in the Portal.
and includes some of the following elements
|Resource Renderer||A resource renderer is responsible for displaying a resource (file, folder, or link) on the screen. is rendered|
|Collection Renderer||A collection renderer is responsible for displaying multiple resources on the screen. It groups the various elements to be displayed and generates the screen display according to defined parameters.|
|Layout Sets||A layout set can be used for the display of an iView or for particular folders.|
There are an amazing set of standard objects that you can use to create your own unique UI. There is also the ability to develop new renderers, etc., based on a released API.
My idea is to have something similar in GP that enables different organizations to provide different interfaces to the GP design time environment. Thus, beginning BPXs might have a simple UI whereas more experienced BPXs might have more functionality. This would also provide design-time users with more information on elements as they are navigating. In the current environment, the only visible information is the name of the element and an icon representing the object type.
Other valuable information is only visible after selecting the object. In my opinion, this information should also be present in the gallery. Information such as version, last changed date, etc, should be visible while navigating. This would allow sorting which might be interest to BPXs. The functions (Cut, Copy, etc.) could be available as menu items. This would also save space and the UI would be more similar to the Windows Explorer with which most users are comfortable.
Both ideas discussed in this blog are based in my long experience with KMC. Both possibilities have long histories there and are established technologies. GP would benefit from their inclusion in the product inasmuch as both would enhance the current functionality and benefit users by providing a more intuitive working environment. Inasmuch as the Composition Environment (which includes GP) will supposedly be separate from the mainstream stream (which means slower) NetWeaver release cycle, such interesting developments may are already in the pipeline and well be seeing them shortly. Lets hope so ..