別の外部セキュリティソース（Active Directory、LDAPなど）を使用するように既存のCognos環境を再構成する必要がある場合は、いくつかの方法があります。 私は彼らを「良い、悪い、そして醜い」と呼ぶのが好きです。 これらの良い、悪い、醜いアプローチを検討する前に、Cognos環境で認証名前空間の変更を促進する傾向があるいくつかの一般的なシナリオを見てみましょう。
一般的なビジネス推進要因:
ハードウェアまたはOSの更新 – BIハードウェア/インフラストラクチャの最新化は、頻繁に推進される可能性があります。 Cognosの残りの部分は、洗練された新しいハードウェアと最新の64ビットOSでチャンピオンのように動作する可能性がありますが、2005年頃のバージョンのAccessManagerをその新しいプラットフォームに移行することをお勧めします。 Access Manager（シリーズ7で最初にリリースされた）は、多くのCognosのお客様にとって過去の数日からの由緒あるホールドオーバーです。 多くの顧客がその残酷な古いバージョンのWindowsServer 2003を使い続けているのは、これが唯一の理由です。AccessManagerの書き込みは、かなり前から壁にかかっていました。 レガシーソフトウェアです。 移行が早ければ早いほどよいでしょう。
アプリケーションの標準化–一元管理されているXNUMXつの企業ディレクトリサーバー（LDAP、ADなど）に対してすべてのアプリケーションの認証を統合したい組織。
合併と買収– A社はB社を買収し、既存のBIコンテンツや構成に問題を引き起こすことなく、A社のディレクトリサーバーを指すようにB社のCognos環境を必要としています。
企業の売却–これは合併シナリオの反対であり、会社の一部が独自のエンティティにスピンオフされ、既存のBI環境を新しいセキュリティソースに向ける必要があります。
名前空間の移行が煩雑になる理由
Cognos環境を新しいセキュリティソースにポイントすることは、同じユーザー、グループ、およびロールで新しい名前空間を追加し、古い名前名を切断し、VOILA！-新しい名前名のすべてのCognosユーザーが一致するほど簡単ではありません。それらのコンテンツ。 実際、あなたはしばしばあなたの手に血まみれの混乱をもたらす可能性があります、そしてここに理由があります…
すべてのCognosセキュリティプリンシパル（ユーザー、グループ、ロール）は、CAMIDと呼ばれる一意の識別子によって参照されます。 他のすべての属性が等しい場合でも、 既存の 認証名前空間は、でそのユーザーのCAMIDと同じにはなりません 新製品 名前空間。 これにより、既存のCognos環境に大混乱が生じる可能性があります。 Cognosユーザーが数人しかない場合でも、CAMID参照はContent Storeのさまざまな場所に存在することを理解する必要があります（Frameworkモデル、Transformerモデル、TM1アプリケーション、キューブ、PlanningアプリケーションなどのContentStoreの外部にも存在する可能性があります。 ）。
多くのCognosのお客様は、CAMIDはマイフォルダのコンテンツやユーザーの好みなどにのみ関係すると誤って信じています。これは真実からかけ離れたものではありません。 それはあなたが持っているユーザーの数だけの問題ではなく、あなたが気にする必要があるCognosオブジェクトの量です。 Content Storeには140を超える種類のCognosオブジェクトがあり、その多くには複数のCAMID参照が含まれている場合があります。.
例：
- コンテンツストア内の単一のスケジュールに複数のCAMID参照（スケジュール所有者のCAMID、スケジュールを実行するユーザーのCAMID、各ユーザーのCAMID、または生成されたレポート出力を電子メールで送信する配布リスト）があることは珍しくありません。 、 NS。）。
- Cognosのすべてのオブジェクトには、オブジェクトにアクセスできるユーザーを管理するセキュリティポリシーがあります（「[権限]タブ」を考えてください）。 Cognos Connectionのそのフォルダにぶら下がっている単一のセキュリティポリシーには、そのポリシーで指定されている各ユーザー、グループ、およびロールのCAMID参照があります。
- うまくいけば、あなたはポイントを得る-このリストはどんどんと続く！
大規模なコンテンツストアに数万のCAMID参照が含まれることは珍しくありません（そして、数十万の大きなものを見てきました）。
さて、何が入っているかについて数学をしてください Cognos環境では、CAMID参照の大群を処理している可能性があることがわかります。 それは悪夢かもしれません！ 認証名前空間を切り替える（または再構成する）と、これらのCAMID参照がすべて解決できない状態のままになる可能性があります。 これは必然的にCognosのコンテンツと構成の問題につながります（たとえば、スケジュールが実行されなくなったり、コンテンツが思ったとおりに保護されなくなったり、パッケージやキューブがデータレベルのセキュリティを正しく実装しなくなったり、マイフォルダのコンテンツとユーザーが失われたりします。好みなど）。
Cognos名前空間の移行方法
ここで、Cognos環境に数万のCAMID参照があり、新しい認証名前名で対応する新しいCAMID値を検索、マッピング、および更新する必要があることを知って、この問題を解決するための良い、悪い、醜いアプローチについて説明しましょう。
グッド：ペルソナによる名前空間の置換
最初の方法（名前空間の置換）は Motioだから、 ペルソナIQ 製品。 このアプローチを採用すると、既存の名前空間は、Cognosに公開されているすべてのセキュリティプリンシパルを仮想化できる特別なPersona名前空間に「置き換え」られます。 既存のセキュリティプリンシパルは、任意の数の外部セキュリティソース（Active Directory、LDAP、さらにはPersonaデータベースなど）によってバックアップされている場合でも、以前とまったく同じCAMIDでCognosに公開されます。
このアプローチのすばらしい点は、Cognosコンテンツに変更を加える必要がないことです。 これは、Personaが、新しいソースによってサポートされている場合でも、既存のプリンシパルのCAMIDを維持できるためです。 では、コンテンツストア、外部モデル、履歴キューブにある何万ものCAMID参照すべてですか？ 彼らはそのままでいることができます。 作業は必要ありません。
これは、既存のCognos環境をある外部セキュリティソースから別の外部セキュリティソースに移行するために使用できる、はるかにリスクが低く、影響が最も少ないアプローチです。 これは、Cognosのダウンタイムが約5分でXNUMX時間以内に実行できます（Cognosのダウンタイムは、Persona名前空間を構成した後のCognosの再起動のみです）。
悪い：ペルソナを使用した名前空間の移行
簡単でリスクの低いアプローチがあなたのお茶ではない場合は、そこにあります is 別のオプション。
ペルソナを使用して、名前空間の移行を実行することもできます。
これには、Cognos環境に1番目の認証名前名をインストールし、（できれば）すべての既存のセキュリティプリンシパルを（古い名前名から）新しい名前名の対応するプリンシパルにマッピングし、次に（ここで楽しい部分）、すべてを検索、マッピング、および更新することが含まれます。 Cognos環境に存在する単一のCAMID参照：コンテンツストア、フレームワークモデル、トランスフォーマーモデル、履歴キューブ、TMXNUMXアプリケーション、計画アプリケーションなど。
このアプローチはストレスがたまり、プロセスが集中する傾向がありますが、生きていると感じるためにアドレナリンラッシュを少し必要とするようなCognos管理者の場合（深夜/早朝の電話を気にしない）、おそらく… この あなたが探しているオプションはありますか？
ペルソナは、このプロセスの一部を自動化するために使用できます。 これは、古いセキュリティプリンシパルと新しいセキュリティプリンシパルの間のマッピングを作成したり、コンテンツストア内のコンテンツのブルートフォース「検索、分析、更新」ロジックを自動化したりするのに役立ちます。このアプローチでの作業の一部には、実際のテクノロジーではなく「人とプロセス」が含まれます。
たとえば、すべてのFramework Managerモデル、すべてのTransformerモデル、すべてのPlanning / TM1アプリケーション、それらを所有するすべてのSDKアプリケーションに関する情報をコンパイルし、それらを更新および再配布する方法を計画することは、多くの作業になる可能性があります。 これを試行するCognos環境ごとに停止を調整し、移行を試行できるメンテナンスウィンドウには、計画とCognosの「ダウンタイム」が含まれる場合があります。 移行後の効果的なテスト計画を考え出す（そして実行する）ことも、かなりの負担になる可能性があります。
また、非実稼働環境で最初にこのプロセスを実行することもごく普通のことです。 本番環境で試してみてください。
ペルソナを使用した名前空間の移行は機能しますが（以下の「醜い」アプローチよりもはるかに優れています）、名前空間の置換よりも侵襲性が高く、リスクが高く、人員がはるかに多く、実行にかかる時間もはるかに長くなります。 通常、移行は、Cognos環境がまだオンラインである「営業時間外」に実行する必要がありますが、エンドユーザーによるフォームの使用は制限されています。
醜い：手動名前空間移行サービス
醜い方法は、しようとするうらやましいアプローチを含みます 手動で ある認証名前空間から別の認証名前空間に移行します。 これには、XNUMX番目の認証名前空間をCognos環境に接続してから、既存のCognosコンテンツと構成の多くを手動で移動または再作成することが含まれます。
たとえば、このアプローチを使用すると、Cognos管理者は次のことを試みる可能性があります。
- 新しい名前空間でグループとロールを再作成します
- 新しい名前空間でそれらのグループとロールのメンバーシップを再作成します
- マイフォルダのコンテンツ、ユーザー設定、ポータルタブなどを各ソースアカウントから各ターゲットアカウントに手動でコピーします
- コンテンツストアですべてのポリシーセットを検索し、古い名前の名前からプリンシパルを参照したのとまったく同じ方法で、新しい名前の名前の同等のプリンシパルを参照するように更新します。
- すべてのスケジュールを再作成し、対応する資格情報、受信者などを入力します。
- コンテンツストア内のすべてのオブジェクトのすべての「所有者」および「連絡先」プロパティをリセットします
- [あなたが忘れようとしているコンテンツストアの他の約40の事柄]
- オブジェクトまたはデータレベルのセキュリティを備えたすべてのFMモデルを収集します。
- それに応じて各モデルを更新します
- 各モデルを再公開する
- 変更したモデルを元の作成者に再配布します
- 元の名前空間に対して保護されているTransformerモデル、TM1アプリケーション、および計画アプリケーションの同様の作業
- [などなど]
一部のCognosマゾヒストは、Cognos Connectionで400,000回クリックするというアイデアにひそかに笑うかもしれませんが、ほとんどの賢明な人々にとって、このアプローチは非常に面倒で、時間がかかり、エラーが発生しやすい傾向があります。 ただし、これはこのアプローチの最大の問題ではありません。
このアプローチの最大の問題は、それがほとんど 常に 不完全な移行につながります。
このアプローチを使用して、あなたは（痛々しいほど）あなたが知っているそれらのCAMID参照を見つけてマッピングしようとします…しかしあなたがあなたが持っているそれらのCAMID参照のすべてを残す傾向があります 知らない.
いったん 考える あなたはこのアプローチで終わりました、あなたはしばしばそうではありません 本当に 行います。
コンテンツストアに、思ったとおりに保護されなくなったオブジェクトがあります…スケジュールが以前のように実行されていない、データが思ったとおりに保護されていないそれはそうです、そしてあなたは特定の操作のために説明のつかないエラーを持っているかもしれません あなたは本当に指を置くことはできません.
悪いアプローチと醜いアプローチが恐ろしいことがある理由：
- 自動化された名前空間の移行は、ContentManagerに多くのストレスをかけます。 Content Store内のすべてのオブジェクトの検査と更新の可能性により、多くの場合、CognosへのSDK呼び出しが数万回発生する可能性があります（事実上すべてがContent Managerを通過します）。 この異常なクエリは通常、メモリ使用量/負荷を急上昇させ、移行中にContentManagerがクラッシュするリスクをもたらします。 Cognos環境にすでにある程度の不安定性がある場合は、このアプローチを非常に恐れる必要があります。
- 名前空間の移行には、かなりのメンテナンスウィンドウが必要です。 Cognosは稼働している必要がありますが、移行プロセス中に他のユーザーが変更を加えないようにする必要があります。 これには通常、他の誰も作業していないとき、たとえば金曜日の夜の午後10時に名前空間の移行を開始する必要があります。 金曜日の夜の午後10時にストレスの多いプロジェクトを開始したいと思う人は誰もいません。 言うまでもなく、あなたの精神的能力は、おそらく、次のようなプロジェクトで夜や週末に最高の仕事をしているわけではありません。 ありません 鋭くする必要があります！
- 名前空間の移行には時間と労力がかかることを説明しました。 これについてもう少し詳しく説明します。
- コンテンツマッピングプロセスは正確に実行する必要があり、チームのコラボレーションと多くの工数が必要です。
- 移行のエラーや問題をチェックするには、複数のドライランが必要です。 通常の移行は、最初の試行では完全には進みません。 このような場合に復元できるコンテンツストアの有効なバックアップも必要です。 利用可能な適切なバックアップがない（または、バックアップが不完全であることに気付いていない）多くの組織を見てきました。
- あなたはすべてを識別する必要があります 外側 影響を受ける可能性のあるコンテンツストア（フレームワークモデル、トランスフォーマーモデルなど）。 このタスクには、複数のチーム間の調整が含まれる場合があります（特に、大規模な共有BI環境で）。
- Cognosコンテンツへのさまざまなアクセス度を持つ代表者を含む優れたテスト計画が必要です。 ここで重要なのは、移行が完了した直後に、すべてが完全に移行され、期待どおりに機能していることを確認することです。 通常、すべてを検証することは非現実的であるため、代表的なサンプルであると期待するものを検証することになります。
- あなたはbを持っている必要がありますroad Cognos環境とそれに依存するものに関する知識。 たとえば、カスタムビューを備えた履歴キューブは、NSMルートを使用する場合に再構築する必要があります。
- あなたまたはあなたが名前空間の移行を外部委託した会社が…SDKアプリケーションのような何かを忘れた場合はどうなりますか？ スイッチを入れたら、正しく更新されていないと、これらは機能しなくなります。 これにすぐに気付くための適切なチェックがありますか、それとも症状が表面化し始めるまでに数週間/月かかりますか？
- Cognosのアップグレードを何度も行った場合、コンテンツストアに一貫性のない状態のオブジェクトが含まれる可能性があります。 SDKを使用しない場合、どのオブジェクトがこの状態にあるかを確認できません。
名前空間の置換が最良のオプションである理由
ペルソナ名前空間置換方法を使用すると、先ほど概説した主要なリスク要因と時間のかかる手順が排除されます。 名前空間置換アプローチを使用すると、Cognosのダウンタイムが5分になり、コンテンツを変更する必要がなくなります。 「良い」方法は、私にはカットアンドドライの「簡単」のように思えます。 金曜日の夜はリラックスするためのものであり、名前空間の移行の最中にContentManagerがクラッシュしたという事実を強調するものではありません。
