Mise à jour des références codées en dur

Questions fréquentes d'ordre général

1. Que sont les références codées en dur (spécifiques à l'instance) ?

a) Une référence codée en dur est une URL qui contient le nom de l'instance (par exemple, na1.salesforce.com). Remplacez ces références codées en dur par des URL non spécifiques à l'instance ou relatives (par exemple, login.salesforce.com ou <mondomaine>.my.salesforce.com).

Voici un exemple de référence codée en dur : https://na1.salesforce.com/{Case.Id}
Convertissez-la en référence relative en retirant 'na1.salesforce.com', comme suit : /{Case.Id}

REMARQUE : Dans Salesforce, les références relatives vous redirigent automatiquement vers l'enregistrement approprié. Les requêtes externes doivent être envoyées à un point de terminaison générique, tel que : https://login.salesforce.com, au lieu de https://na1.salesforce.com.
 

2. Comment puis-je rechercher les références codées en dur ?

a) Utilisez l'outil Salesforce de Vérification de la préparation à Lightning Experience pour découvrir les références codées en dur. Cet outil permet également de déterminer votre préparation à Lightning Experience :
Dans Lightning : accédez à Configuration | Lightning Experience | Vérifier la préparation
Dans Classic : accédez à Configuration | cliquez sur 'Commencer' sous 'Assistant de migration de Lightning Experience’ | Vérifier la préparation

Notez que les références codées en dur ne sont pas toutes découvertes par l'outil Lightning Experience Readiness Check. Pour en savoir plus sur les résultats renvoyés par cet outil, consultez la documentation Quels sont les éléments évalués par la vérification de la préparation à Lightning Experience ?

b) Recherchez les références codées en dur avec Salesforce Extensions for Visual Studio Code
Salesforce Extensions for Visual Studio Code est un outil de développeur qui permet de retrouver les références codées en dur. Suivez les étapes de l’article Creating a Salesforce Project in Visual Studio Code and Searching for Hard-Coded References pour mettre à jour les références codées en dur* dans votre organisation et les métadonnées de votre organisation (configuration ou code client).

3. Comment puis-je mettre à jour les références codées en dur dans des intégrations ?

Pour vos intégrations à des produits Salesforce ou à Force.com, utilisez la requête login() de l'API Force.com comme point de départ. La requête login() doit être envoyée à un point de terminaison générique, tel que : https://login.salesforce.com/services/Soap/u/26.0.
L'appel login() établit une session Force.com et répond avec l'URL du serveur de connexion. Définissez cette URL de serveur en tant que serveur cible pour les requêtes d'API ultérieures, puis définissez l'ID de session renvoyé dans l'en-tête SOAP afin de fournir l'autorisation du serveur pour les requêtes API ultérieures.

Questions fréquentes sur l'actualisation de l'instance et la migration d'organisation
Ces questions relatives aux références codées en dur vous concernent lorsque vous préparez une migration vers une nouvelle instance.

4. Quelles références codées en dur les serveurs Salesforce peuvent-ils rediriger après la migration vers une nouvelle instance ?

Les préférences codées en dur ne sont pas toutes redirigées après une actualisation d'instance ou une migration d'organisation. Par conséquent, nous recommandons vivement d'implémenter Mon domaine et de retirer toutes les références codées en dur avant une migration. La liste ci-dessous répertorie les éléments que les serveurs Salesforce peuvent rediriger. Vous risquez toutefois de remarquer un ralentissement des performances en utilisant ces objets après une migration vers une nouvelle instance : 

i. Liens de navigateur
ii. URL de favoris de navigateur
iii. Boutons personnalisés
iv. URL de contenu
v. Publications Chatter
vi. URL de connexion en libre-service (sserv/login.jsp?orgid)
vii. Intégrations

5. Quelles références codées en dur doivent être mises à jour (c.-à-d. qu’elles ne seront pas redirigées) avant la migration vers une nouvelle instance ?

Si vous n’avez pas activé Mon domaine, vous devez mettre à jour les références codées en dur dans les modèles d’e-mail et les articles Knowledge.
Que Mon domaine soit activé ou non, assurez-vous que toutes les images des articles Knowledge et des modèles d’e-mail ont été chargées depuis votre ordinateur, pas depuis une adresse Web, pour pouvoir les afficher après la maintenance.

i. Si vous avez des images insérées via une adresse Web, téléchargez-les sur votre ordinateur, puis rechargez-les en sélectionnant l’option « Charger une image » et insérez-les dans l’article Knowledge ou le modèle d’e-mail. Reportez-vous au diagramme ci-dessous correspondant au processus approprié.

REMARQUE : Si les images qui n’ont pas été chargées depuis votre ordinateur sont rompues après la maintenance, vous devez remplacer l’ancien nom d’instance dans l’URL de l’image par le nouveau nom d’instance. Téléchargez ensuite l’image sur votre ordinateur, puis rechargez-la depuis votre ordinateur afin d’éviter tout problème pour les futures maintenances.

6. Comment puis-je m’assurer que les images insérées dans mes articles Knowledge et mes modèles d’e-mail ont été chargées depuis mon ordinateur, pas depuis une adresse Web ?

Si une image a été chargée à partir d’un ordinateur local, son URL inclut « https://[HÔTE-OU-MON-DOMAINE]/servlet/rtaImage… ».

Si une image a été liée depuis une adresse Web (ou votre onglet Documents), son URL inclut « https://[HÔTE-OU-MON-DOMAINE]/servlet/servlet.ImageServer... » ou « https://[HÔTE-OU-MON-DOMAINE]/servlet/servlet.FileDownload… »

7. Dois-je mettre à jour les références codées en dur dans mes intégrations CTI si je migre vers une nouvelle instance ?

Si vous utilisez Open CTI et que l'URL de l'adaptateur CTI dans la définition de votre centre d'appels est codée en dur avec votre instance Salesforce (par exemple https://c.na6-visual.force.com/apex/Softphone ), votre intégration CTI sera impactée.
Changez cette référence codée en dur en URL relative (par exemple /apex/Softphone) afin de garantir le fonctionnement de votre intégration CTI après la migration vers une nouvelle instance. Pour la mettre à jour, accédez à l'objet Centre d'appels : Configuration > Centres d'appels.

Si vous utilisez l'outil d'intégration Salesforce Desktop CTI, cette maintenance n'aura aucun impact sur votre intégration CTI, car cet outil n'autorise pas les références codées en dur.

8. Dois-je mettre à jour les ID de mes flux d'e-mails si je migre vers une nouvelle instance ?

Si vous avez créé des ID de thread d'e-mail personnalisés, vous risquez d'être impacté(e) après une migration vers une nouvelle instance. Sinon, il n'est pas nécessaire de mettre à jour les ID de thread d'e-mail personnalisés générés par Salesforce après une migration vers une nouvelle instance (même si le nom de l'ancienne instance est toujours référencé).

Pour corriger les ID de thread d'e-mail personnalisés générés, procédez comme suit :
i. Mettez à jour votre formule personnalisée sous le format suivant : ref:_00D[XX][yyyyy]._500[AA][bbbbb]:ref
ii. yyyyy et bbbbb correspondent à l'ID d'enregistrement à 10 caractères sans les zéros d'en-tête.
iii. Les formats d'ID de flux d'e-mails qui peuvent être analysés par notre code système sont les suivants, (yyyyy et bbbbb correspondent à l'ID d'enregistrement sans les zéros d'en-tête).

REMARQUE : ref:00DXyyyyy.500Abbbbb:ref correspond à l'ancien format qui n'est plus utilisé.

Salesforce peut changer les formats au fil du temps. C'est pourquoi nous recommandons aux clients de ne pas générer leurs propres ID de thread. Si vous utilisez des ID de thread personnalisés, vous risquez de rencontrer un problème avec E-mail vers requête (E2C) à la demande, car de nouvelles requêtes sont créées et ne sont pas jointes à la requête d'origine avec les réponses. Ne créez pas vos propres formats d'ID de thread personnalisés. Nous ne prenons pas officiellement en charge les formules personnalisées pour les ID de thread de requête. Par conséquent, nous recommandons aux clients d'utiliser la formule d'ID de thread prête à l'emploi que Salesforce génère. Pour plus d'informations, lisez l'article Utilisation d'ID de thread personnalisés avec E-mail vers requête.

9. Les clients pourront-ils accéder à notre portail partenaire avec l'ancienne URL d'instance après la migration vers une nouvelle instance ?

Après la migration vers une nouvelle instance, les clients pourront accéder à votre portail partenaire pendant environ 30 jours en utilisant l'ancienne URL d'instance. Une fois les 30 jours passés, l'ancienne URL de connexion à l'instance sera déclassée. Avant de migrer vers une nouvelle instance, nous recommandons aux administrateurs d'ajouter une note personnalisée sous le message « Maintenance système », dans le portail partenaire de leur organisation, pour inviter les clients à utiliser la nouvelle URL du portail partenaire après la migration vers la nouvelle instance. Les administrateurs peuvent également recommander aux clients de mettre à jour leurs favoris de connexion avec la nouvelle URL du portail partenaire.

10. Les Web vers pistes/requêtes (W2X) seront-ils affectés après la migration vers une nouvelle instance ?

Si vous avez des références codées en dur dans vos W2X, vous devrez les mettre à jour vers des URL relatives avant de migrer vers une nouvelle instance. Si vous ne mettez pas à jour les références codées en dur, vous risquez de subir des interruptions de service W2X inattendues après la maintenance. Les W2X seront mis en file d'attente et traités après l'opération de maintenance.

11. Les noms de sites distants devront-ils être mis à jour après la migration vers une nouvelle instance ?

Oui. Si vous n'utilisez pas Mon domaine, les références codées en dur dans les noms de sites distants devront être mises à jour avec le nom de la nouvelle instance immédiatement après la maintenance.
Si vous ne mettez pas à jour les références codées en dur dans les noms de sites distants après la maintenance, vous risquez de subir des interruptions de service inattendues vers les sites distants.

12. La migration vers une nouvelle instance affectera-t-elle le kit de développement Salesforce Mobile SDK ?

La migration vers une nouvelle instance peut affecter les données des applications créées avec le kit Salesforce Mobile SDK si les utilisateurs n'ont pas les toutes dernières versions. Nous recommandons de mettre à jour toutes les applications créées avec le kit Salesforce Mobile SDK et de transmettre automatiquement ces mises à jour à tous les utilisateurs de votre organisation avant la maintenance.
Si les utilisateurs disposent des toutes dernières versions des applications créées avec le kit Salesforce Mobile SDK, la migration vers une nouvelle instance ne devrait pas affecter les données de ces applications.

​​13. Que dois je faire si j'ai une implémentation Live Agent ou SOS ?

Si votre page Web ou vos certificats contiennent des références codées en dur à l'URL du point de terminaison de Live Agent, une actualisation d'instance, une migration d'organisation ou un basculement de site risque d'impacter votre fonctionnalité Live Agent/SOS. Pour limiter l'impact, suivez les meilleures pratiques, évitez les références codées en dur au point de terminaison, et mettez à jour l'URL du point de terminaison dans le code de déploiement que vous avez copié depuis la page Déploiement dans la Configuration. Le code de déploiement que nous fournissons peut rediriger vers le nouveau serveur attribué. Vous devez cependant mettre immédiatement à jour le point de terminaison une fois l'actualisation terminée. 

Pour plus d'informations sur les points de terminaison de Live Agent et la signification d'un point de terminaison codé en dur, lisez l'article Live Agent server (endpoint URL) has changed and now Live Agent Chat is no longer working (en anglais).

14. Quelles sont les mesures à prendre pour les WSDL générés par les services Web Apex ?

Si vous utilisez des WSDL pour générer le code, vous devez vérifier les références codées en dur dans toutes les zones où vous avez employé le code. Toutes les références codées en dur doivent être mises à jour vers une URL Mon domaine ou une URL relative (login.salesforce.com). Nous recommandons d’implémenter Mon domaine avant de migrer vers une nouvelle instance. Ainsi, lorsque vous aurez corrigé toutes les références codées en dur pour quelles pointent vers la nouvelle URL Mon domaine, vous n’aurez plus à accomplir cette tâche.