Happy new Year!!! We start the new year with a gift to you. A new product: powerEvents. The short story is that now all the Vault client events, such as lifecycle change, check-in, check-out, etc. can be easily consumed via a PowerShell script.

Why should you care? Let’s suppose you like to fill or empty some properties automatically on a lifecycle transition. Or want to set some properties, maybe taken from the parent folder, when a file is checked in. Or you may want to queue a job for just a specific type of file or category on lifecycle transition. Or you want to prevent a lifecycle transition when a combination of property values does not match. Or save item and BOM information into a file every time the item changes. Or perform some custom actions when a folder gets created. Or…. I think you get it.

The Vault client provides events for a lot of actions, such as check-in, -out, lifecycle change, etc. So far, in order to get advantage of such events, you’ve had to write .Net code with Visual Studio. With powerEvents, you can now just put some simple logic in a PowerShell script file and powerEvents will do the rest.

powerEvents is a Vault client extension, so the setup needs to be installed on each Vault client. After the installation, you’ll have under c:\ProgramData\coolOrange\powerEvents the PowerShell scripts. We already exposed all available events in the scripts, and grouped the events by object type. So, for instance, you have a file.ps1 which contains all the events related to files. If you have logic that might be useful across several actions, then you can place it into the common.psm1 file.

By default, powerEvents listen to all the events. In the script files you can see all the available events and start doing some tests. For each event, you have 3 functions, a GetRestriction, Pre and Post. The GetRestriction is the first function called, and allows you to prevent the execution of an event. Let’s say you don’t want to allow lifecycle transitions, then you can go into the file.ps1, scroll down to the GetFileStateChangeRestriction function, and set there a restriction, like this:

function GetFileStateChangeRestriction($FromFiles, $ToFiles, $Restrictions)
    $Restrictions.AddRestriction("my object","my custom restriction")

In this case, every attempt to perform any lifecycle transition with any file will be blocked and you’ll get the usual Vault dialog telling you which object (file, item, etc.) is affected by which restriction.

In case there are no restrictions, then the Pre function is executed. In case of the file lifecycle state change, the function is the PreFileStateChange. Here, you can perform actions before the lifecycle transition is performed. At this point you cannot stop the event any more, but you can do something with the object or other Vault objects.

At the end the Post function is called, in our case the PostFileStateChange. At this stage, the event is completed, and you can do something with the according object afterword. To be more specific, if you like to clean up some properties when you move from Release back to Work In Progress, then you have to apply you code in the Post function, as during the Pre, the file is still released and cannot be changed. If you like to set some properties on releasing a file, then you’ll have to do it during the Pre, while the file is still Work In Progress, and not during the Post, as at this stage the file is already released and blocked by the permissions.

Within these functions you have access to the Vault API via the usual $Vault variable, and you can make us of powerVault, which simplifies dealing with Vault. You can access to the complete Vault, so for instance, while you react on a file event, you can access to the folder or items, and do something, like creating a link, adding, modifying, etc. With a bit more work, you can also interact with the user via some dialogs and the like.

By leveraging powerGate, you can also interact with your ERP system. As an example, you could check during lifecycle change, whether the part number is filled and an according item exists in the ERP and is in the correct state. If not, you can interrupt the lifecycle and inform the user, that the expected pre-requisites are not given.

While you are playing with powerEvents, you can put in the so called DebugMode. This is a setting in the C:\ProgramData\Autodesk\Vault 2017\Extensions\powerEvents\powerEvents.dll.config file. If the DebugMode is set to True, then each change made in the PowerShell scripts has immediate effect. You don’t need to restart Vault. This allows you to test and tune the code, without constantly restarting Vault. Once you are done with testing and ready for production, set the DebugMode back to False. This has some significant performance improvements, as the scripts will not be read every time and the PowerShell runspace will also be reused, and not restarted with every event.

Also, every line of code has his cost. Therefore, you can decide which events you like to use and which not. Those that are not relevant to you, should be either commented or removed. At the next start of Vault, powerEvents will just register the events present in the script. By default, all the events are active, so you will have to manually comment or remove the unnecessary events.

powerEvents is now available as a Beta version and can be downloaded from here: http://www.coolorange.com/en/beta.php

Being a Beta version, it comes with no need for license, and with a limited life time that expires on August 1st. If you like the product and need pricing information, reach out to sales@coolorange.com.

We have powerEvents already in action at some customers and collected great feedback. However, before we officially launch this product in April with the other 2018 products, we like to get some more feedback from you. So, anything that comes up to your mind, feel free to send an email to support@coolorange.com with your questions, comments, suggestions.

We already love powerEvents, and so do the customers and resellers that supported us in the development of this tool. We are sure you will love it too and find many ways to improve your Vault workflows via powerEvents.

This entry was posted in powerEvents. Bookmark the permalink.

2 Responses to powerEvents

  1. Tobias Haase says:

    Are there any issue known with newer Vault 2017 Service Packs?

    Got a error when i checkin files from Inventor:
    Die Datei oder Assembly “Autodesk.Connectivity.Explorer.ExtensibilityTools, Version=, Culture=neutral, PublicKeyToken=aa20f34aedd220e1” oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

    Vault 2017.0.2
    Inventor 2017.3.1

    • Marco Mirandola says:

      hi Tobias, yes, there is a known issue when consuming events from within Inventor. There is a workaround, which is manually copying the file Autodesk.Connectivity.Explorer.ExtensibilityTools.dll (found in the Vault client folder) into the powerEvents extension folder. Autodesk suggest not to deliver such files with the extensions, therefore we do not deliver that file, however, in this case, this should solve the problem. We will “soon” release the official version, which will obviously have a more appropriate fix. However, I hope this helps for now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s