More blog posts in SAP NetWeaver Identity Management (SAP IdM)Where is place located?

SAP NetWeaver Identity Management (SAP IdM)

4 Posts authored by: Domink Trui

The IdM 7.2 Config Analyzer - A deeper look inside

Posted by Domink Trui Mar 8, 2012

The IdM 7.2 Config Analyzer - A deeper look inside

In this blog I want to give a broader overview on the IdM Config Analyzer as the SAP document "Using the Configuration Analyzer" did. Also I want to visualize the config analyzer a bit more.
At first I will go into the configuration options in detail. After that the output of the config analyzer will follow as well as interpreting it for some examples and telling you what has to be done in these cases. At the end I will sum up the benefits of the config analyzer and give an outlook on the migration sidesteps we experienced so far.

The following systems / applications have been used in this blog:

SAP NetWeaver Identity Management 7.1 SP 4 and SP 5
Both, MSSQL 2005 and Oracle 10.x databases

Knowledge / experience in the following areas are necessary / helpful:

IdM 7.1 in general
The new IdM 7.2 database structure
Understanding and changing database queries

Referenced SAP documents:

How to use the IdM 7.2 config analyzer

Please see the document "Using the Configuration Analyzer" for details about the usage. The most important steps are the correct configuration of the details.
A ready to be used configured overview will look like in the picture below. In this case I retrieved the parameters from a dispatcher:

Please note that the dispatcher has to be on the same machine the config analyzer is executed on. If you have only dispatchers on Unix/Linux, you can use the machine you created the dispatcher or where your Identity Center is running. So, even if you use Unix/Linux as your primary operation system somewhere has to be a Windows. All your correct configured Identity Centers can be used as a source.

For an Oracle database this looks like this:

Please note that I changed the encrypted password to plain text. This can be necessary if the decryption does not work properly.

This is also a good idea when you use the third option of manually entering the connection data. What has to be entered is as follows:

The JDBC URL can found in the Identity Center and adapted as needed
The driver will be oracle.jdbc.driver.OracleDriver or com.microsoft.sqlserver.jdbc.SQLServerDriver in most of the cases. Actually, in over four years and a good dozen of projects I have never seen other drivers than Oracle or MSSQL
In the classpath the paths to the SQL JAR's of the drivers have to be entered

The output

As seen in the SAP document these files are created:

The files in the archive are a bit more for information than the actual migration. Yet, they are quite helpful indeed. Please see chapter "Benefits of using the config analyzer regularly" for more details.
The results of the three issue files will be discussed in the next chapter.

Examples from IdM 7.2 migration

If you take a look in the .html file you will find a neat looking overview. This is helpful in the beginning of a migration where you need to understand and find the mentioned issues. For the .csv file I recommend to store it in Excel format. This allows you to add some more information like a responsible, status, etc. The .xml file, well, the only thing I could think of is viewing it in Notepad++ or a similar text editor.

The first thing which is really eye-catching are a lot of issues from the 7.1 SAP Provisioning Framework. If you have a second development system or dare to (which I do not recommend except in a system created only for this purpose), erase it and all the "sap_" Scripts. After that run the config analyzer again. Now there should be quite less issues remaining. If I remember correctly there are some 200 to 300 of them.
Erasing the old SAP Provisioning Framework is only a good idea if you are really sure that you changed everything to the new one.

The different types of issues are described quite well in the SAP documentation. Instead of describing them again, I will give you some examples. In all queries I replaced the global constants as well as I did some anonymizing.

Example 1: Different logic needed:

Query from a job’s source tab regarding the role model:

SELECT * FROM sapISV_SAProleAssign WHERE
AND (mskey IN (SELECT mskey FROM MXIV_SENTRIES
WHERE attrname = 'ISV_STATUS' AND searchvalue = 'ACTIVE'))))
ORDER BY logonuid, roleAssignments

And here the 7.2 query:

SELECT * FROM sapISV_SAProleAssign WHERE
AND NOT mskey IN (SELECT mskey FROM IDMV_VALUE_BASIC
WHERE attrname='ISV_STATUS' AND searchvalue = 'DELETED'))))
ORDER BY logonuid , roleAssignments

The view change is nothing spectacular. But what was special here is that we had to change the query logic a bit as the role model is quite complex. There were also changes in the , but then the query would be too complex to understand.

Example 2: Two views needed instead of only one

We used this query in 7.1:

select distinct m1.mskey from mxiv_sentries m1
join mxiv_sentries m2 on m1.mskey = m2.mskey
join mxiv_sentries m3 on m1.Searchvalue = to_char(m3.mskey)
where m1.attrname = 'MXREF_MX_PRIVILEGE' and
m2.attrname = 'ACCOUNTISV_SAP' and not m2.searchvalue in (select distinct logonuid from sapISV_SAPuser) and
m3.Attrname = 'MX_REPOSITORYNAME' and m3.searchvalue = 'ISV_SAP'

Which turns into this in 7.2:

select distinct L1.mcthismskey as mskey from idmv_link_ext L1 join idmv_value_basic T1 on L1.mcthismskey = T1.mskey join idmv_value_basic T2 on L1.mcothermskey = T2.mskey where L1.mcattrname = 'MXREF_MX_PRIVILEGE' and T1.attrname = 'ACCOUNTISV_SAP' and not T1.searchvalue in (select distinct logonuid from sapISV_SAPuser) and T2.Attrname = 'MX_REPOSITORYNAME' and T2.searchvalue = 'ISV_SAP'

In this example a triple join on the mxiv_sentries turns into a join on two different views. If you would “just replace” everything with a single view except the vallink views it would not work. Indeed the vallink views would work in this example, but if you have queries where other columns than the standard ones are included, you will get into trouble.
Please note that instead of the searchvalue column the mcothermskey column is used. In latter are only MSKEYs so no more to_char is needed. This is some slight improvement, but should not have such great influence

Personally I prefer value and link over vallink. But it is up to you what you want to use.

Benefits of using the config analyzer regularly

So what are the benefits of this little tool? Well, there more than supporting the migration:

"One click" summary available everytime you want. This comes very handy if you want to protocol the system state on a regularly base.
Detailed information about the actual implementation in some of the most important aspects like the global constants, repositories, jobs, scripts, etc.
Comparability between your IdM systems. Find out the differences between development, test and production.
Finding inconsistencies / possible problems in the audit and on the entries
Job information and their local scripts. This can be very nice if you want to replace local scripts with a global one.
All global scripts in plain text for documentation, archiving and more
For all tasks you can see if there is an access control and whether there are child tasks.

Unfortunately this last part is a bit thin on the outline. There are neither the access queries nor the task names available.

To be honest, the config analyzer is no universal remedy, but it CAN help a lot finding problems and taking a deeper look into the implementation.

Just to give an example:
There is a timeout/deadlocking problem somewhere in the system and it cannot be located. Sure, observing the database server is one part towards the solution, but if it happens quite randomly you can take a look inside the results of the config analyzer in the meantime. Searching for scripts with heavy database access, queries which are complex, etc. All of these can be found more easily looking into the output of the config analyzer.

Migration sidesteps

In this chapter I do not want to examine all the steps mentioned in the migration guide further. What I want to mention here are the experiences made during migrations which were leading to sidesteps during the migration.

Simply "solving the issues" found and going on, has not and probably will not work in most cases. Sometimes you have to rework the changes or even add workarounds to your implementation. Especially the new 7.2 views can be tricky if you have queries which concern both, values and links.

Although there is a new transport mechanism in the portal, by now we have chosen the traditional way of transporting over the new one. Just to be safe which changes really happen. The new way might be useful if you have time and IdM systems enough to try it out beforehand. I would try it out if there are at least four stages and enough time. There I would use the new mechanism between stage two and three (which I assume are test and integration). But if you are under time/budget pressure it is better to transport as before. In addition to this the mentioned rework from chapter "Examples from IdM 7.2 migration" comes into effect.

And never forget to test. Testing every bit of the whole solution is crucial as you do not want your productive system to produce errors. Sounds like an old hat? Yes, but this applies to a 7.2 migration even more than to a "normal development" as not the implementation has changed but the systems' foundation.

But all these sidesteps depend on each individual implementation. Some might be necessary in one project, but a waste of time in the next one. Yet, testing is a simple must have not a sidestep.

Summary

As a conclusion I only can recommend the IdM Config Analyzer. It is not only a must have during the migration to 7.2, but it also can be an everyday tool.
The usage is quite easy. The configuration for accessing the IdM database can be retrieved from a dispatcher, the Identity Center Console or entered manually. As output there are several files from which you can take advantage. These files carry the information about migration issues as well as system and implementation details.
As a small rounding I gave some insights in the migration sidesteps which may occour during a 7.2 migration.

How To Replace SAP CUA with SAP Identity Management

Posted by Domink Trui Mar 28, 2011

How To Replace SAP CUA with SAP Identity Management

In this blog I will write about the CUA replacement process. The topics will cover what you have to consider during this process.

Introduction

The Central User Administration (CUA) is no longer the strategic solution from SAP to centrally manage users and authorizations. The replacement with the new SAP NetWeaver Identity Management 7.2 (IdM) provides benefits in following main areas:

Integration to non-SAP applications
Personal data from HR with automatic user creation / delimiting
Configurable workflows with requests and approvals including emails
More flexible SAP ABAP and SAP Java child system distribution, e.g. including rules for local fields
Cross-system business role model and optionally automatic granting processes based on rules
Reporting with SAP BW or SAP BO Crystal Reports - also for request overviews

Following blog focuses on the step-by-step CUA replacement process, which needs to be well-planned for a smooth shift towards SAP IdM.

Knowledge / experience in the following areas are helpful:

SAP CUA experience
SAP IdM basics

Areas to be Considered

For a successful CUA replacement, following areas need to be considered:

How the administration workflow and role model should be in future with focus on delegating requests and approvals to the departments
Self-Services for password resets, requesting roles, maintaining master data etc. with early workshops for involved users
Rules based on leading systems for personal data and organizational structures, e.g. SAP HCM
Which distribution model to be used in comparison to the CUA, e.g. child system specific attributes handled in IdM
Custom ABAP programs related to user administration need to be adapted or switched off
Other 3rd party systems to be integrated, e.g. directories
Reconciliation processes for child system, when local departments are responsible and inconsistencies could happen

CUA Replacement Process

1. Connecting CUA to IdM
In our case we assume that SAP IdM is already set-up. First, we would connect towards CUA using the SAP ABAP repository template for the system connection and the job templates for data import to SAP IdM. The job should be adapted to map fields according to the distribution model. The information from the child systems is retrieved via CUA in this step.

When IdM administrative masks and other workflows are configured, the data can be checked. In addition, the distribution model needs to be adapted. The provisioning can be switched on step-by-step for certain attributes / roles / users to test the functionality from a leading IdM and distribute via CUA. This helps the users to be trained and gain knowledge about IdM. CUA can still be used for certain reports or other custom functionalities. In this case, a reconciliation process inside IdM needs to be configured.

In addition, other leading and target systems could be integrated to already use new IdM functionalities, e.g. with HR data and a business role model for CUA, SAP Java systems and the company directory.

2. Connecting CUA Child Systems to IdM
From now on the child systems will be connected one after another to IdM. The general steps for a connection to a child system are:

Maintain connection data in IdM via a repository
Load the data from the child system to IdM via a job and stop administration via CUA
Disable the CUA connection inside CUA and the child system itself
Migrate the account information and SAP roles inside IdM via a job pointing directly to the child system instead of CUA
Switch on initial provisioning from IdM and start administration via IdM
Schedule the child system in IdM for the update load / reconciliation job

This downtime between CUA and IdM administration could take up to a few hours when you have large amounts of data in each child system.

3. Shutdown the CUA
After the last child system is disconnected from the CUA, the CUA itself can be disconnected from the IdM and turned off.

Summary

A full replacement of the CUA by SAP IdM has a lot of advantages, e.g. integrating non-SAP systems, using delegated workflows and more flexible distribution rules. Therefore, the mentioned areas need to be evaluated to get the best out of the new IdM functionalities.

After setting up SAP IdM, the CUA is first connected to IdM. This solution can be tested by still having the administration possibilities inside the CUA - if needed. Afterwards, the child systems are disconnected from the CUA and connected towards IdM. This process can be changed and optimized to own needs. With the shutdown of the CUA, the full advantages of IdM can be used.

Custom Approval Objects with SAP Identity Management

Posted by Domink Trui Jun 18, 2010

Custom Approval Objects with SAP Identity Management

Another great advantage of SAP Identity Management is that it is possible to extend the schema to own needs. With this you can create your own custom entry types and attributes. In this blog this is used to create two entry types. The first entry type will be for requests (ISV_REQUEST). The second one will be used after the requests are approved (ISV_PENDING_VALUE). This second entry type contains values which will be added to a person object as part of an approval process at a given time. The construct is similar to the existing Pending Value Object (PVO).

The following systems / applications have been used in this blog:

SAP NetWeaver Identity Management 7.1 SP4
MS SQL Server 2005 Database

Knowledge / experience in the following areas are necessary / helpful:

IdM Schema in general (Custom Entry Types and Attributes)
Workflow / Approval in general

Scenario description

Imagine you have several processes in your company, which include approving new users or deactivation for existing ones. I will focus on these two use cases in this blog.
You retrieve any needed information and begin to implement the processes in the IdM. As it is no good idea to let normal users create person objects, one might think about using a request instead. This is due to security issues a better option. If normal users create persons this could easily be used to have access to information normal users should never have to. Using a standard PVO will not work because of the administrators have the knowledge to set up the SAP roles and AD specific attributes like Terminal Server Profile Path in the approvals. See the next chapter about for details.
After coming up with the solution to create a new entry type for requests, it is possible to let the user enter the data for the new employee and the approvers to complete the needed information. After everything is done, you can create a new person object. E-Mail notifications can be sent during the process to the requester, approvers and the manager of the new employee.
For the time dependant deactivation you will also need an entry type for that. One could also use the standard PVO for that but if you want to do some special work the standard PVO just will not work.

Advantages in using own Approval Objects

For information about the standard PVO refer to the Identity Store Schema (link above).
One of the advantages of the standard PVO is the built in functionality of time dependant applying. If you want to use your own approval objects, this functionality has to be built up by your own.
Yet, there are some disadvantages of the PVO. The attributes of a PVO cannot be changed in approval tasks. So there is no possibility to change the data given in further approval steps. But this is sometimes crucial for the daily work of administrators / key users which approve the requests.
Another downside is that the PVO is applied internally and then moved to the history. If you want to do more with a pending object than just applying one value of the PVO will not work. If you want several attributes to be changed or special provisioning, I suggest using your own Request / Pending Value object construct.
For this you will need two new entry types already mentioned. The ISV_REQUEST object will handle the requests and approvals and the ISV_PENDING_VALUE will do the PVO part.
The request may contain every attribute your MX_PERSON object has like first name, surname, account information, roles, etc. You can also retrieve information from the person the request was filed upon.
In addition to these, the pending object will also contain the same attributes of the PVO like valid date, attribute name and value. Yet, the pending does not need every attribute of the request like the information about the approvals or not relevant attributes for the applying of the pending.
In combination these two entry types overcome the disadvantages of the standard PVO. Also they can be adapted individually to your needs without manipulating MX entry types or their behavior.
The infrastructure for your own Pending Value can easily be set up using tasks and jobs in the Identity Center. The UI and approval tasks retrieve all needed information. The rest is done automatically in some post processing tasks.
The own Pending Value has also an advantage in post processing after applying the pendings. You can call tasks which handle the setting of attributes and do some special provisioning actions.

Usage of the Custom Request Object

Using requests you can deal with all information and roles for a new or existing person before writing these to a person. In this part I will show you how the Custom Request Object can be used to file requests for a new user and deactivation.

Requesting a new user

A request in the UI for a new user might look like this:

After the user completes the requests and presses the "Request new user" button, the post processing can begin. For example this can be:

Setting up general request attributes
Mailing the user and administrators / key users
Checking on existence of the desired username
Setting the requester

Setting up general request attributes

As it is no good idea to use the standard MSKEYVALUE in general, I recommend resetting it via a ToGeneric pass and a small Javascript. This is simple, just set the MSKEYVALUE using uIS_SetValue. The code might look like this:

var newMskeyvalue = "REQUEST:USER:" + desiredUsername + isv_generateTimestap()
uIS_SetValue(mskey, isId, "MSKEYVALUE", newMskeyvalue);

Please note that the variables isId and desiredUsername have to be set up properly. The mentioned script for timestamp generation is optional. Just use another small script to retrieve the actual date and parse it into what you want. An advantage of setting up a timestamp is that you can search for the date the request was sent.
With another script you can set up the requester. Showing the requester in the approval tasks is a really nice feature for the administrator / key users.

Mailing the user and administrators / key users

For the mailing you have to set up several tasks and scripts. Best practices are text or ini files to store the text templates. In these templates you can use "variables" to fill in the actual values of the request. An example might be __FIRSTNAME__. You need a script that fills in these variables to whatever the user entered.

Here an example of a mail. The replaced variables are red framed.

Checking on existence of the desired username

The desired username should be checked on existence before the request is even approved. You could also use the unique option of an attribute (Validation tab) but then you would have to store this at the persons, too.

There are advantages and disadvantages of doing this, also depending on your company’s solution. One of the disadvantages is that you have to maintain every namechange (old and new name!) or else there might be problems in the future mixing up persons. Another might be the reconciliation with your end systems (SAP, AD, …) if you still allow users to be added in special cases. Also you have to overcome the problem of storing the username in the request and the person at the same time. Or at least until the request is moved to history.

In this case I will focus on the option to not use the unique attribute. To ensure that there is no existing user with the same username, simply use a script with a uSelect() on the database:

SELECT COUNT(*) FROM MXIV_SENTRIES WHERE AttrName = 'MSKEYVALUE' AND Searchvalue = '" + desiredUsername + "'"

If there are zero rows, everything is fine and the username can be returned as is. In the other case you have to ensure that the administrators change the username. To enforce the changing in the UI it is a good idea to use a regex validation on the field in the approval tasks. To ensure that the username is really unique you can loop around in a several approval task until the username is entered as a unique name.

Approving tasks

After all the post processing is done the administrators / key users have to approve the new user. Using the approval tab you can set up who should approve this request.

In this example the mail address has been generated using the format firstname.surname@sap.com.
The approver has the possibility to change the username and the other information. Yet, you can handle this to your own company’s needs

The SAP Roles tab shows the two attributes for privilege and roles which the approver can choose due to the entered further information of the user.
After all approvals are done you can create the user using a ToIdentityStore pass. Afterwards mail the manager that a new user was created. Depending on how you hand over the password, you can implement this as needed. The easiest way during implementation is sending it in the mail to the manager.

Requesting deactivation

The request for deactivation shall be time dependant so that a user can file the request long before the deactivation should take part.
This process will not only use the ISV_REQUEST but also use the ISV_PENDING_VALUE for the time dependant processing. How this Pending works is described in the next chapter. Yet, before the pending you have to set up the request firs, which is quite simple. Just let the requester enter these things:

The user which should be deactivated
The date on which the deactivation should be
A reason for the deactivation

The post processing after filing the request can be similar to the one for user creation.

The approval may look like this:

After the approving is done an ISV_PENDING_VALUE is created automatically. The Pending is created similar to the normal PVO.

Usage of Custom Pending Value Object

The custom pending value is used to hold the pendings until the day they should approved. This is similar to the PVO. Remember, the PVO could be used, too, but will not work when you not only want to apply one value but have to do more work like special provisioning.

You now set up the processing of the Pending Value. There are two parts:

A job which is scheduled every night and applies the Pending Values
Tasks which are called from this job

The Apply Pending Value Batch-Job

The first thing you have to do is gathering information which Pendings in your system are ready to be applied. This is still very close to the PVO. You have to retrieve the following values:

The Pending Values which shall be applied today
The person which shall be deactivated for each Pending Value

After that you have to write the Pending Value to the person the request was filed upon. In this case the pending value is the MX_LOCKED attribute with a value of 1 indicating the lock.
From this point on there may be other things to be processed, like mailing the requester, manager, user or doing some special provisioning actions. For the deactivation process it could be needed to remove all groups and roles from the person, depending on your existing processes.
For only one type of pendings (e.g. deactivation or name change) you could do this in the job itself. But if you want to set up more than one type I suggest using tasks. Post processing requests like name change or reactivation might be trickier to handle. Especially when you have to divert more than one case, a task structure is more flexible than a job in the Job folder. For these processes running provisioning tasks is just fine.
The last thing you have to do is to delete the Pending Values which were applied before. Simply call a ToIdentityStore pass with the changetype delete on the MSKEYVALUE of the Pending Values.

Possible task structure of the post processing

As the post processing of the deactivation in this case is quite simple this could also be done in the job above. Yet, I want to call a task "Delete roles and privileges" from the job. Also it is possible to do the post processing time dependant. Let’s say the roles and groups shall be deprovisioned not directly but a whole month later. Simply call the task with the parameters you want.

Summary

If you want to set up your processes involving every user in your company you can do this by extending the given schema. Two objects for requests and pendings will be enough to handle any processes you have. The first collects all data from users and administrators / key users independent from all existing persons in the IdM until approval of the request. The latter handles time dependant processes like name change or deactivation.

How to use custom classes in the SAP NetWeaver Identity Management

Posted by Domink Trui Nov 17, 2008

How to use the IdM-API – According to the custom passes FromCustom and ToCustom

One of the largest advantages of the SAP Identity Management is that it supplies not only the predefined passes to the well-known target systems but also has a Java-API delivered right out with the installation of the Identity Center. With the help of the API jobs can be equipped with passes which handle the connection to custom systems. So the IdM-Java-API can be used to implement a connection to every system which handles users, their attributes, roles, etc.

The following systems applications have been used in this blog:

SAP NetWeaver Identity Management 7.0 SP02 Patch 2
MS SQL Server 2005 Database
Eclipse Europa (Version 3.3) using
Java SE SDK 6.0

Knowledge experience in the following areas are necessary helpful:

Java programming language
Basic API knowledge

Scenario description

Imagine the following. There is a system in your company which is essential to the daily work but costs a lot of maintaining work administering the users, their attributes, access roles, etc. Not to forget the everlasting problem caused by passwords resets. As there exists already a SAP IdM which handles all of the systems but this last one, it would be great to administer them all using the IdM. Unfortunately there are no passes which can be used in jobs to do this in a swift way, like we are used to.

For this little problem exists a powerful IdM-DSE-Java-API, especially the classes used in the FromCustom and ToCustom passes. What now has to be done is to write the system’s implementation on the base of the classes of the Identity Center API. Note that the target system has to exhibit a way to access the users, their attributes, roles or whatever shall be retrieved using their Java-API. For other systems different passes have to be used, for other programming languages the Windows runtime engine has to be selected instead of the Java runtime.

Preparations in the IdM

Before you start the implementation for your system, the classpaths of your later class files and custom Java-API have to be set up. This is done in the Identity Center: Go to Tools => Options => Java => Classpath extension. Note that classfiles must not be referenced with their complete path but with their folder they are in. If there shall be more than one entry, they have to be separated by semicolons.

A jar-file entry then looks like:
C:\\SomeFolder\\APIs\\CustomAPI.jar

The folder for the class files has to be set like this:
C:\\SomeFolder\\CLASSES

For further information on this please refer to the documentation of the Identity Center.

With this the preparations in the Identity Center are finished and the creation of the passes can begin. The implementation of the classes will follow afterwards.

Setting up the passes and the needed information

As the passes have to be set up as FromCustom and ToCustom ones, you have to set up the tabs Source and Destination and if needed the Delta, too. The Repository tab has to be set according to the usage. Also the information about the repository has to be specified in the Identity Center. In this example I use only one attribute at a time to avoid information overload. \ Instead of the server’s name, there are attributes possible like the user name and password which is used for the connection, the port, the database name, etc. All depending on the system which shall be accessed.

Repository information

To avoid having to rewrite and compile the classes again every time, you use a new repository or change the settings otherwise, there is a possibility to hand over the needed information. That is, the classes can a bit more generic.

There is a way to avoid changing and compiling the classes again and again, if you want to use a different system. Just hand over the needed attributes and retrieve them in the classes. This information have to be specified in the constants of the management section of the repository. How this is done the class in detail is explained in the section Retrieval of necessary attributes.

FromPass - Source tab

In the field Pass type the path to the class has to be specified. That is the folders are separated by dots ending with the class name itself, without .class as shown in the example. Using the FromExample.class, its unique package (see the implementation section below) and the classpath above, the file would be located in:
C:\\SomeFolder\\CLASSES\\idm\\blog\\apiexample\\FromExample.class

The only parameter in this example which will be handed over, is the server’s name. The name example.server.name only contains dots because it is easier to read then, they have no special meaning. Any parameter name will do as long it is unique in this pass. As the value is retrieved from the information stored in the repository, the variable %$rep.Example_Server_Name% can retrieve it during runtime.

FromPass - Destination tab

In the Database field simply insert the variable for the Identity Center as %$ddm.identitycenter%. Specify the table to which the entries shall be written to in the Table name field. Using the Table update options you can specify what has to happen to the table.

In the field below the Insert template button the table’s schema will be specified. Only what you enter here will be written to the database. In this example there is only a user Id entered. The Target, Type and Size fields are for the table. The Source is specified is the key used in the class building up the DSEEntry object.

FromPass - Delta tab

Not needed here in the from pass.

ToPass - Source tab

Depending on whether you use the Identity Store or not, you have to check the Use identity store button. The Database field is set accordingly. The SQL query has to be entered manually in the SQL statement field or generated using the button right of this field.

ToPass - Destination tab

As in the Source tab of the FromPass the Pass type is the path to the class. Also the paramater-value pairs are the same as in that section.
The only parameter in this example for the server’s name example.server.name and the variable %$rep.Example_Server_Name% are used here.

Note that only inserted attributes can be retrieved within your classes.

ToPass - Delta tab

The delta database has to be enabled while using the ToPass. So activate it and select the database by using the %$ddm.identitycenter% variable. The Delta identifier, the Delta key and the Source key have to be set accordingly, too.

Preparations in Eclipse

Now we are ready to create a new Eclipse Java project to do the programming work. If you choose to work local on your own machine you have to copy the class files on the server to the location specified above. The other option is to set the projects workspace and ist output folder in a way that it matches the previously specified location of the classpath.
However, I choose to work completly local and only copy the class files to server when needed. To do this efficiently I wrote a little copy batch file which I stored in my Java project. Note that the batch file may vanish from time to time, if it is placed in the binary folder of the project.
To be able to extend the FromCustom and ToCustom classes, it is necessary to import the jar-file they are located in to the Java Build Path of the Eclipse project. For this import the DSE.jar using „Add external JARs“ in the properties. Both classes can be found in the package com.sap.idm.ic.
Now we are finally ready to write the system’s classes.

Implementing the system’s classes

At first we will create a custom FromExample class using FromCustom as superclass. After that a ToExample class extending ToCustom will be implemented.

FromCustom

Create a class and name it like FromExample.java. This class has to extend the FromCustom class as superclass and will be placed it in a package of your choice. It is advisable to use unique names like idm.blog.apiexample for the package declaration to avoid any interference with other classes. The checkbox for "Inherited abstact methods" has to be checked, too.
After the creation and some cleaning up the FromExample class looks like shown below.

Method	Parameter	Description	Return value
initCustom	None	The initCustom retrieves all information which is stored in the IdM repository about the target system to built up a connection to your target system.	A boolean which indicates the success of the initialization
hasMore	None	The hasMore method checks if there are still entries of the type DSEEntry left.	A boolean which indicates that there are more DSEEntry objects available
getNextEntry	None	The getNextEntry retrieves the next DSEEntry object.	A DSEEntry object
exit	None	The exit method is designed to do the cleaning up work in your system. If you need to close connections which were established previously, close them here.	As this is a void method, nothing will be given back.

How the hasMore and getNextEntry methods are implemented in detail cannot be stated here, because every system is at least a bit different.

Meaning of the return values of the methods - FromExample

Method	Return values
initCustom	true means that the initialization in the custom system was successful	false means that the initialization in the custom system was not successful
hasMore	true means that there are more entries in the custom system	false means that there are no more in the custom system left
getNextEntry	A non-null value with a filled DSEEntry object means that this entry will be processed to what was specified in the destination tab of the pass	A null as return value means that the pass will throw an error because there is a no object given back

ToCustom

Create a class and name it like ToExample.java. This class has to extend the ToCustom class as ist superclass and will be placed it in a package of your choice. It is advisable to use unique name like idm.blog.apiexample for the package declaration to avaoid any interference with other classes. The checkbox for „Inherited abstact methods“ has to be checked. After the creation the ToCustom class something looks like shown below. There are five inherited methods which have to be filled with your custom code.

Method	Parameter	Description	Return value
initCustom	None	The initCustom retrieves all information which is stored in the IdM repository about the target system to built up a connection to your target system.	A boolean which indicates the success of the initialization
addEntryCustom and modEntryCustom	A DSEEntry object which contains one or more attributes	The addEntryCustom and modEntryCustom are quite similar because both take a DSEEntry object. This object is created in the Identity Center pass and will be described in the section where the passes are created. Depending on your target system both add and modify method	A boolean which indicates a successful adding or modification
deleteEntryCustom	A string with a unique identity	The deleteEntryCustom takes only a string, e.g. with the user name in it. If more information were passed over, the splitting work can be done here.	An integer which indicates the success of the deletion
exit	None	The exit method is designed to do the cleaning up work in your system. If you need to close connections which were established previously, close them here.	As this is a void method, nothing will be given back.

Meaning of the return values of the methods - ToExample

Method	Return values
initCustom	true means that the initialization in the custom system was successful	false means that the initialization in the custom system was not successful
addEntryCustom and modEntryCustom	true means that the adding/modifying in the custom system was successful	false means that the adding/modifying in the custom system was not successful
deleteEntryCustom	-1 means that the deletion in the custom system was successful	Any integer above -1 means that the deletion was not successful

Retrieval of necessary attributes

So, how to get the information which were handed over from the FromCustom and ToCustom passes? Remember what was specified in the passes above? The values of can be retrieved using the getPassAttr in the initCustom methods. Simply hand over the parameter you entered in the pass. For example the server name of the custom system can be retrieved as follows:

String exampleServerName = getPassAttr("example.server.name");

The second thing refers to the DSEEntry objects. As there are two way these objects are used, there are two different access methods for them. In the case you have to give an DSEEntry object back, simply create a new DSEEntry object and put all necessary attributes in it:

nextEntry.put("entryName“, entryName);

If you get an DSEEntry object and want to retrieve the attributes use the get method:

String entryName = entryToAdd.get(„entryName“);

Filter Blog

By author:

By date:

By tag: