WSDL ya ndani bado inaweza kumtuma SoapClient kwenye mtandao

service.wsdl ya ndani bado inaweza kusababisha SoapClient kuleta hati za mbali wakati wa ujenzi. Kufanya faili ya kwanza kuwa ya ndani huondoa tu upakuaji huo wa kwanza:

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

Anza na upataji wa kwanza ulioshindikana, kabla ya wito wa kwanza wa biashara wa SOAP. Orodhesha kila uingizaji wa WSDL na kila schema location, ikiwa ni pamoja na hati ambazo nazo zinarejelea. Hifadhi URL ya msingi au njia inayotumika kutatua kila rejeleo la jamaa. Tenganisha host za ndani na rasilimali ambazo kwa kweli zinahitaji proxy ya nje.

proxy ya SoapClient iliyo wazi inaweza kutuma schema ya ndani kupitia mpatanishi mwenye mtazamo tofauti wa DNS au sera tofauti ya ufikiaji. Kigezo no_proxy cha kiwango cha mchakato hakithibitishi kwamba njia hii ya upakiaji kinakisoma. Tumia chaguo zilizoandikwa kwa toleo lako la PHP; kuitaja chaguo kwa jina la kigezo cha mazingira hakuundi kichaguzi kwa kila uingizaji.

Ili kupeleka ufafanuzi kikamilifu ndani, pata matoleo yaliyoidhinishwa ya seti yote ya utegemezi, sasisha maeneo husika ya uingizaji kwenye kifurushi cha ndani na hifadhi misingi yao ya njia jamaa. Toa matoleo ya hati hizo pamoja ili WSDL mpya ya mzizi isitumie aina zilizopitwa na wakati.

Usiguse vitambulisho vya namespace. Vinaweza kuonekana kama URL, lakini vinatambua msamiati wa schema badala ya kumwambia kipakiaji wapi apate faili. Kuvibadilisha kunaweza kubadilisha mkataba wa huduma.

Jaribu tena ujenzi ukiwa na hali ya akiba iliyorekodiwa: ufafanuzi uliohifadhiwa unaweza kuficha utegemezi unaokosekana kwenye mashine moja. Ubadilishaji wa URL ya huduma unatumika katika hatua ya baadaye, na __doRequest() maalum hushughulikia mabadilishano ya SOAP; hakuna kati yao kinachopaswa kudhaniwa kuandika upya au kunasa upakuaji wote wa schema wakati wa ujenzi.