• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 94 subscribers
  • Views 7455 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 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.

     

Reply
  • 0 over 6 years ago

    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.

     

Children
No Data