NetWeaver Identity Management 7.1 Implementation Challenges

Challenge 1:  Self Service is Not Intuitive for Unsophisticated Users
Companies deploying NetWeaver Identity Management will find that that the interface for self service for the least technical employees will require training.   Clicking a self service task to request a privilege or business role will result in a standard WebDynPro interface that will show them two search boxes. The one on the left will be for searching for what they want (Available) and the one on the right what they already have had assigned.    Experience has shown that this interface can cause confusion with unsophisticated users. Companies will want to make judicious use of access controls to limit what choices are presented to the self service client.  This requires that logic be established in advance based upon some set to which they are a member.  Additionally, companies will want to train employees in advance of deployment to reduce help desk calls.

Challenge 2:  Fragmented Documentation
The documentation for accomplishing end to end workflows is scattered across many different documents.  There are few scenario based use case “how-to” documents.  Companies deploying NetWeaver IdM 7.1 will want to permit sufficient time for their deployment team to work with the product in order to gain a full understanding, before undertaking a deployment.  Alternatively, companies can bring in outside experts to assist, and train personnel.

Challenge 3:  Limitations in the Staging Environment
NetWeaver IdM 7.1 uses an xml export file to move from development to Test and Test to Production.    The file is exported using a built in utility.  The file is created within the identity center by selecting export.  Many settings between environments are not exported for example, repositories, event agents, provisioning/deprovisioning tasks on privileges must be done manually.  There are some bugs, for example, complex linking between tasks are sometimes broken during import.   These limitations can be mitigated with manual adjustments but the process is lengthy.
Challenge 4:   Job Customization Frequently Requires Custom JavaScript
Under NetWeaver IdM 7.1 the imported “SAP Provisioning Framework” has greatly simplified system deployment, however, there are simple functions, for example, E-Mail notifications which still must be done entirely in JavaScript.  This also applies to any non-simple data modification.   This slows down deployment.  The alternatives are to custom development Java templates or wait for the product to mature.

Challenge 5:  Few Useful Reports Available in Default Installation

Most of the default reports available lack the simplicity of being able to easily show standard audit information like “who did what to whom and when”.  Although extensive audit information is stored the database, it is not always easy to extract the data without extensive SQL queries.  The documentation itself does not clearly explain the complex relationship between the data in the tables.  There are no shortcuts available , careful analysis of the underlying tables and proper query writing must be done.

 

NB: Since I am on a project and can’t go to Tech Ed watch Matt Pollicove’s blog for updates on whether these challenges are being addressed.

Netweaver IdM Connector Development Kit

In the middle of September SAP began its push for certified solutions to increase the number of connectors for NW IdM.  This is the latest “integration scenario.”  Sometimes I think that SAP sets the standard for clunky phrases and naming conventions.  They are looking for partners and developers to increase the number of connectors.  The best part of this is that you get to pay for the privilege of improving their product.

And there is an additional “ONE TIME OFFER” from SAP: Every company that signs a certification agreement in the category “NW-IDM-CON” before December 31^st. 2010 will receive a 20 percent discount on the certification fee.

At least you are getting the certification discount;  I suppose you can then sell your connector to others after achieving certification.  I wonder how many “uncertified” connectors will start to circulate that people will write for their own use.   At times it seems that SAP is entirely driven by revenue generation.   I can’t help but wonder how better off they would be if they actually encouraged a vibrant developer community.

I haven’t had a chance to review the kit yet but having worked on custom jobs under 7.0, the documentation has to be better than just javadocs.

Please Note

In the document for installing the GUI under Netweaver 7.1 sp14 is this little snippet:

Note:
On the server, verify that the file exists in the location
usrsap\j2eeclusterserver0binext
(e.g. C:usrsapF21JC30j2eeclusterserver0binextSQL2005). Sometimes an empty file is
created. If this is the case, copy the file manually into the location then restart the server.

Sometimes?  I have never had a case where it did anything but place an empty file perhaps others have a different experience.  Whenever you see something like this it just shows how pressed for time developers are.  No time to fix this little bug, just release.  For the last three years, most IT is under staffed and fearful of asking for the money they need to get their job done.  I don’t envy them.

Importing the SAP Provisioning Framework

One of the main reasons that one goes with SAP NetWeaver Identity Management is for the integration with other SAP modules.  The main way that this is done is through something called the SAP Provisioning Framework which comes bundled with the product.

There are a couple of challenges to accessing the framework.  The first is how to load it.  By default, the Framework exsists as an import file which needs to be located. By default the import file exists in “C:Program FilesSAPIdMIdentity CenterTemplatesIdentity CenterSAP Provisioning frameworkSAP Provisioning Framework_Folder.mcc”

Now that we know where the Framework is located, we can load the import/export from the NW IDM MMC console. However when loading the Framework you might get the following Error Message: “Could not import global script ’67/custom_generateHRID’ to identity center” I could not find any setting in import/export that allowed me to prevent the script from being processed.

After some research and poking around, I remembered that the SAP Provisioning Framework_Folder.mcc file is actually XML code.  So I went through and searched on the phrase “custom_generateHRID” and found exactly one reference (Highlight added):

      <GLOBALSCRIPT>
         <SCRIPTREVISIONNUMBER/>
         <SCRIPTLASTCHANGE>2007-10-04 12:52:52.7</SCRIPTLASTCHANGE>
         <SCRIPTLANGUAGE>JScript</SCRIPTLANGUAGE>
         <SCRIPTID>67</SCRIPTID>
         <SCRIPTDEFINITION>{B64}Ly8gTWFpbiBmdW5jdGlvbjogY3VzdG9tX2dlbmVyYXRlSFJJRA0KDQpmdW5jdGlvbiBjdXN0b21fZ2VuZXJhdGVIUklEKFBhcil7DQoJcmV0dXJuICIiOw0KfQ0K</SCRIPTDEFINITION>
         <SCRIPTLOCKDATE/>
         <SCRIPTHASH>a2b6834ea85aff0bae2559222d861c78</SCRIPTHASH>
         <SCRIPTDESCRIPTION/>
         <SCRIPTNAME>custom_generateHRID</SCRIPTNAME>
         <SCRIPTLOCKSTATE>0</SCRIPTLOCKSTATE>
      </GLOBALSCRIPT>

So being the intrepid guy that I am, I deleted the highlighted line and tried the import again.  It worked like a charm!  Not sure what to take away from this, but I’m glad I solved the problem.  Has anyone else seen this problem and solved it a different way?

MSKEYs and MSKEYVALUEs, Views and Tables

It does not take long before the NW IDM Administrator starts peeking under the hood to see what sits in the database. This is not a bad thing since there is a lot of good information that one can gain here, especially in the way of analytics and audit data. Understanding the database structure is also important in terms of developing and troubleshooting access rules and other Identity Store SELECT criteria. This posting will talk about a couple of key characteristics of the NW IDM Identity Store database. One of the great things about NW IDM is that there are virtually no differences between the Oracle and MS SQL database schemas so this article works for both environments.

This article will be one of several in a series covering the NW IDM Database structure.  We would be very interested in hearing about other areas of the back end that should be discussed.

When looking at these tables one of the first things that people notice is that there is seemingly no direct reference to the MSKEYVALUE attribute and that there is a value for something called an MSKEY. Consider this extract from a sample Identity Store regarding the user Johnny Scooter:

mskey	attr_id	aValue	SearchValue
187	2	JScooter	JSCOOTER
187	1	MX_USER	MX_USER
187	4	Johnny Scooter	JOHNNY SCOOTER
187	36	Johnny	JOHNNY
187	37	732 123 4567	732 123 4567
187	39	Scooter	SCOOTER
187	40	Information Systems	INFORMATION SYSTEMS
187	41	732 765 4321	732 765 4321
187	42	Systems Engineer	SYSTEMS ENGINEER
187	55	CN=JScooter,OU=IdM,DC=nwidm,DC=local	CN=JSCOOTER,OU=IDM,DC=NWIDM,DC=LOCAL
187	49	Johnny.Scooter@nwidm.local	JOHNNY.SCOOTER@NWIDM.LOCAL

This is a snapshot from the MXI_VALUES table listing four columns, mskey, attr_id, aValue and SearchValue. (For a complete listing of the NW IDM Identity store schema take a look at this document.) The aValue and SearchValue show the attributes’ values in the form that they were entered into the system and a globally consistent format for easy searching respectively. So going back to our question from above, where’s the MSKEYVALUE. If we look in MXI_ATTRIBUTES we’ll find:

Attr_ID	AttrName
2	MSKEYVALUE
1	MX_ENTRYTYPE
4	DISPLAYNAME
36	MX_FIRSTNAME
37	MX_PHONE_ADDITIONAL
39	MX_LASTNAME
40	MX_DEPARTMENT
41	MX_PHONE_PRIMARY
42	MX_TITLE
55	MX_MAIL_PRIMARY
49	AD_DN

So this answers the first question, how do you match up those Attr_ID’s anyway as there is a direct link between the two tables via the attr_id column. The second and more important question is that a value of “2” for Attr_ID corresponds to MSKEYVALUE. So what is going on here, anyway? To begin; let us look at an excerpt from the view MXIV_SENTRIES about our friend Johnny Scooter, which is a separate, friendlier representation of MXI_VALUES since there’s more name information rather than value references.

mskey	AttrName	aValue	SearchValue
187	MSKEYVALUE	JScooter	JSCOOTER
187	MX_ENTRYTYPE	MX_USER	MX_USER
187	DISPLAYNAME	Johnny Scooter	JOHNNY SCOOTER
187	MX_FIRSTNAME	Johnny	JOHNNY
187	MX_PHONE_ADDITIONAL	732 123 4567	732 123 4567
187	MX_LASTNAME	Scooter	SCOOTER
187	MX_DEPARTMENT	Information Systems	INFORMATION SYSTEMS
187	MX_PHONE_PRIMARY	732 765 4321	732 765 4321
187	MX_TITLE	Systems Engineer	SYSTEMS ENGINEER
187	AD_DN	cn= JScooter,OU=IdM,DC=nwidm,DC=local	CN= JSCOOTER, JSCOOTER,OU=IDM,DC=NWIDM,DC=LOCAL
187	MX_MAIL_PRIMARY	Johnny.Scooter@nwidm.local	JOHNNY.SCOOTER@NWIDM.LOCAL

Basically, there are two identifiers that are in use by NW IDM, the first is the more publicly known MSKEYVALUE. This unique identifier is exposed via the Workflow User Interface and is easily seen in MXIV_SENTRIES. However when we look at MXI_VALUES we see that the references to MSKEYVALUE are harder to root out as we need to go through the Attributes table. We also see a reference to the MSKEY field, which appears to be an identifier in both the MXIV_SENTRIES view and in the MXI_VALUES table. This tells us that NW IDM uses the MSKEY field as an internal unique Identifier. Why is this? I would say that the most basic reason is that the MSKEYVALUE is subject to change and would thus be ineligible for use as a link between tables. Even though we have only spoken about user identities, all entries in the Identity store (users, roles, privileges, entry types) have both MSKEYs and MSKEYVALUES. Therefore, if the MSKEYVALUE were the only identifier it would be a poor choice for linking between tables as a foreign key link as referential integrity issues would soon arise.

So to wrap up, what can we conclude from all of this?

• MSKEYVALUE is the unique identifier used by NW IDM at the workflow layer and is changeable
• MSKEY is the internal unique identifier and is not changeable. It is also used as a foreign key link between various NW IDM tables
• MXI_VALUES is an NW IDM table holding information about all of the objects in NW IDM
• MXIV_SENTRIES is a NW IDM View that holds a “friendlier” representation of MXI_VALUES

A Deeper Look Into the Database

Unlike some identity management solutions Netweaver Identity Management uses a SQL database instead of LDAP directory using a database storage engine.  There are distinct advantages to this. For one you can subsume a hierarchy in SQL database but you can’t do set relations in LDAP. The layout of the database can be somewhat confusing so I thought I would pick the most used view and discuss its composition.  Nearly every job and task are run against views and there are many in the backend database.  Most the work is performed against a view called mxiv_sentries.   Before we dig deeper into its composition, it pays to review some of the flaws of SQL which are maddening:

• NULL values are permitted and it seems that everyone implements it differently.  This flaw cannot be bypassed.  Try to avoid filling your database up with NULL values.
• Duplicate Rows  are permitted, you will type SELECT DISTINCT many times.
• Duplicate Column Names are tolerated.  Be careful naming temp tables and using AS,  for example SELECT Col1 AS Name, Col2 AS Name.

There are others you can search them out on the web.  Returning to  the view mxiv_sentries.  As previously  stated this is the most commonly used view, it is denormalized and at first rather confusing to look at.   You will find yourself doing many subselects to extract the information you need.  The diagram below shows you which table columns are used to create the view.

The columns with which you will work with the most are MSKEY, AttrName,  aValue, and SearchValue.  MSKEY is primary key which is generated by the database.  It changes across environments. AttrName is the name of the attributes that you either create or import;  aValue stores the attribute values, for example, the MSKEYVALUE.  SearchValue is aValue in all caps.  The table below shows what we have learned from analysis since the internals of the database are not published.  If you see an error or would like to add something send us a comment.

Greased Lightbox – Update available (v0.18)

→←+–↻

Loading image

Click anywhere to cancel

Image unavailable

VDS Logging

The astute observer will notice that the most recent releases of SAP’s NetWeaver Virtual Directory Server are missing the logging control buttons. There is a  very good reason for this seemingly missing functionality.  Much like NetWeaver Identity Management, VDS is also merging into the NetWeaver, specifically NetWeaver’s logging framework.  This means that there is not a need to have VDS offer internal logging.

However, VDS also offers the ability to run in a “Standalone mode” which allows for VDS to run independently of NetWeaver.  If you plan on running in this mode you’ll need to take advantage of the following configuration tweak in order to access the logs:

Update the file standalonelog.prop that can be found in the Configurations folder.  If you do not have this file, information can be found in the SAP NetWeaver Idenity Management Operations Guide. This document can be found on SDN. The file is a basic text file that includes setting the log level and desired location of the log file.

Once this file is configured it needs to be placed in the Work Area folder (typically underneath the Configurations folder.  Note that creating this file will not bring the buttons back, it will only create the logs in the paths specified in standalonelog.prop.

From what I understand the internal log viewer will be back in the next Service Pack for VDS.  It will be good to have it back.

Netweaver IdM 7.1 and Netweaver CE 7.1

In case you haven’t heard, as of this writing they won’t work together without the enhancement pack for CE. Since both products are in ramp up, you are better off testing with just the standard Netweaver 7.0. Most likely this will not be an issue by the time 7.1 exits ramp up.