एपीआई से जुड़ी गड़बड़ियों को समझना

इस गाइड में बताया गया है कि Data Manager API, गड़बड़ियों को कैसे मैनेज करता है और उनकी जानकारी कैसे देता है. एपीआई से जुड़ी गड़बड़ियों के स्ट्रक्चर और उनके मतलब को समझना ज़रूरी है. इससे ऐसे मज़बूत ऐप्लिकेशन बनाए जा सकते हैं जो अमान्य इनपुट से लेकर सेवा के अस्थायी तौर पर उपलब्ध न होने जैसी समस्याओं को आसानी से हल कर सकते हैं.

Data Manager API, Google API के स्टैंडर्ड गड़बड़ी मॉडल का पालन करता है. यह मॉडल, gRPC स्टेटस कोड पर आधारित है. एपीआई से मिली जानकारी के हर जवाब में, गड़बड़ी होने पर Status ऑब्जेक्ट शामिल होता है. इसमें ये चीज़ें होती हैं:

  • गड़बड़ी का कोड, संख्या में.
  • गड़बड़ी का मैसेज.
  • गड़बड़ी के बारे में ज़्यादा जानकारी. यह ज़रूरी नहीं है.

कैननिकल गड़बड़ी के कोड

Data Manager API, gRPC और एचटीटीपी के तय किए गए कैननिकल गड़बड़ी कोड के सेट का इस्तेमाल करता है. इन कोड से, गड़बड़ी के टाइप के बारे में खास जानकारी मिलती है. आपको हमेशा इस कोड की जांच करनी चाहिए, ताकि समस्या की बुनियादी वजह का पता चल सके.

इन कोड के बारे में ज़्यादा जानने के लिए, एपीआई डिज़ाइन गाइड - गड़बड़ी के कोड देखें.

गड़बड़ी मिलने पर तुरंत रिपोर्ट करने वाला मॉडल

Data Manager API, फ़ास्ट-फ़ेल मॉडल का इस्तेमाल करता है. अगर किसी अनुरोध में स्ट्रक्चर से जुड़ी गड़बड़ियां हैं या किसी ज़रूरी फ़ील्ड के लिए कोई रिकॉर्ड मान्य नहीं है, तो पूरा अनुरोध पूरा नहीं होगा. साथ ही, एपीआई उस अनुरोध में मौजूद किसी भी डेटा को प्रोसेस नहीं करेगा.

कुछ समय के लिए काम न करने वाले मॉडल से तुलना

फ़ास्ट-फ़ेल मॉडल, Google के कुछ अन्य एपीआई में मौजूद पार्शियल फ़ेल मॉडल से अलग होता है. जैसे, Google Ads API और Campaign Manager 360 API. आंशिक तौर पर अनुरोध पूरा होने वाले मॉडल में, कुछ रिकॉर्ड में गड़बड़ियां होने के बावजूद अनुरोध पूरा हो जाता है. साथ ही, जवाब में उन रिकॉर्ड की गड़बड़ी की जानकारी शामिल होती है जिन्हें प्रोसेस नहीं किया जा सका.

हालांकि, कुछ हद तक काम न करने वाले मॉडल का इस्तेमाल करना आसान हो सकता है, लेकिन इससे जुड़े जोखिम बहुत ज़्यादा होते हैं. ऐसा इसलिए, क्योंकि कुछ हद तक काम न करने वाला मॉडल, आपको पहले से गलतियों के बारे में सूचना नहीं देता. आपको हर जवाब में गलतियों की जांच करनी होगी. इससे अहम समस्याएं छिप सकती हैं, क्योंकि अनुरोध में शामिल कई या सभी रिकॉर्ड को एपीआई से अस्वीकार किए जाने पर भी अनुरोध पूरा हो जाता है. अगर किसी अनुरोध में मौजूद रिकॉर्ड के बड़े हिस्से में गड़बड़ियां हैं, लेकिन आपने जवाब की जांच नहीं की है, तो हो सकता है कि आपको अपने डेटा से जुड़ी कई समस्याओं के बारे में पता न चले. साथ ही, आपको इन समस्याओं के बारे में सिर्फ़ कुछ दिनों या हफ़्तों बाद पता चले, जब कुल नतीजे आपकी उम्मीदों के मुताबिक न हों.

फ़ास्ट-फ़ेल मॉडल इन कमियों से बचने में मदद करता है. यह आपको डेटा या इंटिग्रेशन से जुड़ी समस्याओं के बारे में तुरंत सूचना देता है, ताकि आप ज़रूरी कार्रवाई कर सकें.

validateOnly की मदद से, फ़ेल होने वाली गड़बड़ियों की जांच करना

डेटा शामिल करने और हटाने के ज़्यादातर अनुरोधों में, validateOnly फ़ील्ड का इस्तेमाल किया जा सकता है. validateOnly को true पर सेट करने पर, Data Manager API, सामान्य अनुरोध के लिए किए जाने वाले बुनियादी पुष्टि वाले चेक ही करता है. हालांकि, यह किसी भी डेटा को शामिल या नहीं करता है.

  • अगर अनुरोध में गड़बड़ियां हैं, तो आपको वही गड़बड़ी वाला जवाब मिलेगा जो आपको सामान्य अनुरोध से मिलता है.
  • अगर अनुरोध की पुष्टि हो जाती है, तो उसे पूरा कर दिया जाता है. जवाब में, वैकल्पिक फ़ील्ड के लिए कोई भी fieldWarnings शामिल होता है. यह ठीक उसी तरह होता है जैसे किसी सामान्य अनुरोध में होता है.

validateOnly का इस्तेमाल करके:

  • लाइव डेटा पर असर डाले बिना, नए या अपडेट किए गए इंटिग्रेशन को टेस्ट करें.
  • अनुरोध को फिर से भेजने से पहले, पुष्टि करें कि समस्या ठीक हो गई है.

गड़बड़ियां ठीक करना

अनुरोध पूरा न होने पर, यह तरीका अपनाएं:

  1. गड़बड़ी किस तरह की है, यह जानने के लिए गड़बड़ी का कोड देखें.

    • gRPC का इस्तेमाल करने पर, गड़बड़ी का कोड Status के code फ़ील्ड में होता है. अगर क्लाइंट लाइब्रेरी का इस्तेमाल किया जाता है, तो हो सकता है कि यह गड़बड़ी के कोड से मेल खाने वाली किसी खास तरह की गड़बड़ी को दिखाए. उदाहरण के लिए, अगर गड़बड़ी कोड INVALID_ARGUMENT है, तो Java के लिए क्लाइंट लाइब्रेरी com.google.api.gax.rpc.InvalidArgumentException दिखाती है.
    • REST का इस्तेमाल करने पर, गड़बड़ी का कोड error.status पर गड़बड़ी के रिस्पॉन्स में होता है. साथ ही, इससे जुड़ा एचटीटीपी स्टेटस error.code पर होता है.
    फिर से भेजें.

  2. गड़बड़ी के कोड के लिए, स्टैंडर्ड डिटेल पेलोड देखें. स्टैंडर्ड जानकारी वाले पेलोड, Google API से जुड़ी गड़बड़ियों के मैसेज का सेट होते हैं. ये आपको गड़बड़ी की जानकारी, स्ट्रक्चर्ड और एक जैसे फ़ॉर्मैट में देते हैं. डेटा मैनेजर API से जुड़ी हर गड़बड़ी के लिए, एक से ज़्यादा स्टैंडर्ड डिटेल पेलोड मैसेज हो सकते हैं. Data Manager API की एपीआई क्लाइंट लाइब्रेरी में, गड़बड़ी से स्टैंडर्ड जानकारी वाले पेलोड पाने के लिए सहायता करने वाले तरीके मौजूद हैं.

    गड़बड़ी का कोड कोई भी हो, हमारा सुझाव है कि आप ErrorInfo, RequestInfo, Help, और LocalizedMessage पेलोड की जांच करें और उन्हें लॉग करें.

    • ErrorInfo में ऐसी जानकारी होती है जो शायद अन्य पेलोड में न हो.
    • RequestInfo में अनुरोध आईडी होता है. अगर आपको सहायता टीम से संपर्क करना है, तो यह आईडी आपके काम आ सकता है.
    • Help और LocalizedMessage में लिंक और अन्य जानकारी होती है, ताकि आपको गड़बड़ी ठीक करने में मदद मिल सके.

    इसके अलावा, BadRequest पेलोड, INVALID_ARGUMENT गड़बड़ियों को ठीक करने में मददगार होता है. इसकी वजह यह है कि इससे यह जानकारी मिलती है कि किन फ़ील्ड की वजह से गड़बड़ी हुई है.

डेटा ट्रांसफ़र करने से जुड़ी चेतावनियां

Data Manager API, डेटा ट्रांसफ़र करने के अनुरोध को ज़्यादा से ज़्यादा स्वीकार करता है. अगर आपने ऐसा डेटा शामिल किया है जिसकी ज़रूरत नहीं है, तो उन फ़ील्ड के लिए पुष्टि करने की प्रोसेस पूरी न होने पर भी अनुरोध पूरा हो जाएगा. उदाहरण के लिए, अगर कार्ट में मौजूद किसी आइटम में कारोबारी या कंपनी के प्रॉडक्ट आईडी की जानकारी मौजूद नहीं है, तो एपीआई अनुरोध के बाकी हिस्से को प्रोसेस करता है और चेतावनी दिखाता है.

डेटा को शामिल करने के अनुरोध के पूरा होने पर मिलने वाले जवाब (एचटीटीपी स्टेटस कोड 200) में, ये चेतावनियां fieldWarnings सूची में शामिल होती हैं. हर एंट्री, FieldWarning ऑब्जेक्ट होती है. इसमें ये फ़ील्ड होते हैं:

field

अनुरोध में फ़ील्ड की जगह. यह स्नेक केस पाथ सिंटैक्स में होती है.

अगर कोई पाथ, सूची (repeated फ़ील्ड) में मौजूद किसी आइटम की ओर इशारा करता है, तो सूची के नाम के बाद उसका इंडेक्स स्क्वेयर ब्रैकेट ([...]) में दिखाया जाता है.

उदाहरण के लिए, events.events[0].cart_data.items[0].merchant_product_id से पता चलता है कि अनुरोध में मौजूद पहले इवेंट के कार्ट डेटा में मौजूद पहले आइटम से जुड़ी चेतावनी है.

description

दी गई वैल्यू की वजह से चेतावनी क्यों मिली, इसकी जानकारी.

reason

WarningReason enum वैल्यू, जो चेतावनी के टाइप की पहचान करती है.

FieldWarning का इस्तेमाल करके बनाया गया उदाहरण

यहां डेटा को शामिल करने के अनुरोध का एक सैंपल रिस्पॉन्स दिया गया है. इसमें एक चेतावनी शामिल है, क्योंकि कार्ट में मौजूद किसी एक आइटम के लिए कारोबारी या कंपनी का प्रॉडक्ट आईडी मौजूद नहीं था.

{
  "requestId": "126365e1-16d0-4c81-9de9-f362711e250a",
  "fieldWarnings": [
    {
      "field": "events.events[0].cart_data.items[0].merchant_product_id",
      "description": "The merchant product ID is missing in the cart item.",
      "reason": "WARNING_REASON_CART_DATA_ITEM_MERCHANT_PRODUCT_ID_MISSING"
    }
  ]
}

स्टैंडर्ड जानकारी वाले पेलोड

Data Manager API के लिए, स्टैंडर्ड जानकारी वाले पेलोड ये हैं:

BadRequest

जब कोई अनुरोध INVALID_ARGUMENT (एचटीटीपी स्टेटस कोड 400) के साथ पूरा न हो, तब BadRequest पेलोड की जांच करें.

BadRequest मैसेज से पता चलता है कि अनुरोध में ऐसे फ़ील्ड शामिल थे जिनकी वैल्यू गलत थी या किसी ज़रूरी फ़ील्ड की वैल्यू मौजूद नहीं थी. field_violations में मौजूद BadRequest सूची देखें. इससे आपको पता चलेगा कि किन फ़ील्ड में गड़बड़ियां हैं. हर field_violations एंट्री में, गड़बड़ी को ठीक करने में आपकी मदद करने वाली जानकारी होती है:

field

अनुरोध में फ़ील्ड की जगह. यह स्नेक केस पाथ सिंटैक्स में होती है.

अगर कोई पाथ, सूची (repeated फ़ील्ड) में मौजूद किसी आइटम की ओर इशारा करता है, तो सूची के नाम के बाद उसका इंडेक्स स्क्वेयर ब्रैकेट ([...]) में दिखाया जाता है.

उदाहरण के लिए, destinations[0].operating_account.account_id, destinations सूची में मौजूद पहले आइटम के operating_account में account_id है.

description

इस वैल्यू की वजह से गड़बड़ी क्यों हुई, इसकी जानकारी.

reason

ErrorReason enum, जैसे कि INVALID_HEX_ENCODING या INVALID_CURRENCY_CODE.

BadRequest के उदाहरण

यहां BadRequest मैसेज के साथ INVALID_ARGUMENT गड़बड़ी के लिए एक सैंपल जवाब दिया गया है. field_violations से पता चलता है कि गड़बड़ी accountId है, जो संख्या नहीं है. field वैल्यू destinations[0].login_account.account_id दिखाती है कि accountId में फ़ील्ड के उल्लंघन की समस्या है. यह destinations सूची में मौजूद पहले आइटम के login_account में है.

{
  "error": {
    "code": 400,
    "message": "There was a problem with the request.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "INVALID_ARGUMENT",
        "domain": "datamanager.googleapis.com",
        "metadata": {
          "requestId": "t-a8896317-069f-4198-afed-182a3872a660"
        }
      },
      {
        "@type": "type.googleapis.com/google.rpc.RequestInfo",
        "requestId": "t-a8896317-069f-4198-afed-182a3872a660"
      },
      {
        "@type": "type.googleapis.com/google.rpc.BadRequest",
        "fieldViolations": [
          {
            "field": "destinations[0].login_account.account_id",
            "description": "String is not a valid number.",
            "reason": "INVALID_NUMBER_FORMAT"
          }
        ]
      }
    ]
  }
}

यहां INVALID_ARGUMENT से मिली गड़बड़ी के जवाब का एक और सैंपल दिया गया है. इसमें BadRequest मैसेज भी शामिल है. इस मामले में, field_violations सूची में दो गड़बड़ियां दिख रही हैं:

  1. पहले event में ऐसी वैल्यू है जिसे इवेंट के दूसरे उपयोगकर्ता आइडेंटिफ़ायर पर हेक्स-कोड में नहीं बदला गया है.

  2. दूसरे event की वैल्यू, इवेंट के तीसरे उपयोगकर्ता आइडेंटिफ़ायर पर हेक्स-कोड में नहीं है.

{
  "error": {
    "code": 400,
    "message": "There was a problem with the request.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "INVALID_ARGUMENT",
        "domain": "datamanager.googleapis.com",
        "metadata": {
          "requestId": "t-6bc8fb83-d648-4942-9c49-2604276638d8"
        }
      },
      {
        "@type": "type.googleapis.com/google.rpc.RequestInfo",
        "requestId": "t-6bc8fb83-d648-4942-9c49-2604276638d8"
      },
      {
        "@type": "type.googleapis.com/google.rpc.BadRequest",
        "fieldViolations": [
          {
            "field": "events.events[0].user_data.user_identifiers[1]",
            "description": "The HEX encoded value is malformed.",
            "reason": "INVALID_HEX_ENCODING"
          },
          {
            "field": "events.events[1].user_data.user_identifiers[2]",
            "description": "The HEX encoded value is malformed.",
            "reason": "INVALID_HEX_ENCODING"
          }
        ]
      }
    ]
  }
}

RequestInfo

जब भी कोई अनुरोध पूरा न हो, तब RequestInfo पेलोड की जांच करें. RequestInfo में request_id शामिल होता है. यह आपके एपीआई अनुरोध की यूनीक पहचान करता है.

{
  "@type": "type.googleapis.com/google.rpc.RequestInfo",
  "requestId": "t-4490c640-dc5d-4c28-91c1-04a1cae0f49f"
}

गड़बड़ियों की जानकारी देते समय या सहायता टीम से संपर्क करते समय, अनुरोध आईडी ज़रूर शामिल करें. इससे गड़बड़ियों का पता लगाने में मदद मिलेगी.

ErrorInfo

ज़्यादा जानकारी पाने के लिए, ErrorInfo मैसेज देखें. यह जानकारी, अन्य स्टैंडर्ड डिटेल पेलोड में शामिल नहीं की जा सकती. ErrorInfoपेलोड में, गड़बड़ी के बारे में जानकारी देने वाला metadata मैप होता है.

उदाहरण के लिए, यहां ErrorInfo दिया गया है. यह PERMISSION_DENIED, Google Cloud प्रोजेक्ट के क्रेडेंशियल इस्तेमाल करने की वजह से मिला है. इस प्रोजेक्ट में Data Manager API चालू नहीं है. ErrorInfo से गड़बड़ी के बारे में ज़्यादा जानकारी मिलती है. जैसे:

  • अनुरोध से जुड़ा प्रोजेक्ट, metadata.consumer में मौजूद होता है.
  • metadata.serviceTitle में मौजूद सेवा का नाम.
  • वह यूआरएल जहां metadata.activationUrl में जाकर सेवा चालू की जा सकती है.
{
  "error": {
    "code": 403,
    "message": "Data Manager API has not been used in project PROJECT_NUMBER before or it is disabled. Enable it by visiting https://console.cloud.google.com/apis/api/datamanager.googleapis.com/overview?project=PROJECT_NUMBER then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
    "status": "PERMISSION_DENIED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "SERVICE_DISABLED",
        "domain": "googleapis.com",
        "metadata": {
          "consumer": "projects/PROJECT_NUMBER",
          "service": "datamanager.googleapis.com",
          "containerInfo": "PROJECT_NUMBER",
          "serviceTitle": "Data Manager API",
          "activationUrl": "https://console.cloud.google.com/apis/api/datamanager.googleapis.com/overview?project=PROJECT_NUMBER"
        }
      },
      ...
    ]
  }
}

कोटा और दर की सीमा से जुड़ी गड़बड़ियां

जब कोई अनुरोध, प्रोजेक्ट की सीमा से ज़्यादा होता है, तो एपीआई RESOURCE_EXHAUSTED गड़बड़ी (एचटीटीपी स्टेटस कोड 429) दिखाता है. ErrorInfo पेलोड में इस बारे में जानकारी होती है कि metadata मैप में कौनसी सीमा पार की गई है:

consumer
अनुरोध से जुड़ा Google Cloud प्रोजेक्ट, जिसे projects/PROJECT_NUMBER के तौर पर फ़ॉर्मैट किया गया है.
quota_limit
कोटा की उस सीमा का नाम जिसे पार किया गया है. जैसे, IngestionMutateRequestsPerMinutePerProject या IngestionMutateRequestsPerDayPerProject. इस वैल्यू का इस्तेमाल करके यह पता लगाया जा सकता है कि ऐप्लिकेशन ने हर मिनट की सीमा या रोज़ाना की सीमा को पार किया है या नहीं. सीमाओं के नामों की पूरी सूची देखने के लिए, प्रोजेक्ट की सीमाएं देखें.
quota_location
वह जगह जहां कोटा लागू किया गया है. Data Manager API के लिए, यह हमेशा global होता है.
quota_metric
सीमा से जुड़ी मेट्रिक, जैसे कि datamanager.googleapis.com/ingestion_mutate_requests.
service
सेवा का नाम, datamanager.googleapis.com.

यहां RESOURCE_EXHAUSTED गड़बड़ी के जवाब का एक उदाहरण दिया गया है. यह तब दिखता है, जब डेटा ट्रांसफ़र करने के अनुरोध, हर मिनट के हिसाब से तय की गई सीमा से ज़्यादा होते हैं:

{
  "error": {
    "code": 429,
    "message": "Quota exceeded for quota metric 'Ingestion mutate requests' and limit 'Ingestion mutate requests per minute' of service 'datamanager.googleapis.com' for consumer 'project_number:PROJECT_NUMBER'.",
    "status": "RESOURCE_EXHAUSTED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "RATE_LIMIT_EXCEEDED",
        "domain": "googleapis.com",
        "metadata": {
          "consumer": "projects/PROJECT_NUMBER",
          "quota_limit": "IngestionMutateRequestsPerMinutePerProject",
          "quota_location": "global",
          "quota_metric": "datamanager.googleapis.com/ingestion_mutate_requests",
          "service": "datamanager.googleapis.com"
        }
      }
    ]
  }
}

Help और LocalizedMessage

Help और LocalizedMessage पेलोड देखें. इनसे आपको दस्तावेज़ों के लिंक और स्थानीय भाषा में गड़बड़ी के मैसेज मिलेंगे. इनसे आपको गड़बड़ी को समझने और उसे ठीक करने में मदद मिलेगी.

उदाहरण के लिए, यहां PERMISSION_DENIED के लिए Help और LocalizedMessage दिया गया है. यह , Google Cloud प्रोजेक्ट के क्रेडेंशियल इस्तेमाल करने की वजह से फ़ेल हुआ है. इस प्रोजेक्ट में Data Manager API चालू नहीं है. Help पेलोड में, उस यूआरएल की जानकारी होती है जहां सेवा को चालू किया जा सकता है. साथ ही, LocalizedMessage में गड़बड़ी की जानकारी होती है.

{
  "error": {
    "code": 403,
    "message": "Data Manager API has not been used in project PROJECT_NUMBER before or it is disabled. Enable it by visiting https://console.cloud.google.com/apis/api/datamanager.googleapis.com/overview?project=PROJECT_NUMBER then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
    "status": "PERMISSION_DENIED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.LocalizedMessage",
        "locale": "en-US",
        "message": "Data Manager API has not been used in project PROJECT_NUMBER before or it is disabled. Enable it by visiting https://console.cloud.google.com/apis/api/datamanager.googleapis.com/overview?project=PROJECT_NUMBER then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
      },
      {
        "@type": "type.googleapis.com/google.rpc.Help",
        "links": [
          {
            "description": "Google API Console API activation",
            "url": "https://console.cloud.google.com/apis/api/datamanager.googleapis.com/overview?project=PROJECT_NUMBER"
          }
        ]
      },
      ...
    ]
  }
}

ऐक्सेस करने में हुई गड़बड़ी की जानकारी

अगर क्लाइंट लाइब्रेरी का इस्तेमाल किया जा रहा है, तो स्टैंडर्ड जानकारी वाले पेलोड पाने के लिए, हेल्पर तरीकों का इस्तेमाल करें.

.NET

try {
    // Send API request
}
catch (Grpc.Core.RpcException rpcException)
{
    Console.WriteLine($"Exception encountered: {rpcException.Message}");
    var statusDetails =
        Google.Api.Gax.Grpc.RpcExceptionExtensions.GetAllStatusDetails(
            rpcException
        );
    foreach (var detail in statusDetails)
    {
        if (detail is Google.Rpc.BadRequest)
        {
            Google.Rpc.BadRequest badRequest = (Google.Rpc.BadRequest)detail;
            foreach (
                BadRequest.Types.FieldViolation? fieldViolation in badRequest.FieldViolations
            )
            {
                // Access attributes such as fieldViolation!.Reason and fieldViolation!.Field
            }
        }
        else if (detail is Google.Rpc.RequestInfo)
        {
            Google.Rpc.RequestInfo requestInfo = (Google.Rpc.RequestInfo)detail;
            string requestId = requestInfo.RequestId;
            // Log the requestId...
        }
        else if (detail is Google.Rpc.ErrorInfo)
        {
            Google.Rpc.ErrorInfo errorInfo = (Google.Rpc.ErrorInfo)detail;
            // Log the errorInfo.Reason and errorInfo.Metadata...

            // If handling a rate limit error, check the exceeded quota limit:
            if (errorInfo.Reason == "RATE_LIMIT_EXCEEDED" &&
                errorInfo.Metadata.TryGetValue("quota_limit", out string quotaLimit))
            {
                // Inspect quotaLimit to determine whether it is a per-minute
                // or daily limit (for example,
                // IngestionMutateRequestsPerMinutePerProject).
            }

            // Log the details in the 'Metadata' map...
            foreach (
                KeyValuePair<String, String> metadataEntry in errorInfo.Metadata
            )
            {
                // Log the metadataEntry.Key and metadataEntry.Value...
            }
        }
        else
        {
            // ...
        }
    }
}

Java

try {
  // Send API request
} catch (com.google.api.gax.rpc.InvalidArgumentException invalidArgumentException) {
  // Gets the standard BadRequest payload from the exception.
  BadRequest badRequest = invalidArgumentException.getErrorDetails().getBadRequest();
  for (int i = 0; i < badRequest.getFieldViolationsCount(); i++) {
    FieldViolation fieldViolation = badRequest.getFieldViolations(i);
    // Access attributes such as fieldViolation.getField() and fieldViolation.getReason()
  }

  // Gets the standard RequestInfo payload from the exception.
  RequestInfo requestInfo = invalidArgumentException.getErrorDetails().getRequestInfo();
  if (requestInfo != null) {
    String requestId = requestInfo.getRequestId();
    // Log the requestId...
  }
} catch (com.google.api.gax.rpc.ApiException apiException) {
  // Fallback exception handler for other types of ApiException.

  // Gets the standard ErrorInfo payload from the exception.
  ErrorInfo errorInfo = apiException.getErrorDetails().getErrorInfo();
  // Log the 'reason' and 'domain'...

  // If handling a rate limit error, check the exceeded quota limit:
  if (errorInfo != null && "RATE_LIMIT_EXCEEDED".equals(errorInfo.getReason())) {
    String quotaLimit = errorInfo.getMetadataMap().get("quota_limit");
    // Inspect quotaLimit to determine whether it is a per-minute
    // or daily limit (for example,
    // IngestionMutateRequestsPerMinutePerProject).
  }

  // Log the details in the 'metadata' map...
  for (Entry<String, String> metadataEntry : errorInfo.getMetadataMap().entrySet()) {
    // Log the metadataEntry key and value...
  }

  // Gets the standard RequestInfo payload from the exception.
  RequestInfo requestInfo = apiException.getErrorDetails().getRequestInfo();
  if (requestInfo != null) {
    String requestId = requestInfo.getRequestId();
    // Log the requestId...
  }
  ...
}

गड़बड़ी ठीक करने के सबसे सही तरीके

भरोसेमंद ऐप्लिकेशन बनाने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं.

भेजने से पहले पुष्टि करें
इंटिग्रेशन बनाते या बदलते समय, validateOnly को true पर सेट करके अनुरोध भेजें. इससे डेटा को प्रोसेस करने से पहले ही, गड़बड़ियों का पता चल जाएगा.
गड़बड़ी की जानकारी देखना
हमेशा स्टैंडर्ड जानकारी वाले पेलोड में से किसी एक को देखें. जैसे, BadRequest. हर स्टैंडर्ड डिटेल पेलोड में ऐसी जानकारी होती है जिससे आपको गड़बड़ी की वजह समझने में मदद मिलती है.
क्लाइंट और सर्वर की गड़बड़ियों में अंतर करना

पता लगाएं कि गड़बड़ी, क्लाइंट (आपका सिस्टम) या सर्वर (एपीआई) में से किसकी वजह से हुई है.

  • क्लाइंट की गड़बड़ियां: INVALID_ARGUMENT, NOT_FOUND, PERMISSION_DENIED, FAILED_PRECONDITION, UNAUTHENTICATED जैसे कोड. इनके लिए, अनुरोध में बदलाव करने या आपके ऐप्लिकेशन की स्थिति/क्रेडेंशियल में बदलाव करने की ज़रूरत होती है. समस्या को ठीक किए बिना, अनुरोध को फिर से न भेजें.
  • सर्वर से जुड़ी गड़बड़ियां: UNAVAILABLE, INTERNAL, DEADLINE_EXCEEDED, UNKNOWN जैसे कोड. इनसे पता चलता है कि एपीआई सेवा में कुछ समय के लिए कोई समस्या हुई है.
फिर से कोशिश करने की रणनीति लागू करना

यह तय करें कि गड़बड़ी को फिर से ठीक किया जा सकता है या नहीं. इसके बाद, फिर से कोशिश करने की रणनीति का इस्तेमाल करें.

  • सर्वर से जुड़ी कुछ समय के लिए होने वाली गड़बड़ियों (जैसे कि UNAVAILABLE, DEADLINE_EXCEEDED, INTERNAL, UNKNOWN, और ABORTED) और हर मिनट के हिसाब से तय की गई दर की सीमाओं (RESOURCE_EXHAUSTED के साथ RATE_LIMIT_EXCEEDED) के लिए, सिर्फ़ फिर से कोशिश करें.

  • रेट लिमिट के लिए, quota_limit in ErrorInfo की जांच करें:

    • अगर सीमा प्रति मिनट है (जैसे कि IngestionMutateRequestsPerMinutePerProject), तो अनुरोधों को रोकें और जिटर के साथ एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करके फिर से कोशिश करें.

    • अगर सीमा हर दिन के हिसाब से तय की गई है (जैसे कि IngestionMutateRequestsPerDayPerProject), तो तुरंत फिर से कोशिश न करें. प्रोसेसिंग को तब तक रोकें, जब तक पैसिफ़िक टाइम के मुताबिक आधी रात को हर दिन का कोटा रीसेट नहीं हो जाता.

  • फिर से कोशिश करने के बीच के समय को बढ़ाने के लिए, एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करें. इससे पहले से ही तनाव में चल रही सेवा पर ज़्यादा दबाव नहीं पड़ता. उदाहरण के लिए, पहले एक सेकंड, फिर दो सेकंड, फिर चार सेकंड इंतज़ार करें. ऐसा तब तक करें, जब तक फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या या इंतज़ार का कुल समय पूरा न हो जाए.

  • बैकऑफ़ में होने वाली देरी में थोड़ा सा रैंडम "जिटर" जोड़ें, ताकि "थंडरिंग हर्ड" की समस्या को रोका जा सके. इस समस्या में कई क्लाइंट एक साथ फिर से कोशिश करते हैं.

पूरी जानकारी लॉग करना

गड़बड़ी की पूरी जानकारी को लॉग करें. इसमें सभी स्टैंडर्ड जानकारी वाले पेलोड शामिल होने चाहिए. खास तौर पर, अनुरोध आईडी. यह जानकारी डीबग करने के लिए ज़रूरी है. साथ ही, ज़रूरत पड़ने पर Google सहायता टीम को समस्याओं की शिकायत करने के लिए भी यह जानकारी ज़रूरी है.

उपयोगकर्ता के सुझाव, शिकायत या राय

स्टैंडर्ड डिटेल पेलोड में मौजूद कोड और मैसेज के आधार पर, अपने ऐप्लिकेशन के उपयोगकर्ताओं को साफ़ तौर पर और मददगार सुझाव/राय दें या शिकायत करें. उदाहरण के लिए, सिर्फ़ "कोई गड़बड़ी हुई" के बजाय,"लेन-देन आईडी मौजूद नहीं था" या "डेस्टिनेशन खाते का आईडी नहीं मिला" कहा जा सकता है.

इन दिशा-निर्देशों का पालन करके, Data Manager API से मिली गड़बड़ियों का पता लगाया जा सकता है और उन्हें ठीक किया जा सकता है. इससे ज़्यादा स्थिर और इस्तेमाल में आसान ऐप्लिकेशन बनाए जा सकते हैं.

पीछे जाएं
उपयोगकर्ता का डेटा एन्क्रिप्ट (सुरक्षित) करें
आगे बढ़ें
सबसे सही तरीके