Best Practices for Testing Object Event Handler Scripts

Before you add an object event handler, we recommend reviewing our best practices to ensure that you are aware of potential issues. These best practices can be helpful when creating and testing object event handler scripts.

• Have a complete test in mind. Consider all of the expected conditions and effects of the object event handler script and test for them in the test harness.
• Handle expected and possible errors with try/catch statements.
• Perform both of these tasks:
  • Select the Can Suppress check box on the process designer.
  • Include SuppressExternalEvents in a ->save in your script.
  Note: If neither of these tasks is performed, the script might re-enter itself in an infinite loop.
• Consider the test harness when integrating with external systems. For instance, the $run_mode parameter and the apply() method of your object event handler script can be tested to determine whether they are being run as part of a test or not. You must decide how to test against external integrations or systems.
• Objects passed after an edit contain only the data that was modified during the edit. For instance, if an incident thread is modified during an edit, only that thread is passed. Other data associated with the object (such as other incident threads) needs to be passed using a new instance of the object.
• Object event handler script headers include Package: and Objects: tags. The package tag defines the package where you place the script rather than the package where the objects are found. The objects tag defines which objects the event handler impacts. You must list the objects using their PHP names. For instance, if you have a custom object named Warranty found in the CO package, the object’s name in the tag will be CO/Warranty.
• Custom processes do not affect the behavior of PHP global variables. See Variable scope in the standard PHP documentation.
• When testing an object event handler script before deployment:
  • Any regular or error output displays in a dialog when the test is complete.
  • Any errors encountered prevent the State field from being marked Tested.
  • Any errors encountered within the test harness are not logged and are not counted against the runtime errors of a deployed script.
• When testing an object event handler script after deployment:
  • Any deployed object event handler script that encounters five errors (without any intervening success) will be disabled and the status of the State field will be changed to Errored. Otherwise, the script will become disabled on or after the fifth run if the error:success ratio becomes greater than or equal to 50%.
  • Error and success rates will stop recording when the error:success ratio falls below 10%.
  • All runtime errors are recorded to the Info log. See Log File Errors and Information.