Vlocity Build Tool: Local Compilation for Faster Development

Introduction

In Salesforce Industries (Vlocity) you’ve created a lot of objects. Things like Omniscripts, DataRaptors, products or even FlexCards. These are usually created by an Omnistudio admin and developer or CPQ Industries Developer. The admin or developer will usually work in a developer org, an org of type sandbox or even scratch org. The work done by these people need to be transferred to different orgs like test org and later Production org so the users can enjoy the creations we developers and admins build.?

Context

To transfer the things we admins and developers create, we use tooling to support this process. In the Salesforce world we use tools like SFDX or the new SF CLI to transfer metadata.?

Because the configuration made for Salesforce Industries (Vlocity) isn’t metadata, but just data records in SObject tables. Therefor we need a different tool.

With Salesforce Industries (Vlocity) we employ the tool called Vlocity Build Tool (short: VBT) or we use the frontend of the same called Industries Developer eXperience Workbench (IDX workbench).

Now get to the problem:

The OmniScripts and FlexCards are deployed in the org as LWC Components. These are generated by a screen automation tool called Puppeteer. As you may imagine this takes a lot of time, as the screen automation tool needs to go one by one to generate and deploy the LWC Components one by one.?

Where this problem really clearly appears is when you start using the new industries CPQ Cart (LWC). This cart consists of a lot of Flexcards: 141 And? 18 Omniscripts. Using the VBT puppeteer deployment method, this takes over one hour! But this is a risky process and needs a lot of adjustments and retakes, so realistically this process takes hours.

Why should I give it a try?

Given developers and admins deploy FlexCards and Omniscript a lot, multiple times a day with CI/CD. Having a process that takes hours of waiting time for developers is not acceptable.

So how do we deal with this??

That’s where VBT Local Compilation comes in. This is a new development. Initially this was delivered in last year's Spring release but only recently became usable for bigger projects, so that’s why I’m writing about this now.?

This Local compilation feature takes the compilation to the developer or admins desktop and generates the LWC components ahead of time. This way the LWC Components are deployed with regular Metadata API Deployment which saves a lot of time. The LWC cart example is now gone from hours deployment to if you are lucky 10 minutes more or less.?

My Experience

That’s huge! Is there a catch? No, not really. The only thing I've experienced so far is that it is a bit finicky when the repository (containing the local compiler) is online or not. But usually this is available so far. We’ve only experienced an outage for one day so far. Another good thing to know is that the local compiler is not open source and code cannot be easily viewed as a customer. Providing improvements or fixes is impossible with this change compared to VBT which was in the open and I could regularly provide improvements to the code.?

The other challenge is that the versioning is not very clear. Not for every version of CME Vlocity Package there is a released version of the local compiler. Also there are no published changelogs, so it’s on your own to verify what changed in the local compiler. A command that helped me with this is:?

npm diff \
--diff=@vlocity-cme/[email protected] \
--diff=@vlocity-cme/[email protected]        

Where “900.472.10” is your current version and “900.481.0” the new version.

This will show you the code changes that the developers of the local compiler made.?

What sources would you suggest to use to get started?

To get started i would suggest to read the article online: https://github.com/vlocityinc/vlocity_build#initial-support-for-omniscript--flexcards-local-compilation (“Initial Support for OmniScript / FlexCards Local Compilation“)

Wrapping up

The future is bright: Salesforce is slowly adding more features to the native core, the first published is Standard OmniStudio, and has a runtime which runs natively on the Salesforce Platform and also uses standard Metadata types. If you want to read more about that, let us know, we might write about that next.

As a Salesforce engineer, don't miss CaseNine's now famous Technical DeepDive Series. In each episode, one of our engineers covers a deep technical topic.?Subscribe today. That way you won't miss a single CaseNine Technical DeepDive episode.