Compiling and debugging scripts

• To use compiled scripts, ensure that the common.properties file contains the this setting:

  script_execution_mode=compiled_only

• For individual scripts, disable script compilation by including the this directive at the beginning of the script:

  script_execution_mode=not_compiled

  However, this is not recommended as it leads to significant performance degradation. If you use non-compiled scripts, you can set this parameter to not_compiled rather than disabling compilation at the script level.

Using a combination of compiled and non-compiled scripts is not recommended because the performance is adversely impacted. However, if you must use this combination, then please be aware that while a non-compiled scripts can invoke functions in other compiled scripts, the reverse is not possible.

Common Script Compilation Errors

When using compiled scripts, a script can be saved in the script console only if it compiles correctly. If there is an error, check the svc.out file in the appsvr logs directory for the full Java™ compiler (javac) output and error messages. The following are some common compilation errors:

• A break or return statement inside a forEach*Element() block does not compile due to an "unreachable code" error. To fix this issue:

  forEachItemSetElement(itemSet, item)
  {
      return item;
  }
  
  Change it to:
  
  forEachItemSetElement(itemSet, item)
  {
  if (item != null) {
       return item;
    }
  }

  This is equivalent, but satisfies the compiler.
• If you return a value from a function, you must return a value in every case. This sample code will not compile.

  function sample() {
  var e = null;
  catchError (e) {
  // do something...
  return "a string";
  } if (e != null) {
  reportError(...);
  }
  }

  You must modify the function because it does not return a value if an exception occurs in the catchError block.

  function sample() {
  var e = null;
  catchError (e) {
  // do something...
  
  return "a string";
  }
  if (e != null) {
  reportError(...);
  }
  return null;
  }

• For major compilation issues, you can look at the generated .java files. These files are in a directory specified by the parameter tmp_dir in the common.properties file. The Java file naming convention has recently been changed to include the script name and a generated sequence. For example, MyScript12345.java.
• The full path of the script from the docstore is placed as a comment at the top of each generated .java file. If you map the docstore to the file system, you can run the grep command recursively to find which .java file matches a script.

Common Runtime Errors

• Invalid argument type: you might have passed the wrong type of argument to a function. For example, a HashMap instead of a String. This also happens if WPC cannot infer the type correctly; so you may need to use script operations like checkString() to be explicit.
• Mismatched argument types in comparisons: If you do not have the same data type on both sides of a conditional operator such as “==”, “>”, “<”, “<=” etc, then the expression will evaluate to false. This will not result in an error message but the corresponding code will not be executed. For example, the following will not work:

  var id = “12345” ;
  var my_id = item.getEntryAttrib
  	(path to some attribute that is a sequence) ;
  if ( id == my_id) {
  // statements that need to be executed but won't be
  }

  The solution in this case is to explicitly use:

  var id = “12345” ;
  var my_id = checkString(item.getEntryAttrib
  	(//some attribute that is a sequence),””) ;
  if ( id == my_id) {
  // statements to be executed
  }

• XML parsing: The following code works in non-compiled mode and even in compiled mode when run from the sandbox:

  new XmlDocument(xmlDoc) ;
  forEachXmlNode("item") {
  // do the needful
  }

  However, in compiled mode, if this code is used in a script library function that is invoked by multiple users, then the statements inside the forEachXmlNode block do not get executed. There is no error message. The workaround is:

  var doc = new new XmlDocument(xmlDoc) ;
  var xmlNode ; forEachXmlNode(doc, "item", xmlNode) {
  //do the needful
  }

Resolving runtime errors

To resolve runtime errors on the appserver, refer to the file svc.out in the appsvr log directory. Sometimes, examining exception.log and default.log may be helpful. With the new generated .java file naming convention, it is easy to identify which script failed. The error message also identifies the line number in the generated .java file. To resolve a problem, view the generated .java file and scroll to the line where the runtime error occurred. The generated Java code now includes actual script code as comments every few lines. For example, consider the following portion of code from a sample generated .java file:

// function checkIfPartyPartyTypeExist(party, partyType)
public static Object ScriptFunction__checkIfPartyPartyTypeExist
	(HashMap hmContext, Object party, Object
partyType) throws Exception
{
// var bRet = false;
Object bRet = (java.lang.Boolean) Boolean.FALSE; //
var rootEntry = party.getRootEntryNode();
Object rootEntry = GenGetRootEntryNodeOperation.execute(hmContext ,
	 (IEntry) party);
// var entryNodes = rootEntry.getEntryNodes(getCatalogSpecName() + 
	"/Party Types/Party Type Code");
Object entryNodes = GenGetEntryNodesOperation.execute(hmContext , 
	(EntryNode) rootEntry, (String)
BinaryOperation.execute(BinaryOperation.PLUS, 
	ScriptFunction__getCatalogSpecName(hmContext), "/Party
Types/Party Type Code"));
// var entryNodesSize = entryNodes.size();
Object entryNodesSize = (java.lang.Integer) 
	GenSizeOperation.execute(hmContext , (HashMap) entryNodes);