Edge for Private Cloud 4.53.01 में हुए बदलाव

बदलावों की खास जानकारी

Edge for Private Cloud 4.53.01 में कई बदलाव किए गए हैं. इनसे प्लैटफ़ॉर्म की सुरक्षा को बेहतर बनाया गया है. साथ ही, ज़रूरी सॉफ़्टवेयर और लाइब्रेरी के अपडेट किए गए वर्शन शामिल किए गए हैं. इन बदलावों से, इन नीतियों पर असर पड़ता है:

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

बदलावों के बारे में पूरी जानकारी

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

OAS (OpenAPI स्पेसिफ़िकेशन) की पुष्टि करने की नीति

कॉन्टेक्स्ट

OAS की पुष्टि करने की नीति, OpenAPI 3.0 स्पेसिफ़िकेशन (JSON या YAML) में तय किए गए नियमों के हिसाब से, आने वाले अनुरोधों या जवाबों की पुष्टि करती है. Edge for Private Cloud 4.53.01 में, OAS (OpenAPI स्पेसिफ़िकेशन) नीति को बेहतर बनाया गया है. इसमें एपीआई रिस्पॉन्स बॉडी की पुष्टि को ज़्यादा सटीक और सख्त बनाया गया है.

बदलाव

Edge for Private Cloud 4.53.01 में, OAS नीति के ज़रिए एपीआई से मिले जवाबों की पुष्टि करने के तरीके में दो अहम बदलाव किए गए हैं. इससे यह पक्का किया जा सकेगा कि आपके OpenAPI स्पेसिफ़िकेशन के साथ ज़्यादा से ज़्यादा समानता हो:

  • पहला विकल्प:
    • पिछला तरीका: अगर आपके OpenAPI स्पेसिफ़िकेशन में रिस्पॉन्स बॉडी की ज़रूरत होती थी, लेकिन टारगेट या अपस्ट्रीम नीति से मिले असल रिस्पॉन्स में वह शामिल नहीं थी, तो नीति इसे पुष्टि करने से जुड़ी गड़बड़ी के तौर पर फ़्लैग नहीं करती थी.
    • मौजूदा तरीका: इस स्थिति में, नीति अब पुष्टि करने से जुड़ी गड़बड़ी (उदाहरण: defines a response schema but no response body found) को सही तरीके से दिखाएगी. इससे पता चलेगा कि अनुमानित और असल जवाब मेल नहीं खाते.
  • दूसरी स्थिति:
    • पिछला तरीका: अगर आपके OpenAPI स्पेसिफ़िकेशन में साफ़ तौर पर बताया गया था कि जवाब के मुख्य हिस्से की ज़रूरत नहीं है, लेकिन टारगेट या अपस्ट्रीम नीति से मिले जवाब में मुख्य हिस्सा शामिल था, तो नीति का पालन न करने से जुड़ी समस्या नहीं होती थी.
    • मौजूदा तरीका: इस मामले में, नीति का पालन न करने पर अब गड़बड़ी (उदाहरण: No response body is expected but one was found) दिखेगी. इससे यह पक्का किया जा सकेगा कि जवाब, तय किए गए स्कीमा के मुताबिक ही हों.

गड़बड़ी की गंभीरता को कम करना

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

  • OAS की पुष्टि करने की नीति को Source टैग के साथ कॉन्फ़िगर किया जाता है. इसे response पर सेट किया जाता है.
  • OAS Validation नीति, जवाब जनरेट करने वाली किसी अन्य नीति से मिले जवाब की पुष्टि कर रही है.

इस टूल का इस्तेमाल करने पर, आपको इस फ़ॉर्मैट में आउटपुट मिलेगा:

संगठन परिवेश आर्टफ़ैक्ट का नाम आर्टफ़ैक्ट का टाइप पुनरीक्षण नीति का नाम नीति प्रकार असर किस तरह का है इंपैक्ट से जुड़ा फ़ील्ड असर की संभावना दस्तावेज़
org2 dev proxy2 प्रॉक्सी 4 oas-validateresponse OASValidation oas_content_type_handling Source=calloutresponse मीडियम OAS की पुष्टि करने से जुड़ी नीति
org1 prod proxy3 sharedflow 1 oas-spec-validation OASValidation oas_content_type_handling Source=response मीडियम OAS की पुष्टि करने से जुड़ी नीति

आउटपुट टेबल में मौजूद कॉलम के बारे में ज़्यादा जानकारी पाने के लिए, टूल के आउटपुट को समझना सेक्शन देखें.

प्रॉक्सी या शेयर किए गए फ़्लो की पहचान होने के बाद, पक्का करें कि रिस्पॉन्स और ओएएस स्पेसिफ़िकेशन में, रिस्पॉन्स बॉडी के मौजूद होने या न होने के बारे में एक जैसी जानकारी हो. अपने ट्रैफ़िक पैटर्न की समीक्षा करने के लिए, Apigee के स्टैंडर्ड ट्रेस का इस्तेमाल किया जा सकता है. अगर टारगेट से कभी-कभी जवाब मिलता है, तो जवाब को OAS Validation नीति को पास करने से पहले, उसकी पुष्टि करने के लिए अन्य नीतियों का इस्तेमाल करें.

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

Private Cloud 4.53.01 पर अपग्रेड करने से पहले, OAS की पुष्टि करने की नीति या टारगेट बिहेवियर को ज़रूरत के मुताबिक अपडेट करें. आपको सबसे पहले अपने नॉन-प्रोडक्शन एनवायरमेंट में, ऐसे वर्कफ़्लो की पुष्टि करनी चाहिए. इससे प्रोडक्शन क्लस्टर को अपग्रेड करने के दौरान होने वाली रुकावटों के जोखिम को कम किया जा सकेगा.

JSON पाथ

कॉन्टेक्स्ट

Edge for Private Cloud 4.53.01 में, JSON पाथ एक्सप्रेशन को अलग-अलग नीतियों में इस्तेमाल करने के तरीके में बदलाव किए गए हैं. JSON कॉन्टेंट को पार्स करने या वैरिएबल में वैल्यू सेव करने के लिए, JSONPath एक्सप्रेशन का इस्तेमाल ExtractVariable नीति, RegularExpressionProtection नीति, डेटा मास्किंग जैसी नीतियों में किया जा सकता है. JSONPath एक्सप्रेशन का इस्तेमाल, सामान्य मैसेज टेंप्लेटिंग में भी किया जा सकता है. इससे प्रॉक्सी के एक्ज़ीक्यूशन के दौरान, वैरिएबल को वैल्यू से डाइनैमिक तरीके से बदला जा सकता है. नए JSONPath एक्सप्रेशन और फ़ॉर्मैट, JSON एक्सप्रेशन के नए स्टैंडर्ड के मुताबिक हैं.

बदलाव

यह ज़रूरी है कि आप उन नीतियों के लिए मौजूदा एपीआई प्रॉक्सी/शेयर्ड फ़्लो की समीक्षा करें जो JSONPath एक्सप्रेशन का इस्तेमाल करती हैं. इसमें Extract Variables नीति, Regular Expression Protection नीति या JSONPath का इस्तेमाल करने वाले मैसेज टेंप्लेट वाली कोई भी नीति शामिल है. हालांकि, इसमें और भी नीतियां शामिल हो सकती हैं.

बदलावों के बारे में बताने के लिए, यहां दिए गए JSON इनपुट का इस्तेमाल किया गया है:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}
  1. ऑब्जेक्ट वैल्यू के लिए, [*] JSONPath वाइल्डकार्ड के व्यवहार में बदलाव

    किसी JSON ऑब्जेक्ट की सभी वैल्यू ऐक्सेस करने के लिए, [*] वाइल्डकार्ड का इस्तेमाल करने पर इसके व्यवहार में बदलाव किया गया है. इससे पहले, $.object[*] फ़ंक्शन, एक JSON ऑब्जेक्ट में रैप की गई वैल्यू दिखाता था. अपडेट की गई लाइब्रेरी की मदद से, अब आउटपुट एक ऐसी सरणी होती है जिसमें ये वैल्यू शामिल होती हैं.

    उदाहरण के लिए, $.store[*]:

    पिछली गतिविधि: 
    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}
    मौजूदा व्यवहार: 
    [
  [
    {"category": "reference", "author": "Nigel Rees", "price": 8.95},
    {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
    {"category": "fiction", "author": "Herman Melville", "price": 8.99}
  ],
  {
    "color": "red",
    "book": [{"author": "Abc"}]
  }
]
    कार्रवाई:

    पहले से फ़ेच किए गए आइटम को सीधे तौर पर टारगेट करने के लिए, JSONPath एक्सप्रेशन को बदलकर सिर्फ़ पैरंट ऑब्जेक्ट (उदाहरण: $.store) को टारगेट करें.

  2. पाथ में (.) JSONPath ट्रेलिंग डॉट की वजह से गड़बड़ी हो रही है

    JSONPath एक्सप्रेशन के लिए, पुष्टि करने की प्रोसेस ज़्यादा सख्त होती है. इससे पहले, अमान्य ट्रेलिंग डॉट (उदाहरण: $.path.to.element.) पर खत्म होने वाले पाथ को अनदेखा कर दिया जाता था. साथ ही, अगर पहले का मान्य पाथ सेगमेंट मैच होता था, तो क्वेरी अब भी नतीजा दिखाती थी. नए वर्शन में, इस तरह के गलत पाथ की पहचान अब अमान्य के तौर पर की जाती है. साथ ही, इससे गड़बड़ी होती है.

    उदाहरण के लिए, $.store.book.

    पिछली गतिविधि: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"}
]
    मौजूदा व्यवहार: 
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'

    जिन मौजूदा नीतियों में JSONPath एक्सप्रेशन का इस्तेमाल किया जाता है और जिनके आखिर में अनचाहा बिंदु है वे अब InvalidPathException के साथ काम नहीं करेंगी.

    कार्रवाई:

    ऐसे JSONPath एक्सप्रेशन से आखिर में मौजूद बिंदु को हटाएं जो इससे खत्म होता है. उदाहरण के लिए, $.store.book. को $.store.book में बदलें.

  3. JSONPath रिकर्सिव डिसेंट (..) आउटपुट स्ट्रक्चर में बदलाव

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

    उदाहरण के लिए, $..book

    पिछली गतिविधि: 
    [
  {"price":8.95,"category":"reference","author":"Nigel Rees"},
  {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
  {"price":8.99,"category":"fiction","author":"Herman Melville"},
  {"author":"Abc"}
]
    मौजूदा व्यवहार: 
    [
  [
    {"category":"reference","author":"Nigel Rees","price":8.95},
    {"category":"fiction","author":"Evelyn Waugh","price":12.99},
    {"category":"fiction","author":"Herman Melville","price":8.99}
  ],
  [
    {"author":"Abc"}
  ]
]
    कार्रवाई:

    नेस्ट किए गए नए ऐरे स्ट्रक्चर के लिए, डाउनस्ट्रीम प्रोसेसिंग लॉजिक अपडेट करें. आपको हर एलिमेंट को ऐक्सेस करने के लिए, आउटर JSONArray और फिर हर इनर JSONArray को दोहराना होगा.

  4. एक से ज़्यादा आइटम चुनने या फ़िल्टर करने के बाद, JSONPath इंडेक्सिंग से खाली कलेक्शन मिलता है

    मल्टी-आइटम सिलेक्टर (जैसे: [*]) या फ़िल्टर ([?(condition)]) के तुरंत बाद इंडेक्स (उदाहरण: [0]) लागू करने पर, नतीजे अलग-अलग दिखते हैं. इससे पहले, इस तरह के एक्सप्रेशन से, मिले-जुले नतीजों में से तय किए गए इंडेक्स पर मौजूद आइटम को चुना जाता था. नए वर्शन में, ये एक्सप्रेशन अब एक खाली कलेक्शन ([]) दिखाएंगे.

    उदाहरण के लिए, $.store.book[*][0]

    पिछली गतिविधि: 
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    मौजूदा व्यवहार: 
    []
    कार्रवाई:

    अगर आपको फ़िल्टर करने के बाद, फ़िल्टर किए गए सेट से कोई खास आइटम पाना है, तो JSONPath से मिले फ़िल्टर किए गए ऐरे को प्रोसेस करें. उदाहरण के लिए, $..book[?(@.category == 'fiction')] और फिर पिछले नतीजे से [0] लें.

  5. JSONPath में नेगेटिव इंडेक्स का इस्तेमाल करके ऐरे को स्लाइस करने के आउटपुट में बदलाव

    नए वर्शन में, नेगेटिव ऐरे स्लाइसिंग (उदाहरण: [-2:], [-1:]) के तरीके में बदलाव किया गया है. पहले, किसी ऐरे पर नेगेटिव स्लाइस लागू करने पर (ऐरे के आखिर से एलिमेंट दिखाने पर), पुराना वर्शन उस स्लाइस से सिर्फ़ एक आइटम दिखाता था. नया वर्शन अब उन सभी एलिमेंट की सूची (ऐरे) को सही तरीके से दिखाता है जो तय की गई नेगेटिव रेंज में आते हैं.

    उदाहरण के लिए $.store.book[-2:]

    पिछली गतिविधि: 
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    मौजूदा व्यवहार: 
    [
  {"category":"fiction","author":"Evelyn Waugh","price":12.99},
  {"category":"fiction","author":"Herman Melville","price":8.99}
]
    कार्रवाई:

    अब डाउनस्ट्रीम प्रोसेसिंग लॉजिक को अपडेट करना होगा, ताकि JSON ऐरे को दोहराकर मनमुताबिक आउटपुट पाया जा सके.

  6. JSONPath में डॉट से पहले काफ़ी ज़्यादा वर्ण

    रूट से सीधे ऐक्सेस किए गए एलिमेंट के लिए, सिंटैक्स को ज़्यादा सख्ती से लागू किया जाता है. जब एलिमेंट को सीधे रूट से ऐक्सेस किया जाता है और उससे पहले कोई डॉट नहीं होता है (उदाहरण: $propertyelement), तो ऐसे सिंटैक्स को अब गड़बड़ी माना जाता है. इससे प्रॉक्सी डिप्लॉयमेंट नहीं हो पाएगा.

    उदाहरण के लिए $store,

    {
  "bicycle": {
    "color": "red",
    "book": [{"author": "Abc"}]
  },
  "book": [
    {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
    {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
    {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
  ]
}

    मौजूदा व्यवहार:

    Proxy will fail to deploy.

    कार्रवाई:

    अपने JSONPath में बदलाव करके, उसमें डॉट शामिल करें: $.propertyName (उदाहरण: $.store). इससे वैल्यू को सही तरीके से टारगेट किया जा सकेगा और उसे वापस पाया जा सकेगा.

  7. डाइनैमिक JSONPath एक्सप्रेशन

    उन नीतियों पर खास ध्यान दें जिनमें JSONPath एक्सप्रेशन, वैरिएबल (उदाहरण: {myJsonPathVariable} या {dynamicPath}) से मिलता है. इन वैरिएबल की वैल्यू की जांच, ऊपर बताए गए संभावित व्यवहार में होने वाले बदलावों के हिसाब से भी की जानी चाहिए.

गड़बड़ी की गंभीरता को कम करना

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

संगठन परिवेश आर्टफ़ैक्ट का नाम आर्टफ़ैक्ट का टाइप पुनरीक्षण नीति का नाम नीति प्रकार असर किस तरह का है इंपैक्ट से जुड़ा फ़ील्ड असर की संभावना दस्तावेज़
org1 dev proxy1 प्रॉक्सी 4 EV-ExtractRequestParams ExtractVariables ऑब्जेक्ट वैल्यू के लिए JSONPath वाइल्डकार्ड [*] के काम करने के तरीके में बदलाव $.store[*] उच्च ऑब्जेक्ट वैल्यू के लिए JSONPath वाइल्डकार्ड [*] के काम करने के तरीके में बदलाव
org2 prod proxy2 sharedflow 1 EV-ExtractResponseParams ExtractVariables पाथ में JSONPath के आखिर में मौजूद डॉट (.) की वजह से अब गड़बड़ी होती है $.store.book. उच्च पाथ में JSONPath के आखिर में मौजूद डॉट (.) की वजह से गड़बड़ी होती है
org3 dev proxy3 प्रॉक्सी 3 SC-FetchUserProfile ServiceCallout JSONPath Recursive Descent (..) के आउटपुट स्ट्रक्चर में बदलाव $..book उच्च JSONPath रिकर्सिव डिसेंट (..) के आउटपुट स्ट्रक्चर में बदलाव
org4 prod proxy4 sharedflow 2 RF-InvalidAuthToken RaiseFault एक से ज़्यादा आइटम चुनने या फ़िल्टर करने के बाद, JSONPath इंडेक्सिंग अब खाली कलेक्शन दिखाती है $.store.book[*][0] उच्च एक से ज़्यादा आइटम चुनने या फ़िल्टर करने के बाद, JSONPath इंडेक्सिंग से खाली कलेक्शन मिलता है
org5 जांच proxy5 प्रॉक्सी 6 SC-FetchProfileDetails ServiceCallout JSONPath नेगेटिव ऐरे स्लाइसिंग आउटपुट में बदलाव $.store.book[-2:] उच्च JSONPath में नेगेटिव इंडेक्स का इस्तेमाल करके ऐरे को स्लाइस करने के आउटपुट में बदलाव
org6 prod proxy6 प्रॉक्सी 2 ML-LogRequestDetails MessageLogging JSONPath Stricter Preceding Dot $store उच्च JSONPath में पहले आने वाले डॉट के लिए ज़्यादा सख्त नियम
org7 जांच proxy7 प्रॉक्सी 5 RF-InvalidTokenDetails RaiseFault डाइनैमिक JSONPath एक्सप्रेशन myJsonPathVariable मीडियम डाइनैमिक JSONPath एक्सप्रेशन

ऊपर दी गई आउटपुट टेबल में मौजूद कॉलम के बारे में ज़्यादा जानकारी पाने के लिए, टूल के आउटपुट को समझना सेक्शन देखें.

इससे बचने के लिए, एक पूरी रणनीति बनाना ज़रूरी है. इस प्रोसेस में, अपडेट करने का सही तरीका तय करना और पता लगाए गए JSONPath एक्सप्रेशन के लिए ज़रूरी सुधार लागू करना शामिल है.

अपग्रेड करने का वह तरीका चुनें जो आपके लिए सबसे सही हो:

  • बिना किसी डाउनटाइम के माइग्रेशन

    इस रणनीति में, एक या उससे ज़्यादा नए एनवायरमेंट हासिल करना शामिल है, ताकि आप अलग-अलग मैसेज प्रोसेसर नोड को इससे कनेक्ट कर सकें. ऐसे मैसेज प्रोसेसर नोड को 4.53.01 वर्शन इंस्टॉल करने के लिए सेट किया जा सकता है. साथ ही, इनमें मॉडर्न JSONPath एक्सप्रेशन वाली प्रॉक्सी होती हैं. इनका इस्तेमाल अपग्रेड के दौरान किया जा सकता है. अपग्रेड पूरा होने के बाद, इन्हें बंद किया जा सकता है. यह रणनीति बिना किसी रुकावट के काम करती है. हालांकि, इसमें अपग्रेड को आसानी से पूरा करने के लिए, कुछ समय के लिए मैसेज-प्रोसेसर के अतिरिक्त नोड हासिल करने पड़ते हैं. इसकी जानकारी यहां दी गई है:

    • एक नया एनवायरमेंट बनाएं. इसके बाद, इस नए एनवायरमेंट में वर्शन 4.53.01 के नए मैसेज-प्रोसेसर नोड जोड़ें.
    • जिन प्रॉक्सी पर असर पड़ा है उनके लिए, नए एनवायरमेंट में प्रॉक्सी बंडल अपलोड करें. साथ ही, समस्या हल करने के सेक्शन में बताए गए ज़रूरी सुधार लागू करें और अपडेट किए गए प्रॉक्सी बंडल को नए एनवायरमेंट में डिप्लॉय करें.
    • ट्रैफ़िक को नए एनवायरमेंट पर रीडायरेक्ट करें और पुराने एनवायरमेंट से उन प्रॉक्सी को अन-डिप्लॉय करें जिन पर असर पड़ा है.
    • ओरिजनल मैसेज प्रोसेसर नोड को 4.53.01 पर अपग्रेड करें. ऐसे प्रॉक्सी डिप्लॉय करें जिनमें ओरिजनल एनवायरमेंट में JSONPath से जुड़ी समस्याओं को ठीक किया गया हो.
    • ट्रैफ़िक को वापस पुराने एनवायरमेंट पर स्विच करें. इसमें अब 4.53.01 वर्शन वाले मैसेज प्रोसेसर और नई jsonpath एक्सप्रेशन के लिए अपडेट की गई प्रॉक्सी है.
    • नए एनवायरमेंट और उससे जुड़े नोड को मिटाएं और बंद करें.
  • डाउनटाइम और अपग्रेड

    इस रणनीति में, गलत JSON पाथ एक्सप्रेशन का इस्तेमाल करके एपीआई प्रॉक्सी के लिए डाउनटाइम हासिल करना शामिल है. इसके लिए, अतिरिक्त मैसेज प्रोसेसर नोड खरीदने की ज़रूरत नहीं होती. हालांकि, इससे उन प्रॉक्सी के लिए एपीआई ट्रैफ़िक में रुकावट आती है जिन पर असर पड़ा है.

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

    Edge for Private Cloud 4.53.01 पर अपग्रेड करने से पहले, प्रॉक्सी को फिर से डिज़ाइन किया जा सकता है. किसी खास JSON पाथ एक्सप्रेशन पर भरोसा करने के बजाय, किसी दूसरे तरीके का इस्तेमाल करके भी वही नतीजा पाया जा सकता है.

    उदाहरण के लिए, अगर JSON पाथ के साथ Extract Variable Policy का इस्तेमाल किया जा रहा है, तो इस नीति को Javascript नीति से बदला जा सकता है. इससे नए वर्शन पर अपग्रेड करने से पहले, मिलता-जुलता डेटा निकाला जा सकता है. अपग्रेड पूरा होने के बाद, प्रॉक्सी को नए फ़ॉर्मैट के साथ JSON पाथ का इस्तेमाल करने के लिए वापस बदला जा सकता है.

JavaCallout में बदलाव

कॉन्टेक्स्ट

Edge for Private Cloud 4.53.00 और इससे पहले के वर्शन में, deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) नाम की एक डायरेक्ट्री होती थी. इसमें कई JAR लाइब्रेरी होती थीं. इन लाइब्रेरी का इस्तेमाल, JavaCallout नीति में Java कोड के लिए किया जा सकता था. साथ ही, इन्हें आपके कस्टम Java कोड से सीधे या किसी और तरीके से इस्तेमाल किया जा सकता था.

बदलाव

Edge for Private Cloud के वर्शन 4.53.01 में, सेवा में नहीं है डायरेक्ट्री को हटा दिया गया है. अगर आपका Java कोड ऐसी लाइब्रेरी पर निर्भर करता है, तो Java कॉलआउट का इस्तेमाल करने वाली प्रॉक्सी काम नहीं करेंगी. ऐसा तब होगा, जब मैसेज प्रोसेसर को 4.53.01 वर्शन पर अपग्रेड किया जाएगा. इस तरह की समस्याओं से बचने के लिए, मैसेज-प्रोसेसर को वर्शन 4.53.01 पर अपग्रेड करने से पहले, यहां दिया गया तरीका अपनाएं.

गड़बड़ी की गंभीरता को कम करना

  1. बदलाव का पता लगाने वाले टूल का इस्तेमाल करके या मैन्युअल तरीके से, Java Callout की नीतियों और उनसे जुड़े जार की समीक्षा करें. देखें कि क्या किसी नीति में, आपके मौजूदा मैसेज प्रोसेसर की “deprecated” डायरेक्ट्री में मौजूद लाइब्रेरी का रेफ़रंस दिया गया है.

    अगर ऊपर दी गई समस्याओं का पता लगाने के लिए, Apigee के टूल का इस्तेमाल किया जा रहा है, तो टूल एक रिपोर्ट जनरेट करेगा. यह रिपोर्ट, यहां दी गई टेबल में दिखाई गई है. खास तौर पर, यह उन नीतियों को टारगेट करता है जो Edge for Private Cloud के पुराने वर्शन की $APIGEE_ROOT/edge-message-processor/lib/deprecated डायरेक्ट्री में मौजूद JAR के बारे में बताती हैं.

    यह टूल, इस फ़ॉर्मैट में रिपोर्ट जनरेट करेगा:

    संगठन परिवेश आर्टफ़ैक्ट का नाम आर्टफ़ैक्ट का टाइप पुनरीक्षण नीति का नाम नीति प्रकार असर किस तरह का है इंपैक्ट से जुड़ा फ़ील्ड असर की संभावना दस्तावेज़
    org1 कोई नहीं कोई नहीं org-level-jar कोई नहीं कोई नहीं java-callout simple-javacallout-o1-jar-1.jar के लिए, बंद की गई लाइब्रेरी का पता चला ['Detected use of class org.apache.commons.io.FileUtils from commons-io-2.5.jar, 'Detected use of class org.apache.commons.io.input.XmlStreamReaderException from commons-io-2.5.jar'] उच्च JavaCallout में बदलाव
    org3 env3 कोई नहीं env-level-jar कोई नहीं कोई नहीं java-callout fat-javacallout-e3-jar-1.jar के लिए, बंद की गई लाइब्रेरी का पता चला ['Detected use of class org.apache.http.impl.auth.NTLMSchemeFactory from httpclient-4.5.2.jar'] उच्च JavaCallout में बदलाव
    org1 env1 p1 proxy-level-jar 1 कोई नहीं java-callout simple-javacallout-p1-jar-1.jar के लिए, बंद की गई लाइब्रेरी का पता चला ['Detected use of class org.apache.commons.lang3.builder.ToStringBuilder from commons-lang3-3.4.jar', 'Detected use of class org.apache.commons.lang3.Validate from commons-lang3-3.4.jar'] उच्च JavaCallout में बदलाव

    ऊपर दी गई आउटपुट टेबल में मौजूद कॉलम के बारे में ज़्यादा जानकारी पाने के लिए, टूल के आउटपुट को समझना सेक्शन देखें.

  2. ऐसी बंद की गई लाइब्रेरी की पहचान करने के बाद , समस्या को कम करने के लिए इनमें से कोई एक तरीका अपनाया जा सकता है.
    • संसाधन प्लेसमेंट (अगर आपके पास बंद की गई डायरेक्ट्री से कुछ जार / लाइब्रेरी हैं जिन्हें Java-Callout जार से रेफ़र किया जा रहा है, तो इसका सुझाव दिया जाता है)
      • पहचान किए गए बंद किए गए जार को, संसाधन के तौर पर अपनी ज़रूरत के हिसाब से अपलोड करें: एपीआई प्रॉक्सी का वर्शन, एनवायरमेंट या संगठन.
      • Apigee सॉफ़्टवेयर को हमेशा की तरह अपग्रेड करें.
    • मैन्युअल प्लेसमेंट (अगर आपके पास बड़ी संख्या में जार / लाइब्रेरी हैं जिन्हें Java-Callout जार से रेफ़र किया जा रहा है, तो यह तरीका इस्तेमाल करने का सुझाव दिया जाता है)
      • हर मैसेज प्रोसेसर नोड पर, $APIGEE_ROOT/data/edge-message-processor/ पाथ पर external-lib नाम की एक नई डायरेक्ट्री बनाएं.
      • पहचाने गए JAR को, बंद की गई डायरेक्ट्री से इस external-lib डायरेक्ट्री में कॉपी करें: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • पक्का करें कि Apigee उपयोगकर्ता, डायरेक्ट्री और उससे जुड़ी जार फ़ाइलों को पढ़ सकता हो: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Apigee सॉफ़्टवेयर को हमेशा की तरह अपग्रेड करें.

OpenLDAP में बदलाव

कॉन्टेक्स्ट

OpenLDAP का इस्तेमाल, Edge Private Cloud में पुष्टि करने और अनुमति देने, दोनों के लिए किया जा सकता है. Edge for Private Cloud 4.53.01 में, Apigee की ओर से शिप किए गए OpenLDAP सॉफ़्टवेयर को वर्शन 2.4 से 2.6 पर अपग्रेड किया गया था.

बदलाव

OpenLDAP 2.6 में, रिलेटिव डिस्टिंग्विश्ड नेम (आरडीएन) की सीमा करीब 241 बाइट/वर्ण है. यह सीमा तय है और इसे बदला नहीं जा सकता.

असर
  • बहुत बड़े RDN वाली एंट्री के लिए, रेप्लिकेशन या इंपोर्ट नहीं हो पाता.
  • संगठन, एनवायरमेंट, कस्टम रोल, अनुमतियां वगैरह जैसी इकाइयां बनाने की कोशिश करने पर, आपको यह गड़बड़ी का मैसेज मिल सकता है: "message": "[LDAP: error code 80 - Other]".
  • Apigee के LDAP में, 241 बाइट से ज़्यादा लंबाई वाले किसी भी डीएन पर इसका असर पड़ता है. ऐसे डीएन की वजह से, Apigee OpenLDAP सॉफ़्टवेयर को अपग्रेड नहीं किया जा सकेगा. इसलिए, अपग्रेड करने से पहले आपको ऐसे आइटम के लिए, समस्या कम करने की रणनीतियों का पालन करना होगा.

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

उदाहरण के लिए, 

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

आम तौर पर, आपके पास संगठन, एनवायरमेंट, और भूमिका के ऐसे नाम होते हैं जिनकी लंबाई इस तरह से होती है कि LDAP में RDN 241 बाइट से कम हो जाते हैं.

गड़बड़ी की गंभीरता को कम करना

4.53.01 वर्शन में अपग्रेड करने से पहले:

यहां दिए गए चरणों से, आपके मौजूदा LDAP 2.4 क्लस्टर में लंबे RDN की मौजूदगी की पुष्टि करने में मदद मिलेगी.

#1 - LDAP डेटा एक्सट्रैक्ट करना

डिस्टिंग्विश्ड नेम (डीएन) ढूंढने के लिए, ldapsearch कमांड का इस्तेमाल करें और आउटपुट को किसी फ़ाइल पर रीडायरेक्ट करें: 

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

पक्का करें कि ऊपर दी गई DN.ldif फ़ाइल में LDAP एंट्री हों.

#2 - लंबे आरडीएन की पहचान करना

बदलाव का पता लगाने वाला टूल, जनरेट की गई LDIF फ़ाइल का इस्तेमाल करके, 241 बाइट/वर्ण से ज़्यादा वाले LDAP RDN की पहचान करता है.

यह टूल, इस फ़ॉर्मैट में रिपोर्ट जनरेट करेगा:

संगठन परिवेश आर्टफ़ैक्ट का नाम आर्टफ़ैक्ट का टाइप पुनरीक्षण नीति का नाम नीति प्रकार असर किस तरह का है इंपैक्ट से जुड़ा फ़ील्ड असर की संभावना दस्तावेज़
कोई नहीं कोई नहीं cn=really-long-name,ou=userroles,o=edge-platform,ou=organizations,dc=apigee,dc=com ldif फ़ाइल कोई नहीं कोई नहीं कोई नहीं Ldap RDN में 241 से ज़्यादा वर्ण हैं cn=really-long-name उच्च OpenLDAP में बदलाव

ऊपर दी गई आउटपुट टेबल में मौजूद कॉलम के बारे में ज़्यादा जानकारी पाने के लिए, टूल के आउटपुट को समझना सेक्शन देखें.

अगर ऊपर दिए गए निर्देश से कोई आउटपुट नहीं मिलता है, तो इसका मतलब है कि मौजूदा LDAP सेटअप में कोई भी RDN, 241 बाइट/वर्ण से ज़्यादा नहीं है. अपग्रेड की प्रोसेस को सामान्य तरीके से जारी रखा जा सकता है.

अगर ऊपर दिए गए निर्देश से कोई आउटपुट जनरेट होता है, तो इसका मतलब है कि RDN की संख्या 241 बाइट/वर्ण से ज़्यादा है. ऐसे आइटम के लिए, Edge for Private Cloud 4.53.01 को अपग्रेड करने से पहले, तीसरे चरण में बताए गए तरीके से समस्या को कम करने के लिए ज़रूरी कार्रवाई करें.

#3 - Handle long RDNs

अगर दूसरे चरण में आउटपुट मिलता है, तो इसका मतलब है कि RDN की संख्या 241 बाइट/वर्ण से ज़्यादा है. इस समस्या को हल करने के लिए, यहां दिया गया तरीका अपनाएं:

241 बाइट से ज़्यादा की LDAP एंट्री की समीक्षा करें.

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

ऊपर दिए गए चरणों को तब तक दोहराएं, जब तक आपके एलडीएपी में 241 बाइट से ज़्यादा लंबाई वाले आरडीएन न हों. इस स्थिति में पहुंचने के बाद, निजी क्लाउड वर्शन को सामान्य तरीके से अपग्रेड करें.

क्रिप्टोग्राफ़ी सेवा देने वाली कंपनी में बदलाव

कॉन्टेक्स्ट

यह बदलाव, Edge for Private Cloud 4.53.00 से लिया गया है. Edge for Private Cloud 4.53.00 में, इंटरनल क्रिप्टोग्राफ़ी प्रोवाइडर को Bouncy Castle (BC) से Bouncy Castle FIPS (BCFIPS) में अपडेट किया गया है, ताकि FIPS की सुविधा चालू की जा सके.

बदलाव

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

गड़बड़ी की गंभीरता को कम करना

इस समस्या को हल करने के लिए, BCFIPS प्रोवाइडर का इस्तेमाल करने का सुझाव दिया जाता है. JavaCallout को लागू करने के लिए, पुराने प्रोवाइडर पर निर्भर रहने वाले कस्टम कोड की समीक्षा करनी होगी. साथ ही, उन्हें Bouncy Castle FIPS प्रोवाइडर का इस्तेमाल करके फिर से लागू करना होगा. इसे "BCFIPS" स्ट्रिंग का इस्तेमाल करके ऐक्सेस किया जा सकता है.

बदलाव का पता लगाने वाला टूल

बदलाव का पता लगाने वाला एक टूल बनाया गया है. इससे उन Apigee प्रॉक्सी, नीतियों, और शेयर किए गए फ़्लो का पता लगाया जा सकता है जिन पर Edge for Private Cloud 4.53.01 पर माइग्रेट करने के दौरान और बाद में असर पड़ सकता है. यह टूल, बदलावों से जुड़ी रिपोर्ट जनरेट करता है. इसमें डिप्लॉय की गई प्रॉक्सी, शेयर किए गए फ़्लो, और OpenLDAP के बारे में जानकारी होती है. साथ ही, यह टूल उन प्रॉक्सी या शेयर किए गए फ़्लो से जुड़ी खास गाइड और रणनीतियों के बारे में बताता है.

ज़रूरी शर्तें

  1. इस टूल को चलाने के लिए, RHEL पर आधारित मशीन की ज़रूरत होती है.
  2. टूल की स्क्रिप्ट चलाने के लिए, होस्ट वर्चुअल मशीन पर JRE 8 इंस्टॉल होना चाहिए और सही तरीके से कॉन्फ़िगर किया गया होना चाहिए.
  3. इस टूल को मैनेजमेंट सर्वर के सही एंडपॉइंट (यूआरएल) और पुष्टि करने के लिए मान्य एडमिन क्रेडेंशियल की ज़रूरत होती है. साथ ही, डेटा वापस पाने के लिए भी इनकी ज़रूरत होती है.
  4. इस टूल को बंडल निकालने, लॉग जनरेट करने, और आउटपुट सेव करने के लिए, तय की गई वर्किंग डायरेक्ट्री (जैसे,/tmp) का ऐक्सेस चाहिए. पक्का करें कि इस डायरेक्ट्री में डिस्क स्पेस मौजूद हो और पढ़ने/लिखने की अनुमतियां सही हों.
  5. इस टूल को OpenLDAP change - Extract LDAP data सेक्शन में ldapsearch कमांड का इस्तेमाल करके, LDIF फ़ाइल की ज़रूरत होती है. इससे 241 वर्णों / बाइट से ज़्यादा वाले लंबे आरडीएन का पता लगाया जा सकता है.

टूल का इस्तेमाल करना

ऊपर बताई गई सभी ज़रूरी शर्तें पूरी करने के बाद, टूल डाउनलोड करें. साथ ही, Apigee का वह उपयोगकर्ता नाम और पासवर्ड डालें जिसका इस्तेमाल Apigee रिपॉज़िटरी को ऐक्सेस करने के लिए किया जाता है. डाउनलोड हो जाने के बाद, डाउनलोड किए गए संग्रह को एक्स्ट्रैक्ट करें.

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.0.zip -o /tmp/change-detector-for-4.53.01_1.0.0.zip
 
unzip /tmp/change-detector-for-4.53.01_1.0.0.zip

डाउनलोड पूरा होने के बाद, टूल के लिए उपलब्ध सभी विकल्प देखने के लिए, यह कमांड चलाएं:

./change-detector --help

टूल चलाने के लिए, इस निर्देश का इस्तेमाल करें और प्लेसहोल्डर को अपनी जानकारी से बदलें:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

बड़ी RDN LDAP एंट्री का पता लगाने के लिए, यह कमांड चलाएं:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

यह टूल, आउटपुट को json या csv फ़ॉर्मैट में जनरेट करता है. इसे सीधे तौर पर इस्तेमाल किया जा सकता है या Google Sheets जैसे टूल में इंपोर्ट किया जा सकता है.

टूल के आउटपुट को समझना

संगठन

इससे उस संगठन का नाम पता चलता है जहां आर्टफ़ैक्ट मौजूद है. OpenLDAP में बदलाव करने के लिए, यह None होगा.

परिवेश

संगठन के अंदर मौजूद कोई खास एनवायरमेंट (जैसे, dev, test, prod). OpenLDAP में बदलाव करने के लिए, यह None होगा.

Java Callout में किए गए बदलावों के लिए, अगर आर्टफ़ैक्ट टाइप=env-level-jar है, तो यह फ़ील्ड None होगा.

आर्टफ़ैक्ट का नाम

इस फ़ील्ड से, प्रॉक्सी/शेयर किए गए फ़्लो के नाम के बारे में पता चलता है. OpenLDAP में बदलाव करने पर, यह फ़ील्ड RDN की LDAP इकाई दिखाता है.

Java Callout में बदलाव करने के लिए, अगर Artifact Type=env-level-jar या org-level-jar है, तो यह फ़ील्ड None होगा.

आर्टफ़ैक्ट का टाइप

  • OAS और JSON में किए गए बदलावों के लिए, यह कॉलम आर्टफ़ैक्ट, प्रॉक्सी या शेयर किए गए फ़्लो के टाइप के बारे में बताता है.
  • Java कॉलआउट में हुए बदलाव के लिए, यह कॉलम उस जगह या लेवल के बारे में जानकारी देता है जहां असर डालने वाली JAR फ़ाइल अपलोड की गई है. JAR फ़ाइलों को तीन में से किसी एक लेवल पर सेव किया जा सकता है: org-level, env-level, proxy-level.
  • OpenLDAP में बदलाव करने के लिए, यह फ़ील्ड टूल में इस्तेमाल की गई LDIF फ़ाइल के बारे में बताता है.

पुनरीक्षण

यह उस प्रॉक्सी/शेयर किए गए फ़्लो के डिप्लॉय किए गए वर्शन की ओर इशारा करता है जिस पर असर पड़ा है. OpenLDAP में बदलाव करने के लिए, यह None होगा.

नीति का नाम

उस नीति का नाम जिसे संभावित समस्या के तौर पर पहचाना गया है. OpenLDAP में बदलाव करने के लिए, यह None होगा.

नीति का टाइप

इससे नीति के टाइप के बारे में पता चलता है. OpenLDAP में बदलाव करने के लिए, यह None होगा.

असर किस तरह का है

  • इस फ़ील्ड में, प्रॉक्सी/शेयर किए गए फ़्लो में पता चले बदलाव के टाइप के बारे में बताया गया है.
  • Java कॉलआउट में बदलाव के लिए, java-callout से जुड़े बदलावों का पता लगाने के लिए, यह टूल उस java-callout की ओर इशारा करता है जिस पर असर पड़ा है. इसमें इस कॉलम में, Edge for Private Cloud के पुराने वर्शन की $APIGEE_ROOT/edge-message-processor/lib/deprecated डायरेक्ट्री में मौजूद JAR के रेफ़रंस होते हैं.
    • deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR
  • OpenLDAP में बदलाव करने पर, यह फ़ील्ड दिखाता है कि क्या किसी LDAP इकाई का RDN, 241 बाइट या वर्णों से ज़्यादा है.

किसी फ़ील्ड पर असर

  • ओएएस में बदलाव के लिए, यह फ़ील्ड उस वैरिएबल का नाम है जिसका इस्तेमाल नीति के सोर्स टैग में किया जाता है.
  • JSON में हुए बदलाव के लिए, यह फ़ील्ड उस JSONPath एक्सप्रेशन या एलिमेंट को दिखाता है जिसे संभावित समस्या के तौर पर फ़्लैग किया गया है.
  • Java Callout में बदलाव के लिए, इस फ़ील्ड में उन क्लास की जानकारी होती है जिन पर असर पड़ा है. साथ ही, इसमें उस JAR का नाम भी होता है जिसका इस्तेमाल किया गया है या जिसे रेफ़र किया गया है. यह JAR, Private Cloud के पुराने वर्शन की $APIGEE_ROOT/edge-message-processor/lib/deprecated डायरेक्ट्री में मौजूद होता है. अगर इस समस्या को ठीक नहीं किया जाता है, तो वर्शन 4.53.01 पर अपग्रेड करने के बाद, JavaCallout jar काम नहीं करेगा.
    •  ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
    Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
  .. , .. , ]
  • OpenLDAP में बदलाव करने पर, यह फ़ील्ड LDAP इकाई का RDN दिखाता है. यह 241 बाइट या वर्णों से ज़्यादा होता है.

असर की पुष्टि

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

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

  • JavaCallout और OpenLDAP में हुए बदलावों से जुड़ी समस्याओं का पता लगाने पर, असर की संभावना वाले कॉलम के लिए हमेशा High वैल्यू दिखेगी.

दस्तावेज़

इस कॉलम में, Apigee के दस्तावेज़ (इस लेख के काम के सेक्शन) का हाइपरलिंक दिया गया है. इसमें समस्या और उसे कम करने के तरीके के बारे में बताया गया है.