Skip to Content
Author's profile photo Murali Shanmugham

IdM integration with BW for Reporting

In this blog I would like to explore how the BW Reporting is enabled for Identity Management.  Identity Reporting Using SAP NetWeaver Business Warehouse – Implementation Guide ( covers all the steps to enable reporting. I will try and get into more details of the configuration with screen captures.

The below components are involved in the landscape. Identity center communicates via LDAP protocol to the VDS. The BW configuration in VDS is used to make a Web service call to BW system to pass all the identities and attributes.


By using the job wizard in Identity Center, the standard “IdM to BW Data transfer” job can be created in IdM


As shown above, there are several passes which are executed to achieve the data transfer from IdM to BW

Prepare Delta Criteria:

IdM assigns a change number for all the changes performed on an Entry/attribute and records this change number in database tables. The objective of this pass is to obtain the change numbers for all current attribute records, current link records and history records. The value is stored temporarily in local job variables which will be used for processing further down the line.  This “To Generic” pass runs a script. Below is the code snippet


By the end of this script execution, there would be 3 local job variables created to hold the change numbers


Transfer Current Attributes:

This is a “To LDAP” pass which makes a call to the VDS passing attributes for all the records fetched by the below SQL executed on table idmv_bw_current_values.


The function sap_getNewLastChangeNoForCurrentAttrs() would return the value contained in local job variable DELTA_NEW_LAST_CHANGE_NO_CURRENT_ATTRS. 

The function sap_getSQLDeltaCriteriaForCurrentAttrs() is added at the end to provide a dynamic where clause.  If this is not the initial load, it forces the system to use “AND ChangeNumber > “+ <<permanent job variable>> at the end of the SQL statement to retrieve latest records (which have not been sent to BW). The value for the <<permanent job variable>> will be set in the last step shown below.

Transfer Current Links:

This is a “To LDAP” pass which makes a call to the VDS passing attributes for all the records fetched by the below SQL executed on table idmv_bw_current_links.


Again, the functions are to retrieve the value contained in the local job variable DELTA_NEW_LAST_CHANGE_NO_CURRENT_LINKS and also to handle delta runs.

Transfer Historical Attributes and Links

This is a “To LDAP” pass which makes a call to the VDS passing attributes for all the records fetched by the below SQL executed on table idmv_bw_old_values_and_links.


Again, the functions are to retrieve the value contained in the local job variable DELTA_NEW_LAST_OLD_ID_OLD_ATTRS_LINKS and also to handle delta runs.

End of Transmission

This is another “To LDAP” pass which actually triggers the process chain in BW system.


If StartChain attribute is set to <blank>, this will not trigger the process chain in BW system

Update Delta to Permanent Variables

This “To Generic” pass stores the local job variable value into a permanent job variable. Note that the value of the permanent job variables will be reference in the above “To LDAP” passes (in the subsequent delta runs) to determine if the job is being run as an Initial run or Delta run. Below code snippets shows how the value of permanent job variables are set and those of local job variables are cleared.


After the Initial load is executed, you should see some values against each of the permanent job variables as shown below


The “To LDAP” passes make a call to VDS. The BW Configuration in VDS would look something similar to the below screen. The MX_USERNAME is an actual user in BW system which will be used while executing the Web Service.


Hint: The BW connector by default collects 1000 entries, which it sends in one package to the BW system, in order to minimize transport communication overhead. If you would like to reduce the package size, you could use SUBMIT_SIZE in the constants to a lesser value.

Under User Group > Authenticated section, the bwuser user created is used for communication between Identity Center and VDS. The bwuser is provided in the repository (BW to VDS ) created in Identity Center


When VDS receives a request from Identity center, it in turn makes a Web service call to the BW system to trigger a process chain. The below screen shows an activated web service RS_BCT_IDM_CHAIN_START  which has been configured with a default binding.


In the BW system, two tasks would need to be done initially

  • A  Source System (Web Service Type) would need to be manually created to receive the Web Service call.  This has to be done manually in all your BW system in the landscape
  • BI Content for IdM Reporting must be installed and captured in transports

Below screen is the default setting (which does not need to be changed) of the Data source. It shows the web service connection in the Data Source.


You should be able to view the execution result of the Process Chain via RSPC transaction


Troubleshooting Tips:

1) One of the common issues is incorrect Host names and Port number being provided in VDS. Sometimes, in a large landscape, it gets complicated and the best way is to work with BASIS team to get these details. Another good way to find the values is to go to SICF transaction and navigate to /sap/bc/srt/rfc/ sap/rs_bct_idm_chain_start/<client>/rs_bct_idm_chain_start/default and test the service. This should launch a browser window with authentication prompt. Note the URL and also check if you can login with the correct user.

You might get an error message as shown below:

putNextEntry failed storingcn=948 236 30 1 ,o=bwconnector

Exception from Add operation:javax.naming.NamingException: [LDAP: error code 1 – (WS Client Data Source:1:Error while sending IDM data to BW web service. Original error message: (401)Unauthorized)]; remaining name ‘cn=765 654 56 ,o=bwconnector’

2) Activation of services under /sap/bc/srt/rfc in SICF transaction.  Whenever you get into a new system, these services have to be manually activated (Note 1626311)

3) Note 1586820 – OutOfMemoryError when transferring data to BW (on MSSQL)

4) When you get the below error while running the job, check that you have an updated Java, JDBC and JDBC Driver version.  I spent nearly a month to resolve this issue simply by wasting my time looking for the issue elsewhere  😛

E:Exception from Add operation:ToDSADirect.addEntry … failed with NamingException. (LDAP error: Initialization of LDAP library failed)

Explanation: Waited for LDAP response: timed out after 15000ms.

5) Ensure that the BW user executing the Web Service has correct access in backend system (Role: SAP_BC_WEBSERVICE_CONSUMER)

By default VDS does not give lot of information on the error message.Hence, in VDS navigate to Configure > Logging > Operation and set the Log Level to ALL or DEBUG. In the Identity Center, if you want more information in the DSE logs, select your dispatcher, go to Policy tab and set “Log Level” to debug and stack trace to Full trace. Apply the changes, generate the dispatcher script and restart the dispatcher.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks for the informative post. We are also exploring reporting on IDM with BW. So far, do you find the stanard BW reports useful? From the doc, it doesn't look like the reporting touches the approvals. It would be nice if you can drill down the approvals directly in the reports

      Author's profile photo Murali Shanmugham
      Murali Shanmugham
      Blog Post Author

      Hi Jonathan, I am not sure what type of reports have been made available recently. But in one of my implementations, the data from the BW system was used by custom BO Crystal reports. If the standard does not fit your requirement, you could also use BO reports and query the tables getting real time data.

      Author's profile photo Former Member
      Former Member

      Thanks. I am working on the IDM reporting proof of concept with BW. So far, I noticed that it is lacking 2 major things:

      1) No out of box BW contents on approval reporting.

      2) Vanilla infosets and reports only support direct assignment. The data for the indirect assignment is there in 0IDM_IS04, but stored not in a nice way. We may have to create a custom cube/infoset and it is not easy to do.

      In your implementation, are you using any of the BW infosets at all or simply use BO to run reports against the IDM database.

      Thanks in advance,