Երբ դուք պետք է վերակազմակերպեք գոյություն ունեցող Cognos միջավայրը ՝ օգտագործելով արտաքին անվտանգության այլ աղբյուր (օրինակ ՝ Active Directory, LDAP և այլն), կան մի քանի մոտեցումներ, որոնք կարող եք ձեռնարկել: Ես սիրում եմ նրանց անվանել «Լավը, Վատը և Տգեղը»: Նախքան այս Լավ, Վատ և Տգեղ մոտեցումները ուսումնասիրելը, եկեք նայենք մի քանի սովորական սցենարների, որոնք հակված են առաջացնել նույնականացման անվան փոփոխություններ Cognos միջավայրում:
Ընդհանուր բիզնես վարորդներ:
Սարքավորման կամ OS- ի թարմացում - BI սարքավորումների/ենթակառուցվածքների արդիականացումը կարող է հաճախակի շարժիչ ուժ հանդիսանալ: Թեև Cognos- ի մնացած մասը կարող է առաջատարի պես աշխատել ձեր գեղեցիկ նոր սարքավորումների և ժամանակակից 64-բիթանոց ՕՀ-ի վրա, հաջողություն ՝ մոտավորապես 2005-ի Access Manager- ի ձեր տարբերակը տեղափոխելով այդ նոր հարթակ: Access Manager- ը (առաջին անգամ թողարկվել է 7 -րդ սերիայով) հանդիսանում է Cognos- ի շատ հաճախորդների համար անցած օրերի հարգված պահվածքը: Դա միակ պատճառն է, որ շատ հաճախորդներ պահում են Windows Server 2003 -ի այդ խրոխտ հին տարբերակը: Գրությունը պատին է երկար ժամանակ Access Manager- ի համար: Դա ժառանգական ծրագրակազմ է: Որքան շուտ կարողանաք հեռանալ դրանից, այնքան լավ:
Դիմումի ստանդարտացում- Կազմակերպություններ, որոնք ցանկանում են համախմբել իրենց բոլոր դիմումների իսկությունը նույնականացված մեկ կորպորատիվ գրացուցակի սերվերի դեմ (օրինակ ՝ LDAP, AD):
Միաձուլումներ և ձեռքբերումներ- A ընկերությունը գնում է B ընկերությունը և կարիք ունի B ընկերության Cognos միջավայրին ՝ մատնանշելու A ընկերության գրացուցակի սերվերը ՝ առանց խնդիրներ առաջացնելու BI- ի առկա բովանդակության կամ կազմաձևի հետ:
Կորպորատիվ Divestitures- Սա միաձուլման սցենարի հակառակն է, ընկերության մի մասն անջատված է իր սեփական կազմակերպության մեջ և այժմ պետք է անվտանգության առկա նոր աղբյուրի վրա մատնանշի իր առկա BI միջավայրը:
Ինչու՞ անվան տարածքի տեղաշարժերը կարող են խառնաշփոթ լինել
Անվտանգության նոր աղբյուրին Cognos միջավայրը մատնանշելը այնքան էլ պարզ չէ, որքան նոր անունների ավելացումը նույն օգտվողների, խմբերի և դերերի հետ, հին անունների տարածքի և VOILA- ի անջատումը: դրանց բովանդակությունը: Իրականում, դուք հաճախ կարող եք հայտնվել արյունոտ խառնաշփոթով ձեր ձեռքերում, և ահա թե ինչու…
Բոլոր Cognos անվտանգության սկզբունքները (օգտվողներ, խմբեր, դերեր) հղում են կատարում CAMID կոչվող եզակի նույնացուցիչով: Նույնիսկ եթե մյուս բոլոր հատկանիշները հավասար են, ապա CAMID- ը օգտագործողի համար գոյություն ունեցող նույնականացման անունների տարածքը նույնը չի լինի, ինչ CAMID- ը այդ օգտվողի համար նոր անունների տարածք. Սա կարող է ավերածություններ պատճառել գոյություն ունեցող Cognos միջավայրին: Նույնիսկ եթե դուք ընդամենը մի քանի Cognos օգտվող ունեք, դուք պետք է գիտակցեք, որ CAMID հղումներ կան ձեր Բովանդակության խանութի ՇԱՏ տարբեր վայրերում (և նույնիսկ կարող են գոյություն ունենալ ձեր բովանդակության խանութից դուրս ՝ Framework մոդելներում, Transformer Models- ում, TM1 հավելվածներում, Cubes- ում, Planning Applications- ում և այլն): ):
Cognos- ի շատ հաճախորդներ սխալմամբ կարծում են, որ CAMID- ն իսկապես կարևոր է միայն Իմ Թղթապանակի բովանդակության, օգտագործողի նախասիրությունների և այլնի համար: Սա չի կարող ճշմարտությունից հեռու լինել: Խոսքը միայն ձեր օգտագործողների թվի մասին չէ, այլ Cognos օբյեկտների քանակի, որոնցով պետք է մտահոգվեք: Բովանդակության խանութում կան ավելի քան 140 տարբեր տեսակի Cognos օբյեկտներ, որոնցից շատերը կարող են ունենալ բազմաթիվ CAMID հղումներ.
Օրինակ `
- Հազվադեպ չէ, որ ձեր Բովանդակության խանութի մեկ ժամանակացույցը ունենա բազմաթիվ CAMID հղումներ (ժամանակացույցի սեփականատիրոջ CAMID- ը, օգտագործողի CAMID- ը, ժամանակացույցը պետք է գործի այնպես, ինչպես յուրաքանչյուր օգտագործողի CAMID- ը կամ բաշխման ցուցակը, որը պետք է ուղարկի հաշվետվության արդյունքը և այլն):
- Cognos- ի յուրաքանչյուր օբյեկտ ունի անվտանգության քաղաքականություն, որը որոշում է, թե որ օգտվողները կարող են մուտք գործել օբյեկտ (մտածեք «Թույլտվությունների ներդիր»): Cognos Connection- ում այդ թղթապանակից կախված մեկ անվտանգության քաղաքականություն ունի CAMID հղում յուրաքանչյուր օգտագործողի, խմբի և դերի համար, որը նշված է այդ քաղաքականության մեջ:
- Հուսանք, որ դուք հասկացաք կետը. Այս ցուցակը շարունակվում է և շարունակվում:
Հազվադեպ չէ, որ Բովանդակության մեծ խանութը պարունակում է տասնյակ հազարավոր CAMID հղումներ (և մենք տեսել ենք մի քանի խոշորները ՝ հարյուր հազարներով):
Այժմ, մաթեմատիկա կատարեք, թե ինչ կա դրա մեջ Ձեր Cognos միջավայր, և դուք կարող եք տեսնել, որ դուք պոտենցիալ կերպով գործ ունեք CAMID հղումների հորդաների հետ: Դա կարող է լինել մղձավանջ: Նույնականացման անվան տարածքի փոխարկումը (կամ վերակազմակերպումը) կարող է այս բոլոր CAMID հղումները թողնել անլուծելի վիճակում: Սա անխուսափելիորեն հանգեցնում է Cognos- ի բովանդակության և կազմաձևման խնդիրների (օրինակ ՝ ժամանակացույցեր, որոնք այլևս չեն գործարկվում, բովանդակություն, որն այլևս ապահովված չէ ձեր կարծիքով, փաթեթներ կամ խորանարդներ, որոնք այլևս չեն իրականացնում տվյալների մակարդակի անվտանգություն, Իմ Թղթապանակի բովանդակության և օգտագործողի կորուստ նախապատվություններ և այլն):
Cognos անվան տարածքի անցման մեթոդներ
Այժմ, իմանալով, որ Cognos միջավայրը կարող է ունենալ տասնյակ հազարավոր CAMID հղումներ, որոնք կպահանջեն գտնել, քարտեզագրել և արդիականացնել իրենց համապատասխան նոր CAMID արժեքին նույնականացման նոր անվանման տարածքում, եկեք քննարկենք այս խնդրի լուծման Լավ, Վատ և Տգեղ մոտեցումները:
The GoodԱնուն տարածքի փոխարինում Անձով
Առաջին մեթոդը (Անվան տարածքի փոխարինում) օգտագործում է Motioի, Անձի IQ արտադրանք. Այս մոտեցումն ընդունելով ՝ ձեր գոյություն ունեցող անունների տարածքը «փոխարինվում է» հատուկ Persona անունով, որը թույլ է տալիս վիրտուալացնել անվտանգության բոլոր սկզբունքները, որոնք ենթարկվում են Cognos- ին: Նախկին անվտանգության սկզբունքները ենթարկվելու են Cognos- ի ճշգրիտ նույն CAMID- ով, ինչպես նախկինում, չնայած դրանք կարող են ապահովված լինել արտաքին անվտանգության որևէ շարք աղբյուրներով (օրինակ ՝ Active Directory, LDAP կամ նույնիսկ Persona տվյալների շտեմարան):
Այս մոտեցման գեղեցիկ մասն այն է, որ այն պահանջում է CՐՈ փոփոխություններ ձեր Cognos բովանդակության մեջ: Դա պայմանավորված է նրանով, որ Անձը կարող է պահպանել նախկինում գոյություն ունեցող տնօրենների CAMID- ը, նույնիսկ այն դեպքում, երբ նրանց աջակցում է նոր աղբյուր: Այսպիսով… ձեր Բովանդակության խանութում CAMID- ի բոլոր այն տասնյակ հազարավոր հղումները, արտաքին մոդելները և պատմական խորանարդի՞կ: Նրանք կարող են մնալ այնպես, ինչպես կան: Աշխատանք չի պահանջվում:
Սա մինչ այժմ ամենաքիչ ռիսկային, ամենացածր ազդեցության մոտեցումն է, որը կարող եք օգտագործել ձեր գոյություն ունեցող Cognos միջավայրը անվտանգության մեկ արտաքին աղբյուրից մյուսը անցնելու համար: Դա կարող է կատարվել մեկ ժամից պակաս ՝ մոտ 5 րոպե Cognos- ի խափանումով (միակ Cognos- ի խափանումն է Cognos- ի վերագործարկումը, երբ դուք կազմաձևեք Persona անվան տարածքը):
The Bad: Անունների միգրացիա ՝ օգտագործելով Persona- ն
Եթե հեշտ, ցածր ռիսկով մոտեցումը պարզապես ձեր բաժակ թեյը չէ, ապա այնտեղ is այլ տարբերակ.
Persona- ն կարող է օգտագործվել նաև Անվան տարածության միգրացիա կատարելու համար:
Սա ներառում է ձեր Cognos միջավայրում նույնականացման երկրորդ անվանման տարածքի տեղադրում, քարտեզագրում (հուսանք) ձեր առկա բոլոր անվտանգության սկզբունքների (հին անվան տարածքից) նոր անունների համապատասխան սկզբունքների վրա, այնուհետև (ահա զվարճալի մասը), յուրաքանչյուրի որոնումը, քարտեզագրումը և թարմացումը: ձեր Cognos միջավայրում գոյություն ունեցող մեկ CAMID հղում ՝ ձեր բովանդակության խանութը, շրջանակային մոդելները, տրանսֆորմատորային մոդելները, պատմական խորանարդիկները, TM1 ծրագրերը, պլանավորման ծրագրերը և այլն:
Այս մոտեցումը հակված է լինել սթրեսային և ինտենսիվ գործընթացի, բայց եթե դուք այն Cognos- ի ադմինիստրատորն եք, որին անհրաժեշտ է մի փոքր ադրենալին շտապել ՝ իրեն ողջ զգալու համար (և դեմ չէ ուշ գիշեր / վաղ առավոտյան հեռախոսազանգերին), ապա գուցե… սա այն տարբերակն է, որը դուք փնտրու՞մ եք:
Persona- ն կարող է օգտագործվել այս գործընթացի մասերի ավտոմատացման համար: Դա կօգնի ձեզ ստեղծել քարտեզագրում հին անվտանգության և նոր անվտանգության տնօրենների միջև, ավտոմատացնել բովանդակության խանութում բովանդակության բովանդակությունը «գտնելու, վերլուծելու, թարմացնելու» դաժան ուժը և այլն: այս մոտեցման մեջ ներգրավված աշխատանքն ավելի շատ ներառում է «մարդիկ և գործընթացները», քան իրական տեխնոլոգիաները:
Օրինակ ՝ շրջանակային մենեջերի յուրաքանչյուր մոդելի, յուրաքանչյուր տրանսֆորմատորի մոդելի, յուրաքանչյուր պլանավորման / TM1 հավելվածի, յուրաքանչյուր SDK հավելվածի, ում են պատկանում դրանց կազմելը և դրանց թարմացման և վերաբաշխման պլանավորումը կարող է շատ աշխատանք լինել: Cognos- ի յուրաքանչյուր միջավայրի խափանումների համակարգումը, որոնցում ցանկանում եք փորձել, և սպասարկման պատուհանները, որոնց ընթացքում կարող եք փորձել միգրացիան, կարող է ներառել պլանավորում և Cognos «ժամանակի նվազում»: Ձեր միգրացիայից հետո արդյունավետ փորձարկման պլանի ստեղծումը (և իրականացումը) կարող է նաև բավականին արջ լինել:
Նաև միանգամայն նորմալ է, որ դուք կցանկանաք այս գործընթացն անել առաջին հերթին ոչ արտադրական միջավայրում մինչեւ փորձելով այն արտադրության մեջ:
Մինչ Անձնակազմի հետ Անունների Միգրացիան աշխատում է (և դա շատ ավելի լավ է, քան ստորև բերված «Տգեղ» մոտեցումը), այն ավելի ինվազիվ է, ավելի ռիսկային, ընդգրկում է շատ ավելի շատ անձնակազմ և իրականացման համար շատ ավելի շատ մարդկային ժամեր են պահանջում, քան Անվանական տարածքի փոխարինումը: Սովորաբար միգրացիան պետք է իրականացվի «անջատ ժամերին», մինչդեռ Cognos միջավայրը դեռ առցանց է, սակայն վերջնական օգտագործողների կողմից ձևի օգտագործումը սահմանափակ է:
The Ugly: Ձեռնարկի անվան տարածքի միգրացիոն ծառայություններ
Տգեղ մեթոդը ներառում է փորձելու աննախանձելի մոտեցում ձեռքով տեղափոխել նույնականացման անվանման տարածքից մյուսը: Սա ենթադրում է երկրորդ նույնականացման անվան տարածքի միացում ձեր Cognos միջավայրին, այնուհետև ձեռքով տեղափոխել կամ վերստեղծել գոյություն ունեցող Cognos բովանդակության և կազմաձևման մեծ մասը:
Օրինակ, օգտագործելով այս մոտեցումը, Cognos- ի ադմինիստրատորը կարող է փորձել.
- Ստեղծեք խմբեր և դերեր նոր անունների տարածքում
- Նոր անունների տիրույթում վերստեղծեք այդ խմբերի և դերերի անդամակցությունները
- Յուրաքանչյուր թղթապանակից յուրաքանչյուր թիրախային հաշվին ձեռքով պատճենեք իմ թղթապանակների բովանդակությունը, օգտվողի նախասիրությունները, պորտալի ներդիրները և այլն
- Գտեք բովանդակության խանութում տեղադրված յուրաքանչյուր քաղաքականություն և թարմացրեք այն նոր անվանումների համարժեք սկզբունքներին ՝ նույն անունով, ինչպես դա վերաբերում էր հին անունների սկզբունքներին:
- Ստեղծեք բոլոր ժամանակացույցերը և լրացրեք դրանք համապատասխան հավատարմագրերով, ստացողներով և այլն:
- Վերականգնել Բովանդակության խանութի բոլոր օբյեկտների «սեփականատիրոջ» և «կոնտակտի» բոլոր հատկությունները
- [Բովանդակության խանութում մոտ 40 այլ բան, որոնց մասին մոռանալու եք]
- Հավաքեք FM- ի բոլոր մոդելները օբյեկտի կամ տվյալների մակարդակի անվտանգությամբ.
- Թարմացրեք յուրաքանչյուր մոդել համապատասխանաբար
- Հրապարակեք յուրաքանչյուր մոդելը
- Փոփոխված մոդելը վերաբաշխեք սկզբնական հեղինակին
- Նմանատիպ աշխատանք Transformer մոդելների, TM1 ծրագրերի և պլանավորման ծրագրերի համար, որոնք ապահովված են սկզբնական անունների տարածքի դեմ
- [եւ շատ ավելի]
Թեև որոշ Cognos մազոխիստներ գաղտնի կարող են ուրախությամբ ծիծաղել Cognos Connection- ում 400,000 անգամ կտտացնելու գաղափարի համար, բայց շատ խելամիտ մարդկանց համար այս մոտեցումը հակված է չափազանց հոգնեցուցիչ, ժամանակատար և սխալների: Այնուամենայնիվ, դա այս մոտեցման ամենամեծ խնդիրը չէ:
Այս մոտեցման ամենամեծ խնդիրն այն է, որ գրեթե միշտ հանգեցնում է թերի միգրացիայի:
Օգտագործելով այս մոտեցումը, դուք (ցավոտ) գտնում և փորձում եք քարտեզագրել այն CAMID հղումները, որոնց մասին դուք գիտեք ... բայց հակված եք թողնել CAMID- ի այն բոլոր հղումները, որոնք դուք չգիտեմ դրա մասին.
Երբ դուք մտածել Դուք ավարտել եք այս մոտեցումը, հաճախ ոչ իրոք կատարած.
Ձեր բովանդակության խանութում դուք ունեք օբյեկտներ, որոնք այլևս ապահովված չեն ձեր պատկերացմամբ ... դուք ունեք ժամանակացույցեր, որոնք չեն աշխատում այնպես, ինչպես նախկինում էին, դուք ունեք տվյալներ, որոնք այլևս ապահովված չեն ձեր կարծիքով դա, և դուք կարող եք նույնիսկ ունենալ անբացատրելի սխալներ որոշակի գործողությունների համար, որոնք դուք իսկապես չեք կարող ձեր մատը դնել.
Պատճառները, թե ինչու վատ և տգեղ մոտեցումները կարող են սարսափելի լինել.
- Անվանումների ավտոմատացված միգրացիաները մեծ սթրես են դնում Բովանդակության մենեջերի վրա: Ձեր Բովանդակության խանութի յուրաքանչյուր օբյեկտի ստուգումն ու հնարավոր թարմացումը հաճախ կարող է հանգեցնել տասնյակ հազարավոր SDK զանգերի Cognos (գրեթե բոլորը հոսում են Բովանդակության կառավարիչով): Այս աննորմալ հարցումը սովորաբար մեծացնում է հիշողության օգտագործումը / բեռը և բովանդակության կառավարչին վտանգում է միգրացիայի ընթացքում վթարի ենթարկվելու վտանգը: Եթե ձեր Cognos միջավայրում արդեն ունեք որևէ անկայունություն, ապա պետք է շատ վախենաք այս մոտեցումից:
- Անունների տեղաշարժերը պահանջում են պահպանման մեծ պատուհան: Cognos- ը պետք է բարձրացված լինի, բայց դուք չեք ցանկանում, որ մարդիկ փոփոխություններ կատարեն միգրացիայի գործընթացում: Դա սովորաբար կպահանջի անվան տարածքի միգրացիան սկսել այն ժամանակ, երբ ոչ ոք չի աշխատում, ասենք ուրբաթ երեկոյան երեկոյան ժամը 10 -ին: Ոչ ոք չի ցանկանում սթրեսային նախագիծ սկսել ուրբաթ երեկոյան ժամը 10 -ին: Էլ չեմ ասում, որ ձեր մտավոր ունակությունները, հավանաբար, իրենց լավագույն աշխատանքային գիշերներն ու հանգստյան օրերը չեն այն նախագծի վրա, որը does պահանջում է լինել կտրուկ!
- Ես նշեցի, որ Անունային տարածքները միգրացիան ժամանակատար և աշխատատար են: Ահա մի փոքր ավելին դրա մասին.
- Բովանդակության քարտեզագրման գործընթացը պետք է կատարվի ճշգրիտ և պահանջում է թիմային համագործակցություն և շատ մարդկային ժամեր:
- Միգրացիայի սխալների կամ խնդիրների առկայությունը ստուգելու համար պահանջվում են բազմաթիվ չոր վազքներ: Տիպիկ միգրացիան կատարյալ չի անցնում առաջին փորձից: Ձեզ նույնպես պետք կլինի ձեր բովանդակության խանութի վավեր կրկնօրինակը, որը կարող է վերականգնվել նման դեպքերում: Մենք տեսել ենք բազմաթիվ կազմակերպություններ, որոնք չունեն լավ պահուստ (կամ ունեն կրկնօրինակում, որը նրանք չգիտեն, որ թերի է):
- Պետք է ամեն ինչ նույնականացնել դուրս բովանդակության խանութը, որը կարող է հնարավոր ազդեցություն ունենալ (շրջանակային մոդելներ, տրանսֆորմատորների մոդելներ և այլն): Այս առաջադրանքը կարող է ներառել համակարգում մի քանի թիմերի միջև (մասնավորապես ՝ ընդհանուր ընդհանուր BI միջավայրերում):
- Ձեզ անհրաժեշտ է լավ փորձարկման ծրագիր, որը ներառում է ձեր Cognos բովանդակությանը տարբեր աստիճանի հասանելիություն ունեցող ներկայացուցչական մարդկանց: Այստեղ բանալին միգրացիայի ավարտից կարճ ժամանակ անց ստուգելն է, որ ամեն ինչ ամբողջությամբ տեղափոխվել է և գործում է այնպես, ինչպես սպասում եք: Սովորաբար ամեն ինչ ստուգելը անիրագործելի է, այնպես որ դուք վերջնականապես ստուգում եք այն, ինչ հույս ունեք, որ ներկայացուցչական նմուշներ են:
- Դուք պետք է ունենաք բroad Cognos միջավայրի և դրանից կախված բաների իմացություն: Օրինակ, սովորական տեսարաններով պատմական խորանարդները ՊԵՏՔ է վերակառուցվեն, եթե գնաք NSM երթուղով:
- Իսկ եթե դուք կամ այն ընկերությունը, որի աութսորսսնսով փոխանցե՞լ եք անունների տարածքի միգրացիան, մոռանաք ինչ -որ բանի մասին, օրինակ ՝… SDK ծրագրեր: Անջատիչը շրջելուց հետո, այս իրերը դադարում են աշխատել, եթե դրանք ճիշտ չեն թարմացվել: Ունե՞ք համապատասխան ստուգումներ ՝ դա անմիջապես նկատելու համար, թե՞ ախտանիշների ի հայտ գալուց մի քանի շաբաթ / ամիս կպահանջվի:
- Եթե դուք բազմաթիվ Cognos արդիականացումների եք ենթարկվել, ձեր բովանդակության խանութում կարող եք ունենալ անհամապատասխան վիճակում գտնվող օբյեկտներ: Եթե դուք չեք աշխատում SDK- ի հետ, չեք կարողանա տեսնել, թե որ օբյեկտներն են այս վիճակում:
Ինչու՞ անվան տարածքի փոխարինումը լավագույն տարբերակն է
Հիմնական ռիսկի գործոնները և ժամանակատար քայլերը, որոնք ես պարզապես նկարագրեցի, վերացվում են, երբ օգտագործվում է Անձի անվան տարածքի փոխարինման մեթոդը: Օգտագործելով Namespace Replacement մոտեցումը ՝ դուք ունեք Cognos- ի 5 րոպե դադար, և ձեր բովանդակությունից ոչ մեկը չպետք է փոխվի: «Լավ» մեթոդը ինձ թվում է կտրված և չոր «անիմաստ»: Ուրբաթ երեկոները հանգստանալու համար են, այլ ոչ թե շեշտը դնելու այն փաստի վրա, որ ձեր Բովանդակության կառավարիչը պարզապես վթարի է ենթարկվել Անունային տարածքի միգրացիայի կենտրոնում:
