Scripting artifacts

Script and Launch point creation are done using wizards that are available from the List tab in the Automation Script application. You can launch the Automation Script application from the GoTo → System Configuration → Autoscript menu. In the List tab drop down actions list, you can see the following wizards:

These wizards will guide you through the process of creating a script and optionally associating launch points with it. Launch points are discussed in detail in a later section.

After the script and launch point has been created, you can use the Automation Script application for maintenance. Maintenance can be done using the Main, Variables, Launch point tabs in the Automation Script application. You can add or update the variables and their bindings as well as the bindings at the launch point level, if they are overridable. You cannot delete variables unless none of the launch points refer to that variable.

Scripts use variables to interact with Maximo. Variables are either IN, INOUT, or OUT. These variables follow the classical definition where IN is the pass-by-value, and INOUT and OUT are passed by reference. The script can modify only the INOUT and OUT variables. Modifying IN variables in the script has no impact outside the script. Variables can be bound to a Maximo artifact including a mbo attribute, a maxvar, and a maximo system property or can be bound to a literal value which is not related to any Maximo artifact. Variables bound to a maxvar or a system property are always IN variables as the script cannot modify them. Variable data type for mbo attributes is driven by the mbo attribute datatype. For example, a variable bound to Purchase Order MBOs totalcost attribute will inherit its type. Variables bound to maxvar and system properties are always String variables. You can define the data type of variables bound to literal values by specifying “literaldatatype” attribute in the autoscriptvars table. The supported literal data types are ALN, INTEGER, SMALLINT, DECIMAL, YORN, DATETIME, and FLOAT. You can define variable bindings at the script level or the launch point level if the definition at the script level allows override of that value at the launch point level.
Another important aspect of the OUT and INOUT variables is how their values can be set back to the MBOs. You can set MBO attributes with the NOACTION flag, which determines if modifying the value of the MBO attribute will call the field validations action routine. You can also set MBO attributes with the NOVALIDATION flag, which determines if modifying the value of the MBO attribute will call the field validations validate routine. You can use MBO atributes to set the NOACCESSCHECK flags, which determine if the Action/Validation routine of the MBO attributes are called. You can set an MBO attribute with any combination of these flags. You can enable these settings from the script or launch point creation wizards and Automation Script application.

The following table explains their usage:

Another important feature of scripting is implicit and explicit variables. Explicit variables are explicitly defined and bound in the variables page. Implicit variables are not explicitly defined in the variables page and are provided to you behind the scenes by the framework. Implicit variables follow the convention over configuration pattern where the framework will intelligently inject variables at run time which might otherwise have needed JAVA coding to fetch and set. Some implicit are injected based on how the explicit variables are defined and some are injected irrespectively. The following table lists and describes implicit variables.

Some implicit variables are injected into the script based on the explicitly defined variables. The following table describes the implicit variables that are based on explicitly defined variables whose binding type is an MBO attribute. There are no implicit variables for explicitly defined variables of other binding types like Literals, Maxvars, and System properties. The assumption is that “var” is the explicitly defined variable that binds to an MBO attribute.

Launch points are application customization points. Launch points define which application artifact the user wants to customize by attaching the script to that point. In effect, the script is executed in the context of a launch point. For example, if you want to customize the Asset MBO’s initialization routine, use the key words Asset MBO & initialization routine. Another example is if you want to customize the Asset MBO’s purchaseprice attribute field validation routine. The key words that define the launch point are - Asset MBO, purchaseprice attribute, and field validation routine. Essentially, a launch point is a configuration to identify the application point to customize. A script can be associated with one or more launch points simultaneously. For example, a generic site-level validation script can be associated with all site level objects where each association is defined as an individual launch point. A script can be associated with a single launch point. For example, a script associated with the Object launch point cannot be associated again with another attribute launch point. After the first association is Completed between a script and a launch point – all subsequent launch points have to be the same type as the first.

The following launch points are currently supported by the scripting framework:

Note: Launch points and callbacks are the first artifacts to consider when customizing an application.

Scripts can be activated or deactivated from the Launch Point tab of the Automation Scripting application or from the Script main page. The deactivation from the main script will deactivate the script for all launch points of that script. Deactivating from launch point only deactivates that particular launch point. All other active launch points should continue working as usual.

Maximo will not invoke a deactivated script. For example, if an Attribute launch point is deactivated, the script for that launch point will not be invoked if the value of that MBO attribute changes. Activating and deactivating scripts is a very useful tool for debugging issues with the application behavior and can take the script out of the equation temporarily to test the application without customization. The autoscript status attribute value has no significance on how the scripting framework will or will not invoke the script.