Automation with Helix IPLM

Helix IPLM has three main built in interfaces for initiating automated flows. The Events System is the primary method, it provides access to every event performed by every user on every object in the platform. Notifications or Automation can be triggered on each of these events.

Server Side hooks allow customization and enforcement of Business Logic. Client Side hooks can be used to automate flows around workspace actions.

Events system

The Helix IPLM events system is capable of triggering automation and communications based on all of the user access, modification, and metadata changes that occur on the platform. Once something happens in Helix IPLM an event is published, and event consumers can be configured to listen to these events and take action based on the occurrence.

Typical Event consumer functions include:

Sending emails to user when IP releases occur that they have subscribed to
Publishing Slack notifications based on project milestones
Aggregating audit logs of user access
Creating dashboard data for Splunk
Initiating Jenkins jobs to run simulation and verification on new releases

Users are able to subscribe to the events that are associated with specific Libraries, IPs or other objects of interest.

Because Events give access to all the actions that are performed in Helix IPLM, they are a one of the main methods of initiating automation.

Server Side hooks

Server Side hooks can be run prior to allowing certain data to be modified on the Helix IPLM server. They can be applied to various commands and enforce customer business logic on how objects are modified and to enforce standardized formatting in object fields.

The following tables lists some of the example flow options that can be enforced:

Operation	Example Flow Enforcements
Adding IPs	Enforce field values and naming when an IP is added to Helix IPLM Add information to descriptions and other fields
Editing IPs	Enforce field values and permitted changes to existing fields Add information to version messages
Copying IPs	Enforce allowed copying of IPVs to new IPs or Lines Enforce permitted naming of new lines and IPs Add metadata describing copy operation
Locking/Unlocking Aliases	Set permissions of users to be able to lock/unlock aliases Protect certain aliases from being unlocked

Client Side hooks

Client side hook scripts can be configured on an IP or IP Library (which apply to all IPs in the Library) to perform actions at different points in the lifecycle of the IP.

Pre-Release hook

The Pre-Release hook is triggered on an IP release, and is run before the release is actually created in Helix IPLM. Typically this is used to run a 'smoke' test to validate the quality of the contents of the IP (does it compile, pass lint, etc). If the hook passes the test, the release is then created.

Post-Release hook

The Post-Release hook is triggered on an IP release, and is run after the release is created. The newly created release information can be passed in to the hook script as variables, and can be used by the hook script to initiation continuous integration flows, build new workspaces, run verification and simulations, or any other checking that needs to be done on the release. Once these activities are complete information gathered by the script can be formatted into Helix IPLM widgets and automatically added to the new release, or data can be stored in the appropriate properties attached to the IPV.

In this way metadata capture can be automated, which results in a consistent set of data across the various releases of an IP, without burdening users with additional (and too often ignored) manual data gathering requirements.

An example output from a post-release hook script is shown in the following code block. The release is created and the requirements information is retrieved from an external requirements management system (in this case JAMA) and is used to inform parameters in the simulation. A simulation is initiated, and once complete the results of the simulation are captured and applied as Widgets (formatted attributes) to the new release object (IPV) in Helix IPLM. Aliases are applied to the release based on the quality levels achieved in the simulation, and labels are applied. Finally a Jenkins job is initiated to create documentation from the metadata and release information in the newly released Helix IPLM IP Hierarchy, once finished the automatically generated document will be linked to from the IPV's page. The Jenkins job also runs DRC and LVS automatically on the new release, and links the results to the IPV page.

Post-release hook Script