Vlocity Build Tool: een lokale compilatie voor snellere ontwikkeling

Vlocity Build Tool: een lokale compilatie voor snellere ontwikkeling

Er zijn veel objecten gecreëerd in Salesforce Industries (Vlocity). Zaken zoals OmniScripts, DataRaptors, producten of zelfs FlexCards. Deze worden meestal gemaakt door een OmniStudio-beheerder en -ontwikkelaar of door een CPQ Industries-ontwikkelaar. Meestal werken beheerders of ontwikkelaars in een ontwikkelaarsorganisatie, een sandbox-organisatie of zelfs een scratch-organisatie. Het werk dat zij verrichten moet echter worden overgezet naar verschillende omgevingen, zoals een testomgeving en uiteindelijk een productieomgeving, zodat gebruikers kunnen profiteren van de creaties die wij als ontwikkelaars en beheerders hebben gemaakt.

Context

Om de dingen die wij als beheerders en ontwikkelaars maken over te dragen, gebruiken we tools om dit proces te ondersteunen. In de Salesforce-wereld gebruiken we bijvoorbeeld SFDX of de nieuwe SF CLI om metadata over te dragen.

Aangezien de configuratie voor Salesforce Industries (Vlocity) niet alleen metadata is, maar ook datarecords in SObject-tabellen omvat, is er een andere tool nodig om deze te beheren.

Binnen Salesforce Industries (Vlocity) maken we gebruik van twee verschillende tools om onze configuratie te beheren. De eerste is de Vlocity Build Tool (VBT), terwijl we voor de tweede tool gebruikmaken van frontend van de Industries Developer eXperience Workbench, ook wel bekend als de IDX Workbench.

Laten we ons nu richten op het probleem:

De OmniScripts en FlexCards worden in de organisatie geïmplementeerd als LWC-componenten. Deze worden gegenereerd door een tool voor schermautomatisering genaamd Puppeteer. Zoals je je kunt voorstellen, kost dit veel tijd, omdat de tool voor schermautomatisering één voor één moet gaan om de LWC-componenten één voor één te genereren en in te zetten.

Waar dit probleem echt duidelijk wordt, is wanneer je begint met het gebruik van de nieuwe industrieën CPQ Cart (LWC). Deze kar bestaat uit een heleboel Flexcards, namelijk 141, en 18 OmniScripts. Het gebruik van de VBT-poppenspeler-inzetmethode om deze te implementeren duurt meer dan een uur, wat een langdurig en risicovol proces is dat veel aanpassingen en herhalingen vereist. Realistisch gezien kan dit proces uren duren.

Waarom zou ik het overwegen?

Aangezien ontwikkelaars en beheerders veel FlexCards en OmniScript gebruiken. Dit zelfs meerdere keren per dag met CI/CD. Een proces hebben waardoor ontwikkelaars urenlang moeten wachten, is onaanvaardbaar.

Dus hoe gaan we hiermee om?

Dit is waar VBT Local Compilation bijkomt kijken. Het is een nieuwe ontwikkeling. Oorspronkelijk werd dit geleverd in de voorjaarsrelease van vorig jaar, maar het werd pas onlangs bruikbaar voor grotere projecten. Dat is de reden waarom ik er nu over schrijf.

Deze lokale compilatiefunctie zorgt ervoor dat de compilatie naar de desktop van de ontwikkelaar of beheerder gebracht wordt en genereert de LWC-componenten van tevoren. Op deze manier worden de LWC-componenten ingezet met reguliere Metadata API-implementatie, wat veel tijd bespaart. Het inzetten van de LWC-kar is nu gereduceerd van uren tot slechts ongeveer 10 minuten, afhankelijk van de omstandigheden.

Mijn ervaring

Dat klinkt goed! Is er een addertje onder het gras? Nee niet echt. Tot nu toe is mijn ervaring met de tool dat deze enigszins kieskeurig kan zijn als het gaat om het online zijn van de repository (met de lokale compiler). Gelukkig is deze meestal beschikbaar en hebben we tot nu toe slechts één dag een storing gehad. Het is echter belangrijk om te weten dat de lokale compiler geen open source is en dat code niet gemakkelijk aangepast kan worden door klanten. In tegenstelling tot VBT, dat open source was en waarmee ik regelmatig codeverbeteringen kon aanbrengen, is het met deze tool niet mogelijk om wijzigingen of fixes aan te brengen.

Een andere uitdaging is dat het versiebeheer niet erg duidelijk is. Niet voor elke versie van CME Vlocity Package is er een vrijgegeven versie van de lokale compiler. Er zijn ook geen gepubliceerde changelogs. Het is dus aan jou om te verifiëren wat er is veranderd in de lokale compiler. Een opdracht die mij hierbij hielp is:

Waarbij “900.472.10” je huidige versie is en “900.481.0” de nieuwe versie.

Dit toont je de codewijzigingen die de ontwikkelaars van de lokale compiler hebben aangebracht.

Welke bronnen zou je aanraden om te gebruiken om aan de slag te gaan?

Om te beginnen zou ik willen voorstellen om dit artikel te lezen:https://github.com/vlocityinc/vlocity_build#initial-support-for-omniscript–flexcards-local-compilation (“Initiële ondersteuning voor lokale compilatie van OmniScript / FlexCards”)

Wrapping up

De toekomst ziet er veelbelovend uit: Salesforce voegt stap voor stap meer functies toe aan de native kern. Een van de eerste toevoegingen is de Standard OmniStudio, die native op het Salesforce Platform draait en standaard metadatatypes gebruikt. Als je hier meer over wilt lezen, laat het ons dan weten. Wellicht schrijven we hier de volgende keer over.

Theodoor van Donge

Tech Lead

Theodoor van Donge is bij CaseNine werkzaam als Tech lead. In deze hoedanigheid is verantwoordelijk voor diverse projecten bij klanten. Theodoor houdt zich niet alleen bezig met de daadwerkelijke ontwikkeling en implementatie, maar adviseert klanten ook op de gebieden van proces en strategie.