It's All Just Ones and Zeros

DECO 2014

Update:  DECO 2015 is now available

Time to start updating my apps.  The first on the list is DECO (Design Editor for Custom Objects).  Not only is this a must-have when using custom objects, but it gave me a chance to play with the new grid control in the Vault SDK.  If you are unfamiliar with DECO, have a look at the page for the 2013 version.

I added one cool new feature for DECO 2014: a grid containing all the linked children.  You can now view/add/delete links using UI created with DECO.

Have a look at this short video...

---

Requirements:

• Vault Professional 2014
• XAML editor such as Visual Studio Express or Expression Blend

Click here for the application
Click here for the source code

---

Issues / Limitations:

• Custom Objects only.  No support for files, folders, items, and so on.
• The grid control only works with links to child entities.  There is no way to show “where used” data in a DECO control.
• Visual Studio 2010 has problems editing a XAML file with a WindowsFormsHost control.  I don’t know about Visual Studio 2012.
• The XAML files and Settings.xml need to be distributed to all clients in order for them to see the custom UI.  This issue will be addressed in the next release of Project Thunderdome.
• When adding a link, the browse dialog only lets you browse items available through Project Explorer.  In other words, only files, folders and linked entities.

As with all the samples on this site, the legal disclaimer applies.

Vault 2014 SDK - What’s New

The Vault 2014 SDK has some nice goodies for the development community.  Of course there are also changes that you need to make when upgrading your old code.  I’ll be going into each of these topics in more detail.  For now, here is a quick overview of what’s new.

---

The VDF

We came up with a set of tools so cool, we had to come up with a new acronym.  The Vault Development Framework (VDF) is a set of client-side libraries to support higher level operations and workflows.  It’s basically there so that you can do more with less code.

Here is a brief look at the architecture.

The VDF doesn’t provide complete feature coverage, so there are still many cases where you need to make web service calls.  If you are updating your code from a previous release, your web service calls can stay in place for the most part.

There are some VDF pages on the Vault Wiki.  I’ll be covering the same content on my blog in the upcoming weeks.

---

Filestore Server

The web services have shifted around to incorporate the concept of a filestore server.  For many years now, the top tier Vault products have allowed for the filestore and database to be on separate servers.  This is a good feature, but the API wasn’t reflecting the architecture.  All API calls used to go through the server with the filestore on it.  It’s not a very good approach since a second hop would be needed for database data.

In Vault 2014, the API has been re-designed so that database-related calls go straight to the database server and file-related calls go straight to the file store.  The WebService manager takes care of most of this for you, but there are some changes that will impact your code...

---

Uploading and Downloading

Uploading and Downloading requires both database and filestore data, so those operations can no longer be done in a single call.  The good news is that the VDF wraps the extra complexity.  I suggest you use Connection.FileManager.AcquireFiles for download and check out.  The FileManager also has AddFile and CheckinFile for the upload-related tasks.

---

API Compatibility

Vault 2014 continues with the web service API compatibility feature from the last release.  This time around, Vault supports 2 releases back, which means Vault 2012 and Vault 2013 clients will still be able to talk to a Vault 2014 server. 

Just like before, the compatibility feature only applies to the web service layer.  All other API features are version-specific.

Vault 2014 will be the last release that supports the 2012 web services.

---

.vcet.config Syntax

The XML syntax has changed for the .vcet.config files.  The new format is more flexible and allows for new extension types.  The easiest thing to do is copy-paste from the Getting Started section of the SDK documentation.  If you want to see the full spec, it’s in the Knowledgebase section of the SDK documentation.

---

Vault Explorer and Job Processor Extensions

The VaultContext class has been removed.  Instead your extension will be given a fully working Connection object.  Things are much cleaner this way since you don’t have to construct your own WebServiceManager.  It also fixes a couple of other issues, such as error 300.

The interface for Vault Explorer extensions has been renamed from IExtension to IExplorerExtension.

---

Persistent IDs

In the past, there was never a reliable way to reference a File from outside Vault.  File names can change, so that’s not good.  File ID and MasterId are database keys, so it’s not a good idea to use those.  In Vault 2014, we now support persistent IDs, which are guaranteed to never change.  The feature applies to Files, Folders, Items, Change Orders, and Custom Entities.

The relevant functions are GetPersistentIds and ResolvePersistentIds in the KnowledgeVaultService.

Logging in through the Vault 2014 API

Now the Vault 2014 is out, I thought I would just jump in and show off one of the new API features - the Login Dialog.  Next week I’ll take a step back and explain all the new stuff.  For now, just sit back and enjoy my new intro sequence...

The Package Service

The Package Service is harder to describe than the rest of the Vault web services.  It was designed with one thing in mind, but ended up doing something else.  As a result, there are some artifacts left around that make it confusing to work with.  The main use nowadays is to import and export BOM data between the Item service and a file.  But there is still some active legacy behavior that you might find useful.

---

File Import/Export:

The Package Service implements the Import and Export commands for Item BOM data.  You can find sample code in the ItemEditor example in the SDK.

The biggest confusion with import/export API is that the Package Service has its own BOM objects, which act as an intermediate between the Item Service BOM and the imported/exported file.  Another point of confusion is the fact that the words "import" and "export" don't show up in any of the API functions.  

For example, to export, you call PackageService.GetItemsAndBOMsFromItemIds() to convert the Item BOM to the Package BOM.  Next you call PackageService.DownloadPackage() to convert the Package BOM into a file.

Import works pretty much the same way but in reverse.  The major difference is that the Package BOM has can detect conflicts in the import.  For example, if you try to import revision A of an item but Vault has the same item at revision B, that's a conflict.  The Package BOM allows you to see, and sometimes fix, conflicts like these before the Item BOM gets updated.

---

Legacy Behavior:

The original intent of the Package service was to be an integration point between Vault and ERP Systems.  The original name for the service was the ERPService and you can still see ERP used in a few class names.  Out of the box, Vault supported compatibility to Microsoft Great Plains.  There was an Axapta integration too, but I think it required Autodesk Consulting.  Both integrations consisted of Vault importing/exporting data to a Microsoft Message Queue (MSMQ).

The intent was to support more integrations and maybe even have a pluggable interface.  But once the Job Server feature was developed, it became the main focus for integrations.  I wouldn’t go as far to say that the Package Service is gathering dust, but I don’t expect any other systems to be added to the Package Service.  You can basically import/export to an MSMQ or a file (which is labeled as “other” in the UI).  As far as I know, the MSMQ features still work, so you can use it as an alternative to Vault job queue.

Status Update

Vault 2014 is out but only the Basic version.  I’m waiting until Vault Professional 2014 is released before I dive into the technical details of the API.  Stay tuned... or whatever the 21st century equivalent is.

This upcoming year, I will try a new format for my videos.  Currently most of the content is contained is a 6-hour block of videos, which I realize is probably intimidating to some people.  The new format will favor more videos with a smaller size.  I’m hoping for around 10 minutes in length.  Each video will cover only one topic to make it more bite size.

I’m officially on the PLM 360 team.  In fact, I’ve been on the team since the new year.  But don’t worry, Vault API Expert isn't a title I will be parting with anytime soon. I’ll still be providing plenty of Vault content on this blog and in the development community.  You will also see a few others from the Vault team contributing to things like API support and discussion groups.

As to what I’m working on in PLM 360, I’ll leave it to your speculation.  As you probably know, I can’t talk about things that haven’t been released yet.