(2008-12-12) Export To ILM “2” Throws A ‘Failed-Creation-Via-Web-Services’ Error

I have been playing with ILM "2" the last few days and I wanted to test the following scenario. Basically it is the demo environment I always use at customers to show the capabilities of ILM 2007. Now I wanted to do the same build it upon ILM "2". Let’s start easy and small and build it up all the way.

My connected data sources are:

• An HR application based upon SQL Server 2008 (HR-FTE)
  
• Active Directory Domain Services (AD-DS)
  
• ILM "2" Management Portal (ILM)
  

For that I created the following management agents in ILM "2" Identity Manager.

REMARK: Only certain configurations of the MAs are shown here. Others are not because these are not important for this or the defaults were just used.

The credentials for the HR-FTE MA are configured as follows:

The attributes for the HR-FTE MA are configured as follows:

In the ILM "2" Management Portal the Inbound/Import Attribute Flow for HR-FTE looks like:

The credentials for the AD-DS MA are configured as follows:

The attributes for the AD-DS MA are configured as follows:

REMARK: although not shown in the list the "userAccountControl" attribute is also selected

In the ILM "2" Management Portal the Outbound/Export Attribute Flow for AD-DS looks like:

REMARK: In addition to the Outbound/Export Attribute Flow you also need to create an Action Workflow for a Sync Rule and also a Management Policy Rule. Both are not shown here as it is not important for this post

The credentials for the ILM MA are configured as follows:

REMARK: I used this account because I do not know yet what the minimum permissions are to sync to and from the ILM DB

The attributes for the ILM MA are configured as follows:

So looking at this the idea is as follows:

Certain data in the HR application flows to the ILM Metaverse (MV) based upon the Inbound/Import Sync Rule for HR-FTE. From the MV data then flows to the ILM DB based upon the Outbound/Export Attribute Flow defined in the ILM MA. From the ILM DB it flows back into the MV and then it flows to AD. Both the Inbound Sync Rule for HR-FTE and the Outbound Sync Rule for AD-DS are defined in the ILM "2" Management Portal. Inbound Sync Rules are linked to a certain connector space (CS) and as soon as that rule is in the MV the sync engine will apply it when the corresponding MA is "running" (Based upon some Run Profile). Outbound Sync Rules are different and those need additional configuration such as an Action Workflow (AW) and Management Policy Rule (MPR). The objects need to flow first into the ILM DB so that the system can determine, based upon the MPR and AW, which Outbound Sync Rule applies to a certain object. As soon as that is determined the corresponding sync rule is defined on the object as an attribute entry in the Expected Rules List. As soon as that information is in the MV the sync engine will apply it when the corresponding MA is "running" (Based upon some Run Profile).

So I took the following steps:

• The following is required for provisioning to succeed, otherwise you will get those ‘missing parent errors’
  
  • Full Import (Stage Only) for AD-DS
    
• The following is required after the Sync Rules and the MPR and AW have been configured in the ILM "2" Management Portal so that these are available in the MV
  
  • Full Import (Stage Only) for ILM
    
  • Full Sync for ILM
    
• The following is required so that the Outbound Sync are determined for the objects
  
  • Full Import (Stage Only) for HR-FTE
    
  • Full Sync for HR-FTE (this one will provision objects in the ILM CS)
    
  • Export for ILM (this one will export and create the objects in the ILM DB
    

When executing the last step I got the errors as shown below

Looking closer at the errors, you will see:

Now this is weird. It complains about the ‘objectType’ being unknown, but on the other window it does specify it is a PERSON. The ‘CreatedTime’ is also weird because it is a value determined by the ILM DB. It is only determined as soon the object arrives in the ILM DB.

Looking at the object itself you see what data was being exported. From a first look there is nothing wrong with it.

I specified "EMPLOYEES" as the value for the ’employeeType’ attribute because I got the data from my ILM 2007 demo. So I also used it here. Based upon that value the Outbound Sync Rule is applied to the object and because of that it is provisioned into AD. At least, that is what I wanted to.

This sounds very simple, but it took me quite a few hours to figure this out!

To see if something was wrong I started to "click around" in the ILM "2" Management Portal. I also tried to create a new user to see what was being written by default when only specifying the minimum information required. And that was the moment I thought I might have found the error. As you can see below, by default ILM has three values that can be used for the ’employeeType’ attribute…"Contractor", "Intern" and "Full Time Employee".

Now look in the previous picture! I was flowing the "EMPLOYEES" value into that same attribute. Why did it not accept it? Permissions? No, I was using the default domain account and I was able to create a user in the ILM "2" Management Portal. The data itself? My thought was that ILM was not accepting that specific value. I removed it from the Inbound Attribute Flow from the ILM MA and did a Full Sync again for the HR-FTE MA (so that it re-writes the objects into the ILM CS). Suddenly the export to ILM succeeded. Hmmmm!

Then I thought "how are the default three ’employeeType’ values determined in the drop down list?". Got it! Both attribute definitions and attribute binding definitions have an option for attribute value validation. Guess what the values are for both! See below.

Looking at the regular expression…. ^(Contractor|Intern|Full Time Employee)?$

It means: the value starts and ends with one of the specified values. And my value (EMPLOYEES) is not listed. Lets add it to both (I have learned from a colleague of mine that the data must meet all the validations to be written). So the new regular expressions for looked like: ^(Contractor|Intern|Full Time Employee|EMPLOYEES)?$

After that I added the Export Attribute Flow to the ILM MA in the Identity Manager (I had removed it previously as mentioned above) and as before I did a Full Fync of the HR-FTE MA. My ’employeeType’ value was now being accepted by ILM as it now did meet the regular expression.

The moral of this story? The error specified by ILM wasn’t helpful and it did not give any hint the structure of my data was wrong. It would have been better if it would have said some like "incorrect data structure" or "data does not meet validation" etc etc etc. But like that same colleague of mine also said: "that would have been too easy to troubleshoot!" 😉

But….. we’re not done yet!

I have also found other scenarios when the ‘Failed-Creation-Via-Web-Services’ error is thrown. I’m not going to show everything again, but I’m just listing the scenarios I found that cause this:

• Incorrect data structure whereas it does not meet the data validation configured in the ATTRIBUTE and THE ATTRIBUTE BINDING
  
• Duplicate objects. I got the error during the export to the ILM DB when the ILM CS contained objects with the same ‘accountName’ attribute value (although the objects had different MVobjectID)
  
• Insufficient permissions. Before using the default domain account I used another account. It was able to read the ILM schema, but it was not able to write into the ILM DB.
  

If you analyze the ‘Failed-Creation-Via-Web-Services’ error more closely, it basically says it is not able to create/update the object and a few causes are mentioned above.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————