• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 94 subscribers
  • Views 7461 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Available scripts and objects in synchronization engine mapping scripts

zebulon.griggs
over 6 years ago

 I am not finding any documentation that discusses the available scripts, objects, and functions that are able to be referenced from within a synchronization engine mapping script.  I would like to be able to reference the custom schema type (filter), the mapping object name, or other properties of the mapping or workflow that should be available at run time.  The goal in this scenario is to be able to connect to an LDAP system that doesn't natively have groups exposed.  I have created a custom filtered schema class and a mapping that references the new class, but the value for vrtStructuralObjectClass (in browse) shows the parent schema class instead of the one selected during the mapping creation.  I need some way of determining which mapping is currently running so that I can use that information in a property mapping script (OU selection).

Parents
  • 0 over 6 years ago
    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.
Reply
  • 0 over 6 years ago
    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.
Children
No Data