Documente Academic
Documente Profesional
Documente Cultură
to a Role
Applies to:
SAP NetWeaver Composition Environment 7.1 SR3 Evaluation Version. For more information, visit the
Composition homepage.
Summary
This article gives an insight to role handling in CAF-GP. It deals with different ways of assigning users to a
GP role and their specific usages.
Author:
Srinivasan Subbiah
Author Bio
Srinivasan Subbiah is an Application Developer working in HCL Technologies Limited on SAP NetWeaver
Technology (CAF, Web Dynpro for JAVA and GP).
Table of Contents
Introduction .........................................................................................................................................................3
Assigning Users to Default Roles .......................................................................................................................4
Assigning Users Using Initiator Option ...............................................................................................................6
Assigning Users Using Built-in Callable Object ..................................................................................................8
Assigning Users Using Context Parameters ....................................................................................................11
Assigning Users GP API...................................................................................................................................13
Parameter Consolidation and Result State Setting ..........................................................................................17
Testing the Process ..........................................................................................................................................18
Related Content................................................................................................................................................20
Disclaimer and Liability Notice..........................................................................................................................21
Introduction
A process role defines a set of tasks that a user assigned to the role can execute on a process. When we
design a process we will have processor for each action which we may then consolidate to different roles at
block level. At runtime when the process is being executed an instance of type IGPProcessRoleInstance will
be created for each role. When we assign users to that role GPEngine will simply add the user instances to
the corresponding role instances. The above procedure will happen in whatever way we assign the users.
The different ways of assigning users to role include the following.
Assigning users to role using initiator option and initiation defined option
We will design a sample Leave application management process to have a feel of the above prescribed
methods. This process will have four blocks namely
HR Approval block
Each of them will have separate roles assigned to them. In the first block, the applicant will apply leave. In
the second block, HR can view the number of days of leaves and can approve it. If it is approved, it will go to
the third block for the approval of the manager. He can approve or escalate. If escalated, it will go to the next
block where the senior manager will approve or reject it. We will assign the users to each role in a different
way. For simplicity we are not updating any backend systems. The screen shot provides the detailed
structure of the process.
In the Default Roles, we can see the above said three roles to be listed. Click Add Default. Using the Add
Users value help, we can add a user to these roles by clicking Add. Here I am adding Administrator user
for these roles.
This kind of assigning users can be done even after we have activated the process. It should be noted that
this process of assigning default users should be repeated after each time we activate the process (if we edit
the process and then activate again).
If a user owns the process administrator role, he can perform this assignation from GP Administration tab
also.
It will have four input fields for getting No. of days of leave(String), HR Ecode (String), Manager Ecode
(String List) and Senior Manager Ecode(String).
Click Go button.
Now the leave applicant will be the user who starts this process. So at process level, we will assign initiator
as the user for this role.
Go to the process by clicking on the Leave Management Process.
Select the Roles tab.
Select Applicant role.
In the Role Type dropdown select Initiator.
On doing this type of assignation, whoever is initiating the process will be automatically assigned as the user
for the role Applicant and only he can perform the action of applying the leave.
Click next.
Here the input parameter is already defined since it is a built-in callable object type. As we can see, it
consists of a structure UserList. Inside it there is another structure called UserItem which is a list. Inside that
there is UserIdentifier. For assigning user to the role, we will map the UniqueId of the user to this
UserIdentifier. If we have a list of UniqueIds then in that case we have to map the structure containing the
uniqueIds to the structure UserItem. It will iterate and assign all the users to the role automatically.
We can get the unique id for a user from the api or if we want to test we can get from the UserAdministration
as shown below.
Click next and then finish for creating the callable object.
Next create the second action with name ApprovalHRAC. This will have a data display form callable object.
Create the callable object with the attributes given below in figure.
Click Next.
Insert the parameter No. of days. Then click Finish.
Now we will have two processors for this block. We will consolidate these two processors at block level to
one role namely HR Manager. For doing this select the block HRApprovalBlock.
Select the Roles tab.
Press ctrl and select the two processors.
Enter role name HR Manager in the Consolidate to input field and select Go.
Now when we map the input (users unique id) to the Assign user for HR role AC, the built-in callable
object will assign the users to the role of HR Manager. Thus users will be assigned to both the actions.
Note that when we are using this built-in callable object, if we are executing it in a loop and we have different
users in each loop iteration, then the new users will be added to the role but the old users will not be
removed or replaced. In simpler terms this only adds users to the process role instance and will not replace
the existing ones with new ones.
Now we will have to assign users to the role. Select the block and go to Roles tab.
Select the Processor of Manager Approval.
Click on the Filled from Context Parameter dropdown.
Now we have assigned the context parameter UserLogonId to the role. Note that this attribute should be a
valid login id of a portal account.
This method of assigning users to a role will replace the existing users for the role with the new users. We
can also assign multiple users this way. So it can be used when we need to execute some looping actions
with different users assigned as processors each time. After doing this kind of assignation, this role will not
be visible at process level.
Note the major disadvantage with this kind of assignment is that we cannot consolidate multiple processors
to a single role and then perform this assignation. This type of assigning users is limited to the processors of
action alone (action alone). It also mandates that the action should have the logonId as a mandatory
parameter.
In the execute method, we are getting the input parameter which will be a valid logon id via SeniorManager
parameter. Then we will get the IUser instance of the portal user with that logon id. This is done via the code
As described earlier, a ProcessRoleInstance would have been created for the role corresponding to this
role. We have to retrieve this role instance and add our IUser (user) to it for assigning a user to this role. We
can retrieve the ProcessRoleInstance using the following code.
Then we have to add the runtime defined user which we retrieved previously to this role instance via the following code.
Here we will use the GPRuntimeManagers addRuntimeDefinedUserToRole() which will take the process
instance, role name, iuser instance of the user we want to assign and the user context of that user. We can
get the process role instance using the design time id of the process which we can get from GP design time
as shown below.
The second action will have a decision dialog callable object with name Approval and with following
attributes.
Click next, next and enter the message and button details.
Now during the process flow, our background callable object will assign the user to the role Senior Manager.
The main advantage of using the GP API can be felt when we already have some logic to be implemented
via a background callable object. We can just have our role assigning code embedded along with the logic.
In that case, we can avoid having a separate built-in callable object and hence an action for just assigning
users to a role. That will improve the performance.
Then check whether the HR Role and Senior Manager are of type Runtime Defined.
We have to set the result states for getting the proper flow. Go to Manager Approval Block.
Select the Manager Approval AC. Select the Result States.
Set target for result state End to be Terminal.
Set target for result state Continue to be Senior Management Approval AC (Senior Management
Approval).
LogonId
UniqueID
Description
Leave
Applicant
L181641
HR Manager
H181641
Manager
M181641
Senior
Manager
S181641
HR manager
Now with Leave Applicant user, we will initiate the process since Applicants role type is Initiator. Now we
will see the input page for Leave Applicant user.
Note: we have to give uniqueId for HR Manager as we are using the built-in callable object for assigning the users to the
role. For Manager Ecode and Senior manager Ecode, we can give the logonId.
Click Submit.
It will go to the next user, HR Manager. In HR Managers GP Runtime, we can see the work item in the
pending tasks. Select it.
Now he can see the number of days for which leave is applied. Click Ok.
Now we will go to the pending actions of the Manager and open the work item.
Now the control will go to the senior manager. Open the pending work item in the Senior Manager login.
Related Content
For information on default process roles please refer to Process Roles
For information on creating webdynpro callable objects please refer to Implementing webdynpro callable
object
For more information, visit the Composition homepage.