সর্বোত্তম অনুশীলন

নিম্নলিখিত সর্বোত্তম অনুশীলনগুলি অ্যাকশন সেন্টার লোকাল সার্ভিস বিজ্ঞাপন এন্ড-টু-এন্ড ইন্টিগ্রেশনে প্রযোজ্য এবং ব্যবহারযোগ্যতা এবং পারফরম্যান্স সমস্যা এড়াতে ব্যবহার করা যেতে পারে। নিম্ন ডেটার গুণমান ইনভেন্টরি টেকডাউন হতে পারে।

ফিড

• যদি একটি পরিষেবার একটি নির্দিষ্ট দৈর্ঘ্য না থাকে, তাহলে উপলব্ধতা ফিডে duration_sec নিম্নলিখিতগুলির একটিতে সেট করুন:
  • যুক্তিসঙ্গত পদ্ধতিতে পরিষেবাটি সম্পাদন করতে সেকেন্ডের সংখ্যা।

  • পরিষেবাটি সম্পূর্ণ করার জন্য প্রয়োজনীয় সেকেন্ডের গড় সংখ্যা৷

    দ্রষ্টব্য: যদি ফিডে 0 এর দৈর্ঘ্য জমা দেওয়া হয়, আমাদের সিস্টেম সেই উপলব্ধতা স্লটটিকে অবৈধ হিসাবে গণ্য করে এবং এটি অ্যাকশন সেন্টারে দেখায় না।
• বণিকের ফিডে Category ফিল্ড ইনপুট নির্দিষ্ট করুন। উদাহরণস্বরূপ, একটি রেস্তোরাঁ একটি নির্দিষ্ট ধরনের জমা দিতে পারে, যেমন ফরাসি বা জাপানি। বিশদ বিবরণের জন্য, সম্ভাব্য বিভাগের মানগুলির জন্য স্থানের ধরন দেখুন।

• মার্চেন্ট ফিডের Terms ক্ষেত্রে বণিক-নির্দিষ্ট পরিষেবার শর্তাদি সেট করুন যাতে নিম্নলিখিত নোটটি বুক বোতামের নীচে প্রদর্শিত হয়:

  চালিয়ে যাওয়ার মাধ্যমে, আপনি <merchant> এর পরিষেবার শর্তাবলীতে সম্মত হন।

  এই ক্ষেত্রে, "পরিষেবার শর্তাবলী" হল একটি লিঙ্ক যা ক্লিক করা হলে, শর্তাবলীর পাঠ্য ক্ষেত্রের পাঠ্য সেট প্রদর্শন করে।

• gzip ব্যবহার করে আপনার ফিড কম্প্রেস করুন

বুকিং সার্ভার

মানচিত্র বুকিং API-এর আপনার ইন্টিগ্রেশন অপ্টিমাইজ করতে, নিম্নলিখিতগুলি করুন:

• সর্বদা UTC বিন্যাসে UNIX টাইমস্ট্যাম্প ব্যবহার করুন।
• CreateBooking API-এ একটি নতুন বুকিং কল করা হলে একটি অনন্য বুকিং আইডি তৈরি করুন৷

রিয়েল-টাইম আপডেট

বুকিং প্রক্রিয়া চলাকালীন সর্বোত্তম ব্যবহারকারীর অভিজ্ঞতা নিশ্চিত করতে, নিম্নলিখিতগুলি করুন:

• একটি আদর্শ বাস্তবায়নের জন্য, একটি অ্যাপয়েন্টমেন্টের সূচনা সময়, সময়কাল এবং বুকিং স্থিতি পরিবর্তন করতে BookingNotifications API ব্যবহার করুন, যেমন বাতিল বা নো-শো।
• আপনার তরফ থেকে অ্যাকশন সেন্টার বুকিং-এ কোনও পরিবর্তনের পরে, রিয়েল-টাইমে BookingNotification API-এর সাথে সিস্টেম থেকে রিয়েল-টাইম বুকিং আপডেট পাঠান যাতে অ্যাকশন সেন্টারের দিকে ডেটা বাসি না হয়ে যায়। উদাহরণস্বরূপ, আপনি অ্যাকশন সেন্টারে আপনার সিস্টেম থেকে বুকিং বাতিল, পুনঃনির্ধারণ বা আপডেট করতে পারেন।
• UpdateBookingRequest থেকে প্রতিটি বুকিং আপডেটের জন্য, নিশ্চিত করুন যে UpdateBookingResponse মানটিতে বুকিং আইডি রয়েছে এবং সমস্ত আপডেট করা ক্ষেত্র অবশ্যই নতুন মান প্রতিফলিত করবে৷
• ইনভেন্টরি RTU বাস্তবায়িত হলে
  • শুধুমাত্র প্রতি API কলে 100-1000 স্লটের ব্যাচে উপলব্ধতা আপডেট করুন।
  • সম্পাদনা লক্ষ্যকে সংকুচিত করতে, পেলোডের আকার কমাতে এবং খুব বেশি অপরিবর্তিত ডেটা পুনরায় পাঠানো এড়াতে *Restrict (যেমন startTimeRestrict ) ক্ষেত্রগুলি ব্যবহার করুন।
  • আপনি যদি বেশ কয়েকটি থ্রেড স্পিন অফ করেন, তাহলে থ্রোটল ত্রুটি প্রতিরোধ করতে একটি সূচকীয় ব্যাকঅফ প্রয়োগ করুন। আপনি যদি একটি সূচকীয় ব্যাকঅফ সঠিকভাবে বাস্তবায়ন না করেন, তাহলে আপনি একটি RESOURCE_EXHAUSTED কোটা ত্রুটি পেতে পারেন। আপনি তাদের পরিচালনা করার জন্য সূচকীয় ব্যাকঅফ পুনরায় চেষ্টা করতে পারেন, কিন্তু, আপনি যদি দেখেন যে আপনার সার্ভারটি প্রায়ই কোটায় পৌঁছে যায় যখন আপনি ReplaceServiceAvailability চালান, তাহলে আপনার সার্ভারকে ব্যাচ রিপ্লেস করার জন্য কনফিগার করুন। এই সমাধানটি কোটা ত্রুটি রোধ করে কারণ এটি আপনার পরিবেশন করা API কলের সংখ্যা হ্রাস করে।
• আপনার API কল প্রতিক্রিয়া সময় সীমা এক সেকেন্ডের কম সেট করুন। নিশ্চিত করুন যে আপনার সার্ভার প্রতি সেকেন্ডে (QPS) কমপক্ষে 95% সময়ের সাব-সেকেন্ড লেটেন্সি সহ পাঁচটি প্রশ্ন পরিচালনা করতে পারে।