Agile testing of Launchpoint scripts using a Testsection

Did you ever had the problem that it is sometimes really time consuming when you have to test a more complex script which is called by a script launchpoint? You mostly have to click through the ICD/Maximo GUI to simulate some behaviour so your script gets launched in context of a Mbo.

In this post I will show you a way how you can improve your script with a Testsection and after that you can run it from the Automation Script Application.

What is the base issue we have? Why is it so difficult to just run a script directly from the application editor? In most cases the answer is, that our script requires the context of a Mbo Object which is provided by the implicit variable mbo. So one of our first lines will be normally look like this:

itemMbo = mbo @UndefinedVariable

From this point on we can take the itemMbo to get/set values, to navigate to different MboSet’s and so on.

The easy solution to our issue is, that we need to simulate the mbo variable. If we run the script from the Automation Script Application no implicit variables are defined at all and so no mbo variable is available. We can test on this situation and then initialize the mbo variable our self by getting a specifc Mbo via the MxServer context. The following script will show this in context of the Item Mbo:

from psdi.server import MXServer

mxServer = MXServer.getMXServer()
userInfo = mxServer.getSystemUserInfo()

# Section to test script from Scripteditor
    mbo  # @UndefinedVariable
except NameError:
    mbo = None

if mbo is None:
    scriptHomeSet = mxServer.getMboSet("ITEM", userInfo)
    itemMbo = scriptHomeSet.getMbo(0)
    # This is the normal Entrypoint via a Launchpoint since 
    # implicit variable mbo is defined.
    itemMbo = mbo  # @UndefinedVariable

itemNum = itemMbo.getString("ITEMNUM")
itemDesc = itemMbo.getString("DESCRIPTION")

You just have to change the selection criteria in line 14 to select the correct item record. After that run the script from the Automation Script Application (see here for details).

You can integrate this technique in basically any script initiated by a launchpoint. Only remember, that no implicit variables can be used in the script!

One comment

  • Ravi Ramnarayan

    I am able to catch the exception and write the message to SystemOut.log with a print statement in the ‘except’ code block. I can see them when the script and logger are set to DEBUG. Is there a way to write to the SystemOut.log when the script & logger are at the default ERROR setting?

Leave a Reply

Your email address will not be published.