Extending PTC Integrity Lifecycle Manager with Custom Code: A Best Practices Guide Author: Scott Milton Revision: 1.1 Change History Date Author Version Description 2014-07-21 Smilton 0.1 Draft for review 2014-08-21 Smilton 1.0 General Release 2015-02-28 Smilton 1.1 Pre/Post Event, computed field recommendations 2 | P a g e Table of Contents Change History ---------------------------------------------------------------------------------------------------------- 2 Table of Contents ------------------------------------------------------------------------------------------------------- 3 1. Introduction -------------------------------------------------------------------------------------------------------- 4 2. Trigger Scripts, Server-Side ------------------------------------------------------------------------------------- 5 2.1. Trigger Attributes ------------------------------------------------------------------------------------------ 5 2.2. Trigger Design ---------------------------------------------------------------------------------------------- 5 2.3. Performance ------------------------------------------------------------------------------------------------ 8 2.4. Logging ------------------------------------------------------------------------------------------------------- 8 2.5. Trigger-Type Specific Best Practices------------------------------------------------------------------- 9 2.5.1. Configuration Management Triggers ----------------------------------------------------- 9 2.5.2. Workflows & Documents Triggers, Rule Based ---------------------------------------- 9 2.5.3. Workflows & Documents Triggers, Scheduled --------------------------------------- 10 2.5.4. Workflows & Documents Triggers, Other --------------------------------------------- 11 3. Trigger Scripts, Client-Side ------------------------------------------------------------------------------------ 11 4. Custom Action Buttons ---------------------------------------------------------------------------------------- 12 5. Application Programming Interface (API), JAVA/ANSI C --------------------------------------------- 13 5.1. Command Certification--------------------------------------------------------------------------------- 13 5.2. Connectivity ----------------------------------------------------------------------------------------------- 13 5.3. Performance ---------------------------------------------------------------------------------------------- 14 5.4. Simple Java Example ------------------------------------------------------------------------------------ 15 6. Automated Test Execution Framework (ATEF) ---------------------------------------------------------- 16 7. Web Services ----------------------------------------------------------------------------------------------------- 16 8. Command Line Interface (CLI) ------------------------------------------------------------------------------- 17 9. Report Recipes --------------------------------------------------------------------------------------------------- 19 10. Computed Fields ------------------------------------------------------------------------------------------------- 20 11. For more information ------------------------------------------------------------------------------------------ 20 3 | P a g e 1. Introduction PTC Integrity Lifecycle Manager provides a wealth of configuration options. However, due to the complexity of the development ecosystem and demands from the user base, there will inevitably be a desire for extending the core functionality with custom code. There can be a number of reasons for extending Lifecycle Manager including, but not limited to: Integration to other Applications Custom business logic Automation Improved Interface Efficiency, e.g., role or solution specific Interfaces Due to the ratio of end users to administrators, a large amount of administrative development time should often be exchanged for a relatively modest saving in time for end users. In other words, an investment many hours of administrative time to save a few minutes of end user time is often still a viable exchange. This is because there will be many more end users performing the operation more frequently, so 500 end users each saving a few minutes a day may quickly add up to exceed the amount of time spent by the administrator in developing the time saving functionality. However, you should also consider the amount of time to maintain and upgrade any custom code, as well as any performance impacts it may have on the Lifecycle Manager server or other users. Note: A brief update on naming. The product formerly known as “PTC Integrity” is now named “PTC Integrity Lifecycle Manager”, since PTC Integrity now refers to a family of software and systems engineering products. For brevity and clarity, this guide uses “Lifecycle Manager” as an abbreviation for the full name, “PTC Integrity Lifecycle Manager”. This guide is meant to provide tips and best practices for the various coding interfaces provided by Lifecycle Manager. It cannot cover each topic exhaustively, so references to other guides are noted as applicable. It will also focus specifically on Lifecycle Manager functionality and will not repeat commonly understood best practices for the programming language you intend to use; you should familiarize yourself with those best practices and standards beforehand and consider this guide to be supplementary material. The functional areas discussed in this guide include: Trigger Scripts Custom Action Buttons Application Programming Interface (API) Automated Test Execution Framework (ATEF) Web Services Report Recipes Command Line Interface (CLI) 4 | P a g e 2. Trigger Scripts, Server-Side Generally speaking, trigger scripts are relatively small code files hosted on the Lifecycle Manager server, written in JavaScript but using various Java Objects. They automatically execute when a particular event happens on the Lifecycle Manager server, a particular operation is triggered from an end user, or on a schedule. For more details: Location Details Lifecycle Manager server Homepage, “Event Object Reference Guide Trigger Java Documentation” Link Server Administration Guide General Trigger Details Training Course PTC offers a full training course, including exercises on this topic. 2.1. Trigger Attributes Names and descriptions should follow a standard that is suitable for a given implementation or solution. The standard naming aids visual recognition and allows multiple administrators to more efficiently identify what items triggers will operate on. For instance, prefixing every trigger with the item type names it can operate on. This also helps administrators visually detect which sets of triggers may go together, and how to reorder them is necessary. If there are multiple solutions configured on the same Lifecycle Manager server, an acronym representing the solution would also be recommended. Finally, another suitable naming convention might include the functional aspect of the trigger, for example, Automation/Assignment, Enforcement/Data Validation, and E-mail Notifications. Regardless of the naming convention you may choose, the relative position of triggers is important. The relative position displayed in the Administrative client is also the order in which the triggers execute, should their rule evaluate to true. It is entirely possible for an early run trigger to change the item data such that later triggers will not execute. For instance, a trigger that modifies the item state may result in the item “jumping over” one or more triggers that are later in the execution order. Generally speaking, you should have Automation/Assignment triggers executing first, followed by Enforcement/Data Validation and finally E-mail Notifications. 2.2. Trigger Design An event will generally consist of the following sequence: Begin Transaction PRE-Event Triggers Commit-Transaction POST-Event Triggers 5 | P a g e Keeping in mind this sequence, event triggers can broadly be broken down into three categories, Pre-Commit, Post-Commit and Scheduled. Pre-Commit event triggers are included in the same transaction as the triggering event. As the operation has not yet been committed to the database when the script executes, it allows a trigger author to both validate and modify data, as well as vetoing the event and rolling back the transaction, if desired. Since the changes have not been committed to the database when pre-event triggers are executing, this category of triggers are not suitable for external notifications (emails, generation of reports or charts, calling out to other servers of any type), as the transaction could still be aborted and rolled back by an error or another trigger script. Post-Commit event triggers run only after the transaction has been successfully completed, making them appropriate for logging, notifications, backing up data, etc. Data cannot be changed during a post-event trigger, as the transaction has already completed. Scheduled triggers are available in the Workflows and Documents area of Lifecycle Manager only. This category of trigger scripts will execute at a scheduled frequency and will start their own transaction when editing items, giving the trigger script author control over when to commit any changes to the database. In general, it is better to have many small, “single purpose” trigger scripts, rather than a single monolithic script, assuming those small scripts can be reused elsewhere in the solution. Do not hardcode static argument values within your