sync and move


Hi,

in case of a move to a certain container in the id vault we want to
remove the association and delete the target object.

Whenever we move an object in the id vault (through a driver) we are
receiving a sync from-move and a move operation. If we do not care about
the sync a merge is issued before the object is deleted through a ctp at
the end.

I know that in general the sync operations are important, but can we get
rid of them in the scenario described? Can we be sure to receive a move
realy anytime or would it be better to get rid of the move operation and
simply convert the <sync from-move=true> to whatever we need to ensure
not to run into the merge,

Regards,

Thorsten


--
tschloesser
------------------------------------------------------------------------
tschloesser's Profile: https://forums.netiq.com/member.php?userid=3232
View this thread: https://forums.netiq.com/showthread.php?t=54371

  • tschloesser wrote:

    > I know that in general the sync operations are important, but can we get
    > rid of them in the scenario described? Can we be sure to receive a move
    > realy anytime or would it be better to get rid of the move operation and
    > simply convert the <sync from-move=true> to whatever we need to ensure
    > not to run into the merge,


    In my experience, move events sometime get lost, especially when replication is
    in the mix. Sync events on the other hand seem to show on the subscriber all
    the time. But why choose either-or and not trigger on both?

  • you are right. Triggering on either the sync and the move is simple, but
    in this case we receive (at least) two cosmetic errors, because the
    remove-association and delete are done twice.

    Since the errors are only cosmetic we can live with them - but if there
    is a safe and easy way to ensure the operation are only run once this
    would be nice ;-)


    --
    tschloesser
    ------------------------------------------------------------------------
    tschloesser's Profile: https://forums.netiq.com/member.php?userid=3232
    View this thread: https://forums.netiq.com/showthread.php?t=54371

  • tschloesser wrote:

    > Since the errors are only cosmetic we can live with them - but if there
    > is a safe and easy way to ensure the operation are only run once this
    > would be nice ;-)


    You could check if the association can be resolved to a DN before attempting to
    delete/remove asociation. Or write the association of the last deleted object
    to a driver-scope variable and check against that.
  • I think a sync event that happens because of a move always has
    from-move="true" on it as well which can be detected. Maybe that's a ba
    memory, but Lothar's right; check the conditions for validity first and
    you should be okay.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • ab wrote:

    > I think a sync event that happens because of a move always has
    > from-move="true" on it as well which can be detected.


    That is the assumtion I have always had. We try very hard to avoid moves in our IDVaults though.

  • Thanks!

    I did and now we got rid of the "merge" which ist great ;-)

    But we get different at least three different scenarios all because of
    the same trigger.

    We trigger the move of an user in the id vault through an workorder -
    this is working fine!

    But depending on things we can not name the eDir driver (the new one) is
    receiving differnt operations.

    1)
    Sync from-move=true move (within the same transaction)

    2) only one sync from-move=true followed with a sync chachedtime="some
    timestamp" (two individual transactions)

    From our perspective the move is always initiated by the workorder
    driver.

    All drivers are running on the same saver holding the master replika.

    Can anybody explain why we are receiving such different kinds of
    transactions?

    Thanks !


    --
    tschloesser
    ------------------------------------------------------------------------
    tschloesser's Profile: https://forums.netiq.com/member.php?userid=3232
    View this thread: https://forums.netiq.com/showthread.php?t=54371

  • On 09/30/2015 04:54 AM, tschloesser wrote:
    >
    > I did and now we got rid of the "merge" which ist great ;-)
    >
    > But we get different at least three different scenarios all because of
    > the same trigger.
    >
    > We trigger the move of an user in the id vault through an workorder -
    > this is working fine!
    >
    > But depending on things we can not name the eDir driver (the new one) is
    > receiving differnt operations.
    >
    > 1)
    > Sync from-move=true move (within the same transaction)
    >
    > 2) only one sync from-move=true followed with a sync chachedtime="some
    > timestamp" (two individual transactions)


    Probably just eDirectory internals as they are picked up by IDM. Moves
    are messy, and I've never found anybody from engineering who could explain
    the difference in a way that was detailed enough to make a difference to
    me. At the end of the day I usually veto all move events from the vault
    and only rely on the sync events with from-move="true" since those seem to
    be reliable. I also strongly try to get the vault on the Master as
    recommended, and generally try to avoid moves in the first place (the
    biggest exception being from active to inactive containers using the
    WorkOrder driver). All of this combined means the systems work, and
    therefore the details on why this, or that, or the other, are purely
    academic since the customer is happy and the system reliable.

    If you want more details, knowing how they are to be used may be helpful.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • ab wrote:

    > details on why this, or that, or the other, are purely academic


    *You* have gone pragmatic and given up on researching these details? Did you
    run out of chocolate and icecream lately? ;-)
  • Ha!

    I have limits to my un-pragmatim (word?). I cannot see why it would
    matter since the results are reliable for me, so pushing will get me
    somebody telling me some details I'll forget, and which get me where I am
    today. I have better things to do, like eating ice cream and chocolate.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  • Hi folks,
    I can share my "secret sauce" that allow me to deal with move operation
    and act only on "last" sync event. (timestamp=0#0)

    > <rule>
    > <description>Veto</description>
    > <comment xml:space="preserve">Block this event from process, if it NOT
    > last transaction (after MOVE)
    > v2.2</comment>
    > <conditions>
    > <and>
    > <if-operation mode="case" op="equal">sync</if-operation>
    > <if-class-name mode="nocase" op="equal">User</if-class-name>
    > <if-xml-attr name="from-move" op="available"/>
    > <if-xml-attr mode="nocase" name="timestamp"
    > op="not-equal">0#0</if-xml-attr>
    > </and>
    > </conditions>
    > <actions>
    > <do-if>
    > <arg-conditions>
    > <and>
    > <if-global-variable mode="nocase" name="gcvDebug"
    > op="equal">true</if-global-variable>
    > </and>
    > </arg-conditions>
    > <arg-actions>
    > <do-trace-message color="yellow">
    > <arg-string>
    > <token-text xml:space="preserve">0 Stop and skip events in the
    > midle of Move Transactions!!!</token-text>
    > </arg-string>
    > </do-trace-message>
    > </arg-actions>
    > <arg-actions/>
    > </do-if>
    > <do-veto/>
    > </actions>
    > </rule>


    Alex


    --
    If you find this post helpful, please show your appreciation by clicking
    on the star below :cool:
    ------------------------------------------------------------------------
    al_b's Profile: https://forums.netiq.com/member.php?userid=209
    View this thread: https://forums.netiq.com/showthread.php?t=54371