Connecting Vault with Fusion Lifecycle

Screen Shot 2018-06-27 at 12.48.55

The short answer is YES, and later in this post we described how we connect Vault with Fusion Lifecycle. For the longer answer, there are some topics we need to cover. We believe that CAD data shall be managed locally in Vault, while enterprise-wide engineering processes shall be managed in Fusion Lifecycle. Presumably we could spend hours talking about where Vault ends and where Fusion Lifecycle starts, but we probably agree that CAD files shall be managed locally.

Both systems provide a clean programming interface. Vault has a SOAP (webservices) API, while Fusion Lifecycle has a REST API. Both are HTTP based languages. Fusion Lifecycle can be customized via Java Script, while Vault with .Net. Both Java Script and .Net can deal with SOAP and REST. So, could the two systems be connected directly? Basically yes, but there are a some “but”.

The first hurdle, is to bring the two systems together. Vault is on the local network, behind the firewall, while Fusion Lifecycle sits in the cloud. The connection from the local network to the cloud is simple. The port 80 (443 for HTTPS) is usually open for the internet connection. If you can open the Fusion Lifecycle page with your web browser, it’s all good. For the way back, so from Fusion Lifecyle to Vault, the access to the Vault Server (or IIS) must be open. Usually a port mapping is needed on the firewall. This is technically simple but involves risks. The entire Vault API is available on the internet.

That Vault API is very powerful and comprehensive. Fusion Lifecycle would have to consume the complex Vault API and considers Vault’s business logic, even for simple operations. In addition, the Vault API gets improved/enhanced with each Vault version, and is therefore subject to changes. There is some compatibility, but still. The Fusion Lifecycle API is easier, but you still have to consider the business logic. Fusion Lifecycle currently has 3 APIs: V1 (official), V2 (deprecated), and V3 (technical preview).

In addition, many CAD offices have restricted or no Internet access. Keep in mind, that Fusion Lifecycle may talk directly to the Vault server (sort of server-to-server), while for connecting Vault workflows to Fusion Lifecycle, it’s the Vault client that must talk to Fusion Lifecycle (sort of client-to-server). So, each Vault client would need internet access to Fusion Lifecycle.

For these reasons, we take a different approach. We put powerGate server in the middle, between the two systems. powerGate can be extended with plugins. We already have a Vault plugin that exposes the Vault API as a simple REST API. This API is way simpler and Vault version independent.

New is a powerGate server Fusion Lifecycle Plugin, which makes it simple to talk to  Fusion Lifecycle. So, now we have two simplified APIs, version independent, which allows a bidirectional communication. The powerGate server sits on the local network, and thus reachable by all vault clients. So, Vault clients do not need internet access. The powerGate server can be installed on any server and the preferred port (not 80 or similar) will be exposed to the outside. Only the powerGate server is now reachable from outside. Now, both Vault and Fusion Lifecycle can talk to each other via the powerGate server, without knowing anything from each other.

The current powerGate server plugin for Fusion Lifecycle can query the workspaces, display all items (elements) of a given workspace, read details of a specific item and create new items. It is also possible to upload files and attach them to an item. The Fusion Lifecycle API can do more and we will enhance the plugin in the coming weeks and months, but as of now, it already can to a lot. Since it is powerGate, the REST services can be consumed from PowerShell and .Net. This allows creating very cool workflows in Vault Data Standard, powerEvents and powerJobs. For example, it is possible to check during a Vault release cycle, whether the according Fusion Lifecyle item is released too. Or submit a job that creates a PDF file and loads it as an attachment to the given Fusion Lifecycle item. Or a change process started in Fusion Lifecycle creates a matching Change Order in Vault and links the appropriate Vault files and items.

Here’s an example of how the workspaces can be queried in PowerShell

$workspaces = Get-ERPObjects -EntitySet "FlWorkspaces"
And here you can retrieve all elements to a workspace
$items = Get-ERPObjects -EntitySet "FlItems" -Filter "WorkspaceId eq 93"

And so you can get information of an element

$item = Get-ERPObject -EntitySet "FlItems" -Keys @{WorkspaceId=93;Id=7660} -Expand @('Properties','Relations','Attachments')

As you can see in this last example, the properties, the links, and the attachments are also retrieved. If you are familiar with the Fusion Lifecycle API, then you know that the attachments are a separate API call. But we do not want to deal with such complexity on the Vault Client side. We simply want the desired data. The powerGate Server Plugin should take care of handling this and other complexities.

In order to create a Fusion Lifecycle item, the mandatory and/or editable properties must be set. Here’s an example

$properties = @()
$properties += New-ERPObject -EntityType "FusionLifecycleItemProperty" -Properties @{Name='NUMBER';Value='01-000-0001'}
$properties += New-ERPObject -EntityType "FusionLifecycleItemProperty" -Properties @{Name='TITLE';Value='coolOrange powerGate test'}
$newItem = New-ERPObject -EntityType "FusionLifecycleItem" -Properties @{WorkspaceId=8;Properties=$properties}
Add-ERPObject -EntitySet "FlItems" -Properties $newItem

Files can be uploaded with this line

Add-ERPMedia -EntitySet "FlFile" -File C:\temp\test.pdf -Properties @{WorkspaceId=93;Id=7660;FileName="test.pdf";Description="test upload from powerGate"}

As you can see, the path to the local file, the ID of the workspace and the item to which the file is to be uploaded are specified. The complexity of making a matching HTTP call, using cookies, content-type, converting the file to appropriate bytes, etc. is handled by the powerGate server plugin.

A sample PowerShell Script, the powerGate plugin and the source code can be downloaded here from GitHub. We hope you enjoy this new powerGate extension. We will post more about Vault-Fusion Lifecycle in the future.

This entry was posted in Fusion Lifecycle, powerGate. Bookmark the permalink.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s