একটি স্থানীয় service.wsdl এখনও নির্মাণের সময় SoapClient-কে দূরবর্তী নথি আনতে বাধ্য করতে পারে। প্রথম ফাইলটি স্থানীয় করা কেবল সেই প্রথম ডাউনলোডটিই সরায়:

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

প্রথম SOAP ব্যবসায়িক কলের আগে, প্রথম ব্যর্থ আনয়ন থেকেই শুরু করুন। প্রতিটি WSDL import ও schema location তালিকাভুক্ত করুন, তারা যে নথিগুলোকে পরবর্তীতে উল্লেখ করে সেগুলোসহ। প্রতিটি আপেক্ষিক রেফারেন্স সমাধান করতে ব্যবহৃত ভিত্তি URL বা পথ রাখুন। অভ্যন্তরীণ host-গুলোকে সত্যিই বাইরের proxy প্রয়োজন এমন সম্পদ থেকে আলাদা করুন।

একটি স্পষ্ট SoapClient proxy ভিন্ন DNS দৃষ্টিভঙ্গি বা প্রবেশ নীতি থাকা মধ্যস্থকারীর মাধ্যমে অভ্যন্তরীণ schema পাঠাতে পারে। প্রক্রিয়া-স্তরের no_proxy চলক প্রমাণ করে না যে এই লোডিং পথ এটি পড়ে। আপনার PHP সংস্করণের জন্য নথিভুক্ত অপশন ব্যবহার করুন; পরিবেশ চলকের নামে অপশনের নাম দিলে প্রতি-import নির্বাচক তৈরি হয় না।

সংজ্ঞাগুলো সম্পূর্ণ স্থানীয়ভাবে স্থাপন করতে, সমগ্র নির্ভরতা সেটের অনুমোদিত সংস্করণ নিন, প্রযোজ্য import অবস্থানগুলো স্থানীয় bundle-এ হালনাগাদ করুন এবং তাদের আপেক্ষিক-পথ ভিত্তি সংরক্ষণ করুন। সেই নথিগুলো একসাথে সংস্করণ করুন যাতে নতুন মূল WSDL পুরনো type ব্যবহার না করে।

namespace শনাক্তকারীগুলো অপরিবর্তিত রাখুন। সেগুলো URL-এর মতো দেখালেও schema শব্দভাণ্ডার চিহ্নিত করে, লোডারকে ফাইল কোথা থেকে আনতে হবে তা বলে না। সেগুলো প্রতিস্থাপন করলে সেবা চুক্তি বদলে যেতে পারে।

cache অবস্থা রেকর্ড করে নির্মাণ পুনরায় পরীক্ষা করুন: cache করা সংজ্ঞা একটি মেশিনে অনুপস্থিত নির্ভরতা লুকাতে পারে। সেবা URL override পরের ধাপে প্রযোজ্য, এবং custom __doRequest() SOAP বিনিময় সামলায়; দুটির কোনোটিই নির্মাণকালে সব schema ডাউনলোড পুনর্লিখন বা বাধা দেয় বলে ধরে নেওয়া উচিত নয়।

সম্পর্কিত নিবন্ধ