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

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

এক নজরে

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-এ মার্চেন্ট 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 কী: মেটাডেটা ম্যাপের মধ্যে থাকা কী (যেমন, 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: এগুলি সাধারণত ক্ষণস্থায়ী হয়। এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করে আবার চেষ্টা করুন।

Merchant API সহায়তা টিমের সাথে কীভাবে যোগাযোগ করবেন

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

  1. প্রাপ্ত সঠিক সমস্যার উত্তর
  2. API পদ্ধতির নাম
  3. অনুরোধ পেলোড
  4. টাইমস্ট্যাম্প বা সময়সীমা যার মধ্যে পদ্ধতিটি কল করা হয়েছিল এবং সমস্যা রিসিভ করা হয়েছিল
পূর্ববর্তী
Track usage metrics
পরবর্তী
Error messages