userEdited : exécution uniquement lorsqu’un champ n’a pas été modifié

Deux propriétés de champ sont accessibles dans Sur la configuration/reconfiguration de l’enrichissement : value et userEdited. Bien que la value propriété contienne les données contenues dans le champ et soit généralement ce à quoi on accède lors de l’écriture de scripts, userEdited elle contient une valeur booléenne qui stocke si le champ a été modifié par l’utilisateur final.

Cela peut être utilisé dans les instructions if pour écrire une valeur par défaut uniquement lorsque le champ n’a pas été modifié par l’utilisateur. Par exemple :

if (cfgRequest.[fieldVariableName].userEdited == false) {
      //code to run
}

Tous les champs auront la userEdited propriété définie sur faux lorsque la configuration est initialisée, mais lors de la reconfiguration, certains seront définis sur vrai en fonction des changements apportés par l’utilisateur. Si vous souhaitez qu’un comportement se produise uniquement lorsqu’un champ a été modifié ou non, écrivez le code à exécuter après l’une de ces vérifications.

Champ partenaire lineId

Sinon, si vous souhaitez effectuer une seule vérification dans le script d’enrichissement On Configurer/Reconfigurer et que vous bénéficiez de l’intégration Salesforce, le champ partenaire ne sera rempli qu’avec l’ID Salesforce de la ligne de devis du produit parent configurable lors de la lineId reconfiguration. Il n’est pas renseigné lorsqu’une configuration est initialisée.

En effet, lorsqu’une CPQ configuration est initialisée, cet ID n’existe pas encore, car la configuration n’a pas encore été enregistrée. Ce n’est qu’après la création d’une CPQ configuration et l’enregistrement de l’éditeur de ligne de devis que des lignes de devis sont créées dans Salesforce. Ainsi, lorsque nous voyons que le champ partenaire lineId est présent, nous pouvons être sûrs que la session en cours est due à une reconfiguration, et non à une nouvelle configuration.

Les auteurs de scripts peuvent tirer parti de cette distinction en vérifiant cette valeur pour tout code qui doit être exécuté uniquement lors de l’initialisation ou de la reconfiguration.

Voici comment le champ peut être référencé dans l’enrichissement On Configurer/Reconfigurer :

cfgRequest.partner.quote.lineId.value;

Si le comportement ne doit se produire que lorsque la configuration est initialisée, vous pouvez ajouter la vérification suivante :

if (cfgRequest.partner.quote.lineId.value == null) {
      //code to run
      return cfgRequest;
}

L’ajout de la ligne de retour cfgRequest ; dans la vérification garantit que tout code après la vérification de l’ID de ligne ne sera pas exécuté.

De même, si le comportement ne doit se produire que lorsque la configuration est reconfigurée, ajoutez la vérification inverse :

if (cfgRequest.partner.quote.lineId.value != null) {      
      //code to run
      return cfgRequest;
}

Pour plus d’informations sur les champs Partenaire, reportez-vous à .CPQ champs, champs système et champs partenaire

isInitial : création d’un champ de texte

Une autre façon de garantir qu’une distinction est présente (que Salesforce soit utilisé ou non comme point d’entrée dans le configurateur) est de créer un champ qui vérifie si la configuration actuelle est due à une initialisation ou à une reconfiguration.

Créez un champ de texte avec le nom de variable isInitial. Associez le champ à votre plan. Ensuite, dans Sur la configuration/reconfiguration de l’enrichissement, ajoutez les lignes suivantes :

if (cfgRequest.isInitial.value === "Yes" || cfgRequest.isInitial.value === "No") {
      cfgRequest.isInitial.set("value","No");
}
else
{
c fgRequest.isInitial.set("value","Yes");
}

Lors de l’initialisation, le champ isInitial est vide. Par conséquent, le script définit la valeur de isInitial sur Yes dans la clause else .

Lors de la première reconfiguration, isInitial sera Oui. Par conséquent, le script définira la valeur de isInitial sur Non dans la clause if .

À chaque reconfiguration ultérieure, isInitial sera Non et restera Non.

Cette méthode a l’avantage supplémentaire de ne pas avoir à enregistrer l’intégralité du QLE dans SFDC afin de faire la distinction entre une initialisation ou une reconfiguration. La méthode détecte immédiatement lorsque l’utilisateur entre une deuxième fois dans le configurateur.

Cette méthode inclut également la possibilité de référencer le nouveau champ en tant que condition dans les règles, par exemple en déclenchant une règle spécifiquement lors de l’initialisation ou de la reconfiguration. Il n’est pas nécessaire que le comportement existe uniquement dans le script On Configure/Reconfigure. Toutefois, pour que l’expérience de configuration reste similaire du point de vue de l’utilisateur final, vous devez vous garder de faire trop de différences de comportement entre l’initialisation et la reconfiguration.