পেশাদার পদ্ধতি

Google Ad Manager API-এর জন্য অ্যাপ্লিকেশন ডেভেলপ করার সময় যেসব পেশাদার পদ্ধতি বিবেচনা করা উচিত, এই পৃষ্ঠায় সেগুলি সম্পর্কে আলোচনা করা হয়েছে।

এক্সিকিউশন চলাকালীন সার্ভিস ক্লায়েন্ট/স্টাব আবার ব্যবহার করুন

নতুন পরিষেবা ক্লায়েন্ট/স্টাব তৈরি করার জন্য WSDL ফেচ করা এবং রিসোর্স বরাদ্দ করার সাথে সম্পর্কিত সামান্য খরচ হয়। সম্ভব হলে, এক্সিকিউশন শুরু হওয়ার সময় একবার সার্ভিস ক্লায়েন্ট/স্টাব তৈরি করুন এবং প্রয়োজন অনুযায়ী ক্লাস ও ফাংশনের জন্য এটি উপলভ্য করুন।

অবজেক্ট আনার সময় পেজিং ব্যবহার করুন

সব পরিষেবা get*ByStatement() পদ্ধতি সমর্থন করে, যা PQL সিনট্যাক্স ব্যবহার করে ফলাফল ফিল্টার করার অনুমতি দেয়। LIMIT এবং OFFSET ক্লজ ব্যবহার করে ফলাফলের বড় সেটকে বিভিন্ন পৃষ্ঠায় ভাগ করা যায়, যার ফলে টাইম আউট হয় না এবং রেসপন্স পৃষ্ঠার সাইজও ঠিকঠাক থাকে। আপনার অবজেক্টের জটিলতার উপর নির্ভর করে, সাজেস্ট করা পৃষ্ঠার সাইজ হল ২০০-৫০০।

ব্যাচ আপডেট সংক্রান্ত অনুরোধ

একই ধরনের একাধিক অবজেক্ট পরিবর্তন করার সময়, একই update*() অনুরোধে সব অবজেক্ট পাঠিয়ে আপনি আরও ভালো পারফর্ম্যান্স পেতে পারেন। প্রতিটি অনুরোধের জন্য ক্লায়েন্ট এবং সার্ভারে একটি প্রান্তিক ওভারহেড রয়েছে এবং ব্যাচিং অনুরোধের সংখ্যা কমানোর একটি কার্যকর উপায় হতে পারে। যেমন, প্রতিটি কলে একটি করে অর্ডার আপডেট করার পরিবর্তে updateOrders ব্যবহার করে অর্ডার-এর ব্যাচ আপডেট করুন।

PQL-এ বাইন্ড প্যারামিটার ব্যবহার করুন

বাইন্ড প্যারামিটার হল PQL কোয়েরি স্টেটমেন্টে ভেরিয়েবল যোগ করার একটি উপায়। PQL কোলন দিয়ে শুরু হওয়া স্পেস ছাড়া নাম দিয়ে বাইন্ড ভেরিয়েবলকে বোঝায়, যেমন, :name। PQL সিনট্যাক্স পৃষ্ঠায় কোডের উদাহরণ দেওয়া আছে।

আমরা বাইন্ড ভেরিয়েবল ব্যবহার করার সাজেশন দিই কারণ এটি কোয়েরি স্টেটমেন্টে স্ট্রিং ও ভেরিয়েবল কনক্যাটিনেট করার প্রয়োজনীয়তা দূর করে কোড পড়ার সুবিধা উন্নত করে। এছাড়াও, এগুলি PQL স্টেটমেন্ট আবার ব্যবহার করা সহজ করে তোলে, কারণ বাইন্ড প্যারামিটারের ভ্যালু পরিবর্তন করে নতুন কোয়েরি তৈরি করা যায়।

ব্যবহারকারীকে বিশেষ সুবিধা দেওয়ার ক্ষেত্রে সতর্ক থাকুন

ব্যবহারকারীর ভূমিকা তৈরি/আপডেট করতে UserService ব্যবহার করার সময়, ব্যবহারকারীদের এমন কোনও বিশেষ অধিকার দেবেন না যা তাদের প্রয়োজন নেই। ব্যবহারকারীকে অ্যাডমিনিস্ট্রেটর ভূমিকা অ্যাসাইন করার পরিবর্তে, ভূমিকার সংমিশ্রণ সহ API-এর অনেক ফিচার অ্যাক্সেস করা যেতে পারে। কোনও ব্যবহারকারীকে কোন ভূমিকা অ্যাসাইন করবেন তা ঠিক করার সময় অনুমতি সংক্রান্ত ডকুমেন্টেশন দেখুন। এছাড়াও, থার্ড-পার্টি অ্যাপ্লিকেশন ডেভেলপার হিসেবে, আপনার জন্য কোনও ব্যবহারকারী তৈরি করতে নেটওয়ার্ককে অনুরোধ করার সময় আপনার অ্যাপ্লিকেশনের কোন লেভেলের অ্যাক্সেস প্রয়োজন তা নির্ধারণ করতে ভুলবেন না; অ্যাডমিনিস্ট্রেটরের চেয়ে কম সুবিধা সহ কোনও ভূমিকা যথেষ্ট হতে পারে।

কোটার সীমার মধ্যে থাকুন

Ad Manager API, সিস্টেমের কার্যকারিতা বজায় রাখার জন্য কোটার উপর বিভিন্ন সীমা আরোপ করে। আপনার অ্যাপ্লিকেশনকে এই সীমার মধ্যে রাখা এবং API-এর মাধ্যমে ফেরত আসা কোটা সংক্রান্ত কোনও সমস্যার ক্ষেত্রে কীভাবে প্রতিক্রিয়া জানাতে হবে তা জানা গুরুত্বপূর্ণ।

API কোটা

API অনুরোধে প্রথম যে কোটা প্রয়োগ করা হয় সেটি হল নেটওয়ার্ক-লেভেল কোটা। Ad Manager 360 অ্যাকাউন্টের ক্ষেত্রে, সীমা হল প্রতি সেকেন্ডে ৮টি অনুরোধ এবং Ad Manager অ্যাকাউন্টের ক্ষেত্রে, সীমা হল প্রতি সেকেন্ডে ২টি অনুরোধ। এই সীমা পেরিয়ে গেলে, QuotaError.EXCEEDED_QUOTA সমস্যা হয়। আপনার নেটওয়ার্কে করা সব API অনুরোধ এই কোটায় প্রযোজ্য হয়, এর মধ্যে থার্ড-পার্টি অ্যাপ্লিকেশনও অন্তর্ভুক্ত, যেগুলিকে আপনি বা আপনার কোম্পানির কেউ আপনার নেটওয়ার্কে API অ্যাক্সেস দিয়েছেন।

সিস্টেম-নির্দিষ্ট কোটা

Ad Manager-এর মধ্যে নির্দিষ্ট কিছু রিসোর্স-ইনটেনসিভ সিস্টেমকে পর্যাপ্তভাবে সুরক্ষিত করার জন্য শুধুমাত্র API কোটা যথেষ্ট নয়। রিপোর্টিং ও পূর্বাভাস সিস্টেম তাদের নিজস্ব কোটা নির্ধারণ করে যার ফলে API সংক্রান্ত সমস্যা হতে পারে: যথাক্রমে QuotaError.REPORT_JOB_LIMIT এবং ForecastError.EXCEEDED_QUOTA।

কোটা সংক্রান্ত সমস্যা ম্যানেজ করা

আপনার অ্যাপ্লিকেশন উপরে উল্লেখ করা কোটা সংক্রান্ত কোনও সমস্যার সম্মুখীন হলে, API অনুরোধ আবার করার জন্য একটি কৌশল অবলম্বন করুন। আমরা সাজেস্ট করি যে প্রথমে অন্তত ৫ সেকেন্ড অপেক্ষা করুন এবং তারপরেও যদি সমস্যাটি থেকে যায়, তাহলে আবার চেষ্টা করার মধ্যে সময় বাড়াতে এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করুন। আবার চেষ্টা করে সফল না হলে, আপনার নেটওয়ার্কের কোনও ব্যবহারকারী আপনার কোটা শেষ করে দিচ্ছেন কিনা তা দেখতে আপনার API অ্যাপ্লিকেশনের অডিট করুন।