マルチテナントレポートにSSRSを使用する予定で、実行時に選択した共有データソースをレポートに追加したいと考えています。これはどういう意味ですか?さて、私は柔軟性があるかもしれませんが、おそらく2つの可能性があります(しかし、私は他の可能性もあります)。ランタイム時にレポートの共有データソースを動的に変更する
- 共有データソースは、クライアントの認証によって決まります。私の場合、「クライアント」は.NETアプリケーションであり、ユーザーではありません。したがって、これが実用的なパスであれば、私は何とか
MainDB
を持っていたいと思います。クライアントがログインするサービスアカウント。 - 共有データソースの名前をパラメータとして渡し、使用するデータを指定します。私のクライアントのすべてが「信頼できるプレーヤー」であることを考えれば、私はこのアプローチには満足しています。各クライアントには独自の代表的なサービスアカウントがありますが、それは単なる良い措置のためであり、重要ではありません。したがって、単にデータソース
MainDB
を呼び出す代わりに、Client1DB
とClient2DB
などを追加することができます。新しいデータソースが新しいデプロイメントを意味する場合は問題ありませんが、時間の経過とともに〜50個の異なるデータソースにも容易に対応できるようにする必要があります。
なぜですか?複数の顧客向けに本番アプリケーションを複数または複製しているので、すべてをと複製することは望ましくありません。ウェブアプリケーションとデータベースだけです。私たちはいくつかの共通の「バックエンド」のものでうまくいっています。また、SSRSの場合、ライセンスの高さ(ユーザーによるレポートの実行頻度)が非常に高いため、すべてのお客様に単一のバックエンドを提供したいと考えています(実際には、リカバリの状況 - 報告書は私たちが最も重要でないDRの懸念事項であるため、あまりにも派手である必要はありません。
私は、this postを指しているthis questionを見ましたが、これよりも良い方法があると本当に望んでいました。これらの追加のステップ/努力/制限/などのために、PowerShellを使用して、そのポストの手順を標準化するのではなく、ハードコードされたデータソースを調整してレポートの複製をスクリプト化することができます。その解決策は私にとってはあまりにもハック感があり、全くうまく調整できないように思えます。
悲しいことに、私は共有データソースを使用する必要があります"理由から"(これらの接続文字列は、システム管理者が配備後に管理できるためです)。消費するアプリケーションには接続文字列の情報を渡すためのデータベースの秘密/知識がありませんので、これは他の多くの人にとってはおそらく素晴らしいことですが、これはちょうど良い選択肢ではありません!私は私の質問でリンクされた非常に理想的でないオプションに行くだけで終わった。しかし、この答えはおそらく他の多くにとって有益なので、私たちのためにはうまくいかないものの、それを受け入れるつもりです。 – Jaxidian