Scripting tips

You can use the IBM® Product Master workbench to write your scripts to ensure accuracy of the script syntax.

Read the following scripting tips and best practices:
  • Understanding error messages, for example, the following script:
    var i;
    while ( i < 10)
    {
      out.writeln(i + ": hello world");
      i++;
    }
    This script provides the following error:
    Exception:Script execution failed (java.lang.NullPointerException) 
    Exception:java.lang.NullPointerException at WPCScriptSandboxPath12077873685880.run(WPCScriptSandboxPath12077873685880.java:28)
    This error means that a variable was not defined before it was used, and all variables need to be defined before they are used. The correct script is:
    var i = 0;
    while ( i < 10)
    {
      out.writeln(i + ": hello world");
      i++;
    }
  • Use the startTransaction function, which creates a unit of work if none is current, and runs the contained operations within the current unit of work.
  • Control the changes to scripts by using a configuration repository tool such as Rational® ClearCase®, CVS, or Perforce.
  • If you must search for elements inside the array, use a Hashmap instead of an array.
  • Use the forEachHmElement() operation when looping through a Hashmap.
  • Use the getCategoryCache() operation to get all categories.
  • Use the correct character encoding set when you load a data file.
  • Avoid using sendEmail() to debug the code.
  • Use selections for extracting selective product information.
  • Test for null periodically whenever you use a get method for an object. For example, getSpecByName(). Ensure that the object returned is not NULL before you do anything with it. The following example illustrates the usage:
    var spcSpec = getSpecByName("My Spec");
    if(spec == null)
    {
       out.writeln("My Spec does not exist");
    }
    else
    {
       // do your processing on the spec here
    }
    
  • Use checkString() and checkInt() to test all input.
  • Use the MVC design paradigm when you build applications with trigger scripts.
  • Use EntryNode::throwValidationError() in pre-processing and post-processing scripts to mark errors on individual attributes.
  • Use script libraries in pre-processing and post-processing scripts (or the validation framework) to do validations.
  • When you write a script that dumps output to more than one writer. For example, onto the screen and to a file, use a Boolean variable to control where the output is directed.
  • Do not use reports as a way to load data because the reports lock the items until the report is completed. You can use imports to load data.
  • Do not use reports to export data if the exports manipulate and save items (such as setting status flags on the items). Always use exports.
  • Clean up older versions to reduce the size of the database and to improve performance. When you use imports and exports, a new version of the catalog is created after each import or export.
  • Clean the docstore regularly. An excessively populated docstore (document store with many documents, regardless of the document size) results in poor import performance.
  • When you debug in the log4j2.xml file, check the ipm.log for additional information on unexpected transactional commits and rollbacks. This information might be of use if transactional disruption is suspected as a cause.
  • Implicit variables, for example,
    • in This is the default reader for an import. It refers to the data source, which was chosen during the creation of the import.
    • catalog The destination catalog object that was chosen during the import creation.
  • Use of script libraries like the validation framework to reduce the amount of custom logic within your import. This enables reuse of import components by other scripts.
  • Use the useTransaction script function on the import or report. This commits all of the statements within the useTransaction brackets to the database in one single transaction. This is useful if you need to back out a series of changes if something fails.
    • There can be only one useTransaction in a script. Script calls to functions from another scripts can cause problems if nested useTransaction blocks are created. The transaction rolls back to the state before the use first transaction block.
    • For example, your item model is divided into three catalogs of attributes and you want to cancel all updates if one catalog entry fails. You would place the three catalog updates within a useTransaction block.