Take Full Advantage of SAP Business Workflow in SAP Access Control 10.0

  • by Frank Rambo, PhD, Director, Customer Solution Adoption (CSA), EMEA
  • September 12, 2011
SAP Access Control 10.0 uses the standard SAP Business Workflow for all approval processes in the application, including user access requests. This very robust workflow engine supports more flexible multitiered routing and approval matrices. At the same time, workflow configuration in version 10.0 is one of the areas that underwent significant change and therefore requires delta training for implementers who are already proficient with the previous release 5.3 of the application. Learn how to configure the workflow engine in version 10.0 leveraging SAP NetWeaver’s Business Rule Framework Plus (BRF+).
Key Concept
SAP Access Control 10.0 comes with a variety of capabilities to analyze and mitigate access risk, manage user and emergency access, and manage business roles. Many of these capabilities include approval steps managed by a workflow engine in their business logic. The previous Java-based release 5.3 of Access Control came with its own proprietary workflow engine. With the recoding of version 10.0 in ABAP, it became possible to leverage the SAP Business Workflow, which is a standard technology already delivered with the SAP NetWeaver Application Server ABAP on which the application is deployed. The SAP Business Workflow technology opened the door to more state-of-the-art workflow features to determine the correct routing of workflow items. Its configuration is very flexible and can be based on pre-delivered content for quick results. It also supports the inclusion of SAP NetWeaver’s Business Rule Framework Plus (BRF+) rules, function modules, and ABAP classes to cope with responsibilities in more complex organizations.

SAP Access Control 10.0 relies heavily on workflow to process not only access requests but also other tasks supported by the diverse capabilities of the application. Table 1 lists all workflow-enabled processes in the application. In this article, I focus on access request approval workflow, but the other workflow processes work likewise. On a high level, each of these workflow processes comprises the following elements (Figure 1):

  • One initiator rule: Different from the previous version, 5.3, there can be only one active initiator rule for a given process (e.g., for access request approval workflows). The initiator rule evaluates the request attributes (e.g., request type, employee type, and role names) and returns a result value, which corresponds to a workflow path to route the request along.
  • One or multiple paths: Depending on the request attributes, the initiator rule can return different result values and route the request along different paths.
  • One or multiple stages per path: Each path can contain multiple stages to request approval from different stakeholders in your organization, such as line managers, role owners, or security administrators.
  • Optional routing rule and detour paths: A (standard) path can fork into a detour path, if a specific condition specified in a routing rule is met. An example for a routing rule is the absence of a role owner in the master data of a requested role. This routing rule is useful in cases in which a stage in the standard path requires role owner approval. Again, a detour path can consist of multiple stages.

It is possible to configure access request approval workflows for automated provisioning to the target systems as soon as the request is approved in the last stage. This step is done via IMG menu path Governance Risk and Compliance > Access Control > User Provisioning > Maintain Provisioning Settings. Because of the resulting topology allowing for multiple paths and stages per path, the workflows are called Multistage-Multipath (MSMP) workflows.

Table 1
Workflow processes in SAP BusinessObjects Access Control 10.0

Frank Rambo, PhD

Frank Rambo, PhD, is managing a team within SAP’s Customer Solution Adoption (CSA) organization working with customers in the SAP analytics area with the objective to drive adoption of new, innovative solutions. Prior to this position, he worked eight years for SAP Germany as a senior consultant focusing on SAP security and identity management. Before he joined SAP in 1999, Frank worked as a physicist in an international research team. He lives in Hamburg, Germany.

See more by this author


No comments have been submitted on this article. 

Please log in to post a comment.

To learn more about subscription access to premium content, click here.