cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X

How do I setup a trigger to fire when the Document ID changes?

smccoy
12-Amethyst

How do I setup a trigger to fire when the Document ID changes?

We need to perform some procesing logic when an item is moved from one document into another. We have setup a trigger rule that contrians Document ID != Document ID[New Value], but the script never fires when I cut-content and paste-content. With a little debugging, I'm finding that tne Document ID of the destination document is not available to me in scripts.

Can someone explain to me how to setup a trigger that fires when the Document ID changes for an Item?

Note: In the Trane Solution, the Document model is mostly disabled in this context. No branching, versioning, etc. The document is merely a container and there is no hierarchy to the node items.

ACCEPTED SOLUTION

Accepted Solutions
mrump
16-Pearl
(To:smccoy)

Hi Sean,

Have you tried the following:

1. setup a trigger rule "Contains [new value]" <> "Contains"

This should fire everytime you manually edit the content of an document is moved.

2. Also check "Contains" <> undefined

That should filter the creation of new nodes

3. inside the triggerscript you can now use the ID of the new and old related Items to get their Document ID.

If they do not match, run whatever you want to do in your script.

BTW: You should keep in mind that any ruel based trigger has and effect on your systems performance. If the trigger takes a signifcant amount of time to complete, the users will notice a "slowly responding" UI.

HTH Matthias

View solution in original post

4 REPLIES 4
mrump
16-Pearl
(To:smccoy)

Hi Sean,

as far as I know, the Document ID is a computed field.

I am not shure whether the trigger rule you defined really catches these type of fields.

Your rule definitely works for a "manual" edits.

But it seems that (comparable to changes in a source-link field) the rule is simply not evaluated when the result of the DocumentID computation changes.

A workaround might be a daily or hourly scheduled trigger that uses a "historical" query to identity the Itmes that have a changed Document ID.

HTH

Matthias

smccoy
12-Amethyst
(To:mrump)

Hi Matthias,

Thanks for the quick response. A schedule-based trigger is not sufficient for our use-case. When a user moves a requirement from one document to another, we need to fire an event and perform some processing logic. Once the requirements are in a new document, the user will want to imediately work on them. So waiting is not an option.

Our first thought was to use the contains relationship, and that worked for a while. Unfortunately it does work when hierarchies are present. Although we currently are not using hierarchies for these types, we are building some prototypes that use parts of the hierarchical functionality of the Document Model. So the solution to this problem needs to work whether there is a hierarchy in place, or not.

We switched to a trigger based on changing the Document ID, because it seemed the most straightforward - simply fire off a script when the document changes. Unfortunately, that does not provide the needed functionality. If there are other ways to accomplish the functionality that we need, we are open to them. Please make suggestions, our knowledge of the Integrity engine and the "Document Model" is limited.

Regards,

-Sean

mrump
16-Pearl
(To:smccoy)

Hi Sean,

Have you tried the following:

1. setup a trigger rule "Contains [new value]" <> "Contains"

This should fire everytime you manually edit the content of an document is moved.

2. Also check "Contains" <> undefined

That should filter the creation of new nodes

3. inside the triggerscript you can now use the ID of the new and old related Items to get their Document ID.

If they do not match, run whatever you want to do in your script.

BTW: You should keep in mind that any ruel based trigger has and effect on your systems performance. If the trigger takes a signifcant amount of time to complete, the users will notice a "slowly responding" UI.

HTH Matthias

smccoy
12-Amethyst
(To:mrump)

Hi Matthias,

1) Yes.. This is where we started and ran into issues when there is a hierarchy in place.

2) Yes... We had that at one point, and had mixed results.

3) We were trying to avoid all the complex code associated with this approach.

- If the "Contains/Contained by has changed", fire the script.

- In the script, find the old "Root Node" and the new "Root Node", the Document ID doesn't seem viable as the new and old value don't seem to be both available in a script.

- If if the "Root Node" is the same, do nothing. If the "Root Node" is different, then iterate over the delta issues and all of its childrent (children's children (.... for all levels)) and perform the logic we need performed.

All we need to do is to perform some reset logic when a requirement moves from one document to another. If we have to build #3, we can. A simpler, and less fragile approach is much more desirable.

-Sean

Announcements


Top Tags