સ્થાનિક WSDL હજી પણ SoapClient ને નેટવર્ક પર મોકલી શકે છે

સ્થાનિક service.wsdl હજી પણ SoapClient ને બાંધકામ દરમિયાન દૂરના દસ્તાવેજો મેળવવા મજબૂર કરી શકે છે. પ્રથમ ફાઇલ સ્થાનિક બનાવવાથી ફક્ત એ પ્રથમ ડાઉનલોડ દૂર થાય છે:

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

પ્રથમ SOAP વ્યાપારી કૉલ પહેલાં, પ્રથમ નિષ્ફળ પ્રાપ્તિથી શરૂ કરો. દરેક WSDL આયાત અને દરેક schema location ની યાદી બનાવો, જે દસ્તાવેજો તેઓ વળી સંદર્ભિત કરે છે તે સહિત. દરેક સાપેક્ષ સંદર્ભ ઉકેલવા માટે વપરાતું આધાર URL અથવા પથ રાખો. આંતરિક host ને ખરેખર બાહ્ય proxy ની જરૂર હોય તેવા સંસાધનોથી અલગ કરો.

સ્પષ્ટ SoapClient proxy આંતરિક schema ને અલગ DNS દૃશ્ય અથવા ઍક્સેસ નીતિ ધરાવતા મધ્યસ્થ દ્વારા મોકલી શકે છે. પ્રક્રિયા-સ્તરનું no_proxy ચલ સાબિત કરતું નથી કે આ લોડિંગ પથ તેને વાંચે છે. તમારા PHP સંસ્કરણ માટે દસ્તાવેજીકૃત વિકલ્પો વાપરો; પર્યાવરણ ચલના નામ પર વિકલ્પનું નામ રાખવાથી પ્રતિ-આયાત પસંદગીકાર બનતું નથી.

વ્યાખ્યાઓને સંપૂર્ણપણે સ્થાનિક રીતે તૈનાત કરવા, આખા નિર્ભરતા સમૂહનાં મંજૂર સંસ્કરણો મેળવો, લાગુ પડતાં આયાત સ્થાનોને સ્થાનિક બંડલમાં અપડેટ કરો અને તેમના સાપેક્ષ-પથ આધાર જાળવો. તે દસ્તાવેજોને સાથે સંસ્કરણ કરો જેથી નવું મૂળ WSDL જૂનાં પ્રકારો વાપરે નહીં.

namespace ઓળખકર્તાઓને અકબંધ રાખો. તે URL જેવા લાગી શકે, પણ તે schema શબ્દભંડોળ ઓળખે છે, લોડરને ફાઇલ ક્યાંથી લાવવી તે કહેવાને બદલે. તેમને બદલવાથી સેવા કરાર બદલાઈ શકે છે.

cache સ્થિતિ નોંધીને બાંધકામ ફરી ચકાસો: cache કરેલી વ્યાખ્યાઓ એક મશીન પર ખૂટતી નિર્ભરતા છુપાવી શકે છે. સેવા URL ઓવરરાઇડ પછીના તબક્કે લાગુ પડે છે, અને કસ્ટમ __doRequest() SOAP વિનિમય સંભાળે છે; બંનેમાંથી કોઈ પણ બાંધકામ સમયે બધા schema ડાઉનલોડ ફરીથી લખે અથવા અટકાવે એમ માનવું ન જોઈએ.