7 geheime migratievalkuilen van Product Console naar Product Designer

7 geheime migratievalkuilen van Product Console naar Product Designer

Salesforce Industries stopt met het gebruik van AngularJS dat langzaam maar zeker zal worden uitgefaseerd. Als gevolg hiervan migreren we van de oude Product Console naar de nieuwe glanzende Product Designer. Theodoor van Donge, lead software-engineer bij CaseNine, weet welke migratievalkuilen je kunt verwachten. En hoe je ze kunt vermijden. 

Meer weten over Salesforce Industries? Lees dan onze blog: ‘Wat is Salesforce Industries’?.

Om te beginnen kun je door de handleiding lezen https://docs.vlocity.com/en/Deploy-Industries-CPQ-in-LWC.html. Maar let op, er zijn handleidingen voor alle versies. We ontdekten dat er nog veel dingen zijn die niet in de handleiding staan ​​en die moeten worden opgelost. In dit artikel ga ik mijn ervaring delen en geef ik best practices voor een soepel Product Designer-proces.

Valkuil 1: problemen met VlocObjAttrsFields

In de Product Console hadden we de attributen toegewezen aan producten, maar niet individueel aan de lay-out. We hebben de attributen bekeken met behulp van de aangepaste weergave genaamd “VlocObjAttrsFields”.

Ik ontdekte dat aangepaste weergaven niet worden ondersteund in de Product Designer. Daarom moesten we alle attributen en velden handmatig toewijzen aan de design time layouts voor de Product Designer.

DESKUNDIG ADVIES:

Mijn advies is om niet de aangepaste weergave van VlocObjAttrsFields te gebruiken, maar direct toe te wijzen aan de design time layout.

Valkuil #2: Ontbrekende lay-outs

Tijdens de migratie kwamen we erachter dat we voor sommige van onze producten design time layouts misten. Waarschijnlijk zijn ze gemaakt, maar zijn we vergeten ze naar Git te pushen.

DESKUNDIG ADVIES:

Zorg ervoor dat je alle wijzigingen doorvoert in Git. Maar nu we zijn gemigreerd naar de product Designer, is het belangrijk om dit goed te doen. Dus hebben we de lay-outs handmatig gemaakt voor die producten die een lay-out misten.

Valkuil 3: attributen toegewezen aan producten, maar niet aan objecttypespecificaties

Ik maakte me hier al een beetje zorgen over, maar tijdens de voorbereiding van de migratie merkte ik dat we dit moesten oplossen. Aan nogal wat van onze producten waren attributen toegewezen die niet waren toegewezen aan de geïmplementeerde objecttype specificatie. We zijn waarschijnlijk vergeten die aan Git toe te voegen.

DESKUNDIG ADVIES:

Je kunt handmatig analyseren welke producten en attributen defect zijn, maar gelukkig hebben we een SFDX Plugin gemaakt om dit eenvoudig voor je te analyseren https://www.npmjs.com/package/@casenine/sfi-healthcheck.

Valkuil 4: verouderde min- en max-validatie van attributen van het type nummer

Tijdens de testfase kwamen we erachter dat sommige productpagina’s niet wilden laden. Na veel debuggen kwamen we erachter dat we een oude validatie methode gebruikten voor nummer- (& valuta-) attributen.

Na overleg met ondersteuning via casus en hulp van Carlos Alonso Rodriguez zijn we ervan bewust geworden dat deze functionaliteit vanaf 2017 is afgeschaft. We konden niet veel doen, het feit negerend dat de productontwerper niet voor deze producten werkte. Dit zal een probleem worden met de introductie van de nieuwe LWC Cart, die ook de min/max validatie niet ondersteunt.

DESKUNDIG ADVIES:

Dus we moesten dit natuurlijk oplossen. We hebben een paar oplossingen ontdekt:

• Contextregels gebruiken. We kwamen erachter dat dit niet zou werken omdat het geen validatie op regelitems ondersteunt
• Geavanceerde regels. Dit zou kunnen werken, maar we kwamen erachter dat er nog steeds een onopgelost idee is over de uitwisseling van ideeën waardoor dit wordt voorkomen:https://ideas.salesforce.com/s/idea/a0B8W00000J5aEoUAJ/min-max-validation-for-attributes
• Apex, met behulp van de ProductValidationInterface. Dit is wat we uiteindelijk deden, vrij rechttoe rechtaan, gemakkelijk te bouwen met enige kennis van Apex.

Als je de eenvoud van de oude min & max validatie ook leuk vond, steun ons dan en stem op dit idee op de IdeaExchange: https://ideas.salesforce.com/s/idea/a0B8W00000J5aEoUAJ/min-max-validation-for-attributes

Na het leegmaken van het veld ValidValuesData__c hebben we ons probleem opgelost en werden de productpagina’s opnieuw geladen.

Valkuil 5: Attributen toegewezen aan Producten en/of objecttypespecificaties maar niet aan de design time Product2 Objecttype

Dit was voorheen geen groot probleem, maar we hadden vreemde issues die we niet konden ophelderen. Maar met behulp van deze leuke SFDX-plug-in https://www.npmjs.com/package/@casenine/sfi-healthcheck kwamen we erachter dat we wat dataproblemen hadden. Sommige attributen zijn niet van toepassing gemaakt op het objecttype Product2. Na het oplossen van dit probleem zijn veel issues hiervan verholpen.

Valkuil #6: Attribuut categorieën niet geschikt voor producten

We hadden problemen waarbij we de attributen niet konden koppelen aan de productlay-outs in de ontwerptijd.

DESKUNDIG ADVIES:

We hebben de oorzaak van deze problemen gevonden doordat de velden vlocity_cmt__ApplicableTypes__c niet op de waarde Product2 stonden en hetzelfde voor vlocity_cmt__ApplicableSubType__c niet op de waarde Productkenmerk stond. Nadat we dit hadden opgelost, konden we de attributen toevoegen aan de design time layout.

Valkuil #7: Producten zonder Record type

Tijdens de migratie kwamen we erachter dat aan al onze producten geen recordtype was toegewezen.

DESKUNDIG ADVIES:

Nadat we de Product2-recordtypen beschikbaar hadden gemaakt voor de juiste profielen en machtigingensets, hebben we de producten gerepareerd, waarbij we het vlocity_cmt__Product-recordtype aan alle producten hebben toegewezen.

Theodoor’s conclusie

Hopelijk wil je na het lezen toch nog migreren naar de nieuwe Product Designer. Het kan veel werk zijn, maar de beloning is een nieuwe en gebruiksvriendelijke nieuwe Product Designer. In de huidige staat zal het de oude Product Console niet vervangen, maar voor 80% van je werk zou je goed moeten zijn met de Product Designer. Ik hoop dat dit artikel je zal helpen bij een succesvolle migratie naar de nieuwe Product Designer. Wil je meer weten over OmniStudio FlexCards? Lees dan onze blog: ‘FlexCards: The Easy Way To Create Lightning Web Components‘ voor meer informatie.

Nieuwsgierig geworden naar meer? Abonneer je vandaag nog op de Technical Deep Dive series. 

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.