یک WSDL محلی هنوز می‌تواند SoapClient را به شبکه بفرستد

یک service.wsdl محلی هنوز می‌تواند باعث شود SoapClient در هنگام ساخت، اسناد دور را واکشی کند. محلی کردن فایل اول تنها همان دانلود اول را حذف می‌کند:

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

از نخستین واکشی ناموفق، پیش از نخستین فراخوانی تجاری SOAP شروع کنید. هر import در WSDL و هر schema location را فهرست کنید، از جمله اسنادی که خودشان به آن‌ها ارجاع می‌دهند. نشانی پایه یا مسیری را که برای حل هر ارجاع نسبی به کار می‌رود نگه دارید. میزبان‌های داخلی را از منابعی که واقعاً به پروکسی بیرونی نیاز دارند جدا کنید.

یک پروکسی SoapClient صریح می‌تواند schema داخلی را از طریق واسطه‌ای با دید DNS یا سیاست دسترسی متفاوت بفرستد. متغیر no_proxy در سطح فرایند ثابت نمی‌کند که این مسیر بارگذاری آن را می‌خواند. از گزینه‌های مستند برای نسخه PHP خود استفاده کنید؛ نام‌گذاری یک گزینه بر اساس متغیر محیطی، گزینشگر جداگانه برای هر import نمی‌سازد.

برای استقرار کاملاً محلی تعاریف، نسخه‌های تأییدشدهٔ کل مجموعه وابستگی را به دست آورید، مکان‌های import مربوط را به بستهٔ محلی به‌روز کنید و پایه‌های مسیر نسبی آن‌ها را حفظ کنید. این اسناد را با هم نسخه‌بندی کنید تا WSDL ریشهٔ جدید از انواع کهنه استفاده نکند.

شناسه‌های namespace را دست نزنید. ممکن است شبیه URL به نظر برسند، اما واژگان schema را مشخص می‌کنند نه اینکه به بارگذار بگویند فایل را از کجا بیاورد. جایگزین کردن آن‌ها می‌تواند قرارداد سرویس را تغییر دهد.

ساخت را با ثبت وضعیت حافظهٔ پنهان دوباره بیازمایید: تعاریف ذخیره‌شده می‌توانند وابستگی گمشده را روی یک ماشین پنهان کنند. بازنویسی نشانی سرویس در مرحلهٔ بعدی اعمال می‌شود و __doRequest() سفارشی تبادل SOAP را انجام می‌دهد؛ هیچ‌کدام را نباید به‌گونه‌ای فرض کرد که همهٔ دانلودهای schema در زمان ساخت را بازنویسی یا رهگیری می‌کند.