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

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

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

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

Edge for Private Cloud 4.54.00 में, वर्शन 4.53.01 में उपलब्ध तीन सुविधाएं काम नहीं करती हैं. अपग्रेड करने से पहले, 4.54.00 वर्शन में काम न करने वाली सुविधाएं देखें.

ऐसी सुविधाएं जो 4.54.00 वर्शन में काम नहीं करतीं

Edge for Private Cloud 4.54.00 में ये सुविधाएं काम नहीं करती हैं. हालांकि, ये सुविधाएं 4.53.01 वर्शन में उपलब्ध हैं. अगर आपके डिप्लॉयमेंट में इनमें से किसी भी सुविधा का इस्तेमाल किया जाता है, तो 4.54.00 वर्शन पर अपग्रेड न करें. वर्शन 4.53.01 पर बने रहें और Apigee की सहायता टीम से संपर्क करें.

  • Google Distributed Cloud (GDC) के एयर-गैप्ड एनवायरमेंट पर इंस्टॉल करना. Edge for Private Cloud 4.54.00 को एयर-गैप वाले GDC एनवायरमेंट के लिए सर्टिफ़िकेट नहीं मिला है. वर्शन 4.53.01 की प्रोसेस के लिए, Google Distributed Cloud air-gapped पर Apigee इंस्टॉल करना लेख पढ़ें.
  • FIPS की सुविधा वाला RHEL 8.X या Rocky 8.X. Edge for Private Cloud 4.54.00 को FIPS की सुविधा वाले RHEL 8.X या Rocky 8.X होस्ट पर इंस्टॉल नहीं किया जा सकता. ये ऑपरेटिंग सिस्टम तब काम करते हैं, जब एफ़आईपीएस मोड चालू न हो. वर्शन 4.54.00 के कॉन्फ़िगरेशन विषयों में, एफ़आईपीएस से जुड़े दिशा-निर्देश भी शामिल नहीं हैं. ये दिशा-निर्देश वर्शन 4.53.01 में दिए गए हैं. इनमें बीसीएफ़केएस कीस्टोर तैयार करना, FIPS_OS साइलेंट कॉन्फ़िगरेशन प्रॉपर्टी, और पीकेसीएस12 कीस्टोर कॉन्फ़िगरेशन शामिल हैं. वर्शन 4.53.01 के लिए दिशा-निर्देश पाने के लिए, FIPS की सुविधा वाले RHEL 8.X या Rocky 8.X पर Edge for Private Cloud देखें.
  • साउथबाउंड हार्डवेयर सिक्योरिटी मॉड्यूल (एचएसएम) इंटिग्रेशन. Edge for Private Cloud 4.54.00, मैसेज प्रोसेसर से बैकएंड टारगेट सेवाओं तक साउथबाउंड टीएलएस कनेक्शन के साथ काम नहीं करता. ये सेवाएं, Entrust nShield नेटवर्क एचएसएम का इस्तेमाल करती हैं. वर्शन 4.53.01 की प्रोसेस के लिए, Apigee Edge for Private Cloud के लिए साउथबाउंड हार्डवेयर सिक्योरिटी मॉड्यूल इंटिग्रेशन गाइड देखें.

Java कॉलआउट की नीति में बदलाव

Edge for Private Cloud 4.54.00 में, मुख्य प्लैटफ़ॉर्म कॉम्पोनेंट को Java 21 LTS पर चलाने के लिए अपडेट किया गया है. इनमें मैसेज प्रोसेसर, मैनेजमेंट सर्वर, और राऊटर शामिल हैं. Java 21, Java प्लैटफ़ॉर्म को आधुनिक बनाता है. इसमें लेगसी Java EE और CORBA मॉड्यूल (जेईपी 320) को हटाना, लेगसी इंटरनल यूटिलिटी क्लास को हटाना, और मज़बूत मॉड्यूलर एनकैप्सुलेशन (जेईपी 403) को लागू करना शामिल है.

इन बदलावों की वजह से, कस्टम JavaCallout नीतियों या कस्टम रिसोर्स JAR (प्रॉक्सी, एनवायरमेंट या संगठन के लेवल पर सेव किए गए) वाले एपीआई प्रॉक्सी को 4.54.00 वर्शन पर अपग्रेड करने पर, रुकावट आ सकती है.

बदलावों की ऐसी कैटगरी जिनसे Java कॉलआउट पर असर पड़ सकता है

  1. Java EE और CORBA मॉड्यूल को हमेशा के लिए हटा दिया गया है (JEP 320): Java 8 रनटाइम में पहले से मौजूद मॉड्यूल (इनमें JAXB javax.xml.bind.*, JAF javax.activation.*, JAX-WS javax.xml.ws.*, और CORBA org.omg.* शामिल हैं) को Java SE से हटा दिया गया है. इन पैकेज का रेफ़रंस देने वाले कॉलआउट, रनटाइम के दौरान NoClassDefFoundError के साथ काम नहीं करते. ऐसा तब होता है, जब स्टैंडअलोन रिप्लेसमेंट को बंडल न किया गया हो.
  2. इंटरनल यूटिलिटी क्लास हटा दी गई हैं: लेगसी इंटरनल हेल्पर, जैसे कि sun.misc.BASE64Encoder और sun.misc.BASE64Decoder को हटा दिया गया है. इन क्लास को कॉल करने वाले कॉलआउट, NoClassDefFoundError के साथ काम नहीं करते.
  3. Java के इंटरनल पैकेज का एन्कैप्सुलेशन (JEP 403): java.base में मौजूद इंटरनल पैकेज (जैसे, sun.security.*, sun.reflect.*, और com.sun.*) को कस्टम कॉलआउट से ऐक्सेस नहीं किया जा सकता. रिफ़्लेक्टिव कॉल, रनटाइम के दौरान InaccessibleObjectException के साथ काम नहीं करते.
  4. Java की मौजूदा क्लास में, मेथड सिग्नेचर में बदलाव करना और उन्हें हटाना: Java के कुछ मॉड्यूल में, क्लास Java 21 में मौजूद रहती है. हालांकि, कुछ खास कंस्ट्रक्टर या मेथड सिग्नेचर हटा दिए गए हैं, अब काम नहीं करते या उनमें बदलाव कर दिया गया है. जैसे, org.w3c.dom.Document में डीओएम को पार्स करने के कुछ खास तरीके और एक्सएमएल को पार्स करने वाली क्लास.

    टूल की मदद से पता लगाना: बदलाव का पता लगाने वाला टूल, METHOD_SIGNATURE_MODIFICATION कैटगरी में इन क्लास के रेफ़रंस को फ़्लैग करता है. साथ ही, MEDIUM असर की संभावना के बारे में बताता है. इससे डेवलपर को अपने कॉलआउट के सोर्स कोड की जांच करने के लिए बढ़ावा मिलता है, ताकि वे बदले गए तरीके के कॉल का पता लगा सकें.

समस्या को हल करने की रणनीतियां

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

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

रणनीति 3A, 3B, और 3C, एक ही ऑपरेशनल तरीके को लागू करने के तीन तरीके हैं: प्रॉक्सी बंडल में बदलाव किए बिना, नोड को अपग्रेड करना और प्रॉक्सी को अलग-अलग समय पर फिर से डिप्लॉय करना. एपीआई की उपलब्धता से जुड़ी अपनी ज़रूरतों के हिसाब से, इनमें से कोई एक या एक से ज़्यादा विकल्प चुनें.

डिप्लॉयमेंट के लिए सबसे सही तरीका चुनने के लिए, यहां दी गई गाइड देखें:

Java कॉलआउट से जुड़ी समस्याओं को कम करने के लिए गाइड:

क्या प्रॉक्सी बंडल को अपडेट और फिर से डिप्लॉय करना ज़रूरी है? स्थिति या ज़रूरत सुझाई गई रणनीति इससे क्या फ़ायदा होता है मुख्य सीमाएं
हां (सिर्फ़ बंडल अपडेट) दोनों के साथ काम करने वाली लाइब्रेरी मौजूद है; डाउनटाइम की ज़रूरत नहीं है पहली रणनीति: बंडल किए गए JARs के ज़रिए, दोनों के साथ काम करने वाला प्रॉक्सी यह सुविधा, अलग-अलग वर्शन में मौजूद लाइब्रेरी को बिना किसी डाउनटाइम के वापस लाती है इसके लिए, ड्यूअल-कंपैटिबल स्टैंडअलोन लाइब्रेरी उपलब्ध होनी चाहिए. साथ ही, 4.54.00 में conf_system_java.21.enable.external.allowed.packages=true को चालू करना ज़रूरी है
हां (सोर्स कोड में बदलाव करना) सोर्स कोड को बनाए रखा गया है; लंबे समय तक चलने वाला समाधान चाहिए दूसरी रणनीति: कोड और डिपेंडेंसी को मॉडर्न बनाना हटाए गए क्लास और इंटरनल एपीआई डिपेंडेंसी को हमेशा के लिए ठीक करता है इसके लिए, सोर्स कोड में बदलाव करने और उसे फिर से डिप्लॉय करने की ज़रूरत होती है. साथ ही, रोल आउट करने के लिए रणनीति 3A या 3B के साथ जोड़ना ज़रूरी है
नहीं (ऑपरेशनल अप्रोच) शेड्यूल की गई मेंटेनेंस विंडो की अनुमति रणनीति 3A: रखरखाव के लिए तय किया गया डाउनटाइम (इन-प्लेस रीडिप्लॉयमेंट) इससे पहले नोड को अपग्रेड किया जा सकता है. इसके बाद, अपडेट की गई प्रॉक्सी को डिप्लॉय किया जा सकता है एपीआई का इस्तेमाल करने वाले लोगों के लिए, डाउनटाइम शेड्यूल करना ज़रूरी है
नहीं (ऑपरेशनल अप्रोच) डाउनटाइम की ज़रूरत नहीं है; दो JAR को बंडल नहीं किया जा सकता रणनीति 3B: नया एनवायरमेंट बनाना (बिना डाउनटाइम के माइग्रेशन) माइग्रेशन के दौरान, 4.53 और 4.54 नोड को अलग करता है. इससे ट्रैफ़िक में कोई रुकावट नहीं आती इसके लिए, कुछ समय के लिए मैसेज प्रोसेसर नोड की ज़रूरत होती है
नहीं (ऑपरेशनल अप्रोच) अपग्रेड करने से पहले, प्रॉक्सी बंडल में बदलाव नहीं किया जा सकता * रणनीति 3C: नोड-लेवल पर external-lib प्लेसमेंट यह प्रॉक्सी बंडल में बदलाव किए बिना, पूरे नोड में मौजूद लाइब्रेरी के JAR उपलब्ध कराता है नोड पर मौजूद सभी प्रॉक्सी के साथ शेयर किया जाता है. इससे रिफ़्लेक्शन या java.* पैकेज की समस्या हल नहीं होती
नहीं (क्लोज़्ड-सोर्स वाली तीसरे पक्ष की लाइब्रेरी) तीसरे पक्ष के वेंडर की ऐसी लाइब्रेरी जो Java के इंटरनल पर रिफ़्लेक्शन का इस्तेमाल करती हैं * चौथी रणनीति: जेवीएम फ़्लैग (--add-opens / --add-exports) यह इंटरनल Java पैकेज के लिए, रिफ़्लेक्शन से जुड़ी पाबंदियों में छूट देता है हटाई गई क्लास या तरीकों को वापस नहीं लाया जा सकता. यह नोड-वाइड पर लागू होता है

पहली रणनीति: बंडल किए गए JAR के ज़रिए, दोनों के साथ काम करने वाला प्रॉक्सी (डाउनटाइम से बचने के लिए, अपग्रेड करने से पहले टेस्ट करें)

इसका इस्तेमाल कब करें: इस रणनीति का इस्तेमाल तब करें, जब:

  • दोनों के साथ काम करने वाली एक स्टैंडअलोन रिप्लेसमेंट लाइब्रेरी उपलब्ध है: एक रिप्लेसमेंट JAR मौजूद है, जो ज़रूरी फ़ंक्शन को लागू करता है. इसे सोर्स कोड में बदलाव किए बिना, सीधे आपके एपीआई प्रॉक्सी में बंडल किया जा सकता है.
  • आपको अपने मौजूदा एपीआई प्रॉक्सी और Java कॉलआउट को अपने मौजूदा वर्शन (उदाहरण के लिए, Edge for Private Cloud 4.53.01) और अपग्रेड किए गए वर्शन (Edge for Private Cloud 4.54.00), दोनों पर आसानी से इस्तेमाल करना है.
  • आपको Edge for Private Cloud क्लस्टर को अपग्रेड करने से पहले, अपने स्टेजिंग और प्रोडक्शन एनवायरमेंट में किए गए सभी बदलावों की जांच और पुष्टि करनी है. इससे यह पक्का किया जा सकेगा कि लाइव ट्रैफ़िक में कोई अनचाही समस्या न आए और डाउनटाइम न हो.
  • आपको Java कॉलआउट के कारोबारी नियम को फिर से लिखने या रीफ़ैक्टर करने से बचना है.

यह कैसे काम करता है: Java 8 में, कुछ लाइब्रेरी (जैसे, JAXB javax.xml.bind.* या Activation javax.activation.*) सीधे Java 8 रनटाइम में बनाई गई थीं. इस वजह से, डेवलपर को अपने प्रॉक्सी बंडल में अतिरिक्त JAR फ़ाइलें शामिल करने की ज़रूरत नहीं पड़ती थी. Java 21 में, इन लाइब्रेरी को Java रनटाइम से हटा दिया गया था.

Edge for Private Cloud 4.53.x और 4.54.00 के लिए, अपनी प्रॉक्सी को "दोनों के साथ काम करने वाली" बनाने के लिए:

  1. अपने कॉलआउट के लिए ज़रूरी लाइब्रेरी की पहचान करें. उदाहरण के लिए, JAXB या Activation.
  2. अलग से मौजूद ओपन-सोर्स रिप्लेसमेंट JAR (उदाहरण के लिए, jakarta.xml.bind-api-2.3.3.jar और jaxb-runtime-2.3.8.jar) को डाउनलोड करें.
  3. रिप्लेसमेंट JAR को सीधे apiproxy/resources/java/ में मौजूद प्रॉक्सी बंडल में डालें या प्रॉक्सी-लेवल की रिसॉर्स फ़ाइलें एपीआई का इस्तेमाल करके, इसे प्रॉक्सी रिविज़न में अपलोड करें. इसके अलावा, इसे एनवायरमेंट लेवल या संगठन लेवल पर रिसॉर्स फ़ाइल के तौर पर अपलोड करें. संसाधन फ़ाइलों को मैनेज करने के बारे में ज़्यादा जानने के लिए, Apigee संसाधन फ़ाइलों का दस्तावेज़ देखें.
  4. अपग्रेड करने से पहले डिप्लॉय और टेस्ट करना: Edge for Private Cloud 4.53.x और 4.54.00, दोनों में मौजूद मैसेज प्रोसेसर, इन बंडल किए गए JAR से क्लास लोड करते हैं. इस अपडेट किए गए प्रॉक्सी बंडल को डिप्लॉय किया जा सकता है. साथ ही, इसे अपने मौजूदा Edge for Private Cloud 4.53.x क्लस्टर में सिंथेटिक ट्रैफ़िक के साथ टेस्ट किया जा सकता है.
  5. मैसेज प्रोसेसर पर, बाहरी पैकेज लोड करने की अनुमति दें (4.54.00 के लिए ज़रूरी है): Edge for Private Cloud 4.54.00 में, बाहरी या बंडल किए गए संसाधन JAR से हटाए गए Java पैकेज (जैसे, javax.xml.bind.* और javax.activation.*) लोड करने की सुविधा डिफ़ॉल्ट रूप से बंद (conf_system_java.21.enable.external.allowed.packages=false) होती है. इसलिए, सिर्फ़ JAR को बंडल करने से डिफ़ॉल्ट रूप से काम नहीं चलेगा. आपको कॉन्फ़िगरेशन के साथ कोड (सीडब्ल्यूसी) का इस्तेमाल करके, /opt/apigee/customer/application/message-processor.properties में इस प्रॉपर्टी को चालू करना होगा. इस प्रॉपर्टी को मैसेज प्रोसेसर नोड को अपग्रेड करने से पहले कॉन्फ़िगर किया जा सकता है या अपग्रेड करने के बाद सेट किया जा सकता है. इसके बाद, मैसेज प्रोसेसर को रीस्टार्ट करें: 
    conf_system_java.21.enable.external.allowed.packages=true
  6. अपग्रेड के बाद लाइव ट्रैफ़िक से जुड़ी कोई समस्या नहीं आती: जब आपके क्लस्टर को conf_system_java.21.enable.external.allowed.packages=true चालू करके, Edge for Private Cloud 4.54.00 पर अपग्रेड किया जाता है, तो मैसेज प्रोसेसर के पास पहले से ही ज़रूरी JAR उपलब्ध होता है. साथ ही, वह बिना किसी गड़बड़ी (NoClassDefFoundError) के बंडल की गई रिसॉर्स फ़ाइल से क्लास लोड करता है. इससे, बिना किसी डाउनटाइम के आसानी से अपग्रेड किया जा सकता है.

कोड का उदाहरण: ऑर्डर के एक्सएमएल की पुष्टि और पार्सिंग कॉलआउट

एक सामान्य Apigee Java कॉलआउट पर विचार करें, जो JAXB (JAXBContext और Unmarshaller) का इस्तेमाल करके, इनकमिंग एक्सएमएल ऑर्डर को निकालता है और उनकी पुष्टि करता है.

  • समस्या ठीक होने से पहले (Edge for Private Cloud 4.54.00 में काम नहीं करता): Edge for Private Cloud 4.53.x में, प्रॉक्सी बंडल में सिर्फ़ कॉलआउट JAR होता है. यह JAXB के लिए, पहले से मौजूद Java 8 रनटाइम लाइब्रेरी पर निर्भर करता है: 
    apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar   <-- No JAXB JAR bundled

    Java कॉलआउट को लागू करने का तरीका:

    package com.example.callout;

// other required imports
import java.io.StringReader;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.Unmarshaller;

public class OrderXmlParserCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        try {
            String requestXml = messageContext.getMessage().getContent();
            JAXBContext jaxbContext = JAXBContext.newInstance(Order.class);
            Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
            Order order = (Order) unmarshaller.unmarshal(new StringReader(requestXml));
            messageContext.setVariable("order_id", order.getId());
            return ExecutionResult.SUCCESS;
        } catch (Exception e) { }
    }
}

    गड़बड़ी: Edge for Private Cloud 4.53.x में, यह बिना किसी समस्या के काम करता है. नोड को Edge for Private Cloud 4.54.00 पर अपग्रेड करने के बाद, अनुरोध को प्रोसेस करने के दौरान यह प्रॉक्सी तुरंत काम करना बंद कर देती है:

    java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
        at com.example.callout.OrderXmlParserCallout.execute(OrderXmlParserCallout.java:20)
  • समस्या ठीक होने के बाद (Edge for Private Cloud 4.53.x और 4.54.00, दोनों के साथ काम करता है): आपको Java कॉलआउट कोड को फिर से लिखने या फिर से कंपाइल करने की ज़रूरत नहीं है. स्टैंडअलोन JAR उपलब्ध कराकर, प्रॉक्सी को सीधे तौर पर दोनों के साथ काम करने लायक बनाया जा सकता है:
    1. स्टैंडअलोन JAR को सीधे बंडल या अपलोड करें: स्टैंडअलोन JAXB लाइब्रेरी (jakarta.xml.bind-api-2.3.3.jar और jaxb-runtime-2.3.8.jar) पाएं और उन्हें apiproxy/resources/java/ में अपने प्रॉक्सी बंडल में रखें: 
      apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar
      jakarta.xml.bind-api-2.3.3.jar
      jaxb-runtime-2.3.8.jar

      इसके अलावा, प्रॉक्सी-लेवल की रिसॉर्स फ़ाइलें एपीआई का इस्तेमाल करके, jakarta.xml.bind-api-2.3.3.jar और jaxb-runtime-2.3.8.jar को रिसॉर्स फ़ाइलों के तौर पर अपलोड करें. इसके अलावा, उन्हें एनवायरमेंट लेवल या संगठन लेवल पर भी अपलोड किया जा सकता है, ताकि एक ही स्कोप में मौजूद सभी प्रॉक्सी, उन्हें हर प्रॉक्सी बंडल में बंडल किए बिना शेयर कर सकें.

      अगर Maven का इस्तेमाल करके, सोर्स से प्रॉक्सी बंडल बनाया जाता है, तो इन डिपेंडेंसी को अपने pom.xml में शामिल करें. इससे, बिल्ड के दौरान ये अपने-आप पैकेज हो जाएंगी.

    2. अपने मौजूदा 4.53.x क्लस्टर पर डिप्लॉय और टेस्ट करें: अपडेट किए गए प्रॉक्सी बंडल को अपने मौजूदा Edge for Private Cloud 4.53.x एनवायरमेंट में डिप्लॉय करें और टेस्ट कॉल भेजें. Edge for Private Cloud 4.53.x के मैसेज प्रोसेसर, इन बंडल किए गए JAR से क्लास लोड करते हैं. इसलिए, यह पुष्टि की जा सकती है कि कॉलआउट पहले की तरह ही काम करता रहेगा.
    3. CwC की मदद से, अनुमति वाले बाहरी पैकेज लोड करने की सुविधा चालू करना: Edge for Private Cloud 4.54.00 (conf_system_java.21.enable.external.allowed.packages=false) में, अनुमति वाले बाहरी पैकेज लोड करने की सुविधा डिफ़ॉल्ट रूप से बंद होती है. इसलिए, /opt/apigee/customer/application/message-processor.properties में मौजूद हर मैसेज प्रोसेसर नोड पर, कोड विद कॉन्फ़िगरेशन (CwC) का इस्तेमाल करके इसे चालू करें: 
      conf_system_java.21.enable.external.allowed.packages=true
    4. अपग्रेड के बाद, लाइव ट्रैफ़िक से जुड़ी कोई समस्या नहीं आती: 4.53.x एनवायरमेंट में पुष्टि होने और CwC प्रॉपर्टी के साथ कॉन्फ़िगर होने के बाद, आपकी प्रॉक्सी पूरी तरह से तैयार हो जाती है. जब क्लस्टर को Edge for Private Cloud 4.54.00 पर अपग्रेड किया जाता है, तो मैसेज प्रोसेसर, बंडल की गई JAXB क्लास लोड करता है. इससे यह पक्का होता है कि कोई गड़बड़ी न हो और लाइव ट्रैफ़िक में कोई रुकावट न आए.

दूसरी रणनीति: कोड और डिपेंडेंसी को आधुनिक बनाना

कब इस्तेमाल करें: इसका सुझाव उन ऐक्टिव कोड बेस के लिए दिया जाता है जहां प्रॉक्सी सोर्स कोड को आसानी से मैनेज किया जा सकता है. Java 21 के साथ काम करने के लिए, यह सबसे सही और लंबे समय तक चलने वाला तरीका है. रोलआउट नोट: प्रॉक्सी के आधुनिक बदलावों को डिप्लॉय करने के लिए, मैसेज प्रोसेसर के साथ मिलकर काम करना ज़रूरी है. इसलिए, इस रणनीति को रणनीति 3A (तय किए गए मेंटेनेंस विंडो के दौरान) या रणनीति 3B (पैरलल मैसेज प्रोसेसर के साथ ज़ीरो डाउनटाइम हासिल करने के लिए) के साथ जोड़ें.

यह कैसे काम करता है: हटाई गई Java इंटरनल क्लास को आधिकारिक स्टैंडर्ड Java SE एपीआई या ओपन-सोर्स स्टैंडअलोन क्लास से बदलें. साथ ही, तीसरे पक्ष की ज़रूरी डिपेंडेंसी को सीधे अपने प्रॉक्सी बंडल की रिसॉर्स फ़ाइलों या POM में पैकेज करें.

कोड के उदाहरण:

पहला उदाहरण: तरीके और कोड को आधुनिक बनाना (हटाए गए इंटरनल यूटिलिटी को बदलना)

Java 8 में, कॉलआउट अक्सर sun.misc.BASE64Encoder जैसी इंटरनल यूटिलिटी क्लास का इस्तेमाल करते थे. Java के आधुनिक वर्शन में, इन क्लास को हटा दिया गया था. हालांकि, स्टैंडर्ड java.util.Base64 एपीआई, बाहरी डिपेंडेंसी JAR की ज़रूरत के बिना, सीधे तौर पर रिप्लेसमेंट उपलब्ध कराता है:

  • पहले (लेगसी Java 8 का इस्तेमाल): 
    // Incompatible in Edge for Private Cloud 4.54.00: sun.misc package removed
import sun.misc.BASE64Encoder;
// other required imports

public class Base64EncodeCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        BASE64Encoder encoder = new BASE64Encoder();
        String encoded = encoder.encode("ApigeePayload".getBytes());
        messageContext.setVariable("encoded_data", encoded);
        return ExecutionResult.SUCCESS;
    }
}
  • इसके बाद (Java 21 के साथ काम करने वाला कोड): 
    // Fully compatible with Java 21: uses standard Java SE java.util.Base64 (no external JARs needed)
import java.util.Base64;
// other required imports

public class Base64EncodeCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        String encoded = Base64.getEncoder().encodeToString("ApigeePayload".getBytes());
        messageContext.setVariable("encoded_data", encoded);
        return ExecutionResult.SUCCESS;
    }
}
दूसरा उदाहरण: बंडल की गई लाइब्रेरी (JAXB नेमस्पेस प्रीफ़िक्स मैपर) के साथ इंपोर्ट-लेवल रीफ़ैक्टरिंग

Java 8 में, एक्सएमएल नेमस्पेस प्रीफ़िक्स को पसंद के मुताबिक बनाने वाली एपीआई प्रॉक्सी, आम तौर पर Sun के इंटरनल JAXB मैपर com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper को एक्सटेंड करती थीं. Java 21 में, इंटरनल Sun पैकेज हटा दिए गए हैं और उन्हें ऐक्सेस नहीं किया जा सकता.

स्टैंडअलोन ओपन-सोर्स लाइब्रेरी (org.glassfish.jaxb:jaxb-runtime), com.sun.xml.bind.marshaller.NamespacePrefixMapper के तहत एक जैसी क्लास उपलब्ध कराती है. सभी मेथड सिग्नेचर, पैरामीटर, और रिटर्न टाइप एक जैसे हैं. कोड में बदलाव, सिर्फ़ इंपोर्ट स्टेटमेंट में किया गया है:

  • पहले (लेगसी Java 8 का इस्तेमाल): 
    // In Java 8: Relied on internal Sun class in Java 8 runtime
import com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper;
public class CustomNamespaceMapper extends NamespacePrefixMapper {
    @Override
    public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
        if ("http://schemas.example.com/orders".equals(namespaceUri)) {
            return "ord";
        }
        return suggestion;
    }
}
  • इसके बाद (Java 21 के साथ काम करने वाला कोड): 
    // In Java 21: Identical methods and logic; ONLY the import statement changes (".internal." removed)
import com.sun.xml.bind.marshaller.NamespacePrefixMapper;
public class CustomNamespaceMapper extends NamespacePrefixMapper {
    @Override
    public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
        if ("http://schemas.example.com/orders".equals(namespaceUri)) {
            return "ord";
        }
        return suggestion;
    }
}
  • बंडल की गई डिपेंडेंसी का कॉन्फ़िगरेशन (pom.xml): रनटाइम के दौरान इस क्लास को उपलब्ध कराने के लिए, स्टैंडअलोन JAXB लाइब्रेरी को apiproxy/resources/java/ में बंडल करें या उन्हें अपने pom.xml में शामिल करें: 
    <dependencies>
    <!-- Standalone JAXB API for Java 21 -->
    <dependency>
        <groupId>jakarta.xml.bind</groupId>
        <artifactId>jakarta.xml.bind-api</artifactId>
        <version>2.3.3</version>
    </dependency>
    <!-- Standalone JAXB Runtime providing com.sun.xml.bind.marshaller.NamespacePrefixMapper -->
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.3.8</version>
    </dependency>
</dependencies>

रणनीति 3A: मेंटेनेंस के लिए तय किया गया डाउनटाइम (इन-प्लेस रीडिप्लॉयमेंट)

कब इस्तेमाल करें: इसका इस्तेमाल ऐसे एनवायरमेंट के लिए करें जहां रखरखाव के लिए शेड्यूल की गई विंडो मौजूद हों और सेवा में कुछ समय के लिए रुकावट आने से कोई समस्या न हो.

तरीका:

  1. एपीआई का इस्तेमाल करने वाले लोगों के साथ मिलकर, शेड्यूल किए गए रखरखाव की विंडो तय करें.
  2. अपग्रेड पाथ गाइड में दिए गए निर्देशों का पालन करके, Edge for Private Cloud के कॉम्पोनेंट को 4.54.00 वर्शन पर अपग्रेड करें.
  3. New Edge यूज़र इंटरफ़ेस (यूआई) या Apigee Management API (डिप्लॉयमेंट) का इस्तेमाल करके, अपने एपीआई प्रॉक्सी के पहले से कंपाइल किए गए और 4.54.00 के साथ काम करने वाले वर्शन को डिप्लॉय करें.
  4. मैसेज प्रोसेसर को सिंथेटिक टेस्ट अनुरोध भेजकर और ट्रेस टूल का इस्तेमाल करके लॉग की जांच करके, कॉलआउट के लागू होने की पुष्टि करें.
  5. मेंटेनेंस विंडो को बंद करें और सार्वजनिक ट्रैफ़िक को फिर से चालू करें.

रणनीति 3B: नया एनवायरमेंट बनाना (डाउनटाइम के बिना माइग्रेशन)

कब इस्तेमाल करें: इसका सुझाव ऐसे प्रोडक्शन एनवायरमेंट के लिए दिया जाता है जो बहुत ज़रूरी हैं और जिनमें डाउनटाइम की कोई गुंजाइश नहीं है. इसका इस्तेमाल तब करें, जब Java Callout को Java 8 और Java 21, दोनों पर एक साथ काम करने के लिए अपडेट न किया जा सके.

यह कैसे काम करता है: इस रणनीति में, एक या उससे ज़्यादा नए एनवायरमेंट को हासिल किया जाता है, ताकि आप अलग-अलग वर्शन के मैसेज प्रोसेसर नोड को इससे कनेक्ट कर सकें. इसके बाद, Java 8 के साथ काम करने वाले प्रॉक्सी को 4.53.X मैसेज प्रोसेसर से जुड़े एनवायरमेंट में डिप्लॉय करें. साथ ही, Java 21 के साथ काम करने वाले प्रॉक्सी को 4.54.00 मैसेज प्रोसेसर से जुड़े एनवायरमेंट में डिप्लॉय करें. इसके बाद, लोड बैलेंसर या रूटिंग की अन्य तकनीकों का इस्तेमाल करके, ट्रैफ़िक को सिर्फ़ Java 21 के साथ काम करने वाले प्रॉक्सी पर रूट करें.

इस रणनीति के लिए, यह समझना ज़रूरी है कि संगठन, एनवायरमेंट, और मैसेज प्रोसेसर कैसे इंटरैक्ट करते हैं. इससे ज़ीरो-डाउनटाइम कट-ओवर किया जा सकता है. ज़्यादा जानकारी के लिए, Apigee Edge के संगठन का स्ट्रक्चर देखें:

  • Apigee संगठन, टॉप-लेवल एडमिनिस्ट्रेटिव बाउंड्री है. इसमें कई एनवायरमेंट होते हैं. उदाहरण के लिए, prod, test.
  • एपीआई प्रॉक्सी के किसी बदलाव को किसी खास एनवायरमेंट में डिप्लॉय किया जाता है. सिर्फ़ वे मैसेज प्रोसेसर, प्रॉक्सी के बदलाव को लोड और लागू करते हैं जो साफ़ तौर पर उस एनवायरमेंट से जुड़े होते हैं.
+------------------------------------------------------------------------+
|                          Apigee Organization                           |
|                                                                        |
|  Existing Environment (prod)            Temporary Env (prod-migration) |
|  +--------------------------------+     +----------------------------+ |
|  | Current 4.53.01 MP Nodes       |     | New 4.54.00 MP Nodes       | |
|  |               |                |     |              |             | |
|  | Proxy Rev N (4.53.01)          |     | Proxy Rev N+1 (Modernized) | |
|  +--------------------------------+     +----------------------------+ |
+------------------------------------------------------------------------+
                   ^                                    ^
                   | Step 1: Normal Live                | Step 2: Canary
                   |         Traffic (prod)             | Step 3: Complete
          +------------------------------------------------------+
          |       Upstream Load Balancer / Ingress Router        |
          +------------------------------------------------------+

तरीका:

  1. एक अस्थायी एनवायरमेंट बनाएं: अपने संगठन में एक नया एनवायरमेंट (उदाहरण के लिए, prod-migration) बनाएं. इसके लिए, वर्चुअल होस्ट और एनवायरमेंट सेट अप करना लेख में बताया गया तरीका अपनाएं. साथ ही, एक खास वर्चुअल होस्ट और पोर्ट का इस्तेमाल करें.
  2. 4.54.00 मैसेज प्रोसेसर नोड को प्रोविज़न करना: नए या कुछ समय के लिए बनाए गए वीएम इंस्टेंस पर, Edge for Private Cloud 4.54.00 इंस्टॉल करें. साथ ही, इन नोड को prod-migration से बाइंड करें (मैसेज प्रोसेसर जोड़ना देखें).
  3. जिन प्रॉक्सी पर असर पड़ा है उनकी पहचान करें और अपडेट किए गए वर्शन बनाएं: Java कॉलआउट का इस्तेमाल करने वाले एपीआई प्रॉक्सी की पहचान करें. इसके लिए, बदलाव का पता लगाने वाले टूल का इस्तेमाल करें. इसके बाद, जिन प्रॉक्सी पर असर पड़ा है उनके लिए, Edge for Private Cloud 4.54.00 के साथ काम करने वाले Java कॉलआउट का इस्तेमाल करके, एक नया वर्शन बनाएं. इसके लिए, रणनीति 1 या रणनीति 2 लागू करें.
  4. अपडेट किए गए प्रॉक्सी रिविज़न को कुछ समय के लिए बनाए गए एनवायरमेंट में डिप्लॉय करना: अपडेट किए गए और साथ काम करने वाले प्रॉक्सी रिविज़न को सिर्फ़ prod-migration में डिप्लॉय करें.
  5. ट्रैफ़िक की पुष्टि करना और उसे शिफ़्ट करना: नए वर्चुअल होस्ट के लिए, सिंथेटिक पुष्टि करने वाले टेस्ट चलाएं. पुष्टि होने के बाद, अपने बाहरी लोड बैलेंसर (F5, NGINX) को कॉन्फ़िगर करें, ताकि क्लाइंट ट्रैफ़िक को prod से prod-migration पर रीडायरेक्ट किया जा सके.
  6. ओरिजनल नोड अपग्रेड करना और वापस स्विच करना: prod से लेगसी प्रॉक्सी को अनडिप्लॉय करें. अपग्रेड पाथ गाइड में दिए गए निर्देशों का पालन करके, ओरिजनल मैसेज प्रोसेसर नोड को 4.54.00 पर अपग्रेड करें. अपग्रेड किए गए प्रॉक्सी वर्शन को prod पर डिप्लॉय करें. साथ ही, लोड बैलेंसर ट्रैफ़िक को वापस prod पर रीडायरेक्ट करें और कार्रवाई की पुष्टि करें.
  7. कुछ समय के लिए बनाए गए एनवायरमेंट को बंद करना: prod-migration से प्रॉक्सी को अनडिप्लॉय करें, कुछ समय के लिए बनाए गए मैसेज प्रोसेसर नोड हटाएं, और कुछ समय के लिए बनाए गए एनवायरमेंट को मिटाएं.

रणनीति 3C: नोड-लेवल पर external-lib प्लेसमेंट (शेयर की गई फ़ॉलबैक लाइब्रेरी)

इसका इस्तेमाल कब करें: इसका सुझाव तब दिया जाता है, जब आपके पास Java क्लास पर निर्भर कई एपीआई प्रॉक्सी हों. ये क्लास, Java 21 में हटा दी गई थीं. साथ ही, अपग्रेड करने से पहले हर प्रॉक्सी बंडल को फिर से कंपाइल या फिर से पैकेज करना, ऑपरेशन के हिसाब से मुमकिन नहीं है.

यह कैसे काम करता है: Edge for Private Cloud 4.54.00 में, मैसेज प्रोसेसर एक ऐसा तरीका उपलब्ध कराते हैं जिससे मौजूद नहीं होने वाली Java क्लास को, खास तौर पर बनाई गई नोड डायरेक्ट्री: $APIGEE_ROOT/data/edge-message-processor/external-lib से लोड किया जा सकता है.

इस तरीके के चालू होने पर, मैसेज प्रोसेसर डिफ़ॉल्ट रिज़ॉल्यूशन पर वापस जाने से पहले, इस डायरेक्ट्री में मौजूद क्लास की जांच करता है. तीसरे पक्ष की लाइब्रेरी के JAR से सोर्स करके, मौजूद नहीं होने वाली क्लास उपलब्ध कराई जा सकती हैं. इसके अलावा, ज़रूरी क्लास को JAR में बंडल करके, external-lib में रखा जा सकता है.

तरीका:

  1. हर मैसेज प्रोसेसर नोड पर, बाहरी लाइब्रेरी डायरेक्ट्री बनाएं: 
    mkdir -p /opt/apigee/data/edge-message-processor/external-lib
  2. ज़रूरी JAR फ़ाइलों को डायरेक्ट्री में डालें: ज़रूरी क्लास वाली JAR फ़ाइलों को /opt/apigee/data/edge-message-processor/external-lib में कॉपी करें.
  3. फ़ाइल से जुड़ी सही अनुमतियां सेट करें: पक्का करें कि apigee सेवा का इस्तेमाल करने वाले व्यक्ति के पास, फ़ाइल को पढ़ने की अनुमतियां हों: 
    chown -R apigee:apigee /opt/apigee/data/edge-message-processor/external-lib
chmod 755 /opt/apigee/data/edge-message-processor/external-lib
chmod 644 /opt/apigee/data/edge-message-processor/external-lib/*.jar
  4. मैसेज प्रोसेसर के कॉन्फ़िगरेशन में, बाहरी पैकेज लोड करने की सुविधा चालू करना: Edge for Private Cloud 4.54.00 में, अनुमति वाले बाहरी पैकेज लोड करने की सुविधा डिफ़ॉल्ट रूप से बंद (conf_system_java.21.enable.external.allowed.packages=false) होती है. मैसेज प्रोसेसर को /opt/apigee/data/edge-message-processor/external-lib से क्लास रिज़ॉल्व और लोड करने की अनुमति देने के लिए, आपको कोड विद कॉन्फ़िगरेशन (सीडब्ल्यूसी) का इस्तेमाल करके, /opt/apigee/customer/application/message-processor.properties में यह प्रॉपर्टी चालू करनी होगी: 
    conf_system_java.21.enable.external.allowed.packages=true
  5. मैसेज प्रोसेसर को रीस्टार्ट करें: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

चौथी रणनीति: जेवीएम फ़्लैग (--add-opens / --add-exports — सावधानी और आखिरी विकल्प)

इसका इस्तेमाल कब करें: इस रणनीति का इस्तेमाल, तीसरे पक्ष की क्लोज़्ड सोर्स वेंडर लाइब्रेरी के लिए आखिरी विकल्प के तौर पर करें. ऐसा तब करें, जब सोर्स कोड उपलब्ध न हो, वेंडर ने Java 21 के अपडेट रिलीज़ न किए हों, और JAR पूरी तरह से Java के इंटरनल पैकेज के रिफ़्लेक्टिव ऐक्सेस पर निर्भर हो.

तरीका:

  1. रिफ़्लेक्शन के लिए इस्तेमाल किए गए ऐसे पैकेज की पहचान करें जिसे ऐक्सेस नहीं किया जा सकता: यह पता लगाएं कि तीसरे पक्ष की लाइब्रेरी ने किस इंटरनल Java मॉड्यूल और पैकेज को रिफ़्लेक्टिव तरीके से ऐक्सेस किया है. ध्यान दें: रिफ़्लेक्शन से जुड़ी ये गड़बड़ियां, Edge for Private Cloud 4.54.00 में Java 21 के तहत ही होती हैं. ये गड़बड़ियां, 4.53.x वर्शन के लॉग में नहीं दिखेंगी. अपग्रेड करने के बाद, मैसेज प्रोसेसर लॉग (/opt/apigee/var/log/edge-message-processor/system.log) में InaccessibleObjectException देखें, ताकि ज़रूरी मॉड्यूल और पैकेज की पहचान की जा सके: 
    java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module
  2. कोड विद कॉन्फ़िग (CwC) का इस्तेमाल करके, /opt/apigee/customer/application/message-processor.properties में बदलाव करें. अगर फ़ाइल मौजूद नहीं है, तो उसे बनाएं.
  3. टारगेट किए गए --add-opens या --add-exports फ़्लैग को bin_setenv_ext_jvm_opts में जोड़ें. 
    # Configure targeted JVM module access for closed-source legacy callouts (enclosed in double quotes)
bin_setenv_ext_jvm_opts="-XX:+UseG1GC -XX:+AlwaysPreTouch --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.misc=ALL-UNNAMED --add-opens java.base/sun.security.util=ALL-UNNAMED --add-opens java.base/sun.security.x509=ALL-UNNAMED"
  4. पक्का करें कि आपके पास फ़ाइल का मालिकाना हक और अनुमतियां हों: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
chmod 644 /opt/apigee/customer/application/message-processor.properties
  5. apigee-service का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

टीएलएस और साइफ़र सुइट में बदलाव

Edge for Private Cloud 4.54.00 में, मुख्य प्लैटफ़ॉर्म कॉम्पोनेंट को Java 21 LTS पर चलाने के लिए अपडेट किया गया है. इनमें मैसेज प्रोसेसर, मैनेजमेंट सर्वर, और राऊटर शामिल हैं. इस अपडेट से, क्रिप्टोग्राफ़िक सुरक्षा को आधुनिक बनाया गया है. इसके लिए, TLS 1.3 को डिफ़ॉल्ट रूप से (जेईपी 332) चालू किया गया है. मैसेज प्रोसेसर अब आउटबाउंड बैकएंड कनेक्शन के लिए, पसंदीदा प्रोटोकॉल के तौर पर टीएलएस 1.3 का इस्तेमाल करते हैं. अगर बैकएंड पर टीएलएस 1.3 काम नहीं करता है, तो वे टीएलएस 1.2 का इस्तेमाल करते हैं.

लेगसी बैकएंड की ज़रूरी शर्तें और समस्या को ठीक करने का तरीका

Java 21 क्रिप्टोग्राफ़िक बेसलाइन, jdk.tls.disabledAlgorithms में डिफ़ॉल्ट रूप से बंद किए गए प्रोटोकॉल और साइफ़र सुइट की सूची को अपडेट करती है. जैसे, लेगसी TLS प्रोटोकॉल और नॉन-फ़ॉरवर्ड-सीक्रेट स्टैटिक आरएसए कुंजी-एक्सचेंज सुइट: TLS_RSA_*. Java 21 रनटाइम को खुद ही उपलब्ध कराना होता है. इसलिए, बंद किए गए प्रोटोकॉल और साइफ़र सुइट की सटीक सूची, Java 21 के आपके खास तरीके पर निर्भर करती है.

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

  • बैकएंड सुरक्षा को आधुनिक बनाएं (सुझाया गया): टारगेट सर्वर और लोड बैलेंसर को अपग्रेड करें, ताकि वे आधुनिक ईसीडीएचई साइफ़र सुइट के साथ टीएलएस 1.2 या टीएलएस 1.3 का इस्तेमाल कर सकें. अपने एपीआई प्रॉक्सी में प्रोटोकॉल और साइफ़र सुइट कॉन्फ़िगर करने के लिए, Edge से बैकएंड तक टीएलएस कॉन्फ़िगर करना और टीएलएस/एसएसएल TargetEndpoint कॉन्फ़िगरेशन रेफ़रंस देखें. इसके अलावा, अगर TargetServers का इस्तेमाल किया जा रहा है, तो बैकएंड सर्वर पर लोड बैलेंस करना देखें.
  • CwC का इस्तेमाल करके, लेगसी एल्गोरिदम फिर से चालू करना (अपग्रेड के दौरान ट्रांज़िशन के लिए): अगर प्लैटफ़ॉर्म अपग्रेड होने से पहले बैकएंड अपग्रेड पूरे नहीं हो पाते हैं, तो कोड विद कॉन्फ़िगरेशन (CwC) का इस्तेमाल करके, ज़रूरी एल्गोरिदम को कुछ समय के लिए फिर से चालू किया जा सकता है:
    1. अपने Java 21 इंस्टॉलेशन में, डिफ़ॉल्ट jdk.tls.disabledAlgorithms वैल्यू देखें. उदाहरण के लिए, $JAVA_HOME/conf/security/java.security में.
    2. /opt/apigee/customer/application/message-processor.properties में conf_jvmsecurity_jdk.tls.disabledAlgorithms को बंद किए गए एल्गोरिदम की उसी सूची से बदलें. इसमें सिर्फ़ TLS_RSA_* एंट्री को हटाएं. साथ ही, बंद किए गए अन्य सभी एल्गोरिदम को पहले जैसा ही रखें, ताकि बाकी सुरक्षा सुविधाएं चालू रहें.
    3. apigee-service का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. बैकएंड में ईसीडीएचई साइफ़र सुइट की सुविधा चालू होने के बाद, इस बदलाव को हटाएं.
  • कस्टम साइफ़र सुइट की अनुमति वाली सूची को अपडेट करना: अगर आपने पहले conf_http_HTTPTransport.ssl.cipher.suites.whitelist को बदला है, तो अपग्रेड करने से पहले उसकी समीक्षा करें. Java 21 में अब स्टैटिक आरएसए सुइट (TLS_RSA_*) काम नहीं करते. इसलिए, अनुमति वाली ऐसी सूची जिसमें सिर्फ़ ये सुइट शामिल हैं, मैसेज प्रोसेसर को इस्तेमाल करने लायक साइफ़र नहीं देती. साथ ही, बैकएंड कॉल no cipher suites in common के साथ काम नहीं करते. TLS_RSA_* एंट्री हटाएं और Java 21 के साथ काम करने वाले आधुनिक साइफ़र सुइट कॉन्फ़िगर करें. अगर आपने इस प्रॉपर्टी को बदला नहीं है, तो 4.54.00 के डिफ़ॉल्ट वर्शन में, काम करने वाले सुइट पहले से मौजूद होते हैं. इसलिए, आपको कोई बदलाव करने की ज़रूरत नहीं है.
  • मैसेज प्रोसेसर के साइफ़र के लिए, इंटरनल राऊटर को अपडेट करें: अगर आपने पहले स्टैटिक आरएसए सुइट की मदद से conf_message-processor-communication_local.http.ssl.ciphers को बदला था, तो अपग्रेड करने से पहले इसे Java 21 के साथ काम करने वाले आधुनिक साइफ़र सुइट से अपडेट करें. ऐसा न करने पर, राऊटर, मैसेज प्रोसेसर के साथ टीएलएस हैंडशेक पूरा नहीं कर पाएगा. इसके बाद, मैसेज प्रोसेसर को रीस्टार्ट करें: 
    apigee-service edge-message-processor restart
     राऊटर और मैसेज प्रोसेसर के बीच टीएलएस कॉन्फ़िगर करना देखें.

Edge के कॉम्पोनेंट के बीच टीएलएस कॉन्फ़िगर करने के बारे में जानकारी पाने के लिए, राऊटर और मैसेज प्रोसेसर के बीच टीएलएस कॉन्फ़िगर करना लेख पढ़ें.

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

Apigee, बदलाव का पता लगाने वाला एक टूल उपलब्ध कराता है. इससे आपके क्लस्टर को स्कैन करके, डिप्लॉय किए गए एपीआई प्रॉक्सी, नीतियों, शेयर किए गए फ़्लो, और रिसोर्स JAR का पता लगाया जाता है. इन पर Edge for Private Cloud 4.54.00 पर अपग्रेड करने का असर पड़ सकता है.

यह टूल, अपग्रेड करने में आने वाली संभावित रुकावटों की पहचान करता है. जैसे, Java 21 के साथ काम न करने वाली लाइब्रेरी, पूरी तरह से एन्कैप्सुलेट किए गए इंटरनल एपीआई, लेगसी नीति के तहत बंद किए गए एपीआई, और OpenLDAP RDN की सीमाएं. साथ ही, यह टूल ऐसी रिपोर्ट जनरेट करता है जिनके आधार पर कार्रवाई की जा सकती है. इससे आपको समस्याओं को ठीक करने के लिए सही रणनीतियां चुनने में मदद मिलती है.

ज़रूरी शर्तों, डाउनलोड करने के निर्देशों, कमांड-लाइन सिंटैक्स, और सैंपल रिपोर्ट की पूरी जानकारी के लिए, बदलाव की पहचान करने वाले टूल की गाइड देखें.