Many practical use cases exist where we need to assign tasks to different users belonging to different process roles. SAP provides a predefined callable object called "Dynamically assign user to process roles during runtime" as part of the Composition Tool "Guided Procedures." You can use this object to assign tasks to dedicated users. Depending on how your process template in the Design Time of Guided procedures is modeled, the asssignment of users to process roles can be done interactively, automatically (in background), using rules, or as combination.
In the following we refer to a reference process "Project Management and Employee Service", that is delivered with the Composition Environment.
- Information about the reference application "Project Management and Employee Services" can be found within the NWDS, selecting "Help" in the top level menu, choosing "Welcome", pressing "Samples" and selecting "Project Management Employee Service"
Introduction to the "Project Management and Employee Services" process
For this process two process roles must be defined: the program lead and the project lead. The program lead is responsible for coordinating and creating the projects, whereas the project lead is in charge of managing the projects. In the first step of this process the program lead selects the responsible project manager who will approve the project in case all needed resources are available. In the final step a new project will be created as part of a background step.
Figure: Overview Reference Process
1 Enter Project -- > Visual Composer - UI:
- The UI contains the input fields Title, Description, Schedule
- In this step projectdata are required to fill in
- In this step the project lead will be determined (via web service)
What is really happening in this step? We are using a VC-modelled WebDynpro UI consuming at runtime the webservice "getAllEmployees". Processing this UI displays a list of all the project leads.
Figure: Enter Project and selecting the project lead
So the Program Lead, who has started the process can now select the appropriate Project lead, for example, Sally Springs, and additionally fill in the required project data. (Figure: Enter Project and selecting the project lead).
After you submit the new project, the task is routed to the appropriate project lead. How this is modelled is shown in Part 1 in two different ways (see example 1 and example 2, below).
Figure: Assignment of selected user to role "Project Lead"
Further information concerning the embedding of the Webservice in the VC modelled UI you can find in SAP booklet: Entwicklung von Composite Applications mit dem SAP NetWeaver Composition Environment.
2 Approve Project --> Visual Composer - UI
Above we saw that the next task has been assigned to Sally Springs (role project lead). She is just taking a look at her task list and realizes this.
As you can see, the VC-modeled Web Dynpro UI contains the fields Comment, Resources available, and Accepted to be filled by the project lead. The other fields are prefilled because of the former action:
Figure: Project approve
3 Create Project --> a webservice created in CAF (NWDS) creates projectdata in database as background step in Guided Procedures.
By pressing the submit button, the Project Lead Sally Springs starts a background service that stores the input data in your server's database creating the new project.
The little process that creates the new project is finished when it displays the final screen:
Although the reference application has much more to offer e.g. the interplay of the composition tools as "Guided Procedures", "Visual Composer" and the Composite Application Framework) within this example we will focus on the assignment of users using context parameters.
That's why I invite you to please follow me now, to take a look at this part 1: model driven examples "how to assign users to process roles during runtime dynamically" .What is exciting in the following, is to get to know the different ways to model such an user assignment - and when and why to model it different!
1. Example: Interactive Assignment using a Predefined Callable Object
To realize the interactive user assignment to the process role "Project Lead" to route the aproval step to the selected project lead in step 1 we need to transfer the Login data (see step 1) to the appropriate parameter "Unique ID" used by the predefined CO to dynamically assign user to process role. This "Unique ID" coresponds to the one you can find in the UME:
To convert the Login parameter of the webservice to the Unique ID we will first use the predefined CO "read user information" that fortunately provides both the login and the Unique ID (respectively User Identifier). In addition we can be configure the key parameter for the resolution:
Figure: CO read information - input
Figure: CO read information - output
Figure: CO read information - configuration of the key Parameter for resolution
Secondly, so the user assignment can be done correctly, we also have to do the parameter consolidation as follows:
- Consolidation output parameter "Login" of the first step "Enter Project" (CO WD4VC), the parameter "User Identifier" of the 3. step "Assign role of project lead" (CO dynamically assign user to process role) and the input parameter "Login" of the 4. action "Aprove Project" (CO WD4VC).
- Consolidation of the outputparameter "login" of the first step "Enter Project" and the parameter Logon ID of the 3. step "read project lead" (CO read user information)
- Consolidation of the output parameter Unique ID of CO read user information and the input parameter User Identifier of the CO dynamical assign user to process role
Remark: Of course the webservice could have been created that way that these wo steps will not have been necessary. But the focus in this blog is to show ways of model driven possibilities to realize the dynamical assignment (compare Outlook - see below).
Thirdly, for the user assignment to be done correctly, the role consolidation has to be done:
Figure: Role consolidation on block level
Last but not least, there is one definition left: the role definition on the process level.
For the user assignment to the process role to happen properly, we still have to define the process role "project Lead" as runtime defined. This is mandatory for the dynamic assignment of the user to the process role:
2. Example: interactive assignment using context parameter
Within this example we will focus on the assignment of users using context parameters. In comparison to example 1, using context parameters uses different objects and requires a different modelling effort.
In example 1, we used the predifined COs "Read user information" and "Dynamically assign user to process role during runtime" to get the right transition of the context parameter "Login" from the webservice to the "Unique ID" for the user assignment. In this example, we use the webservice directly, assigning the login parameter to the process role "Project Lead". Doing that, the task "Approve Project" is automatically assigned to the interactively selected user and the role "project lead".
For this we have to place a variable in the GP context which can afterwards be assigned to a process role during the role consolidation. The role consolidation is in principal the same as it was described in example 1, except that we now have 2 less actions because we have two less roles to consolidate (see figure 1) on block level.
The necessary role definition on process level remains the same as that described in example 1.
In figure 1 we have added the parameter "login" to the GP-context containing the Unique ID of the project lead during the execution of this step. The figures 1 and 2 show how the variable is assigned to the process role:
Figure 1: Assigning the context parameter to the process role
Figure 2: Assigning the context parameters to the process role
The source for available users the program lead can choose the project lead from, is retrieved via a web service call. For this "Guided Procedures" is delivered with specialized callable object called "Web Service".
When to use what?
Now surely the question will comes up: are there any recommendations on when to use which kind of dynamic user assignment to process roles?
First we have realized that it is much more effort to do the parameter consolidation, with the given prerequisites, in Example 1 compared with the easy parameter assignment in Example 2, to make the user assignment happen.
However, this is only one aspect. The other ones to be considered are as follows:
- If your use case is such that only one step of your process has to be assigned dynamically, you are supposed to use the option shown in example 2. Please consider that the appropriate login information must be available in the GP-context and that once the user assignment to the role is done this will be valid for all steps (actions) assigned to this role up from that time.
- If your process is huge and a role is supposed to execute several steps (actions) spread all over the process, it is recommended to use the predefined Callable Object "Dynamically assign user to process role during runtime" as described in Example 1. Additionaly, the GP-Framework ensures that the assigned user gets task information in the Work Center for each action executed by the process role.
Interesting Links to SDN - Threads covering the topic "dynamically assign user to process role during runtime"
- Parallel Dynamic Block - Assigning multiple users to a process
- GP: Dynamically assignment of users
- How to assign Dynaminc Approver in GP
- /thread/100472 [original link is broken]
Further related topics:
Outlook to: Different ways to model "Dynamic assignment of user to process roles" using Composition Tool Guided Procedures - Part II
In a follow-up blog (coming soon) I will show an example of how to realize a model-driven rule-based dynamic assignment.
Additionally I'll show how the model-driven examples can be realized with rule-based coding using a Java Class wrapped in a background callable action.
For these two examples we will also refer to the introduced reference application process.
