ত্রুটির প্রতিক্রিয়াগুলি পরিচালনা করুন

এই নির্দেশিকাটি ব্যাখ্যা করে যে মার্চেন্ট এপিআই দ্বারা ফেরত আসা ত্রুটিগুলি কীভাবে পরিচালনা করতে হয়। ত্রুটি প্রতিক্রিয়া কাঠামো এবং স্থিতিশীলতা বোঝা শক্তিশালী ইন্টিগ্রেশন তৈরির জন্য অত্যন্ত গুরুত্বপূর্ণ যা স্বয়ংক্রিয়ভাবে ব্যর্থতা থেকে পুনরুদ্ধার করতে পারে বা ব্যবহারকারীদের অর্থপূর্ণ প্রতিক্রিয়া প্রদান করতে পারে।

সংক্ষিপ্ত বিবরণ

যখন একটি Merchant API অনুরোধ ব্যর্থ হয়, তখন API একটি স্ট্যান্ডার্ড HTTP স্ট্যাটাস কোড ( 4xx অথবা 5xx ) এবং একটি JSON রেসপন্স বডি প্রদান করে যাতে ত্রুটি সম্পর্কে বিশদ বিবরণ থাকে। Merchant API ত্রুটির বিশদ বিবরণের জন্য AIP-193 স্ট্যান্ডার্ড অনুসরণ করে, যা মেশিন-পঠনযোগ্য তথ্য প্রদান করে যা আপনার অ্যাপ্লিকেশনকে নির্দিষ্ট ত্রুটির পরিস্থিতি প্রোগ্রাম্যাটিকভাবে পরিচালনা করতে দেয়।

ত্রুটি প্রতিক্রিয়া কাঠামো

ত্রুটি প্রতিক্রিয়া হল একটি JSON অবজেক্ট যাতে code , message এবং status মতো স্ট্যান্ডার্ড ফিল্ড থাকে। গুরুত্বপূর্ণ বিষয় হল, এতে একটি details অ্যারেও রয়েছে। প্রোগ্রাম্যাটিকভাবে ত্রুটিগুলি পরিচালনা করার জন্য, আপনার details এর মধ্যে এমন একটি অবজেক্ট সন্ধান করা উচিত যেখানে @type type.googleapis.com/google.rpc.ErrorInfo থাকে।

এই ErrorInfo অবজেক্টটি ত্রুটি সম্পর্কে স্থিতিশীল, কাঠামোগত ডেটা সরবরাহ করে:

  • ডোমেইন : ত্রুটির লজিক্যাল গ্রুপিং, সাধারণত merchantapi.googleapis.com ।
  • মেটাডেটা : ত্রুটির সাথে সম্পর্কিত গতিশীল মানের একটি মানচিত্র। এর মধ্যে রয়েছে:
    • REASON : সঠিক ত্রুটির জন্য একটি নির্দিষ্ট, স্থিতিশীল শনাক্তকারী (যেমন, INVALID_NAME_PART_NOT_NUMBER , PERMISSION_DENIED_ACCOUNTS )। এই ক্ষেত্রটি সর্বদা উপস্থিত থাকে। আপনার অ্যাপ্লিকেশন লজিকে সূক্ষ্মভাবে ত্রুটি পরিচালনার জন্য এই ক্ষেত্রটি ব্যবহার করুন।
    • HELP_CENTER_LINK : সমস্যা সমাধানের জন্য অতিরিক্ত প্রসঙ্গ এবং নির্দেশাবলী প্রদান করে। এই ক্ষেত্রটি সমস্ত ত্রুটির জন্য উপস্থিত নয়, তবে আমরা সময়ের সাথে সাথে ত্রুটিগুলির জন্য এর কভারেজ প্রসারিত করার পরিকল্পনা করছি যেখানে আরও প্রসঙ্গ প্রয়োজন হতে পারে।
    • অন্যান্য গতিশীল ক্ষেত্র : প্রসঙ্গ প্রদানকারী অন্যান্য কী, যেমন অবৈধ ক্ষেত্রের নাম ( FIELD_LOCATION ) অথবা ত্রুটির কারণী মান ( FIELD_VALUE )।

নমুনা ত্রুটির প্রতিক্রিয়া

নিম্নলিখিত JSON একটি Merchant API ত্রুটির কাঠামো প্রদর্শন করে যেখানে একটি রিসোর্সের নাম ত্রুটিপূর্ণ ছিল।

{
  "error": {
    "code": 400,
    "message": "[name] The part `account` of the resource name in field `name` must be a number, but has value: `abcd`.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "invalid",
        "domain": "merchantapi.googleapis.com",
        "metadata": {
          "VARIABLE_NAME": "account",
          "FIELD_LOCATION": "name",
          "FIELD_VALUE": "abcd",
          "REASON": "INVALID_NAME_PART_NOT_NUMBER"
        }
      }
    ]
  }
}

এখানে একটি প্রমাণীকরণ ত্রুটির উদাহরণ দেওয়া হল:

{
  "error": {
    "code": 401,
    "message": "The caller does not have access to the accounts: [1234567]",
    "status": "UNAUTHENTICATED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "unauthorized",
        "domain": "merchantapi.googleapis.com",
        "metadata": {
          "ACCOUNT_IDS": "[1234567]",
          "REASON": "PERMISSION_DENIED_ACCOUNTS"
        }
      }
    ]
  }
}

ত্রুটি ক্ষেত্রের স্থিতিশীলতা

ত্রুটি পরিচালনার যুক্তি লেখার সময়, কোন ক্ষেত্রগুলির উপর নির্ভর করা নিরাপদ এবং কোনগুলি পরিবর্তিত হতে পারে তা জানা গুরুত্বপূর্ণ।

  • স্থিতিশীল ক্ষেত্র:

  • details.metadata.REASON : নির্দিষ্ট ত্রুটি শনাক্তকারী। আপনার অ্যাপ্লিকেশনের নিয়ন্ত্রণ প্রবাহ যুক্তির জন্য এই ক্ষেত্রের উপর নির্ভর করা উচিত।

    • details.metadata keys : মেটাডেটা ম্যাপের মধ্যে থাকা কীগুলি (যেমন, FIELD_LOCATION , ACCOUNT_IDS ) স্থিতিশীল।
    • code : উচ্চ-স্তরের HTTP স্ট্যাটাস কোড (যেমন, 400 , 401 , 503 ) স্থিতিশীল।

  • অস্থির ক্ষেত্র:

    • message : মানুষের পঠনযোগ্য ত্রুটি বার্তাটি স্থিতিশীল নয় । এটি শুধুমাত্র ডেভেলপারদের ডিবাগিংয়ের জন্য তৈরি। message ক্ষেত্রের টেক্সট কন্টেন্ট পার্স করে বা তার উপর নির্ভর করে এমন কোড লিখবেন না , কারণ স্পষ্টতা উন্নত করতে বা প্রসঙ্গ যোগ করার জন্য এটি কোনও বিজ্ঞপ্তি ছাড়াই পরিবর্তিত হতে পারে।
    • details.metadata মান : কীগুলি স্থিতিশীল থাকলেও, তথ্যমূলক কীগুলির মান পরিবর্তিত হতে পারে। উদাহরণস্বরূপ, যদি একটি HELP_CENTER_LINK কী সরবরাহ করা হয়, তবে এটি যে নির্দিষ্ট URL-এ নির্দেশ করে তা পূর্ব বিজ্ঞপ্তি ছাড়াই একটি নতুন ডকুমেন্টেশন পৃষ্ঠায় আপডেট করা হতে পারে। তবে, যেমনটি আগে উল্লেখ করা হয়েছে, details.metadata.REASON এর মান স্থিতিশীল।

সেরা অনুশীলন

আপনার ইন্টিগ্রেশন ত্রুটিগুলি সুন্দরভাবে পরিচালনা করতে এই সেরা অনুশীলনগুলি অনুসরণ করুন।

যুক্তির জন্য details.metadata.REASON ব্যবহার করুন

ত্রুটির কারণ নির্ধারণের জন্য সর্বদা metadata ম্যাপের ভিতরে নির্দিষ্ট REASON ব্যবহার করুন। শুধুমাত্র HTTP স্ট্যাটাস কোডের উপর নির্ভর করবেন না, কারণ একাধিক ত্রুটি একই স্ট্যাটাস কোড ভাগ করে নিতে পারে।

ত্রুটি বার্তাটি বিশ্লেষণ করবেন না

স্থিতিশীলতা বিভাগে যেমন উল্লেখ করা হয়েছে, message ক্ষেত্রটি মানুষের ব্যবহারের জন্য। যদি আপনার গতিশীল তথ্যের প্রয়োজন হয় (যেমন কোন ক্ষেত্রটি অবৈধ ছিল), তাহলে FIELD_LOCATION , VARIABLE_NAME মতো স্থিতিশীল কী ব্যবহার করে metadata মানচিত্র থেকে এটি বের করুন।

সূচকীয় ব্যাকঅফ বাস্তবায়ন করুন

অস্থায়ী অনুপলব্ধতা বা হার সীমিতকরণ নির্দেশকারী ত্রুটির জন্য, একটি সূচকীয় ব্যাকঅফ কৌশল প্রয়োগ করুন। এর অর্থ হল পুনরায় চেষ্টা করার আগে অল্প সময়ের জন্য অপেক্ষা করা এবং প্রতিটি পরবর্তী ব্যর্থতার সাথে অপেক্ষার সময় বৃদ্ধি করা।

  • quota/request_rate_too_high : এই ত্রুটিটি নির্দেশ করে যে আপনি নির্দিষ্ট কোটা গ্রুপের জন্য আপনার মিনিটের কোটা অতিক্রম করেছেন। আপনার অনুরোধের হার কমিয়ে দিন।
  • internal_error : এগুলি সাধারণত ক্ষণস্থায়ী হয়। সূচকীয় ব্যাকঅফ দিয়ে পুনরায় চেষ্টা করুন। দ্রষ্টব্য: ব্যাকঅফ দিয়ে একাধিকবার পুনরায় চেষ্টা করার পরেও যদি internal_error চলতে থাকে, তাহলে Merchant API সহায়তার সাথে কীভাবে যোগাযোগ করবেন তা দেখুন।

মার্চেন্ট এপিআই সাপোর্টের সাথে কীভাবে যোগাযোগ করবেন

যদি আপনার কোনও নির্দিষ্ট ত্রুটির জন্য মার্চেন্ট এপিআই সহায়তার সাথে যোগাযোগ করার প্রয়োজন হয়, তাহলে আপনার অনুরোধে নিম্নলিখিত তথ্য প্রদান করুন:

  1. সঠিক ত্রুটির প্রতিক্রিয়াটি পাওয়া গেছে
  2. API পদ্ধতির নাম
  3. অনুরোধের পেলোড
  4. টাইমস্ট্যাম্প বা সময়সীমা যেখানে পদ্ধতিটি কল করা হয়েছিল এবং ত্রুটিগুলি পাওয়া গিয়েছিল