Dynamic Teams in IBM BPM - served chilled by SAP
ydolf 100000F4A4 Visits (10243)
Thank you to Johan Schön for his research in regard to BAPI_USER_GETLIST parameters as well as for his knowledge about SAP composite roles!
One of the features of IBM BPM is the functionality to dynamically allocate the users who are allowed to claim a specific human task. The task will be assigned a team. This team - or rather the the mechanism behind how the users are determined - can be:
Dynamic lookups can be either:
Common for both these approaches is that they do have a set of mandatory input and output parameters. In essence - in both cases - it is the input team. it is possible to add input parameters. It is up to the invocation itself to decide the values mapped to the input parameters. In the former case, it should be constant data, that is environment variables and hard coded values. These additional input parameters are associated with the Team. In the latter case, the input variables can be mapped to any instance data, environment variable or constant. The additional input parameters are in this case associated with the Activity. Saying that - in the case of the Team Filter Service, one is able to add a team assignment.
Using Dynamic Lookup to Acquire SAP User's Associated with a Particular Role
Obviously some other system System of Record knows more about who is allowed to claim a specific task. This system can be LDAP-based or - as in our case - SAP. If access right information Is managed by SAP and only specific users are allowed to claim specific BPM human tasks it would make sense to actually dynamically ask SAP whom is allowed to be a member of the dynamic team. This could in SAP be managed by a role (previously activity group), which is based on the organizational plan of a company. It is possible to specify simple roles and composite roles. It is important to realise however that if a composite role specifies two simple roles, being a member of one or two of the simple roles does not mean that one would also be a member of a composite role. However - being a member of a composite role also means that you are a member of all the simple roles making up the composite role.
SAP Role Access
SAP BAPIs are the standard interfaces to exchange data between SAP components and between SAP and non-SAP components. BAPIs are RFC (Remote Function Call)-enabled functions and can as such typically be called from remote systems. The SAP Business object USER contains user data and can be remotely accessed via a number of BAPI-calls - in order to acquire the users that are of interest for a dynamic team retrieval it is relevant to make use of BAPI_USER_GETLIST BAPI. We now assume that we provide a SAP simple or composite role as the inbound team to the Dynamic Team Retrieval/Team Filter Service.
This picture specifies the team Z:PAYMENT, which has the same name as an SAP role and this is also the name that will be supplied in the input name variable in the Team Retrieval Service.
Above is an example of what the equivalent Team Filter Service would look like: both the team (which will map to originalTeam) and the Team Filter Service is specified.
Creating The Integration
In the Service (Dynamic Team Retrieval Service and Team Filter Service) a call will be performed to an Integration, implemented in IBM Integration Designer. Typically this can be done with an Advanced Integration Service or as a Web Service Client. The way this is accomplished is not to be addressed in detail. For the sake of illustrating we assume that the Service implements a Web Service client, which will call the Integration with the information necessary to lookup a proper name in SAP - in this case only the team name - and the response message will contain all users found wen calling the BAPI_USER_GETLIST functionality.
A reasonable recommendation is to create two Business Objects at an early stage during Integration Development. It would typically not be very nice to export the full BAPI WSDL to be called by the Process Designer Service. By refining the business need, one would also gain the benefit of a level of redirection. Should additional information be needed it would be possible to make room in the existing Business Object without affecting the BAPI business object - which was automatically created by the SAP Adapter.
The Integration side is not very complicated. What is needed is a receiving Web Service Export, some kind of orchestration logic, for example a BPEL-process (Microflow recommended, since failures for long running processes could lead to administrative problems as well as affecting performance negatively for persistence reasons), or a mediation flow.
In addition an outbound SAP Adapter component is required, which represents the BAPI call. The intermediate Java component on the picture to the left represent additional mapping in order to enable dynamic SAP authentication. This is not strictly necessary - a technical non dialog user will prove the point equally as well.
The important part in the pre SAP call map is to specify the correct input prameters to BAPI_USER_GET_LIST. Three parameters are required (a big Thank You to Johan Schön for his research effort!):
AGR_NAME is to contain the team name supplied and FROM_DAT and TO_DAT need to contain the current date. This will ensure that users that belong to this specific role on the current day will be targeted - not for example users whose association with the role expired at an earlier point in time.
The before-call mapping below is an example of how the BAPI structure could be filled in. MaxRows decides how many records that at most will be returned. Since we indeed are interested in the resulting user names, we specify this as well (X). The SapSelectionRange is populated in accordance with the table above - three entries with different cardinality.
In the Process Designer Service, the following is an example of the pre-execution for a team retrieval service. For a Team Filter Service it would be relevant to change the tw.local.name variable to tw.l
After the Integration Web Service has returned (hopefully with the user names corresponding to the role Z:PAYMENT, the example below shows an example of a post-execution for a team retrieval service. Information is read from the return structure returned by the Web Service. If a specific user cannot be found in the BPM User Repository, the user will be discarded. As mentioned previously a user claiming a task must login to the Portal and this would not really be possible should the user not exist in the BPM User repository.