We now have quite a few automation scripts which are using the same element. We are having problems when updating the version of the element to remember which of all the automation scripts are using this element. We try to update the dummy version in all the automation scripts we can remember but inevitably we try to run an automation script and get the wrong dummy version error.
Almost all of our updates to the protocol would not affect the automation scripts, most versions of the protocol is backwards-compatible.
Is there a way to not have to enter the version that a dummy uses so that it always uses a specific element, no matter the protocol version of that element?
Or just list all automation scripts using a specific element/protocol as a dummy?
Or maybe be able to mark a version as compatible with other versions? So if an automation script uses version 1.1 and we update the element to 1.2 but mark it as backwards-compatible with 1.1 then the automation script don't throw an error?
Hi Robin,
You could use a script parameter instead of a script dummy.
The user would then manually have to enter the element name (no dropdown).
But you could use the script parameter value in an engine.findelement(elementname) call.
Note, that you'll have to check the protocol name of the element in your script to make sure the user didn't pass on an element using an incompatible protocol.
If you really want to have a dropdown, you could create an interactive automation script, although that will require some more effort. (check out this recent kata video).
Hi Robin,
Would it be an option for you to use the Production option?
This way when you update the connector version all elements get updated but the scripts keep pointing to the correct version.
Because as far as I am aware this is the only option
Unfortunately no, we have another element using the same protocol but on another version which has to have that version as production. It would be great if we could create our own “version tags” like production to be able to group a bunch of elements and upgrade them all at once and at the same time have the automation scripts follow.
In that case, I don’t think there is an automatic way of having multiple versions being compatible at the same time or of defining that it can be version 1 or higher.
At that point, your best approach is the semi-manual one of adapting the scripts one by one when needed.
Ideally, you would have your scripts as a solution with CICD that could detect such things and automatically adjust when needed but if not possible you could use a combination of a couple of SLNet calls GetInfoMessage(InfoType.Scripts) to retrieve all scripts on the system and then GetScriptInfoMessage to verify the details of the dummy being used.
This is probably closest to a solution and should do it, as we very rarely change the name of the elements.