Hi,
I'm working on an automation that creates a scheduled task.
In this task, I select an automation script that includes a preconfigured dummy element.
Depending on the script I choose in the scheduler, the dummy element may vary. However, when the task executes, I receive an error stating that no dummy was selected. This is confusing, as the dummy is already preconfigured in the script.
When I manually select the script in the scheduler UI, simply selecting the script is enough—it automatically fills in the correct dummy element without any issues.
I’ve tried two approaches when creating the task programmatically:
-
Leaving the
PROTOCOL:1:element empty -
Omitting the
PROTOCOL:1:element entirely
In both cases, the error persists. What's more confusing is that when I inspect the scheduled task afterward, the correct dummy element is visible (like in the second image). However, the task still fails with the "no element linked to dummy" error during execution.
Interestingly, if I manually open the "Actions" tab of the scheduled task and click OK (without making any changes), the task then executes correctly.
Is there a known workaround for this issue? If this is the expected behavior, it seems inconsistent compared to the manual setup and could cause problems in automation workflows. My project depends on this mechanism, and I didn't anticipate running into this kind of issue.
Thanks in advance for your support.
Hi David, when you configure dummies in your automation script, you can define a 'Configuration element'. This is probably what you are referring to as 'Preconfigured dummy elements'. Note however that these are actually not some type of 'default value', but are only used to help you select relevant settings in the Cube Automation script UI. There is a small paragraph about this in the docs that you can find here:
https://docs.dataminer.services/user-guide/Advanced_Modules/Automation_module/Designing_Automation_scripts/Script_variables.html#creating-a-dummy (Item 3)
The actual elements that need to be linked to the dummies always need to be provided when the script is executed. When executing a script from Cube, it will pre-allocate the dropdowns for you with the configuration element, but Cube still sends these element IDs to DataMiner in the execute script message.
The same is the case with a Scheduled task. The task configuration itself should include which elements need to be passed on when the script is triggered. This needs to be done with the 'PROTOCOL:X' option strings you mentioned.
As an example, I have two dummies in my Automation script. (ID 1 & ID 2)
I want to pass that elements 686/556 and 686/6742 are used when executing the script. The options strings will look like this:
- PROTOCOL:1:686:556
- PROTOCOL:2:686:6742
Can you try adding this? Let me know if you would still be experiencing issues.
Great to hear it is working. I understand that this configuration can be confusing. It is something we'll take into account for future UI development. Thanks for sharing this with us.
Yes, it works—yet it’s not the outcome I was aiming for. My intention was to trigger scripts generically by their Script Name, relying on what I understood to be preconfigured settings. This would give the customer the flexibility to adjust configurations without needing to touch any code.
That’s why I’m looking more deeply into why this behavior is only implemented in the UI and not supported in the backend of the automation system. It defeats the purpose of having a 'preselected' configuration if it’s only respected on the front end.
Hi Thomas,
Thank you for your quick response.
I now understand the root of the issue. As you suggested—and as the error message also indicated—the script works flawlessly when the dummy element is explicitly provided.
That said, I’d like to point out that this behavior feels a bit inconsistent. When I configure the dummy element via the UI and run the script from there, no further setup is required—the element is automatically selected in the Start Automation dialog.
This suggests that part of the logic (assigning the dummy element) is handled exclusively by the UI. What I had expected—and what led to the confusion—is that this selection would act as a form of preconfiguration that the script could access even outside the UI context, such as when triggered by a master script or scheduler task. It wasn’t immediately obvious that the dummy selection made in the UI isn’t backed by any underlying configuration data accessible to the sub-script.
Kind regards,