การเปลี่ยนไปใช้แหล่งความปลอดภัย Cognos อื่น

เมื่อคุณต้องการกำหนดคอนฟิกสภาพแวดล้อม Cognos ที่มีอยู่ใหม่เพื่อใช้แหล่งการรักษาความปลอดภัยภายนอกอื่น (เช่น Active Directory, LDAP ฯลฯ) มีวิธีการจำนวนหนึ่งที่คุณสามารถทำได้ ฉันชอบเรียกพวกเขาว่า "ดี เลว และน่าเกลียด" ก่อนที่เราจะสำรวจแนวทางที่ดี ไม่ดี และน่าเกลียด มาดูสถานการณ์ทั่วไปบางอย่างที่มีแนวโน้มว่าจะขับเคลื่อนการเปลี่ยนแปลงเนมสเปซการพิสูจน์ตัวตนในสภาพแวดล้อม Cognos

ตัวขับเคลื่อนธุรกิจทั่วไป:

กำลังอัปเดตฮาร์ดแวร์หรือ OS – การปรับปรุงฮาร์ดแวร์/โครงสร้างพื้นฐาน BI ให้ทันสมัยอาจเป็นตัวขับเคลื่อนที่ใช้บ่อย ในขณะที่ส่วนที่เหลือของ Cognos อาจทำงานได้เหมือนแชมป์บนฮาร์ดแวร์ใหม่ที่ทันสมัยและระบบปฏิบัติการ 64 บิตที่ทันสมัย ​​ขอให้โชคดีในการโยกย้าย Access Manager เวอร์ชันประมาณปี 2005 ของคุณไปยังแพลตฟอร์มใหม่นั้น Access Manager (เปิดตัวครั้งแรกด้วย Series 7) เป็นสิ่งที่น่ายกย่องจากวันที่ผ่านไปสำหรับลูกค้า Cognos จำนวนมาก เป็นเหตุผลเดียวที่ลูกค้าจำนวนมากใช้ Windows Server 2003 เวอร์ชันเก่าที่ไม่เหมาะสม การเขียนดังกล่าวจึงเกิดขึ้นกับ Access Manager มาระยะหนึ่งแล้ว เป็นซอฟต์แวร์รุ่นเก่า ยิ่งคุณเปลี่ยนจากมันได้เร็วเท่าไหร่ก็ยิ่งดีเท่านั้น

แอปพลิเคชันมาตรฐาน– องค์กรที่ต้องการรวมการรับรองความถูกต้องของแอปพลิเคชันทั้งหมดกับเซิร์ฟเวอร์ไดเรกทอรีขององค์กรที่ควบคุมจากส่วนกลาง (เช่น LDAP, AD)

การควบรวมและการซื้อกิจการ– บริษัท A ซื้อบริษัท B และต้องการให้สภาพแวดล้อม Cognos ของบริษัท B ชี้ไปที่ไดเร็กทอรีเซิร์ฟเวอร์ของบริษัท A โดยไม่ทำให้เกิดปัญหากับเนื้อหาหรือการกำหนดค่า BI ที่มีอยู่

การเลิกกิจการของบริษัท– นี่คือสิ่งที่ตรงกันข้ามกับสถานการณ์สมมติการควบรวมกิจการ ส่วนหนึ่งของบริษัทถูกแยกออกเป็นเอนทิตีของตนเอง และตอนนี้จำเป็นต้องชี้ให้เห็นถึงสภาพแวดล้อม BI ที่มีอยู่ในแหล่งความปลอดภัยใหม่

เหตุใดการโยกย้ายเนมสเปซจึงยุ่งเหยิง

การชี้สภาวะแวดล้อม Cognos ไปยังแหล่งการรักษาความปลอดภัยใหม่นั้นไม่ง่ายเท่ากับการเพิ่มเนมสเปซใหม่ที่มีผู้ใช้ กลุ่ม และบทบาทเดียวกัน การตัดการเชื่อมต่อเนมสเปซเก่า และ VOALA!- ผู้ใช้ Cognos ทั้งหมดของคุณในเนมสเปซใหม่จะถูกจับคู่ด้วย เนื้อหาของพวกเขา ที่จริงแล้ว คุณมักจะลงเอยด้วยเลือดเปื้อนมือ และนี่คือเหตุผล...

หลักการรักษาความปลอดภัย Cognos ทั้งหมด (ผู้ใช้ กลุ่ม บทบาท) ถูกอ้างอิงโดยตัวระบุเฉพาะที่เรียกว่า CAMID แม้ว่าแอตทริบิวต์อื่น ๆ ทั้งหมดจะเท่ากัน CAMID สำหรับผู้ใช้ใน an ที่มีอยู่ เนมสเปซการพิสูจน์ตัวตนจะไม่เหมือนกับ CAMID สำหรับผู้ใช้นั้นใน ใหม่ เนมสเปซ สิ่งนี้สามารถทำลายล้างสภาพแวดล้อม Cognos ที่มีอยู่ได้ แม้ว่าคุณจะมีผู้ใช้ Cognos เพียงไม่กี่ราย คุณต้องตระหนักว่าการอ้างอิง CAMID มีอยู่ในที่ต่างๆ มากมายในที่เก็บเนื้อหาของคุณ (และสามารถมีอยู่ภายนอกที่เก็บเนื้อหาของคุณในโมเดล Framework, Transformer Models, TM1 Applications, Cubes, Planning Applications เป็นต้น ).

ลูกค้า Cognos หลายคนเข้าใจผิดคิดว่า CAMID มีความสำคัญกับเนื้อหา My Folder การกำหนดค่าตามความชอบของผู้ใช้ ฯลฯ เท่านั้น สิ่งนี้ไม่สามารถเพิ่มเติมจากความจริงได้ ไม่ใช่แค่จำนวนผู้ใช้ที่คุณมีเท่านั้น แต่ยังเป็นจำนวนอ็อบเจ็กต์ Cognos ที่คุณต้องให้ความสำคัญ มีอ็อบเจ็กต์ Cognos มากกว่า 140 ชนิดใน Content Store ซึ่งส่วนใหญ่อาจมีการอ้างอิง CAMID หลายรายการ.

ตัวอย่างเช่น:

1. ไม่ใช่เรื่องแปลกที่กำหนดการเดียวในที่เก็บเนื้อหาของคุณจะมีการอ้างอิง CAMID หลายรายการ (CAMID ของเจ้าของกำหนดการ, CAMID ของผู้ใช้ที่กำหนดการควรรันเป็น, CAMID ของผู้ใช้แต่ละรายหรือรายชื่อการแจกจ่าย ซึ่งควรส่งเอาต์พุตรายงานไปยังอีเมล เป็นต้น)
2. ทุกอ็อบเจ็กต์ใน Cognos มีนโยบายความปลอดภัยที่ควบคุมว่าผู้ใช้รายใดสามารถเข้าถึงอ็อบเจ็กต์ได้ (คิดว่า “แท็บสิทธิ์”) นโยบายความปลอดภัยเดียวที่ระงับโฟลเดอร์นั้นใน Cognos Connection มีการอ้างอิง CAMID สำหรับผู้ใช้แต่ละราย กลุ่ม & บทบาทที่ระบุไว้ในนโยบายนั้น
3. หวังว่าคุณจะเข้าใจประเด็นนี้ – รายการนี้ดำเนินต่อไป!

ไม่ใช่เรื่องแปลกที่ Content Store ขนาดใหญ่จะมีข้อมูลอ้างอิง CAMID หลายหมื่นรายการ (และเราเคยเห็นรายการขนาดใหญ่บางรายการที่มีข้อมูลอ้างอิงหลายแสนรายการ)

ทีนี้ลองคำนวณดูว่ามีอะไรอยู่ในนั้นบ้าง ธุรกิจ สภาวะแวดล้อม Cognos และคุณจะเห็นว่าคุณกำลังจัดการกับการอ้างอิง CAMID จำนวนมาก อาจเป็นฝันร้าย! การเปลี่ยน (หรือกำหนดค่าใหม่) เนมสเปซการรับรองความถูกต้องของคุณสามารถปล่อยให้การอ้างอิง CAMID เหล่านี้ทั้งหมดอยู่ในสถานะที่ไม่สามารถแก้ไขได้ สิ่งนี้นำไปสู่ปัญหาเนื้อหา & คอนฟิกูเรชันของ Cognos อย่างหลีกเลี่ยงไม่ได้ (เช่น กำหนดการที่ไม่ได้รันแล้ว เนื้อหาที่ไม่ปลอดภัยในแบบที่คุณคิดอีกต่อไป แพ็กเกจหรือคิวบ์ที่ไม่ใช้การรักษาความปลอดภัยระดับข้อมูลอย่างถูกต้องอีกต่อไป การสูญเสียเนื้อหาและผู้ใช้ My Folder ความชอบ ฯลฯ)

วิธีการเปลี่ยนเนมสเปซ Cognos

ตอนนี้ เมื่อรู้ว่าสภาพแวดล้อม Cognos สามารถมีการอ้างอิง CAMID หลายหมื่นรายการที่ต้องการการค้นหา การแม็พ และการอัพเดตเป็นค่า CAMID ใหม่ที่สอดคล้องกันในเนมสเปซการพิสูจน์ตัวตนใหม่ มาพูดคุยถึงแนวทาง Good, Bad & Ugly สำหรับการแก้ปัญหานี้

ดี: การแทนที่เนมสเปซด้วย Persona

วิธีแรก (การแทนที่เนมสเปซ) ใช้ Motio's, บุคลิกภาพไอคิว ผลิตภัณฑ์. โดยใช้วิธีการนี้ เนมสเปซที่มีอยู่ของคุณจะถูก “แทนที่” ด้วยเนมสเปซ Persona พิเศษที่อนุญาตให้คุณจำลองหลักการรักษาความปลอดภัยทั้งหมดที่เปิดเผยต่อ Cognos หลักการรักษาความปลอดภัยที่มีอยู่ก่อนจะเปิดเผยต่อ Cognos ด้วย CAMID ที่เหมือนกันทุกประการ แม้ว่าอาจถูกสำรองโดยแหล่งความปลอดภัยภายนอกจำนวนเท่าใดก็ได้ (เช่น Active Directory, LDAP หรือแม้แต่ฐานข้อมูล Persona)

ส่วนที่สวยงามเกี่ยวกับวิธีการนี้คือต้องการการเปลี่ยนแปลงเป็นศูนย์ในเนื้อหา Cognos ของคุณ เนื่องจาก Persona สามารถรักษา CAMID ของหลักการที่มีอยู่ก่อนได้ แม้ว่าจะได้รับการสนับสนุนจากแหล่งข้อมูลใหม่ก็ตาม ดังนั้น… การอ้างอิง CAMID นับหมื่นเหล่านั้นใน Content Store ของคุณ โมเดลภายนอก และคิวบ์เชิงประวัติศาสตร์? พวกเขาสามารถอยู่ได้อย่างที่เป็นอยู่ ไม่จำเป็นต้องมีงานทำ

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

Bad: การโยกย้ายเนมสเปซโดยใช้ Persona

ถ้าวิธีง่ายๆ ที่มีความเสี่ยงต่ำ ไม่ใช่ชาสักถ้วยของคุณแล้วล่ะก็ is ทางเลือกอื่น

Persona ยังสามารถใช้เพื่อทำการโยกย้ายเนมสเปซ

สิ่งนี้เกี่ยวข้องกับการติดตั้งเนมสเปซการพิสูจน์ตัวตนที่สองในสภาพแวดล้อม Cognos ของคุณ การแม็พ (หวังว่า) หลักการรักษาความปลอดภัยที่มีอยู่ทั้งหมดของคุณ (จากเนมสเปซเก่า) กับหลักการที่สอดคล้องกันในเนมสเปซใหม่ จากนั้น (นี่คือส่วนที่สนุก) การค้นหา แมปและการอัพเดตทุก การอ้างอิง CAMID เดียวที่มีอยู่ในสภาวะแวดล้อม Cognos ของคุณ : ที่เก็บเนื้อหา, Framework Models, Transformer Models, Historical cubes, TM1 Applications, Planning Applications เป็นต้น

แนวทางนี้มีแนวโน้มที่จะเน้นหนักและดำเนินการอย่างเข้มข้น แต่ถ้าคุณเป็นผู้ดูแลระบบ Cognos ที่ต้องการอะดรีนาลีนที่พุ่งพล่านเพื่อให้รู้สึกมีชีวิตชีวา (และไม่สนใจโทรศัพท์ตอนดึก/ตอนเช้า) บางที... นี้ เป็นตัวเลือกที่คุณกำลังมองหา?

Persona สามารถใช้เพื่อช่วยทำให้บางส่วนของกระบวนการนี้เป็นแบบอัตโนมัติ มันจะช่วยให้คุณสร้างแผนที่ระหว่างหลักการรักษาความปลอดภัยเก่ากับหลักการรักษาความปลอดภัยใหม่ ทำให้ตรรกะ "ค้นหา วิเคราะห์ อัปเดต" ของกำลังดุร้ายเป็นอัตโนมัติสำหรับเนื้อหาในที่เก็บเนื้อหาของคุณ ฯลฯ สิ่งที่ Persona สามารถทำให้งานบางอย่างเป็นไปโดยอัตโนมัติได้มาก ของการทำงานในแนวทางนี้เกี่ยวข้องกับ "คนและกระบวนการ" มากกว่าเทคโนโลยีจริง

ตัวอย่างเช่น การรวบรวมข้อมูลเกี่ยวกับโมเดล Framework Manager ทุกรุ่น ทุกโมเดล Transformer ทุกแอปพลิเคชัน Planning / TM1 ทุกแอปพลิเคชัน SDK ใครเป็นเจ้าของ และการวางแผนว่าจะอัปเดตและแจกจ่ายซ้ำได้อย่างไร อาจเป็นงานจำนวนมาก การประสานงานการหยุดทำงานสำหรับแต่ละสภาวะแวดล้อม Cognos ที่คุณต้องการลองในนี้และหน้าต่างการบำรุงรักษา ในระหว่างที่คุณสามารถลองย้ายข้อมูลอาจเกี่ยวข้องกับการวางแผนและ "เวลาหยุดทำงาน" ของ Cognos การคิดแผนการทดสอบที่มีประสิทธิภาพ (และดำเนินการ) หลังจากการโยกย้ายของคุณอาจเป็นเรื่องที่ค่อนข้างลำบาก

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

แม้ว่า Namespace Migration with Persona จะทำงาน (และดีกว่าแนวทาง "Ugly" ด้านล่างมาก) แต่ก็เป็นการบุกรุก เสี่ยงกว่า เกี่ยวข้องกับบุคลากรมากกว่า และใช้เวลาหลายชั่วโมงในการดำเนินการมากกว่า Namespace Replacement โดยทั่วไป การโอนย้ายต้องทำระหว่าง “นอกเวลาทำการ” ในขณะที่สภาพแวดล้อม Cognos ยังคงออนไลน์อยู่ แต่ผู้ใช้ปลายทางใช้แบบฟอร์มที่จำกัด

น่าเกลียด: บริการย้ายเนมสเปซด้วยตนเอง

วิธี Ugly เกี่ยวข้องกับแนวทางที่ไม่อาจปฏิเสธได้ในการพยายาม ด้วยมือ ย้ายจากเนมสเปซการพิสูจน์ตัวตนหนึ่งไปยังอีกเนมสเปซ สิ่งนี้เกี่ยวข้องกับการเชื่อมต่อเนมสเปซการพิสูจน์ตัวตนที่สองกับสภาวะแวดล้อม Cognos ของคุณ จากนั้นพยายามย้ายหรือสร้างเนื้อหาและคอนฟิกูเรชัน Cognos ที่มีอยู่จำนวนมากด้วยตนเอง

ตัวอย่างเช่น โดยใช้วิธีการนี้ ผู้ดูแลระบบ Cognos อาจพยายาม:

1. สร้างกลุ่มและบทบาทใหม่ในเนมสเปซใหม่
2. สร้างการเป็นสมาชิกของกลุ่มและบทบาทเหล่านั้นในเนมสเปซใหม่
3. คัดลอกเนื้อหาโฟลเดอร์ของฉัน การตั้งค่าผู้ใช้ แท็บพอร์ทัล ฯลฯ ด้วยตนเองจากบัญชีต้นทางแต่ละบัญชีไปยังบัญชีเป้าหมายแต่ละบัญชี
4. ค้นหาทุกชุดนโยบายใน Content Store และอัปเดตเพื่ออ้างอิงหลักการที่เทียบเท่าในเนมสเปซใหม่ในลักษณะเดียวกับที่อ้างอิงถึงหลักการจากเนมสเปซเก่า
5. สร้างกำหนดการทั้งหมดใหม่และเติมข้อมูลรับรอง ผู้รับ ฯลฯ ที่เกี่ยวข้อง
6. รีเซ็ตคุณสมบัติ "เจ้าของ" และ "ติดต่อ" ทั้งหมดของวัตถุทั้งหมดในที่เก็บเนื้อหา
7. [อีก 40 อย่างใน Content Store ที่คุณจะลืมไป]
8. รวบรวมโมเดล FM ทั้งหมดที่มีการรักษาความปลอดภัยระดับวัตถุหรือข้อมูล:
   1. อัพเดทแต่ละรุ่นให้เหมาะสม
   2. เผยแพร่ซ้ำแต่ละรุ่น
   3. แจกจ่ายแบบจำลองที่แก้ไขแล้วกลับไปยังผู้แต่งต้นฉบับ
9. งานที่คล้ายกันสำหรับรุ่น Transformer, TM1 Applications และ Planning Applications ซึ่งยึดกับเนมสเปซเดิม
10. [และอื่น ๆ อีกมากมาย]

ในขณะที่นักทำโทษตนเองของ Cognos บางคนอาจแอบหัวเราะคิกคักด้วยความปิติเมื่อคิดที่จะคลิก 400,000 ครั้งใน Cognos Connection สำหรับผู้ที่ฉลาดหลักแหลม แนวทางนี้มักจะน่าเบื่อหน่าย ใช้เวลานาน และมีโอกาสผิดพลาดได้ง่าย นั่นไม่ใช่ปัญหาใหญ่ที่สุดสำหรับแนวทางนี้

ปัญหาที่ใหญ่ที่สุดของแนวทางนี้คือมันเกือบ เสมอ นำไปสู่การย้ายถิ่นที่ไม่สมบูรณ์

เมื่อใช้วิธีนี้ คุณจะค้นหา (อย่างเจ็บปวด) และพยายามจับคู่ข้อมูลอ้างอิง CAMID ที่คุณรู้จัก...แต่มักจะทิ้งข้อมูลอ้างอิง CAMID ทั้งหมดที่คุณ ไม่รู้เกี่ยวกับ.

เมื่อคุณ คิด คุณทำวิธีนี้เสร็จแล้ว คุณมักจะไม่ จริงๆ เสร็จแล้ว

คุณมีออบเจ็กต์ในที่เก็บเนื้อหาของคุณที่ไม่ได้รับการรักษาความปลอดภัยอย่างที่คุณคิดอีกต่อไป... คุณมีกำหนดการที่ไม่ได้ทำงานแบบที่เคยทำ คุณมีข้อมูลที่ไม่ปลอดภัยในแบบที่คุณคิดอีกต่อไป มันเป็นและคุณอาจมีข้อผิดพลาดที่ไม่ได้อธิบายสำหรับการดำเนินการบางอย่างที่ วางนิ้วไม่ได้จริงๆ.

เหตุผลที่แนวทางที่ไม่ดีและน่าเกลียดอาจเป็นเรื่องที่น่ากลัว:

• การโยกย้ายเนมสเปซอัตโนมัติทำให้เกิดความเครียดอย่างมากกับระบบจัดการเนื้อหา การตรวจสอบและการอัพเดตที่เป็นไปได้ของทุกอ็อบเจ็กต์ใน Content Store ของคุณ มักจะส่งผลให้มีการเรียก SDK หลายหมื่นครั้งไปยัง Cognos (ซึ่งเกือบทั้งหมดไหลผ่าน Content Manager) การสืบค้นที่ผิดปกตินี้มักจะขัดขวางการใช้/โหลดหน่วยความจำ และทำให้ระบบจัดการเนื้อหาเสี่ยงต่อการหยุดทำงานในระหว่างการโอนย้าย หากคุณมีความไม่เสถียรในสภาวะแวดล้อม Cognos ของคุณอยู่แล้ว คุณควรกลัวแนวทางนี้มาก
• การโยกย้ายเนมสเปซจำเป็นต้องมีช่วงเวลาการบำรุงรักษาที่ใหญ่ Cognos ต้องพร้อม แต่คุณไม่ต้องการให้ผู้อื่นทำการเปลี่ยนแปลงระหว่างกระบวนการโอนย้าย โดยทั่วไปจะต้องย้ายเนมสเปซเพื่อเริ่มต้นเมื่อไม่มีใครทำงาน สมมติว่าเวลา 10 น. ในคืนวันศุกร์ ไม่มีใครอยากเริ่มโครงการเครียดเวลา 10 น. ในคืนวันศุกร์ ไม่ต้องพูดถึง ความสามารถทางจิตของคุณอาจจะไม่ได้ทำงานที่ดีที่สุดในคืนและวันหยุดสุดสัปดาห์ในโครงการที่ ทำ ต้องเฉียบ!
• ฉันได้กล่าวถึงการโยกย้ายเนมสเปซเป็นเวลาและแรงงานเข้มข้น นี่เป็นอีกเล็กน้อยเกี่ยวกับเรื่องนั้น:
  • กระบวนการแมปเนื้อหาควรทำด้วยความแม่นยำและต้องใช้การทำงานร่วมกันเป็นทีมและชั่วโมงการทำงานจำนวนมาก
  • ต้องใช้การรันแบบแห้งหลายครั้งเพื่อตรวจสอบข้อผิดพลาดหรือปัญหาเกี่ยวกับการย้ายข้อมูล การโยกย้ายโดยทั่วไปไม่ได้สมบูรณ์แบบในการลองครั้งแรก คุณจะต้องสำรองข้อมูลที่เก็บเนื้อหาของคุณอย่างถูกต้องซึ่งสามารถกู้คืนได้ในกรณีดังกล่าว เราเคยเห็นหลายองค์กรที่ไม่มีข้อมูลสำรองที่ดี (หรือมีข้อมูลสำรองที่พวกเขาไม่ทราบว่าไม่สมบูรณ์)
  • คุณต้องระบุทุกอย่าง ด้านนอก Content Store ที่อาจได้รับผลกระทบ (โมเดลเฟรมเวิร์ก โมเดลหม้อแปลง ฯลฯ) งานนี้อาจเกี่ยวข้องกับการประสานงานระหว่างหลายทีม (โดยเฉพาะในสภาพแวดล้อม BI ขนาดใหญ่ที่ใช้ร่วมกัน)
  • คุณต้องมีแผนการทดสอบที่ดีซึ่งเกี่ยวข้องกับตัวแทนที่มีระดับการเข้าถึงเนื้อหา Cognos ของคุณในระดับต่างๆ สิ่งสำคัญคือต้องตรวจสอบหลังจากการย้ายข้อมูลเสร็จสิ้นไม่นานว่าทุกอย่างได้รับการโยกย้ายอย่างสมบูรณ์และทำงานได้ตามที่คุณคาดหวัง โดยทั่วไปแล้วจะไม่สามารถตรวจสอบทุกอย่างได้ ดังนั้นคุณจะต้องตรวจสอบสิ่งที่คุณหวังว่าจะเป็นตัวอย่างที่เป็นตัวแทน
• คุณต้องมี broad ความรู้เกี่ยวกับสภาพแวดล้อมของ Cognos และสิ่งต่าง ๆ ที่ขึ้นอยู่กับมัน ตัวอย่างเช่น คิวบ์เชิงประวัติที่มีมุมมองแบบกำหนดเองจะต้องถูกสร้างขึ้นใหม่หากคุณใช้เส้นทาง NSM
• จะเกิดอะไรขึ้นถ้าคุณหรือบริษัทที่คุณจ้างการโยกย้ายเนมสเปซเพื่อลืมบางสิ่ง เช่น...แอปพลิเคชัน SDK เมื่อคุณพลิกสวิตช์แล้ว สิ่งเหล่านี้จะหยุดทำงานหากไม่ได้รับการอัปเดตอย่างถูกต้อง คุณมีการตรวจสอบที่เหมาะสมเพื่อสังเกตสิ่งนี้ในทันทีหรือจะใช้เวลาหลายสัปดาห์ / เดือนก่อนที่อาการจะเริ่มปรากฏ?
• หากคุณได้รับการอัพเกรด Cognos จำนวนมาก คุณอาจมีอ็อบเจ็กต์ใน Content Store ของคุณที่อยู่ในสถานะที่ไม่สอดคล้องกัน หากคุณไม่ได้ใช้งาน SDK คุณจะไม่สามารถดูได้ว่าอ็อบเจ็กต์ใดอยู่ในสถานะนี้

เหตุใดการเปลี่ยนเนมสเปซจึงเป็นตัวเลือกที่ดีที่สุด

ปัจจัยเสี่ยงหลักและขั้นตอนที่ใช้เวลานานที่ฉันเพิ่งสรุปไว้จะถูกตัดออกเมื่อใช้วิธีการเปลี่ยน Persona Namespace โดยใช้วิธี Namespace Replacement คุณมีเวลาหยุดทำงานของ Cognos 5 นาที และเนื้อหาของคุณไม่ต้องเปลี่ยนแปลง วิธีการ "ดี" ดูเหมือนจะเป็นการ "ไม่ต้องคิดมาก" สำหรับฉัน คืนวันศุกร์มีไว้เพื่อการพักผ่อน ไม่เครียดกับข้อเท็จจริงที่ว่าระบบจัดการเนื้อหาของคุณเพิ่งเกิดขัดข้องในระหว่างการโยกย้ายเนมสเปซ