Recently our IDM team has noted some interesting issues with the importing and exporting of tasks in NetWeaver Identity Manager. I think it is important to bring these issues forward so that other members of the NetWeaver IDM community can benefit from our experiences.
- We have observed that when tasks are exported and then imported into another configuration there can be some issues with attached NetWeaver IDM Repositories.
For the benefit of those unfamiliar with Repositories in NetWeaver IDM, a repository is a special container within NetWeaver Identity Manager that holds constants and variables used in working with and connecting NetWeaver IDM with Source and Target systems that exist in the Enterprise.
What we have found is that upon importing the tasks into the new IDM environment the NW IDM Administrator can make changes to the Repository (examples would be in changing LDAP Starting points, Host IPs, or ODBC connection strings) and they will seemto save. However the changes will not be reflected in the back-end table. The way around this is to go into the affected task node and change the value in the Repository drop down to something else and then change it back. This forces NW IDM to commit the values back to the database.
It would appear that there is a back end issue in the import that is not causing the repository information to be properly updated. While not the biggest issue to be encountered in the world, I’m sure that this will get in the way of some projects as configurations are ported from one environment to another.
- On a related note, we have noticed that when importing tasks from one environment to another the while dispatchers can be mapped from one environment to another, they are not automatically turned on. This can slow down promotion of an IDM implementation from one environment to another.
While NW IDM does include functionality to turn on all jobs for a selected dispatcher from the Management node of the Admin console, this does not bring the context in which the jobs were assigned to dispatchers in the original configuration, and is therefore not terribly helpful in the typical production environment. Right now the basic workaround is to create a stored procedure that will properly assign the dispatchers to their jobs. Of course, the risk here is that mistakes in working with base tables can be quite costly so extreme care must be taken here.