Mahalliy WSDL ham SoapClient'ni tarmoqqa chiqarishi mumkin

Mahalliy service.wsdl hali ham SoapClient qurish paytida masofaviy hujjatlarni olib kelishiga sabab bo'lishi mumkin. Birinchi faylni mahalliy qilish faqat o'sha birinchi yuklab olishni olib tashlaydi:

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

Birinchi SOAP biznes chaqiruvidan oldin, birinchi muvaffaqiyatsiz olishdan boshlang. Har bir WSDL importini va har bir schema location'ni, ular o'z navbatida havola qiladigan hujjatlar bilan birga ro'yxatga oling. Har bir nisbiy havolani hal qilish uchun ishlatiladigan asosiy URL yoki yo'lni saqlang. Ichki hostlarni haqiqatan tashqi proxy kerak bo'lgan resurslardan ajrating.

Aniq SoapClient proxy ichki schema'ni boshqa DNS ko'rinishi yoki kirish siyosatiga ega vositachi orqali yuborishi mumkin. Jarayon darajasidagi no_proxy o'zgaruvchisi bu yuklash yo'li uni o'qishini isbotlamaydi. PHP versiyangiz uchun hujjatlashtirilgan parametrlardan foydalaning; parametrni muhit o'zgaruvchisi nomi bilan atash har bir import uchun tanlagich yaratmaydi.

Ta'riflarni to'liq mahalliy joylashtirish uchun butun bog'liqlik to'plamining tasdiqlangan versiyalarini oling, tegishli import joylarini mahalliy paketga yangilang va ularning nisbiy yo'l asoslarini saqlang. Yangi ildiz WSDL eskirgan turlardan foydalanmasligi uchun o'sha hujjatlarni birga versiyalang.

Namespace identifikatorlariga tegmang. Ular URL kabi ko'rinishi mumkin, lekin yuklovchiga faylni qayerdan olishni aytish o'rniga schema lug'atini belgilaydi. Ularni almashtirish xizmat shartnomasini o'zgartirishi mumkin.

Kesh holatini qayd etib, qurishni qayta sinab ko'ring: keshlangan ta'riflar bitta mashinada yetishmayotgan bog'liqlikni yashirishi mumkin. Xizmat URL'ini qayta belgilash keyingi bosqichga tegishli, va maxsus __doRequest() SOAP almashinuvini boshqaradi; ikkalasidan ham qurish vaqtidagi barcha schema yuklab olishlarini qayta yozadi yoki ushlab qoladi deb o'ylamaslik kerak.