I’m trying to execute a simple automation script (sending an email) from a QAction using protocol.ExecuteScript() or SLNet. Both seem to be failing. On my local machine both calls work as expected, but not on another DMA. If I manually execute the script or use a testing tool, it executes fine, using the exact same setup and variables.
My only guess is there are some permissions preventing the element to run the automation scripts. As I don’t really have any response information or logs (response from SLNet is null), what could be causing my script to not run? Thanks in advance for any information.
Hey Blake,
Permission issues usually are indicated by the server throwing a DataMinerSecurityException during the call. When the script is run from an element. This exception should end up in the Element log (assuming it is properly caught by the protocol). So you could check the element-logfile to make sure this is a permissions issue.
If so the permission you are looking for is the “Execute” Permission under the automation module.
Edit/update: Upon further investigation it turned out the issue here was caused by the automation engine not being licensed. This can be verified by “clicking on your user (top right)”->About->Licenses. And check if the Automation license is present. If it is not present you will be unable to run automationscripts from any source (manually, or from protocol).
Thanks for the reply Brent!
There are no errors in the element log, so perhaps permissions aren’t an issue. When I log protocol.UserInfo (or Cookie) the information is empty so I wasn’t sure what “user” is trying to run the QAction (and therefore the automation). Is that the default DataMiner admin user?
This depends if your QAction is triggered by a user (click of a button parameter for example) or not.
Blake,
A couple of questions, in the hopes of finding a lead for the answer.
1. Can you verify the Automation module is licensed on all the agents in the cluster?
2. How do you try to send the script using protocol.ExecuteScript(string name) or the protocol.ExecuteScript(ExecuteScriptMessage message)?
3. When you looked at the logging was the logging set to the highest loglevel, if not is there anything logged in the elementlogging, SLNet, SLAutomation with the higher logging.
4. Is this dma part of a cluster, if so is the target of the message (the one running the script), the same dma as the one hosting the element?
1. This might actually be the issue. Looking at the DMA (call it DMA2) that runs the element, I do not see the Automation module. Would that be why we don’t see any logging or failure?
2. I tried both ways and saw the same result.
The other two questions I believe are answered with the first point. Basically guessing that since the automation module isn’t on the DMA2, that means the script is not detected or runs. When I tried to look at the Automation logging on DMA2, it didn’t show anything.
I’ll communicate this to my squad and test on DMA1 today to see if that was indeed the case. Thanks!
That was it! Basically since the other DMA wasn’t licensed for automation it wasn’t working. I’ll mark this as best answer but if you want to provide a separate answer with more information, let me know and I can move the mark as best answer.
Thanks!
Hi Blake,
Did you verify already if you can find any logging in the SLAutomation.txt file indicating the script actually started (or not)?
Hi Joey, looks like you were onto the answer, to which you can find in the comments of the selected answer.
What version of dataminer is your local running? Also the other DMA?