Regarding the triggers that you can use in protocols, there is the “after startup” trigger which mentions:
The trigger will go off when the specified protocol has started.
For example: Restart or Activate after stop. It will not trigger after a Pause.
What is meant with “when the specified protocol has started”? Can I replace “protocol” by “element”? So that it means: each time an element using that protocol is created / activated / restarted, the “after startup” trigger should go off for that element?
Reason of my question is that I uploaded a protocol, created an element and (re)started it, but that trigger doesn’t seem to go off and I would like to understand a bit better how such trigger should work (maybe I’m just doing something wrong)
Thanks in advance!
The documentation is indeed confusing, but your guess is correct. The after startup trigger in the protocol used by that element will execute its content whenever the element is (re)started.
How do you know that the trigger is not working? What content do you try to execute from your trigger. To give you an idea, the after startup trigger should look something like this:
In this case the trigger executes an action with id “1”. The comment you see next to that is added by DataMiner Integration Studio (DIS) dynamically and displays the name of the action.
Note that if you want to trigger a QAction from an after startup trigger, you must follow the order explained here, or it may not run correctly.
After startup trigger -> Action -> group -> Action ->QAction
Michiel’ link goes to the old DDL that is going EOL where the screenshots are all broken.
I can’t find this same note “Executing a QAction after startup” in DoJo anywhere else.
@Sam: I found another example using the “after startup” trigger here: https://community.dataminer.services/documentation/data-ingest-control-plane-internal-flow-element-startup/?hilite=after+startup
Unfortunately, it seems that the article is from 2021. As you said, I have found no other example either. Additionally, I have run into the situation that the QAction that is triggered by the second action is executed continuously and in fast succession (it only sets two parameter values).
@Michiel: Do you have a recent example of where you use the “after startup” trigger? I have found no explicit references in the documentation or the “SLC SDF” protocol examples.
Hi Joey, thanks for the clarification!
My QAction is following the flow: Trigger -> Action -> Group -> Action -> Parameter -> QAction
Finally, in that QAction, a script is triggered using the ExecuteScript method of the SLProtocol class.
I investigated further and noticed it’s an issue in my script. Fixing that gives me again the behavior that I want. (I guess I was confused, because I added a “protocol.Log” line in my QAction, but didn’t find it in the logfile, even though I set the loglevels to the highest value)