Debugging with the debugprint() statement

You can also debug scripts with debugprint() statements in your code that can be enabled when debugging. You can populate your debugprint() statements with useful values for debugging your script. Much like a breakpoint in a regular IDE, these statements allow you to determine a value at certain point in time in your script. For example, you may have a work detail and want to know the value after you perform a certain calculation.

To debug an existing script with the debugprint() statement:

  1. Select Maintenance > System Administration > Scriptable Customizations > Extension Script.
  2. Select an existing custom script and click Load.
  3. Insert debugprint() statements at the points in your code where you want to test for values. These debugprint() statements will only generate debug output if you enable debugging (outlined below). For this reason, you can leave the statements in your code even if you are not debugging. See examples of the debugprint() statement in the code snippet below.
    
        void execute(final RCContext context) throws Exception {
    
    debugprint(“Test 1”) 
    
           RCParameters parameters = context.getParameters()
            String rateType = parameters.getParameter(PARAM_USE_RATE_TYPE)
            String rateMode = parameters.getParameter(PARAM_USE_RATE_MODE , "GREATEST")
            boolean isApplyHtypeToBaseRate =     Boolean.valueOf(parameters.getParameter
    (PARAM_APPLY_HTYPE_MULTIPLE_TO_EMP_BASE_RATE, "true")).booleanValue()
     
    debugprint(“Test 2”)
            if (!rateType.equals(RATE_TYPE_BASE)) {
                if (rateType.equals(RATE_TYPE_PIECE)) {
                    applyRateService.applyPieceRate(context, rateMode, isApplyHtypeToBaseRate)
    
  4. To save your changes, click Save.
  5. Select the Enable debugging checkbox. This will enable the debugprint() statements in your code for 1 hour, after which debugging will be disabled.
  6. Next, you can perform an action in WFM that will trigger your rules and conditions to fire. An example of this is found in Testing your custom script in WFM.
  7. After your custom rules and conditions are triggered, you will see an output of “Test 1” and “Test 2” (the debugprint() statements in the example above) in Maintenance > System Administration > Scriptable Customizations > Script Output Window.
  8. The Script Output Window displays a table with this information to help you debug your script:
    • Timestamp: Timestamp of when the script ran.
    • Extension Script: Name of the custom script.
    • User: User that initiated the request.
    • Application: Application that ran the script. Often this value is “Application Server” or “Job Scheduler”.
    • Thread ID: Thread ID of the script.
    • Request Source: Where the script ran.
    • Line Number: Line number of the output.
    • Debug Output: Output of the debugprint() statement.
  9. Based on your results, you may need to repeat this process if debugging was unsuccessful.