Skip to Content
Author's profile photo Kai Ullrich

My concerns with the SAP Provisioning Framework

This time I would like to talk about a couple of issues I have with the SAP Provisioning Framework. Overall, I

find it a pretty cool framework but surprisingly the relatively easy improvements I’m going to talk about in

this post are not part of the standard. However, hope is left since the SAP Provisioning Framework will be

significantly enhanced in 7.2.

The below picture shows the task tree of the ProvisionABAP task which takes care of provisioning for the ABAP

stack. Please notice at the bottom of the picture how the user creation is done.

Configure a retry on all tasks that connect to the backend. I’m not going to talk about this one

much because of obvious shortcomings. What if the network is down too long and all retries fail? What if other

tasks than provisioning tasks fail? Do we have to configure a retry on all tasks in this execution tree then?

Not very nice.

Configure an On Chain Fail handler on ProvisionABAP. See the following screenshot:


A very nice feature. Here we can add a task that is executed whenever a task in the task tree below

ProvisionABAP fails.

    The second point is an excellent entry point for further considerations. What can we do with this? I’m going

    to present 2 ideas. The first one is pretty straight forward and easily implemented, the second one is a

    little more complex but offers more comfort.

    We could write the on chain fail handler to flag users whose provisioning failed. With a smart flagging,

    those users could easily be identified by a nightly job that sends them again into provisioning for the

    corresponding repository. The funny thing is that there is such a background job in the standard which

    almost does the job: It is called Initial Provisioning:


    It sends selected users into provisioning again, only the filter that selects who is provisioned again would

    have to be modified. And a mechanim is needed to remove the flagging once the provisioning has been


      1. The more sophisticated approach would be to create an entry type PROV_FAILURE with a couple of

        attributes like: user, repository name, date and time. Then the on chain fail handler could create an instance

        of the entry type and basically record the failure in this instance. The big advantage with this approach is

        that administrators can then selectively search for failures related to a certain repository, for instance. Or

        selectively restart provisioning for certain users, in contrast to leaving this to a background job.

    Assigned Tags

        Be the first to leave a comment
        You must be Logged on to comment or reply to a post.