Paikallinen WSDL voi silti lähettää SoapClientin verkkoon

Paikallinen service.wsdl voi silti saada SoapClientin hakemaan etädokumentteja rakennusvaiheessa. Ensimmäisen tiedoston paikallistaminen poistaa vain sen ensimmäisen latauksen:

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

Aloita ensimmäisestä epäonnistuneesta hausta ennen ensimmäistä SOAP-liiketoimintakutsua. Listaa jokainen WSDL-tuonti ja jokainen schema-sijainti, mukaan lukien dokumentit, joihin ne vuorostaan viittaavat. Säilytä perus-URL tai polku, jota käytetään kunkin suhteellisen viittauksen ratkaisemiseen. Erottele sisäiset isännät resursseista, jotka todella tarvitsevat ulkoisen proxyn.

Selkeä SoapClient-proxy voi lähettää sisäisen scheman välittäjän kautta, jolla on erilainen DNS-näkymä tai käyttöoikeuskäytäntö. Prosessitason no_proxy-muuttuja ei todista, että tämä latauspolku lukee sitä. Käytä PHP-versiollesi dokumentoituja asetuksia; asetuksen nimeäminen ympäristömuuttujan mukaan ei luo valitsinta tuontia kohden.

Jos määrittelyt otetaan käyttöön täysin paikallisesti, hanki koko riippuvuusjoukon hyväksytyt versiot, päivitä asianmukaiset tuontisijainnit paikalliseen niputukseen ja säilytä niiden suhteellisten polkujen perustat. Versioi nämä dokumentit yhdessä, jotta uusi juuri-WSDL ei käytä vanhentuneita tyyppejä.

Jätä nimiavaruuksien tunnisteet rauhaan. Ne voivat näyttää URL-osoitteilta, mutta ne yksilöivät schema-sanaston sen sijaan, että kertoisivat lataajalle, mistä tiedosto haetaan. Niiden korvaaminen voi muuttaa palvelusopimusta.

Testaa rakennus uudelleen välimuistin tila tallennettuna: välimuistiin tallennetut määrittelyt voivat piilottaa puuttuvan riippuvuuden yhdellä koneella. Palvelun URL-ohitus koskee myöhempää vaihetta ja mukautettu __doRequest() hoitaa SOAP-vaihdon; kummankaan ei pidä olettaa kirjoittavan uudelleen tai sieppaavan kaikkia schema-latauksia rakennusvaiheessa.