Un service.wsdl local peut encore pousser SoapClient à récupérer des documents distants pendant la construction. Rendre le premier fichier local ne supprime que ce premier téléchargement :

local service.wsdl
  → internal Common.xsd
  → external Types.xsd
       → another schema location

Partez de la première récupération en échec, avant le premier appel métier SOAP. Listez chaque import WSDL et chaque emplacement de schéma, y compris les documents auxquels ils renvoient à leur tour. Conservez l'URL ou le chemin de base utilisé pour résoudre chaque référence relative. Séparez les hôtes internes des ressources qui ont réellement besoin du proxy externe.

Un proxy SoapClient explicite peut faire passer un schéma interne par un intermédiaire ayant une autre vue DNS ou une autre politique d'accès. Une variable no_proxy au niveau du processus ne prouve pas que ce chemin de chargement la lit. Utilisez les options documentées pour votre version de PHP ; nommer une option d'après une variable d'environnement ne crée pas de sélecteur par import.

Pour déployer entièrement en local les définitions, obtenez les versions approuvées de l'ensemble des dépendances, mettez à jour les emplacements d'import concernés vers le paquet local et conservez leurs bases de chemins relatifs. Versionnez ces documents ensemble afin qu'un nouveau WSDL racine n'utilise pas de types obsolètes.

Ne touchez pas aux identifiants d'espace de noms. Ils ressemblent à des URL, mais ils identifient le vocabulaire du schéma plutôt que d'indiquer au chargeur où récupérer un fichier. Les remplacer peut modifier le contrat de service.

Retestez la construction en notant l'état du cache : des définitions en cache peuvent masquer une dépendance manquante sur une machine. Une substitution de l'URL de service s'applique à une étape ultérieure, et un __doRequest() personnalisé gère l'échange SOAP ; ni l'un ni l'autre ne doit être supposé réécrire ou intercepter tous les téléchargements de schéma au moment de la construction.

Articles similaires