Vlocity Build Tool: a local compilation for faster development

Vlocity Build Tool: a local compilation for faster development

There are many objects created in Salesforce Industries (Vlocity). Things like OmniScripts, DataRaptors, products or even FlexCards. These are usually created by an OmniStudio administrator and developer or by a CPQ Industries developer. Usually, administrators or developers work in a developer organization, a sandbox organization or even a scratch organization. However, the work they do needs to be transferred to different environments, such as a test environment and eventually a production environment, so that users can benefit from the creations we developers and administrators have made.

Context

To transfer the things we create as administrators and developers, we use tools to support this process. In the Salesforce world, for example, we use SFDX or the new SF CLI to transfer metadata.

Since the configuration for Salesforce Industries (Vlocity) is not only metadata but also includes data records in SObject tables, another tool is needed to manage it.

Within Salesforce Industries (Vlocity), we use two different tools to manage our configuration. The first is the Vlocity Build Tool (VBT), while for the second tool we use front end of the Industries Developer eXperience Workbench, also known as the IDX Workbench.

Now let's focus on the problem:

The OmniScripts and FlexCards are implemented in the organization as LWC components. These are generated by a screen automation tool called Puppeteer. As you can imagine, this takes a lot of time because the screen automation tool has to go one by one to generate and deploy the LWC components one by one.

Where this problem really becomes apparent is when you start using the new industries CPQ Cart (LWC). This cart consists of a lot of Flexcards, namely 141, and 18 OmniScripts. Using the VBT puppeteer deployment method to implement it takes more than an hour, which is a lengthy and risky process that requires many adjustments and iterations. Realistically, this process can take hours.

Why should I consider it?

Since developers and administrators use a lot of FlexCards and OmniScript. This even several times a day with CI/CD. Having a process that makes developers wait for hours is unacceptable.

So how do we deal with this?

This is where VBT Local Compilation comes in. It is a new development. Originally delivered in last year's spring release, it only recently became useful for larger projects. That's the reason I'm writing about it now.

This local compilation function brings the compilation to the developer's or administrator's desktop and generates the LWC components in advance. In this way, the LWC components are deployed with regular Metadata API deployment, saving a lot of time. The deployment of the LWC cart is now reduced from hours to only about 10 minutes, depending on the circumstances.

My experience

That sounds great! Is there a catch? No not really. So far my experience with the tool is that it can be somewhat picky when it comes to the repository being online (with the local compiler). Fortunately, it is usually available and so far we have had only one day of outages. However, it is important to note that the local compiler is not open source and code cannot be easily modified by clients. Unlike VBT, which was open source and allowed me to make regular code improvements, it is not possible to make changes or fixes with this tool.

Another challenge is that version control is not very clear. Not for every version of CME Vlocity Package there is a released version of the local compiler. There are also no published changelogs. So it is up to you to verify what has changed in the local compiler. A command that helped me do this is:

Where "900.472.10" is your current version and "900.481.0" is the new version.

This shows you the code changes made by the developers of the local compiler.

What resources would you recommend using to get started?

For starters, I would suggest reading this article:https://github.com/vlocityinc/vlocity_build#initial-support-for-omniscript-flexcards-local-compilation ("Initial support for local compilation of OmniScript / FlexCards")

Wrapping up

The future looks promising: Salesforce is incrementally adding more features to its native core. One of the first additions is the Standard OmniStudio, which runs native on the Salesforce Platform and uses standard metadata types. If you want to read more about this, let us know. We might write about this next time.

Theodore van Donge

Tech Lead

Theodoor van Donge works at CaseNine as a Tech lead. In this capacity he is responsible for several projects at customers. Theodoor not only deals with the actual development and implementation, but also advises customers in the areas of process and strategy.