Yen sampeyan kudu ngatur ulang lingkungan Cognos kanggo nggunakake sumber keamanan eksternal sing beda (kayata Active Directory, LDAP, lsp), ana sawetara pendekatan sing bisa ditindakake. Aku seneng ngarani dheweke, "Sing Apik, Sing Ala, lan Sing Ala." Sadurunge nggoleki pendekatan sing Apik, Ala, lan Ala iki, ayo priksa sawetara skenario umum sing cenderung nyebabake pangowahan jeneng spasi otentikasi ing lingkungan Kognos.
Drivers Bisnis Umum:
Nganyari Piranti Lunak utawa OS - Modernisasi hardware / infrastruktur BI bisa dadi driver umum. Nalika Cognos liyane bisa mlaku kaya perangkat keras anyar sing apik lan OS 64-bit modern, muga-muga pindah versi Access Manager circa-2005 menyang platform anyar kasebut. Access Manager (pisanan dirilis karo Seri 7) minangka pangunggalan sing mulya wiwit pirang-pirang dina kepungkur kanggo akeh pelanggan Cognos. Minangka alesan siji-sijine pelanggan tetep nggawe versi lawas saka Windows Server 2003. Tulisan kasebut wis suwe banget dipasang ing tembok kanggo Access Manager. Iki minangka piranti lunak warisan. Cepet sampeyan bisa transisi adoh, luwih apik.
Standardisasi Aplikasi- Organisasi sing pengin nggabungake otentikasi kabeh aplikasi marang siji server direktori perusahaan sing pusat (kayata LDAP, AD).
Campuran & Akuisisi- Perusahaan A tuku Perusahaan B lan butuh lingkungan Kognos Perusahaan B kanggo ngarahake server direktori Perusahaan A, tanpa nyebabake masalah utawa konten BI sing ana.
Divestitur Perusahaan- Iki minangka kebalikan saka skenario penggabungan, bagean saka perusahaan sing diwiwiti menyang entitas dhewe lan saiki kudu nuduhake lingkungan BI sing ana ing sumber keamanan anyar.
Napa Migrasi Namespace bisa Rusak
Nuduhake lingkungan Kognos menyang sumber keamanan anyar ora gampang kaya nambah namesapce anyar karo pangguna, grup, lan peran sing padha, nyopot jeneng ruang lawas, lan VOILA! - kabeh pangguna Cognos sampeyan ing ruang jeneng anyar cocog karo isine Nyatane, sampeyan asring bisa nggawe kekacauan getih ing tangan sampeyan, lan mula kenapa…
Kabeh kepala sekolah keamanan Kognos (pangguna, grup, peran) dirujuk dening pengenal unik sing diarani CAMID. Sanajan kabeh atribut liyane padha, CAMID kanggo pangguna ing ana Jeneng jeneng otentikasi ora bakal padha karo CAMID kanggo pangguna kasebut ing anyar ruang jeneng Iki bisa ngrusak lingkungan Cognos sing ana. Sanajan sampeyan mung duwe sawetara pangguna Cognos, sampeyan kudu ngerti manawa referensi CAMID ana ing pirang-pirang panggonan ing Toko Konten (lan bisa uga ana ing njaba Toko Konten ing model Kerangka, Model Transformer, Aplikasi TM1, Kubus, Aplikasi Perencanaan lsp ).
Akeh pelanggan Cognos kanthi salah percaya manawa CAMID pancen mung prelu kanggo konten Folder Kula, preferensi pangguna, lsp. Iki ora bisa adoh saka kasunyatan. Ora mung masalah jumlah pangguna sing sampeyan duwe, nanging jumlah obyek Cognos sing kudu sampeyan prihatin. Ana luwih saka 140 macem-macem jinis obyek Cognos ing Toko Konten, sing akeh uga duwe sawetara referensi CAMID.
Tuladhane:
- Ora umum yen Jadwal siji ing Toko Konten sampeyan duwe macem-macem referensi CAMID (CAMID saka pemilik jadwal, CAMID pangguna sing kudu dijadwalake, CAMID saben pangguna utawa dhaptar distribusi sing ngirim email nggawe laporan lsp).
- Saben obyek ing Cognos duwe kabijakan keamanan sing ngatur pangguna sing bisa ngakses obyek kasebut (pikirake "Tab Izin"). Kebijakan keamanan siji sing ditutup folder ing Cognos Connection duwe referensi CAMID kanggo saben pangguna, grup & peran sing ditemtokake ing kabijakan kasebut.
- Muga-muga sampeyan bisa ngerti - dhaptar iki terus-terusan!
Ora umum yen Toko Konten sing cukup gedhe ngemot puluhan ewu referensi CAMID (lan kita wis ndeleng sawetara gedhe kanthi atusan ewu).
Saiki, gawe matematika babagan apa sing ana Panjenengan Lingkungan kognos lan sampeyan bisa ngerti manawa sampeyan lagi bisa ngrampungake gerombolan referensi CAMID. Bisa dadi ngipi elek! Ngalih (utawa ngonfigurasi maneh) namespace otentikasi bisa nyebabake kabeh referensi CAMID kasebut ing kahanan sing ora bisa diatasi. Iki mesthi nyebabake masalah konten & konfigurasi Cognos (kayata jadwal sing ora bisa mlaku maneh, konten sing wis ora diamanake kaya sing sampeyan pikirake, paket utawa kubus sing ora bisa ngetrapake keamanan level data kanthi bener, ngilangi konten Folder lan pangguna pilihan lsp).
Metode Transisi Namespace Cognos
Saiki, ngerti manawa lingkungan Cognos bisa duwe puluhan ewu referensi CAMID sing mbutuhake nemokake, pemetaan lan nganyari babagan nilai CAMID sing anyar ing ruang jeneng otentikasi sing anyar, ayo ngrembug babagan pendekatan Apik, Ala & Ala kanggo ngrampungake masalah iki.
The Good: Panggantos Namespace karo Persona
Cara pertama (Panggantos Namespace) digunakake Motio's, Wong IQ produk Kanthi njupuk pendekatan iki, namespace sing wis ana "diganti" karo namespace Persona khusus sing ngidini sampeyan nggawe virtualisasi kabeh kepala sekolah keamanan sing kena Cognos. Kepala sekolah keamanan sing wis ana sadurunge bakal kapacak ing Cognos kanthi CAMID sing padha kaya sadurunge, sanajan bisa didhukung dening sawetara sumber keamanan eksternal (kayata Active Directory, LDAP utawa uga basis data Persona).
Bagéan sing apik babagan pendekatan iki yaiku mbutuhake ZERO pangowahan kanggo konten Kognos sampeyan. Iki amarga Persona bisa njaga kepala sekolah CAMID sing wis ana, sanajan didukung karo sumber anyar. Dadi… kabeh puluhan ewu referensi CAMID ing Toko Konten, model eksternal, lan kiub sejarah? Dheweke bisa tetep padha kaya saiki. Ora ana gaweyan sing dibutuhake.
Iki minangka pendekatan paling mbebayani, paling murah sing bisa digunakake kanggo transisi lingkungan Kognos sing ana saka sumber keamanan eksternal menyang sumber liyane. Bisa rampung sajrone kurang saka sakjam udakara 5 menit downtime Cognos (siji-sijine downtime Cognos diwiwiti maneh Cognos yen sampeyan wis ngonfigurasi namespace Persona).
The Bad: Migrasi Namespace nggunakake Persona
Yen pendekatan sing gampang lan berisiko murah dudu cangkir teh, mula ora ana is pilihan liyane.
Persona uga bisa digunakake kanggo nindakake Migrasi Namespace.
Iki kalebu nginstal ruang jeneng otentikasi kapindho ing lingkungan Cognos, pemetaan (muga-muga) kabeh kepala sekolah keamanan sing ana (saka ruang jeneng lawas) dadi kepala sekolah sing cocog ing ruang jeneng anyar, banjur (iki sing nyenengake), nemokake, pemetaan lan nganyari saben referensi CAMID tunggal sing ana ing lingkungan Kognos: Toko Konten, Model Kerangka, Model Transformer, kios Sejarah, Aplikasi TM1, Aplikasi Perencanaan, lsp.
Cara iki cenderung ora ngepenakke lan proses intensif, nanging yen sampeyan jinis administrator Cognos sing butuh cepet-cepet adrenalin supaya bisa urip (lan ora preduli wengi / telpon esuk), bisa uga… iki pilihan sing sampeyan goleki?
Persona bisa digunakake kanggo mbantu otomatis bagean saka proses iki. Sampeyan bakal mbantu nggawe pemetaan ing antarane kepala sekolah keamanan lawas lan kepala sekolah keamanan anyar, ngotomatisasi logika kekuwatan "temokake, nganalisa, nganyari" kanggo konten ing toko konten sampeyan, lsp. Apa Persona sing bisa ngotomatisasi sawetara tugas ing kene, karya ing pendekatan iki kalebu "wong lan proses" tinimbang teknologi nyata.
Contone - nyusun informasi ing saben model Manager Framework, saben model Transformer, saben aplikasi Perencanaan / TM1, saben aplikasi SDK, sing duwe, lan ngrencanakake cara nganyari lan distribusi maneh bisa uga akeh gaweyan. Koordinasi pemadaman kanggo saben lingkungan Cognos sing pengin sampeyan coba coba lan windows pangopènan nalika sampeyan bisa nyoba migrasi bisa kalebu perencanaan lan "wektu entek" Cognos. Nggawe (lan nglakokake) rencana tes sing efektif sawise migrasi sampeyan uga bisa dadi bear.
Sampeyan uga normal yen sampeyan pengin nindakake proses iki ing lingkungan non-produksi sadurunge nyoba ing produksi.
Nalika Migrasi Namespace karo Persona bisa digunakake (lan luwih apik tinimbang pendekatan "Ugly" ing ngisor iki), luwih invasif, berisiko, kalebu luwih akeh personel, lan butuh luwih akeh wektu kanggo nindakake pria tinimbang Namespace Replaces. Biasane migrasi kudu ditindakake sajrone "jam kerja", nalika lingkungan Cognos isih online, nanging panggunaan formulir diwatesi dening pangguna pungkasan.
Ing Ugly: Layanan Migrasi Namespace Manual
Cara Ugly kalebu pendekatan nyoba sing ora bisa dibantah kanthi manual pindhah saka siji jeneng otentikasi menyang papan liyane. Iki kalebu nyambungake jeneng jeneng otentikasi kapindho menyang lingkungan Kognos, banjur nyoba mindhah utawa nggawe maneka konten Kognos lan konfigurasi kanthi manual.
Contone, nggunakake pendekatan iki, administrator Cognos bisa uga nyoba:
- Gawe grup lan peran ing ruang jeneng anyar
- Gawe maneh anggota grup kasebut lan peran ing ruang jeneng anyar
- Secara manual salin konten folder, preferensi pangguna, tab portal, lan liya-liyane saka saben akun sumber menyang saben akun target
- Temokake saben Set Kebijakan ing Toko Konten lan nganyari kanggo referensi kepala sekolah sing padha ing ruang jeneng anyar kanthi cara sing padha karo referensi kepala sekolah saka ruang jeneng lawas
- Gawe kabeh jadwal lan isi kanthi kapercayan, panampa, lsp.
- Reset kabeh properti "pemilik" lan "kontak" kabeh obyek ing Toko Konten
- [Udakara 40 barang liyane ing Toko Konten sing bakal lali]
- Klumpukake kabeh model FM kanthi keamanan level obyek utawa data:
- Anyari saben model
- Nerbitake maneh saben model
- Sebarake model sing wis dimodifikasi bali menyang penulis asli
- Pakaryan sing padha kanggo model Transformer, Aplikasi TM1 lan Aplikasi Perencanaan sing aman saka namespace asli
- [lan liya-liyane]
Nalika sawetara wong cognos masokis bisa meneng-menengan kanthi gigir nalika ngeklik 400,000 kaping ing Sambungan Cognos, kanggo umume wong sing akal, pendekatan iki cenderung mboseni, mbuwang wektu lan rawan kesalahan. Nanging, dudu masalah paling gedhe babagan pendekatan iki.
Masalah paling gedhe karo pendekatan iki yaiku meh tansah nyebabake migrasi sing ora lengkap.
Nggunakake pendekatan iki, sampeyan (susah) nemokake, lan nyoba kanggo peta referensi CAMID sing sampeyan kenal… nanging cenderung ninggalake kabeh referensi CAMID sing sampeyan ora ngerti babagan.
Sawise sampeyan mikir sampeyan wis rampung karo pendekatan iki, sampeyan asring ora tenan rampung.
Sampeyan duwe obyek ing toko konten sing wis ora diamanake kaya sing sampeyan pikirake… sampeyan duwe jadwal sing ora mlaku kaya biasane, sampeyan duwe data sing ora bisa diamanake kaya sing sampeyan pikirake iku, lan sampeyan uga duwe kesalahan sing ora dingerteni kanggo operasi tartamtu sing sampeyan ora bisa nemenake driji sampeyan.
Alesan kenapa Pendekatan Ala lan Ala bisa Ngeri:
- Migrasi Namespace Otomatis menehi stres ing Manajer Konten. Pamriksa lan nganyari potensial kanggo saben obyek ing Toko Konten sampeyan, asring bisa ngasilake puluhan ewu panggilan SDK menyang Cognos (sakbenere kabeh mlebu liwat Konten Manager). Panyuwunan sing ora normal iki biasane nyebabake panggunaan / mbukak memori lan menehi resiko kanggo nabrak Manajer Konten nalika migrasi kasebut. Yen sampeyan wis ora stabilitas ing lingkungan Kognos, sampeyan kudu wedi banget karo pendekatan iki.
- Migrasi jeneng ruang mbutuhake jendela pangopènan sing cukup gedhe. Kognos kudu siyap, nanging sampeyan ora pengin wong nggawe pangowahan sajrone proses migrasi. Iki biasane mbutuhake migrasi ruang jeneng nalika ora ana wong liya sing makarya, umpamane jam 10 wengi dina Jumuah wengi. Ora ana sing pengin miwiti proyek stres nalika jam 10 wengi ing wayah wengi Jumuah. Ora dikepengini, fakultas mental sampeyan bisa uga ora kerja ing wayah wengi lan akhir minggu paling apik kanggo proyek kasebut ora mbutuhake sampeyan supaya tajem!
- Aku wis nyebutake Migrasi Namespace yaiku wektu lan intensif tenaga kerja. Mangkene sawetara liyane:
- Proses pemetaan konten kudu rampung kanthi tliti lan mbutuhake kolaborasi tim lan pirang-pirang jam pria.
- Multiple dry run dibutuhake kanggo mriksa kesalahan utawa masalah nalika migrasi. Migrasi khas ora sampurna nalika dicoba pisanan. Sampeyan uga butuh cadangan Toko Konten sing bener sing bisa dipulihake yen ana kasus kaya ngono. Kita wis ndeleng akeh organisasi sing ora duwe cadangan sing apik (utawa duwe cadangan sing ora dikepengini durung lengkap).
- Sampeyan kudu ngenali kabeh njaba Toko Konten sing bisa uga kena pengaruh (model kerangka, model trafo, lsp). Tugas iki bisa uga kalebu koordinasi ing pirang-pirang tim (utamane ing lingkungan BI sing akeh dituduhake).
- Sampeyan butuh rencana tes sing apik kanggo nglibatake wong sing duwe macem-macem derajat akses menyang konten Kognos sampeyan. Tombol ing kene yaiku verifikasi sakcepete sawise migrasi ngrampungake manawa kabeh migrasi lan fungsi kaya sing diarepake. Biasane ora praktis kanggo verifikasi kabeh, mula sampeyan bisa verifikasi apa sing dadi conto wakil.
- Sampeyan kudu duwe broad kawruh lingkungan Cognos lan samubarang sing gumantung. Contone, kiub sejarah kanthi tampilan khusus Kudu dibangun maneh yen sampeyan mbukak rute NSM.
- Kepiye yen sampeyan utawa perusahaan sing wis ngoperasikake migrasi ruang jeneng supaya ora lali, kayata… aplikasi SDK? Sawise sampeyan ngalihake tombol, kabeh bakal mandheg yen ora dianyari kanthi bener. Apa sampeyan duwe cek sing tepat kanggo langsung ngerteni, utawa bakal pirang-pirang minggu / wulan sadurunge gejala wiwit muncul?
- Yen sampeyan wis ngalami upgrade Cognos, sampeyan bisa uga duwe obyek ing Toko Konten sing ana ing kahanan sing ora konsisten. Yen sampeyan ora nggarap SDK, sampeyan ora bakal bisa ndeleng obyek sing ana ing negara iki.
Napa Pengganti Namespace minangka Pilihan Paling Apik
Faktor risiko utama lan langkah-langkah sing mbuwang wektu sing dakkandhakake bakal diilangi nalika metode Pengganti Nama Persona digunakake. Nggunakake pendekatan Panggantos Namespace, sampeyan duwe 5 menit downtime Cognos, lan ora ana konten sing kudu diganti. Cara "Apik" kayane ngethok lan garing "ora ana gunane" kanggo aku. Dina Jumuah wengi kanggo santai, ora stres amarga kasunyatane Manajer Konten sampeyan ambruk ing tengah Migrasi Namespace.
