Loka WSDL ankoraŭ povas sendi SoapClient al la reto

Spuru transirajn WSDL- kaj XML-Schema-importojn kiam loka servo-difino ankoraŭ miksas internajn kaj eksterajn prokursejojn.

Loka service.wsdl ankoraŭ povas igi SoapClient preni malproksimajn dokumentojn dum konstruado. Igi la unuan dosieron loka forigas nur tiun unuan elŝuton:

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

Komencu ĉe la unua malsukcesa preno, antaŭ la unua komerca SOAP-voko. Listigu ĉiun WSDL-importon kaj schema-lokon, inkluzive de la dokumentoj al kiuj ili siavice referencas. Konservu la bazan URL-on aŭ vojon uzatan por solvi ĉiun relativan referencon. Apartigu internajn hostojn de rimedoj kiuj vere bezonas la eksteran prokurilon.

Klara SoapClient-prokurilo povas sendi internan skemon tra peranto kun alia DNS-vido aŭ alirpolitiko. Proceza variablo no_proxy ne pruvas, ke ĉi tiu ŝarĝa vojo legas ĝin. Uzu la opciojn dokumentitajn por via PHP-versio; nomi opcion laŭ media variablo ne kreas selektilon por ĉiu importo.

Por surmeti difinojn tute loke, akiru la aprobitajn versiojn de la tuta dependaĵaro, ĝisdatigu la koncernajn importlokojn al la loka pakaĵo kaj konservu iliajn relativajn vojbazojn. Versiu tiujn dokumentojn kune, por ke nova radika WSDL ne uzu kadukajn tipojn.

Lasu nomspacajn identigilojn netuŝitaj. Ili povas aspekti kiel URL-oj, sed ili identigas la skeman vortaron anstataŭ diri al la ŝargilo de kie preni dosieron. Anstataŭigi ilin povas ŝanĝi la servokontrakton.

Retestu konstruadon kun la kaŝmemora stato registrita: kaŝitaj difinoj povas kaŝi mankantan dependecon sur unu maŝino. Anstataŭigo de serva URL aplikiĝas en posta etapo, kaj propra __doRequest() traktas la SOAP-interŝanĝon; oni ne supozu, ke iu ajn el ili reverkas aŭ interkaptas ĉiujn skemajn elŝutojn dum konstruado.

Rilataj artikoloj