การเปลี่ยนแปลงใน Edge for Private Cloud 4.54.00

ภาพรวมของการเปลี่ยนแปลง

Edge for Private Cloud 4.54.00 มีการเปลี่ยนแปลงหลายอย่างที่ช่วยเพิ่มท่าทีด้านความปลอดภัยของแพลตฟอร์ม และอัปเดตคอมโพเนนต์ของแพลตฟอร์มให้ทำงานด้วย Java 21 ส่วน 2 ส่วนด้านล่างนี้จะครอบคลุมการเปลี่ยนแปลงดังกล่าว

นอกจากการเปลี่ยนแปลงเหล่านี้แล้ว โปรดดูคู่มือเครื่องมือตรวจหาการเปลี่ยนแปลงโดยเฉพาะ เราได้จัดเตรียมยูทิลิตี้นี้ไว้เพื่อระบุการเปลี่ยนแปลงพร็อกซี โฟลว์ที่ใช้ร่วมกัน หรืออาร์ติแฟกต์อื่นๆ ในคลัสเตอร์ที่อาจทำให้เกิดการหยุดชะงักอันเป็นผลมาจากการอัปเกรดนี้

การเปลี่ยนแปลงนโยบายไฮไลต์ของ Java

ใน Edge for Private Cloud 4.54.00 คอมโพเนนต์แพลตฟอร์มหลัก ซึ่งรวมถึง Message Processor, Management Server และเราเตอร์ ได้รับการอัปเดตให้ทำงานบน Java 21 LTS Java 21 ปรับปรุงแพลตฟอร์ม Java ให้ทันสมัย ซึ่งรวมถึงการนำโมดูล Java EE และ CORBA เดิมออก (JEP 320) การนำคลาสยูทิลิตีภายในเดิมออก และการบังคับใช้การแคปซูลแบบโมดูลที่เข้มงวด (JEP 403)

การเปลี่ยนแปลงเหล่านี้อาจทำให้พร็อกซี API ที่มีนโยบาย JavaCallout ที่กำหนดเองหรือ JAR ของทรัพยากรที่กำหนดเอง (จัดเก็บไว้ที่ระดับพร็อกซี สภาพแวดล้อม หรือองค์กร) อาจหยุดชะงักเมื่ออัปเกรดเป็นเวอร์ชัน 4.54.00

หมวดหมู่ของการเปลี่ยนแปลงที่อาจส่งผลต่อ Java Callout

  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.*) จะเข้าถึงแบบรีเฟลกทีฟจาก Callout ที่กำหนดเองไม่ได้ การเรียกใช้การสะท้อนล้มเหลวที่รันไทม์พร้อมกับ InaccessibleObjectException
  4. การเปลี่ยนแปลงและการนำซิกเนเจอร์ของเมธอดออกในคลาส Java ที่ยังคงอยู่: ในโมดูล Java บางโมดูล คลาสจะยังคงอยู่ใน Java 21 แต่มีการนำคอนสตรักเตอร์หรือซิกเนเจอร์ของเมธอดบางรายการออก เลิกใช้งาน หรือเปลี่ยนแปลง (เช่น เมธอดการแยกวิเคราะห์ DOM บางรายการใน org.w3c.dom.Document และคลาสการแยกวิเคราะห์ XML ที่เกี่ยวข้อง)

    การตรวจจับเครื่องมือ: เครื่องมือตรวจจับการเปลี่ยนแปลงจะแจ้งว่ามีการอ้างอิงถึงคลาสเหล่านี้ในหมวดหมู่ METHOD_SIGNATURE_MODIFICATION โดยมีMEDIUMความแน่นอนของผลกระทบ ซึ่งจะแจ้งให้นักพัฒนาซอฟต์แวร์ตรวจสอบซอร์สโค้ดของข้อความไฮไลต์เพื่อดูการเรียกใช้เมธอดที่แก้ไขแล้ว

กลยุทธ์การแก้ไข

ก่อนอัปเกรด โปรดตรวจสอบว่านโยบาย Java Callout และทรัพยากร JAR ที่กำหนดเองเข้ากันได้กับรันไทม์ Java 21 การใช้เครื่องมือตรวจหาการเปลี่ยนแปลงจะช่วยให้คุณระบุพร็อกซี API, โฟลว์ที่ใช้ร่วมกัน และทรัพยากร JAR ของสภาพแวดล้อมหรือองค์กรที่ได้รับผลกระทบในคลัสเตอร์ได้

กลยุทธ์การแก้ไขที่อธิบายไว้ในส่วนนี้เป็นคำแนะนำทั่วไปและสามารถใช้ร่วมกันได้ คุณสามารถรวมกลยุทธ์ต่างๆ เข้าด้วยกันได้ตามข้อกำหนดในการดำเนินงาน เช่น การปรับปรุงซอร์สโค้ดของคำขอไฮไลต์ให้ทันสมัยโดยใช้กลยุทธ์ที่ 2 และการติดตั้งใช้งานการแก้ไขพร็อกซีที่อัปเดตแล้วโดยใช้กลยุทธ์ที่ 3B เพื่อให้ระบบทำงานได้ตลอดเวลาในระหว่างการอัปเกรด Message Processor

กลยุทธ์ 3A, 3B และ 3C เป็น 3 วิธีในการใช้แนวทางการปฏิบัติงานเดียวกัน นั่นคือ การอัปเกรดโหนดและการติดตั้งพร็อกซีซ้ำในเวลาที่ต่างกันโดยไม่ต้องเปลี่ยนชุดพร็อกซี เลือกอย่างใดอย่างหนึ่งหรือหลายอย่างรวมกันตามข้อกำหนดด้านความพร้อมใช้งานของ API

ดูคำแนะนำในการตัดสินใจต่อไปนี้เพื่อเลือกแนวทางที่เหมาะสมที่สุดสำหรับการติดตั้งใช้งาน

คำแนะนำในการตัดสินใจสำหรับการบรรเทาการเรียกใช้ Java:

ต้องอัปเดตและติดตั้งใช้งานชุดพร็อกซีอีกครั้งไหม สถานการณ์หรือข้อกำหนด กลยุทธ์ที่แนะนํา ปัญหาที่แก้ไข ข้อจำกัดที่สำคัญ
ใช่ (อัปเดตแพ็กเกจเท่านั้น) มีไลบรารีที่เข้ากันได้ทั้ง 2 แบบ และต้องการให้ระบบทำงานได้ตลอดเวลา กลยุทธ์ที่ 1: พร็อกซีที่เข้ากันได้แบบคู่ผ่าน JAR ที่รวมกลุ่ม กู้คืนไลบรารีที่หายไปในเวอร์ชันต่างๆ โดยไม่มีช่วงเวลาที่ระบบหยุดทำงาน ต้องมีไลบรารีแบบสแตนด์อโลนที่รองรับทั้ง 2 ระบบและเปิดใช้ conf_system_java.21.enable.external.allowed.packages=true ในเวอร์ชัน 4.54.00
ได้ (การแก้ไขซอร์สโค้ด) มีการดูแลรักษาซอร์สโค้ด ต้องการแก้ไขในระยะยาว กลยุทธ์ที่ 2: การติดตั้งใช้งานทางเลือก (การปรับโค้ดและการขึ้นต่อกันให้ทันสมัย) แก้ไขคลาสที่นำออกและการอ้างอิง API ภายในอย่างถาวร ต้องมีการเปลี่ยนแปลงซอร์สโค้ดและการทำให้ใช้งานได้อีกครั้ง (จับคู่กับกลยุทธ์ 3A หรือ 3B สำหรับการเปิดตัว)
ไม่ (แนวทางด้านการดำเนินงาน) ช่วงเวลาบำรุงรักษาตามกำหนดการที่อนุญาต กลยุทธ์ 3A: ช่วงเวลาที่ระบบหยุดทำงานเพื่อการบำรุงรักษาตามแผน (การติดตั้งใช้งานซ้ำในตำแหน่งเดิม) อนุญาตให้อัปเกรดโหนดก่อน แล้วจึงจะติดตั้งใช้งานพร็อกซีที่อัปเดตแล้วได้ ต้องมีการหยุดทำงานตามกำหนดเวลาสำหรับผู้ใช้ API
ไม่ (แนวทางด้านการดำเนินงาน) ต้องไม่มีช่วงพัก ไม่สามารถรวม JAR แบบคู่ได้ กลยุทธ์ 3B: สร้างสภาพแวดล้อมใหม่ (การย้ายข้อมูลโดยไม่มีช่วงเวลาที่ระบบหยุดทำงาน) แยกโหนด 4.53 และ 4.54 ระหว่างการย้ายข้อมูลโดยไม่รบกวนการเข้าชม ต้องจัดหาโหนด Message Processor ชั่วคราว
ไม่ (แนวทางด้านการดำเนินงาน) แก้ไขแพ็กเกจพร็อกซีไม่ได้ก่อนการอัปเกรด * กลยุทธ์ 3C: การวางตำแหน่งไลบรารีภายนอกระดับโหนด จัดเตรียม JAR ของไลบรารีที่ขาดหายไปทั่วทั้งโหนดโดยไม่ต้องแก้ไขแพ็กเกจพร็อกซี แชร์ในพร็อกซีทั้งหมดบนโหนด ไม่แก้ปัญหาแพ็กเกจการสะท้อนหรือ java.*
ไม่ (ไลบรารีของบุคคลที่สามแบบโคลสซอร์ส) ไลบรารีของผู้ให้บริการบุคคลที่สามที่ใช้การสะท้อนภายใน Java * กลยุทธ์ที่ 4: แฟล็ก JVM (--add-opens / --add-exports) ผ่อนคลายข้อจำกัดการสะท้อนสำหรับแพ็กเกจ Java ภายใน กู้คืนคลาสหรือเมธอดที่นำออกไม่ได้ มีผลทั่วทั้งโหนด

กลยุทธ์ที่ 1: พร็อกซีที่เข้ากันได้แบบคู่ผ่าน JAR ที่รวมมา (ทดสอบก่อนอัปเกรดเพื่อไม่ให้เกิดช่วงพักการทำงาน)

กรณีที่ควรใช้: ใช้กลยุทธ์นี้ในกรณีต่อไปนี้

  • มีไลบรารีทดแทนแบบสแตนด์อโลนที่เข้ากันได้ทั้ง 2 แบบ: มี JAR ทดแทนที่ใช้ฟังก์ชันการทำงานที่จำเป็นและสามารถรวมเข้ากับพร็อกซี API ได้โดยตรงโดยไม่ต้องแก้ไขซอร์สโค้ด
  • คุณต้องการให้พร็อกซี API และ Java Callout ที่มีอยู่ทำงานได้อย่างราบรื่นทั้งในเวอร์ชันปัจจุบัน (เช่น Edge for Private Cloud 4.53.01) และเวอร์ชันที่อัปเกรด (Edge for Private Cloud 4.54.00)
  • คุณควรทดสอบและยืนยันการเปลี่ยนแปลงทั้งหมดในสภาพแวดล้อมการทดลองใช้และสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์ก่อนอัปเกรดคลัสเตอร์ Edge for Private Cloud เพื่อให้มั่นใจว่าจะไม่มีปัญหาที่ไม่คาดคิดและไม่มีช่วงเวลาที่ระบบหยุดทำงานในการเข้าชมแบบเรียลไทม์
  • คุณต้องการหลีกเลี่ยงการเขียนใหม่หรือเปลี่ยนโครงสร้างภายในโค้ดของตรรกะทางธุรกิจของ Java Callout

วิธีการทำงาน: ใน Java 8 ไลบรารีบางรายการ (เช่น JAXB javax.xml.bind.* หรือ Activation javax.activation.*) จะสร้างขึ้นในรันไทม์ของ Java 8 โดยตรง ด้วยเหตุนี้ นักพัฒนาแอปจึงไม่จำเป็นต้องรวมไฟล์ JAR เพิ่มเติมไว้ในแพ็กเกจพร็อกซี ใน Java 21 เราได้นำไลบรารีเหล่านี้ออกจากรันไทม์ของ Java

วิธีทำให้พร็อกซี "เข้ากันได้แบบคู่" ใน Edge สำหรับ Private Cloud 4.53.x และ 4.54.00 มีดังนี้

  1. ระบุไลบรารีที่ขาดหายไปซึ่งจำเป็นสำหรับการไฮไลต์ (เช่น JAXB หรือการเปิดใช้งาน)
  2. รับ JAR ทดแทนโอเพนซอร์สแบบสแตนด์อโลน (เช่น jakarta.xml.bind-api-2.3.3.jar และ jaxb-runtime-2.3.8.jar)
  3. วาง JAR ที่จะใช้แทนลงในแพ็กเกจพร็อกซีโดยตรงในส่วน apiproxy/resources/java/ หรืออัปโหลดไปยังการแก้ไขพร็อกซีโดยใช้ Resource Files API ระดับพร็อกซี หรืออัปโหลดเป็นไฟล์ทรัพยากรที่ระดับสภาพแวดล้อมหรือระดับองค์กร ดูข้อมูลเพิ่มเติมเกี่ยวกับการจัดการไฟล์ทรัพยากรได้ที่เอกสารประกอบเกี่ยวกับไฟล์ทรัพยากรของ Apigee
  4. ติดตั้งใช้งานและทดสอบก่อนอัปเกรด: Message Processor ทั้งใน Edge for Private Cloud 4.53.x และ 4.54.00 จะโหลดคลาสจาก JAR ที่รวมมาเหล่านี้ คุณสามารถติดตั้งใช้งานแพ็กเกจพร็อกซีที่อัปเดตนี้และทดสอบกับการเข้าชมสังเคราะห์ในคลัสเตอร์ Edge for Private Cloud 4.53.x ปัจจุบันได้แล้วตอนนี้
  5. เปิดใช้การโหลดแพ็กเกจที่อนุญาตภายนอกใน Message Processor (จำเป็นสำหรับ 4.54.00): โดยค่าเริ่มต้นใน Edge สำหรับ Private Cloud 4.54.00 ระบบจะปิดใช้การโหลดแพ็กเกจ Java ที่นำออก (เช่น javax.xml.bind.* และ javax.activation.*) จาก JAR ของทรัพยากรภายนอกหรือที่รวมมา (conf_system_java.21.enable.external.allowed.packages=false) ดังนั้นการรวม JAR เพียงอย่างเดียวจะไม่ทำงานโดยค่าเริ่มต้น คุณต้องเปิดใช้พร็อพเพอร์ตี้นี้ใน /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) (คุณกำหนดค่าพร็อพเพอร์ตี้นี้ได้ก่อนอัปเกรดโหนด Message Processor หรือตั้งค่าหลังจากอัปเกรดและรีสตาร์ท Message Processor) 
    conf_system_java.21.enable.external.allowed.packages=true
  6. ไม่มีปัญหาเกี่ยวกับการเข้าชมแบบเรียลไทม์หลังการอัปเกรด: เมื่ออัปเกรดคลัสเตอร์เป็น Edge for Private Cloud 4.54.00 โดยเปิดใช้ conf_system_java.21.enable.external.allowed.packages=true แล้ว Message Processor จะมี JAR ที่จำเป็นอยู่แล้วและโหลดคลาสจากไฟล์ทรัพยากรที่รวมมาโดยไม่มีข้อผิดพลาด (NoClassDefFoundError) ซึ่งจะช่วยให้การอัปเกรดเป็นไปอย่างราบรื่นและไม่มีช่วงพักการทำงาน

ตัวอย่างโค้ด: คำสั่งตรวจสอบ XML และคำอธิบายประกอบการแยกวิเคราะห์

พิจารณา Java Callout ของ Apigee ทั่วไปที่แยกและตรวจสอบคำสั่งซื้อ XML ขาเข้าโดยใช้ JAXB (JAXBContext และ Unmarshaller)

  • ก่อนการแก้ไข (ไม่สำเร็จใน Edge for Private Cloud 4.54.00): ใน Edge for Private Cloud 4.53.x แพ็กเกจพร็อกซีจะมีเฉพาะ JAR ของไฮไลต์ โดยอาศัยไลบรารีรันไทม์ Java 8 ในตัวสำหรับ JAXB ดังนี้ 
    apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar   <-- No JAXB JAR bundled

    การใช้งาน Java Callout:

    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 สำหรับ Private Cloud 4.53.x การดำเนินการนี้จะทำงานโดยไม่มีปัญหา เมื่ออัปเกรดโหนดเป็น Edge สำหรับ Private Cloud 4.54.00 พร็อกซีนี้จะล้มเหลวทันทีในระหว่างการประมวลผลคำขอ

    java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
        at com.example.callout.OrderXmlParserCallout.execute(OrderXmlParserCallout.java:20)
  • หลังจากการแก้ไข (เข้ากันได้ทั้ง Edge สำหรับ Private Cloud 4.53.x และ 4.54.00): คุณไม่จำเป็นต้องเขียนใหม่หรือคอมไพล์โค้ด Java Callout ใหม่ คุณสามารถทำให้พร็อกซีเข้ากันได้ทั้ง 2 แบบโดยตรงโดยระบุ 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 เป็นไฟล์ทรัพยากรโดยใช้ Resource Files API ระดับพร็อกซี หรือที่ระดับสภาพแวดล้อมหรือระดับองค์กรก็ได้ เพื่อให้พร็อกซีทั้งหมดในขอบเขตเดียวกันแชร์ไฟล์เหล่านี้ได้โดยไม่ต้องรวมไว้ในแพ็กเกจพร็อกซีแต่ละรายการ

      หากคุณสร้างแพ็กเกจพร็อกซีจากแหล่งที่มาโดยใช้ Maven ให้ประกาศทรัพยากร Dependency เหล่านี้ใน pom.xml เพื่อให้ระบบจัดแพ็กเกจโดยอัตโนมัติในระหว่างการสร้าง

    2. ติดตั้งใช้งานและทดสอบในคลัสเตอร์ 4.53.x ปัจจุบัน: ติดตั้งใช้งานชุดพร็อกซีที่อัปเดตแล้วในสภาพแวดล้อม Edge สำหรับ Private Cloud 4.53.x ที่มีอยู่ แล้วส่งการโทรทดสอบ เนื่องจาก Message Processor ของ 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) ปิดใช้การโหลดแพ็กเกจที่อนุญาตภายนอกโดยค่าเริ่มต้น ให้เปิดใช้ในแต่ละโหนด Message Processor ใน /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) ดังนี้ 
      conf_system_java.21.enable.external.allowed.packages=true
    4. ไม่มีปัญหาการเข้าชมจริงหลังการอัปเกรด: เมื่อได้รับการตรวจสอบในสภาพแวดล้อม 4.53.x และกำหนดค่าด้วยพร็อพเพอร์ตี้ CwC แล้ว พร็อกซีของคุณจะพร้อมใช้งานอย่างเต็มที่ เมื่ออัปเกรดคลัสเตอร์เป็น Edge สำหรับ Private Cloud 4.54.00 แล้ว Message Processor จะโหลดคลาส JAXB ที่รวมมาด้วย เพื่อให้มั่นใจว่าไม่มีข้อผิดพลาดและไม่มีการหยุดชะงักของการเข้าชมแบบเรียลไทม์

กลยุทธ์ที่ 2: การติดตั้งใช้งานทางเลือก (การปรับโค้ดและการขึ้นต่อกันให้ทันสมัย)

กรณีที่ควรใช้: แนะนำสำหรับฐานของโค้ดที่ใช้งานอยู่ซึ่งมีการดูแลรักษาซอร์สโค้ดพร็อกซีอย่างสม่ำเสมอ ซึ่งเป็นแนวทางระยะยาวที่ชัดเจนที่สุดสำหรับการปฏิบัติตามข้อกำหนดของ Java 21 หมายเหตุเกี่ยวกับการเปิดตัว: เนื่องจากการติดตั้งใช้งานการแก้ไขพร็อกซีที่ปรับปรุงใหม่ต้องมีการประสานงานกับ Message Processor ให้จับคู่กลยุทธ์นี้กับกลยุทธ์ 3A (ในช่วงเวลาบำรุงรักษาที่วางแผนไว้) หรือกลยุทธ์ 3B (เพื่อให้ไม่มีช่วงเวลาที่ระบบหยุดทำงานด้วย Message Processor แบบคู่ขนาน)

วิธีการทำงาน: แทนที่คลาสภายใน Java ที่ถูกนำออกด้วย Java SE API มาตรฐานอย่างเป็นทางการหรือรายการเทียบเท่าแบบสแตนด์อโลนโอเพนซอร์ส และแพ็กเกจทรัพยากร Dependency ของบุคคลที่สามที่จำเป็นโดยตรงภายในไฟล์ทรัพยากรแพ็กเกจพร็อกซีหรือ POM

ตัวอย่างโค้ด

ตัวอย่างที่ 1: การปรับปรุงวิธีการและโค้ดให้ทันสมัย (การแทนที่ยูทิลิตีภายในที่ถูกนำออก)

ใน Java 8 การเรียกใช้มักใช้คลาสยูทิลิตีภายใน เช่น sun.misc.BASE64Encoder ใน Java สมัยใหม่ คลาสเหล่านี้ถูกนำออกไปแล้ว แต่ API 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;
    }
}
ตัวอย่างที่ 2: การเปลี่ยนโครงสร้างภายในโค้ดระดับการนำเข้าด้วยไลบรารีที่รวมมา (JAXB Namespace Prefix Mapper)

ใน Java 8 พร็อกซี API ที่ปรับแต่งคำนำหน้าเนมสเปซ XML มักจะขยาย JAXB Mapper ภายในของ Sun 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;
    }
}
  • การกำหนดค่าทรัพยากร Dependency ที่รวมมา (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>

กลยุทธ์ที่ 3ก: ช่วงเวลาหยุดทำงานเพื่อบำรุงรักษาตามกำหนดการ (การติดตั้งใช้งานซ้ำในตำแหน่งเดิม)

กรณีที่ควรใช้: แนะนำสำหรับสภาพแวดล้อมที่มีช่วงเวลาบำรุงรักษาตามกำหนดเวลา ซึ่งยอมรับการหยุดชะงักของบริการเป็นระยะเวลาสั้นๆ ได้

ขั้นตอน

  1. ประสานงานช่วงเวลาบำรุงรักษาที่กำหนดเวลากับผู้ใช้ API
  2. อัปเกรดคอมโพเนนต์ Edge สำหรับ Private Cloud เป็นเวอร์ชัน 4.54.00 โดยทำตามคู่มือเส้นทางการอัปเกรด
  3. ติดตั้งใช้งานการแก้ไขพร็อกซี API ที่คอมไพล์ล่วงหน้าและเข้ากันได้กับ 4.54.00 โดยใช้ New Edge UI หรือ Apigee Management API (Deployments)
  4. ยืนยันการดำเนินการคำขอไฮบริดโดยส่งคำขอทดสอบสังเคราะห์ไปยัง Message Processor และตรวจสอบบันทึกโดยใช้เครื่องมือติดตาม
  5. ปิดช่วงเวลาบำรุงรักษาและเปิดให้มีการเข้าชมแบบสาธารณะอีกครั้ง

กลยุทธ์ 3B: สร้างสภาพแวดล้อมใหม่ (การย้ายข้อมูลแบบไม่มีช่วงเวลาที่ระบบหยุดทำงาน)

กรณีที่ควรใช้: แนะนำสำหรับสภาพแวดล้อมฮาร์ดแวร์และซอฟต์แวร์ที่สำคัญต่อภารกิจซึ่งต้องไม่มีช่วงเวลาที่ระบบหยุดทำงาน ใช้ตัวเลือกนี้เมื่อไม่สามารถอัปเดต Java Callout ให้ทำงานใน Java 8 และ Java 21 พร้อมกันได้

วิธีการทำงาน: กลยุทธ์นี้เกี่ยวข้องกับการจัดหาสภาพแวดล้อมใหม่อย่างน้อย 1 รายการเพื่อให้คุณเชื่อมต่อโหนด Message Processor เวอร์ชันต่างๆ เข้ากับสภาพแวดล้อมดังกล่าวได้ จากนั้นให้ติดตั้งใช้งานพร็อกซีที่เข้ากันได้กับ Java 8 ในสภาพแวดล้อมที่เชื่อมต่อกับ Message Processor 4.53.X และพร็อกซีที่เข้ากันได้กับ Java 21 ในสภาพแวดล้อมที่เชื่อมต่อกับ Message Processor 4.54.00 จากนั้นใช้ตัวจัดสรรภาระงานหรือเทคนิคการกำหนดเส้นทางอื่นๆ เพื่อกำหนดเส้นทางการรับส่งข้อมูลไปยังพร็อกซีที่เข้ากันได้กับ Java 21 เท่านั้น

สำหรับกลยุทธ์นี้ การทำความเข้าใจวิธีที่องค์กร สภาพแวดล้อม และ Message Processor โต้ตอบกันเป็นกุญแจสำคัญในการเปลี่ยนระบบโดยไม่มีการหยุดทำงาน (ดูข้อมูลเพิ่มเติมได้ที่โครงสร้างองค์กร Apigee Edge)

  • องค์กร Apigee คือขอบเขตการดูแลระบบระดับบนสุดที่มีสภาพแวดล้อมหลายรายการ (เช่น prod, test)
  • ระบบจะทำให้การแก้ไขพร็อกซี API ใช้งานได้ในสภาพแวดล้อมที่เฉพาะเจาะจง เฉพาะ Message Processor ที่เชื่อมโยงกับสภาพแวดล้อมนั้นอย่างชัดเจนเท่านั้นที่จะโหลดและเรียกใช้การแก้ไขพร็อกซี
+------------------------------------------------------------------------+
|                          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. จัดสรรโหนด Message Processor เวอร์ชัน 4.54.00: ติดตั้ง Edge สำหรับ Private Cloud เวอร์ชัน 4.54.00 ในอินสแตนซ์ VM ใหม่หรือชั่วคราว แล้วเชื่อมโยงโหนดเหล่านี้กับ prod-migration (ดูหัวข้อการเพิ่ม Message Processor)
  3. ระบุพร็อกซีที่ได้รับผลกระทบและสร้างการแก้ไขที่อัปเดตแล้ว: ระบุพร็อกซี API โดยใช้ Java Callout (ใช้เครื่องมือตรวจหาการเปลี่ยนแปลง) และสร้างการแก้ไขใหม่ของพร็อกซีที่ได้รับผลกระทบแต่ละรายการด้วย Java Callout ที่เข้ากันได้กับ Edge สำหรับ Private Cloud 4.54.00 (ใช้กลยุทธ์ที่ 1 หรือกลยุทธ์ที่ 2)
  4. ติดตั้งใช้งานการแก้ไขพร็อกซีที่ปรับปรุงใหม่ในสภาพแวดล้อมชั่วคราว: ติดตั้งใช้งานการแก้ไขพร็อกซีที่อัปเดตและเข้ากันได้ใน prod-migration เท่านั้น
  5. ตรวจสอบและเปลี่ยนเส้นทางการเข้าชม: ดำเนินการทดสอบการตรวจสอบสังเคราะห์กับโฮสต์เสมือนใหม่ เมื่อยืนยันแล้ว ให้กำหนดค่าตัวจัดสรรภาระงานภายนอก (F5, NGINX) เพื่อเปลี่ยนเส้นทางการเข้าชมของไคลเอ็นต์จาก prod ไปยัง prod-migration
  6. อัปเกรดโหนดเดิมและเปลี่ยนกลับ: ยกเลิกการติดตั้งใช้งานพร็อกซีเดิมจาก prod อัปเกรดโหนด Message Processor เดิมเป็น 4.54.00 โดยทำตามคำแนะนำเกี่ยวกับเส้นทางการอัปเกรด ทำให้การแก้ไขพร็อกซีที่ปรับปรุงใหม่ใช้งานได้ใน prod เปลี่ยนเส้นทางการรับส่งข้อมูลของตัวจัดสรรภาระงานกลับไปยัง prod และยืนยันการดำเนินการ
  7. เลิกใช้งานสภาพแวดล้อมชั่วคราว: ยกเลิกการติดตั้งใช้งานพร็อกซีจาก prod-migration นำโหนด Message Processor ชั่วคราวออก และลบสภาพแวดล้อมชั่วคราว

กลยุทธ์ 3C: การจัดวางไลบรารีภายนอกระดับโหนด (ไลบรารีสำรองที่ใช้ร่วมกัน)

กรณีที่ควรใช้: ขอแนะนำเมื่อคุณมีพร็อกซี API หลายรายการที่ต้องใช้คลาส Java ที่นำออกใน Java 21 และการคอมไพล์หรือการจัดแพ็กเกจพร็อกซีแต่ละรายการใหม่ก่อนการอัปเกรดนั้นไม่สามารถทำได้ในทางปฏิบัติ

วิธีการทำงาน: ใน Edge สำหรับ Private Cloud 4.54.00 Message Processor จะมีกลไกในการโหลดคลาส Java ที่ขาดหายไปจากไดเรกทอรีโหนดเฉพาะ $APIGEE_ROOT/data/edge-message-processor/external-lib

เมื่อเปิดใช้กลไกนี้ Message Processor จะตรวจสอบไดเรกทอรีนี้เพื่อหาคลาสที่ขาดหายไปก่อนที่จะกลับไปใช้ความละเอียดเริ่มต้น คุณสามารถระบุคลาสที่ขาดหายไปได้โดยการจัดหาคลาสจาก JAR ของไลบรารีของบุคคลที่สาม หรือโดยการรวมคลาสที่จำเป็นไว้ใน JAR แล้ววางไว้ใน external-lib

ขั้นตอน

  1. สร้างไดเรกทอรีไลบรารีภายนอกในโหนด Message Processor แต่ละโหนด 
    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. เปิดใช้การโหลดแพ็กเกจภายนอกในการกำหนดค่า Message Processor: โดยค่าเริ่มต้นใน Edge สำหรับ Private Cloud 4.54.00 ระบบจะปิดใช้การโหลดแพ็กเกจที่อนุญาตภายนอก (conf_system_java.21.enable.external.allowed.packages=false) หากต้องการเปิดใช้ Message Processor เพื่อแก้ไขและโหลดคลาสจาก /opt/apigee/data/edge-message-processor/external-lib คุณต้องเปิดใช้พร็อพเพอร์ตี้นี้ใน /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) 
    conf_system_java.21.enable.external.allowed.packages=true
  5. รีสตาร์ท Message Processor: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

กลยุทธ์ที่ 4: แฟล็ก JVM (--add-opens / --add-exports — ข้อควรระวังและทางเลือกสุดท้าย)

กรณีที่ควรใช้: ใช้กลยุทธ์นี้เป็นทางเลือกสุดท้ายสำหรับไลบรารีของผู้ให้บริการบุคคลที่สามแบบโคลสซอร์สที่ไม่มีซอร์สโค้ด ผู้ให้บริการยังไม่ได้เผยแพร่การอัปเดต Java 21 และ JAR ขึ้นอยู่กับการเข้าถึงแบบสะท้อนแสงไปยังแพ็กเกจ Java ภายในอย่างเคร่งครัด

ขั้นตอน

  1. ระบุแพ็กเกจที่เข้าถึงไม่ได้ซึ่งใช้สำหรับการรีเฟลกชัน: ระบุโมดูลและแพ็กเกจ Java ภายในที่ไลบรารีของบุคคลที่สามเข้าถึงแบบรีเฟลกทีฟ หมายเหตุ: ข้อผิดพลาดในการรีเฟลกชันเหล่านี้จะเกิดขึ้นใน Java 21 ใน Edge for Private Cloud 4.54.00 เท่านั้น และจะไม่ปรากฏในบันทึกของเวอร์ชัน 4.53.x ตรวจสอบบันทึกของ Message Processor (/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. แก้ไข /opt/apigee/customer/application/message-processor.properties โดยใช้โค้ดที่มีการกำหนดค่า (CwC) (สร้างไฟล์หากไม่มี)
  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. รีสตาร์ท Message Processor โดยใช้ apigee-service ดังนี้ 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

การเปลี่ยนแปลง TLS และชุดการเข้ารหัส

ใน Edge for Private Cloud 4.54.00 คอมโพเนนต์แพลตฟอร์มหลัก ซึ่งรวมถึง Message Processor, Management Server และเราเตอร์ ได้รับการอัปเดตให้ทำงานบน Java 21 LTS การอัปเดตนี้จะปรับปรุงความปลอดภัยด้านการเข้ารหัสให้ทันสมัยโดยเปิดใช้ TLS 1.3 โดยค่าเริ่มต้น (JEP 332) ตอนนี้ Message Processor จะเจรจา TLS 1.3 เป็นโปรโตคอลที่ต้องการสำหรับการเชื่อมต่อแบ็กเอนด์ขาออก และจะกลับไปใช้ TLS 1.2 ในกรณีที่แบ็กเอนด์ไม่รองรับ

ข้อกำหนดและวิธีแก้ไขแบ็กเอนด์เวอร์ชันเดิม

การอัปเดตพื้นฐานการเข้ารหัสของ Java 21 จะอัปเดตรายการโปรโตคอลและชุดการเข้ารหัสที่ปิดใช้โดยค่าเริ่มต้นใน jdk.tls.disabledAlgorithms (เช่น โปรโตคอล TLS เดิมและชุดการแลกเปลี่ยนคีย์ RSA แบบคงที่ที่ไม่ใช่แบบส่งต่อที่ปลอดภัย: TLS_RSA_*) เนื่องจากคุณจัดหารันไทม์ Java 21 ของคุณเอง รายการโปรโตคอลและชุดการเข้ารหัสที่ปิดใช้จึงขึ้นอยู่กับการติดตั้งใช้งาน Java 21 ที่เฉพาะเจาะจงของคุณ

หากพร็อกซี API ที่มีอยู่เชื่อมต่อกับโครงสร้างพื้นฐานของแบ็กเอนด์เดิมที่ต้องใช้โปรโตคอลที่ปิดใช้หรือการเข้ารหัส RSA แบบคงที่ ให้ตรวจสอบการดำเนินการต่อไปนี้

  • ปรับปรุงความปลอดภัยของแบ็กเอนด์ให้ทันสมัย (แนะนำ): อัปเกรดเซิร์ฟเวอร์เป้าหมายและตัวจัดสรรภาระงานให้รองรับ TLS 1.2 หรือ TLS 1.3 ด้วยชุดการเข้ารหัส ECDHE ที่ทันสมัย หากต้องการกำหนดค่าโปรโตคอลและชุดการเข้ารหัสในพร็อกซี API โปรดดูการกำหนดค่า TLS จาก Edge ไปยังแบ็กเอนด์และข้อมูลอ้างอิงการกำหนดค่า TLS/SSL TargetEndpoint (หรือการจัดสรรภาระงานในเซิร์ฟเวอร์แบ็กเอนด์หากใช้ TargetServers)
  • เปิดใช้อัลกอริทึมเดิมอีกครั้งโดยใช้ CwC (มาตรการเปลี่ยนผ่านระหว่างการอัปเกรด): หากการอัปเกรดแบ็กเอนด์ไม่เสร็จสมบูรณ์ก่อนการอัปเกรดแพลตฟอร์ม คุณสามารถเปิดใช้อัลกอริทึมที่จำเป็นอีกครั้งชั่วคราวโดยใช้โค้ดที่มีการกำหนดค่า (CwC) ดังนี้
    1. ตรวจสอบค่า jdk.tls.disabledAlgorithms เริ่มต้นในการติดตั้ง Java 21 (เช่น ใน $JAVA_HOME/conf/security/java.security)
    2. ลบล้าง conf_jvmsecurity_jdk.tls.disabledAlgorithms ใน /opt/apigee/customer/application/message-processor.properties ด้วยรายการอัลกอริทึมที่ปิดใช้รายการเดียวกัน โดยนำเฉพาะรายการ TLS_RSA_* ออก (เก็บอัลกอริทึมที่ปิดใช้รายการอื่นๆ ทั้งหมดไว้เหมือนเดิมเพื่อให้การป้องกันที่เหลือยังคงเปิดใช้อยู่)
    3. รีสตาร์ท Message Processor โดยใช้ apigee-service นำการลบล้างนี้ออกเมื่อแบ็กเอนด์รองรับชุดการเข้ารหัส ECDHE
  • อัปเดตรายการที่อนุญาตของชุดการเข้ารหัสที่กำหนดเอง: หากก่อนหน้านี้คุณลบล้าง conf_http_HTTPTransport.ssl.cipher.suites.whitelist ไว้ ให้ตรวจสอบก่อนอัปเกรด Java 21 ไม่รองรับชุด RSA แบบคงที่ (TLS_RSA_*) อีกต่อไป ดังนั้นรายการที่อนุญาตซึ่งมีเฉพาะชุดเหล่านั้นจะทำให้ Message Processor ไม่มีรหัสที่ใช้งานได้ และการเรียกใช้แบ็กเอนด์จะล้มเหลวพร้อมข้อความ no cipher suites in common นำรายการ TLS_RSA_* ออกและกำหนดค่าชุดการเข้ารหัสที่ทันสมัยซึ่งรองรับโดยการติดตั้งใช้งาน Java 21 หากคุณไม่ได้ลบล้างพร็อพเพอร์ตี้นี้ ค่าเริ่มต้น 4.54.00 จะมีชุดที่รองรับอยู่แล้วและไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ
  • อัปเดตเราเตอร์ภายในเป็นชุดการเข้ารหัส Message Processor: หากก่อนหน้านี้คุณลบล้าง conf_message-processor-communication_local.http.ssl.ciphers ด้วยชุด RSA แบบคงที่ ให้อัปเดตด้วยชุดการเข้ารหัสสมัยใหม่ที่รองรับโดยการติดตั้งใช้งาน Java 21 ก่อนอัปเกรด ไม่เช่นนั้นเราเตอร์จะไม่สามารถทำแฮนด์เชค TLS กับ Message Processor ได้ จากนั้นรีสตาร์ท Message Processor โดยทำดังนี้ 
    apigee-service edge-message-processor restart
     ดูหัวข้อการกำหนดค่า TLS ระหว่างเราเตอร์กับ Message Processor

ดูรายละเอียดเกี่ยวกับการกำหนดค่า TLS ระหว่างคอมโพเนนต์ Edge ได้ที่หัวข้อการกำหนดค่า TLS ระหว่างเราเตอร์กับ Message Processor

เครื่องมือตรวจหาการเปลี่ยนแปลง

Apigee มีเครื่องมือตรวจหาการเปลี่ยนแปลงเพื่อสแกนคลัสเตอร์หาพร็อกซี API, นโยบาย, โฟลว์ที่ใช้ร่วมกัน และ JAR ทรัพยากรที่อาจได้รับผลกระทบจากการอัปเกรดเป็น Edge สำหรับ Private Cloud 4.54.00

เครื่องมือนี้จะระบุตัวบล็อกการอัปเกรดที่อาจเกิดขึ้น ซึ่งรวมถึงไลบรารีที่เข้ากันไม่ได้กับ Java 21, API ภายในที่แคปซูลอย่างเข้มงวด, การเลิกใช้งานนโยบายเดิม และขีดจำกัด RDN ของ OpenLDAP และสร้างรายงานที่นำไปใช้ได้จริงเพื่อช่วยคุณเลือกกลยุทธ์การแก้ไขที่เหมาะสม

ดูข้อกำหนดเบื้องต้น คำแนะนำในการดาวน์โหลด ไวยากรณ์บรรทัดคำสั่ง และรายงานตัวอย่างทั้งหมดได้ในคู่มือเครื่องมือตรวจหาการเปลี่ยนแปลงโดยเฉพาะ