Available scripts and objects in synchronization engine mapping scripts

It would help if you would provide the following information:

- the definition of your custom schema type
- the definition (just the edit screen from the left hand side menu) for the mapping
- the scripted property, if that is what you are referring to by mapping script.

Hi Markus,

Sorry to jump in on this and poach the question - I have a real world example!

Suppose a DN for a custom target system container needs to be generated using the CN and Ident_UNSRoot for top level containers, e.g. ou=MyContainer, system=MySystem. That's easy enough but if there are nested containers then you need some way to generate  
ou=MyContainer, ou=MyParentContainer, ou=MyGrandparent, system=MyTargetSystem

As a demonstration of what I mean, here's some generic code from the READ side of a custom property in a sync project. It works fine for me as my code doesn't need to support nested containers, but if the code did need to do that...

currentCN = $CN$
currentDN = $DistinguishedName$
CurrentIdent = "MyTargetSystem"
parentContainer = $ParentCN$
container placement

If LEN(currentDN) > 1 THEN
    ' Application set the DN internally so target system is master, OR
    ' a container was created in Manager tools, so Identity Manager is master
    returnDN = currentDN    
Else
    ' We need to create a distinguishedname otherwise the sync will fail.
    If LEN(CurrentIdent) > 1 AND LEN(currentCN) > 1 THEN
        If LEN(parentContainer) > 1 then
            ' no parent container, so DN is container CN + Ident_UNSRoot
            returnDN = "ou="& currentCN & ", system=" & CurrentIdent
        else
        'we need to create a DN which includes CNs for parent containers, by iteration

             ??????????????????
             ??????????????????
             ??????????????????
             ??????????????????
 
        end if
    Else
        returnDN = ""
    End If
End if
return returnDN

How would I reference the CN of the parent, grandparent etc? I do know that various functions and scripts I'd expect to work without any problem in this code block, don't. I'm only using LEN because if I use IsNullOrEmpty the compiler throws this error:

[1777156] The following errors occured while compiling:
BC30451: 'IsNullOrEmpty' is not declared. It may be inaccessible due to its protection level.

I am still having troubles to understand your use-case.

On what side is the read-script running on the target-system side or on the OneIM side? If we talk about the one IM side, you would create the data in OneIM with a template and not with a scripted property. And, you do not need to iterate over the parents as any parent needs to have the DN set correctly.

Hi Markus,

I believe the OP's question was generic.

You are correct to say I could solve this problem by modifying the template, but that's not really the point. There is no established or formally communicated best practice for resolving this sort of issue, and if I were a customer I would be entirely within my rights to insist on a full and formal change control (with design documentation, impact assessment, regression testing and the rest) to modify any script in production in One Identity that affects multiple target systems.

Which means, there's at least one real world scenario that I can think of (because I've already been there!) where modifying a sync project might take a day to develop, unit test and deploy to production, but making a similar change to the template might take 3 months because of the perceived impact.

Here's a real world technical example. I have seen a UNS system in a dev lab which uses containers. Each row has a "Container ID" and a "Parent container ID" value. The system does actually have a field for DN. But these DNs are not the same that would be calculated by Identity Manager.

Should I use the sync project to pass the DN generated by the target system to One Identity Manager, and have the target system owner deal with any data quality issues this picks up on? Change Control risk: does not affect any other system.

Or should I let the template calculate the DN from the CNs and end up owning any data quality issues? Change Control risk: affects every system with containers in the UNS Name Space, while making me responsible for fixing the data as well as regression-testing the change to the template against all other onboarded UNS systems.

My preference would be to do this in the sync project (if possible) because

(a) Data qualities in a custom target system are not my job to fix. I just need MY code to recognize a data quality issue and react appropriately.

(b) A template change impacts on ALL UNSContainerB.DistinguishedName values for ALL container objects across all target systems to undergo the same sanity check. Really, one-off edge cases unique to one target system shouldn't even touch a "global" script.

Here's another example of a "standard" VB function you can't use...

So at the moment I (apparently) don't even have the option of writing my validation code in the sync project because functions that work fine in the template do not work in a read script.

 

HTH

On the last point... IsNull is VBscript function, not a VB.NET function. You can change your code to return String.IsNullOrEmpty($description$) to achieve what you are looking for.

True, but I was using it only as a simple example.

Maybe a better example:

Suppose you have a custom target system in a SQL database which stores information about a container structure without giving us the full DN. (For each row, it exposes the CN and parent CN only).

I've mocked this up in a VM.

If Identity Manager is not given a DN at all, it will construct a DN for each container which will look like this:

CN=container, CN=ParentContainer, system=TargetSystem

However, that might not match the container structure from the target system's perspective - which might be like this:

OU=Container, OU=ParentContainer, DC=TargetSystem, DC=Company, DC=com

In that scenario, which option would you take?

1. Extend the schema so Identity Manager stores both DNs, with some template scripting to link the two

2. Modify the template for UNSContainerB.DistinguishedName so it has a completely different workflow for just this one target system

3. Build the application's DN in the sync project, and set up a bypass on the template so it doesn't overwrite a UNSContainerB.DistinguishedName which follows the application's convention.

4. Let One Identity use its own container DN format, and have a provisioning workflow that string-replaces "system=TargetSystem" and "CN=" if the application supports a DN as an input parameter.

In regards to your discussion about impact, if you do not adopt the template at all and decide to store a different format from your target system in the DN property in the database, your DN might change if some of the components the DN depends on change. Which would lead to data mismatch. Not a great path to follow.

And I am repeating myself when I am saying, that:

1. You can debug and test the scripted properties in Visual Studio and use the rich IntelliSense features of that development platform.
2. The Sync Engine itself has no dependency on the object layer, therefore the use of any DialogScripts is impossible. The same is true for direct object layer access. Data can be accessed through the system connector to OneIM an i have posted several sample to do that.

In regards to your implementation questions.

Implementing everything in scripted properties is not the recommended way of doing it. Most obvious reason is data consistency. Only your sync project would know how to construct or convert the data. At some point in time you need to create new objects in the OneIM database due to your requirements or you need to report on that data. Do you want to re-implement any converting again on each of these occasions?

In regards to your discussion around the impact of changing the template. The impact of not changing the template is the same (see above) and even your sync project needs to use the correct scope definitions and matching rule to not mess up the complete data in all target systems connected in UNSB. So not much gained if you go that route.