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 (http://scn.sap.com/docs/DOC-17058) 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
- DELTA_NEW_LAST_CHANGE_NO_CURRENT_ATTRS
- DELTA_NEW_LAST_CHANGE_NO_CURRENT_LINKS
- DELTA_NEW_LAST_OLD_ID_OLD_ATTRS_LINKS
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 :razz:
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.
- SAP Managed Tags:
3 Comments
