There are two approaches when dealing with Maximo automation scripts input and output variables.
- Using launch point variables – This method is described in the product’s knowledge center and allows to get/set values from/to the database specifying how to bind the script variables to specific database fields.
- Using getter/setter methods – This approach uses Maximo MBO application layer (businessobjects) methods to get and set values. These methods are described in my Maximo Automation Scripts Quick Reference document.
Launch point variables are also called ‘bound variables’ here is how they look like.
I hate launch point variables!
That’s why.
- Code is less easy to read – It is almost impossible to fully understand the logic implemented in the script by simply reading the script code. This may be mitigated using some smart naming convention in the code but to me it will always be less intuitive.
- Less control over read/write variables – Launch point variables allows to define INOUT variables. This will make the script even less clear and reliable.
- Mixed style – At the end you will always be using mbo.getString method (or similar ones) in your code inside loops or to fetch data from related tables so this will end up with mixed use of bound and unbound variables which is really annoying.
- Less powerful – By learning to use Maximo Java APIs you will have more control and you can write more reliable code. Using bound variables creates unnecessary layer between you and Maximo just to avoid writing two or three lines of code.
Let’s see an example. In this IBM post a tutorial explains to set the Work Order’s description from the Service Request’s description when the Work Order is created from a Service Request. This example script is this:
owner = mbo.getOwner()
if owner is not None:
desc = owner.getString("description")What is ‘desc’ in this code? Is it bound to a database field? Which one?
Why not simply writing the script like this and avoid defining the bounded variable?
owner = mbo.getOwner()
if owner is not None:
mbo.setValue("description", owner.getString("description"))My suggestion is to never use bound variables and always use Mbo getter/setter methods to read and write data.
JavaDocs for Maximo Asset Management 7.6 can be downloaded here or can browsed here online.
All that you wrote can also by applied for automation scrips in a whole 🙂
I was adept of automation scripts, last project migration to 7.6.1 (hello java 8 whis nashhorn) was last nail in the coffin cover
One of the original benefits of using launchpoint variables was that the framework removes some of the work around handling rollback situations because the framework manages the updates to the MBOs and the MBOSet saves.
The Scripting with Maximo PDF file (page 21) says:
“Had we used the variables this would have still worked as the framework checks for the error flag right after the script execution end and before setting an OUT and INOUT variable values back to the Mbo’s.”
So if an error is thrown then the values on the MBO are not set and the developer does not need to explicitly write code to restore the old values.
When I looked at this a couple of years ago I believe it was possible for a script to use setValue on MBOs (and then save the mboset) and for those changes to persist even if an error is thrown.
I haven’t tried this again with the newer releases/fix packs but I suspect it is still possible.
If this is still the case then this can lead to data inconsistencies.
I agree with the concerns that launchpoint variables make scripts harder to understand/investigate.
Vetasi Support use a custom tool that retrieves both the script and the launchpoint details and makes it easy to see the full details and piece them together.
I tend to have a comment block at the top of my script that names the implicit and bound variables this script takes advantage of. This resolves the readability problem presented, for me.
I agree that *attribute* bound variables are bad, due to the memory and CPU performance costs of setting up and tearing down all the extra “var_implicitvar” variables, like “desc_required” in the quoted example, that will get set up and likely not used before being torn down. If the name of the attribute my script will work with may change, then I just pass the name of the attribute as a LITERAL ALN bound variable that the launch point uses to specify the name. This avoids 90% of the performance hit (or more) but still retains the flexibility for my script.
I need query to check work flow assignments for the user