We have noticed that performing actions on elements (i.e. setting parameter value) via the automation scripts takes considerably longer time than usual, especially the automation scripts for controlling our satellite uplinks. (usually it took 10 seconds to complete script commands and now it could take over a minute).
Is it possible that the DMA which the automation scripts are run on is approaching its limits (almost 1000 elements) and hence the latency during setting parameters? The way I understand it is when an automation script wants to set a parameter on an element a separate thread is created by that element which is then added to the execution queue of the SLProtocol and the script waits until the set parameter thread is executed.
I remember reading somewhere in the documentation that the automation scripts are run on the agent on which the script was created (or uploaded to) and regardless of which agent the client executing the script is connected to. Is this correct?
I remember reading somewhere in the documentation that the automation scripts are run on the agent on which the script was created (or uploaded to) and regardless of which agent the client executing the script is connected to. Is this correct?
I briefly tried this on a test cluster and a script always runs on the agent I'm connected to.
From the automation app in Cube, I have not tried through a correlation rule as it wasn’t mentioned in the question. I believe scheduled tasks always trigger the script on the agent the task is hosted (DataMiner column in the Scheduler app). From a QAction it will indeed depend on the DataMiner ID property of the ExecuteScriptMessage (default is -1, which is the agent you’re connected to).
Hi Jens,
Please could you let me know how are you triggering the automation scripts?
Currently it is possible to execute an automation script from correlation rules or scheduled tasks. In addition, you can also define the DataMiner ID when triggering an automation script from a QAction.