Hi Dojo,
I want to abort an automation script using:
ScriptControlMessage abortMessage = new ScriptControlMessage(DataMinerID)
{
ScriptID = scriptID, //this is the running automation script ID
Type = ScriptControlType.Detach // this aborts the script
};
How can I get the script ID when I only know the name?
IDmsAutomationScript only has Name, Description..
Thank you,
Ana
Hi Ana,
It is possible to retrieve all currently running scripts using an SLNet message. It is the same message that is used to populate the table in João’s reply. Do note, as João mentioned, that there could be multiple instances running for the script and that you would abort all of them if you match on name only.
After you retrieve the list, you’ll have a collection of script IDs that you can loop over and pass one by one to another SLNet message that will mark the script as ‘Aborted’. This will result in a ‘ScriptAbortException’ to be thrown, the next time the script interacts with the engine object. (E.g. when it wants to send a message to the server or get an element…) This thus behaves pretty much identical to when a script goes in timeout.
You can find a complete working sample script here: https://github.com/Skyline-ThomasGH/DataMiner_ScriptExamples/blob/main/AUTOMATION_AbortRunningScripts.xml
Do note however that this uses internal SLNet messages. I would not recommend using these for crucial production operations.
Hi Ana,
I don’t think you can determine the ScriptID just from the script name and I don’t believe using that SLNet message is the best way of going about canceling a running script.
The same script can be called more than once and the ScriptID is an identifier of each of those instances as you can see below.
I believe the best approach is for the script itself to have a mechanism to cancel its execution or leverage the engine.Timeout property to ensure a script does not run indefinitely.
Hi
In my use case, the end user really wants to abort the execution of the script from the “outside”. The end goal is to have a button for that. It shouldn’t be a situation that occurs often, but they still want to have that possibility.
Hi Ana,
Unfortunately, I do not think it is possible to achieve what you are after.
Besides the fact that forcibly stopping a running piece of code can cause unexpected problems and data corruption depending on the operation currently executing, to my knowledge there is no straightforward way of retrieving and identifying which script execution has which ID unless you use the source from my screenshot.
I believe your best bet will be to create a new feature request here https://community.dataminer.services/feature-suggestions to be able to cancel a running script externally as it should be implemented in a safe way that allows the script to do some cleanup before exiting similar to what a CancellationToken allows.
Hi Ana,
I could not find a way to request the active script IDs as seen in the screenshot from João’s response. The ID is however returned as part of the ExecuteScriptMessage response, so that would be my only guess to be able to actually get a hold of these IDs if you decide to execute all scripts via this call.
Hi Robin,
Thank you for the suggestion!
I tried it out on the client test tool with several automation scripts and I get always ScriptID 0.
Hi Ana, I was using the ‘Follow’ option while executing scripts and then aborting them. I could see that ExecuteScriptMessage response had a ScriptId, and the abort message was using that same ID. I was executing from the Automation Module ‘Execute’ button. I’m not sure why that gives different results than doing it from Client Test tool. You could check if there are other properties missing in the ExecuteScriptMessage.
The script ID will only be returned when an interactive script is executed. (ExecuteScriptMessage contains ‘INTERACTIVE’ option)
One thing I would like to emphasize is the point where Thomas mentions it will throw the exception when the script interacts with the engine object.
This means that if the script is doing something else and gets stuck or takes a long time to finish there is no guarantee the script will stop as the exception is ONLY thrown from interactions with the engine object.