Les callouts Apex partent de Salesforce, pas de votre VPN

L'API privée répond dans votre navigateur dès que l'ordinateur portable rejoint le VPN, donc l'intégration devrait fonctionner. Elle ne fonctionne pas, car le code qui effectue l'appel s'exécute ailleurs, complètement. Apex s'exécute sur les serveurs d'application de Salesforce, et une activité côté serveur de Marketing Cloud s'exécute dans le runtime de ce produit. Ni l'un ni l'autre n'hérite du tunnel de votre ordinateur portable. Procédez comme une courte procédure : identifiez l'appelant, choisissez une entrée que cet appelant peut atteindre, câblez le chemin de bout en bout, puis vérifiez depuis le runtime lui-même.

Rédigez la fiche de l'appelant avant toute modification réseau

Remplissez cinq champs et refusez d'en deviner un seul. Le produit d'exécution et le contexte décident de tout le reste, alors commencez par là plutôt que par le pare-feu du serveur.

Un onglet de navigateur et un callout Apex sont deux clients différents, et un navigateur qui fonctionne prouve seulement qu'un chemin existe depuis votre bureau. Si le champ du runtime indique Apex, la question pertinente est de quelles adresses Salesforce sort, et non quelles adresses possède votre ordinateur portable. C'est pourquoi un tunnel qui fait charger l'API dans un navigateur peut laisser l'intégration échouer avec le même délai d'attente qu'avant. La fiche de l'appelant existe pour arrêter cette erreur avant que quiconque modifie un pare-feu.

Choisissez l'entrée que l'appelant peut réellement utiliser

Les deux conceptions sont légitimes et résolvent des problèmes différents. La première est une entrée publique délibérée : une passerelle d'API HTTPS ou un service d'intégration qui authentifie l'appelant, applique des autorisations étroites et maintient une connexion protégée vers le backend privé. Ce n'est pas la même chose que d'exposer chaque service du backend ou de rediriger un port d'administration vers internet.

La seconde est une connexion privée qualifiée. La documentation Private Connect sortante de Salesforce décrit le routage des callouts pris en charge via une Outbound Network Connection liée à un identifiant nommé, selon son agencement AWS PrivateLink défini. La fonctionnalité a des contraintes d'édition, de licence et de produit, alors confirmez que l'organisation y est éligible avant de concevoir autour d'elle.

Aucune des deux conceptions n'est un client OpenVPN installé dans Salesforce, et l'ancienne affirmation selon laquelle toute intégration doit atteindre un backend public est trop large partout où une connexion privée prise en charge convient. Choisissez celle que le runtime prend en charge, puis terminez le chemin vers la véritable API : un point de terminaison AWS ne connaît pas votre ressource sur site et n'hérite pas de la route de votre ordinateur portable. Le DNS, le routage du backend, la politique d'accès et le trafic de réponse doivent tous suivre l'architecture que vous avez choisie. Un chemin privé à moitié construit échoue d'une manière qui ressemble exactement à un problème d'authentification.

Câblez le chemin privé de bout en bout

Travaillez depuis l'API vers l'extérieur et arrêtez-vous au premier trou. Confirmez que le backend répond en local, puis que le point de terminaison privé l'atteint, puis que l'identifiant nommé et sa connexion sortante ciblent ce point de terminaison.

curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.40.8.20:8080/health
dig +short api.partner.example
sf apex run --file scripts/apex/callout-check.apex --target-org integration

La première commande prouve que le backend est sain depuis l'intérieur du réseau privé, la deuxième montre vers quoi le nom se résout, et la troisième exécute un callout depuis le runtime réel de Salesforce. Un 200 de la première et un échec de la troisième isolent le trou vers le chemin ou l'identifiant, et non vers le service.

Gardez la portée de l'identité précise pendant le câblage. Un identifiant nommé ne répare pas à lui seul un point de terminaison injoignable, car l'identifiant et la connexion privée sont des réglages liés avec des tâches distinctes. Une liste d'IP autorisées resserre l'admission réseau et n'est pas un identifiant d'API, alors conservez la validation TLS normale et le processus d'authentification et de rotation propre au service. Si un test ne réussit qu'après avoir désactivé la vérification du certificat, vous avez trouvé un problème de nom d'hôte et non de chemin, et le certificat doit encore correspondre.

Vérifiez depuis le runtime, puis consignez le retour arrière

Acceptez une requête autorisée et inoffensive depuis le runtime d'intégration, pas depuis votre machine. Consignez la source observée par le service destinataire, le principal authentifié, le résultat et une requête délibérément refusée qui doit échouer.

curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://api.partner.example/v1/ping
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer invalid' https://api.partner.example/v1/ping

Exécutez les deux mêmes sondes depuis le réseau du backend lui-même afin que la source observée puisse être comparée à ce que le runtime a produit. Un 200 suivi d'un 401 ou d'un 403 est la forme recherchée ; deux 200 signifient que le chemin de refus n'est pas réellement appliqué.

Rédigez le retour arrière avant d'en avoir besoin : quelle entrée de liste d'autorisation, quel identifiant nommé ou quelle connexion sortante vous avez modifiés, qui en est propriétaire et comment restaurer la valeur précédente. Puis bouclez en nommant l'appelant cloud et le chemin de service complet dans le ticket, afin que personne ne rouvre le même sujet comme un problème de VPN.