स्थानीय 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 डाउनलोड फिर से लिखने या रोकने वाला नहीं माना जाना चाहिए।