実践 権限管理の基本 (2) アクションの制御

前回に引き続き、セキュリティロールである。

今回は言葉だけでなく実際の制御に関して記載する。

なお、今回は権限レベル(ユーザーや部署など)には触れず、

アクション(作成、読み込み)に関してのみ記載する。

また、権限を確認するために下記のカスタムエンティティを作成している。

・Lookupをもつエンティティ

・関連ビューを持つエンティティ

 

まず、すべての権限がない場合である。

これは想像のとおり、表示がされない。

20140923_001

画面ショットはないが、当然高度な検索の選択エンティティなどにも表示はされない。

次であるが、まずベースとなるのが[読み込み]である。

エンティティが表示されなければ(読み込まれなければ)、その他のアクションは成り立たない。

[読み込み]権限を付与すると下記のようにエンティティが表示される。

20140923_002

実際にエンティティをクリックすると下記のようになる。

20140923_003

[読み込み]権限を付与することでエンティティを表示することができた。

※画像の状態ではレコードが存在していなかった。存在していればレコードも表示される。

次にレコードを[作成]してみたいと思う。[新規]ボタンが表示されていないので、

権限が足りていないことが推測できる。

[作成]権限を付与してみる。付与後の画面は以下のとおりである。

20140923_004

[新規]ボタンが表示され、レコードの新規作成画面が起動する。

以下の画面は、レコードの新規作成画面が表示後、必須項目を入力し、保存した画面である。

20140923_005

保存するとすべてのフィールドに鍵マーク及び右下に[読み取り専用]と表示される。

これはエンティティに対する[書き込み]権限が付与されていないからである。

では次に[書き込み]権限を付与してみる。画面は以下のとおりである。

20140923_010

[名前]のテキストフィールドが変更可能となった。ただ、[Lookup]や[所有者]に関しては鍵マークのままである。

これは、後述する[追加][追加先]や[割り当て]の権限が付与されていないからである。

上記を解説する前に[削除]に関して触れておく。

ビュー上の[削除]ボタンに関しては[読み込み]権限を与えた時点で表示がなされている。

※権限がなければ表示されないのが基本なので、不具合とも言えるかもしれない。

削除権限を付与する前に[削除]をクリックしてみる。

20140923_006

20140923_007

20140923_008

[権限がありません]というダイアログが表示され、削除ができないことが分かる。

若干テーマからそれるが、上記のようなダイアログが発生し、原因調査をしたい場合は

[ログファイルのダウンロード]をクリックするとヒントが表示される。

内容は下記のようなテキストであるが、”privilege”が”missing”とあるんおで権限が不足というなことがなんとなく分かる。

20140923_009

話しを戻す。

次に分かりやすい、[割り当て][共有]を先に説明するである。

これは下記のようにボタンが表示されるものであると思えばよい。

20140923_013

最後に[追加][追加先]である。

結論から言うと、Lookupを持つエンティティで[追加]、関連ビューを持つエンティティで[追加先]

を選択していないと、Lookupフィールドの鍵マークが表示され、値の選択ができない。

単純に[書き込み]の権限だけを付与すると以下のとおり、[Lookup]フィールドは読み取り専用である。

20140923_010

以下のように権限を付与してみる。

20140923_011

すると、[Lookup]フィールドの鍵マークが表示されなくなり、選択が可能となる。

20140923_014

以上。

実践 権限管理の基本 (1) セキュリティーロール

新しいテーマである。

ここからは権限に関して記載する。

まずは、セキュリティロールである。

Dynamics CRMを利用するにはかならず、1つ以上のセキュリティロールが必要である。

権限管理を行う上でベースとなるものがセキュリティロールでの設定であり、

これでできないことを他の機能で補完していくのが基本的な考え方である。

セキュリティロールは下記のような画面で設定する。エンティティ単位の制御及び特権の管理を行う。

設定可能なすべての項目に対してチェックを行う方法で権限を付与する。

20140919_001

セキュリティロールは複数作成でき、ユーザー(及びチーム)に対して複数適用することができる。

複数適用した場合は範囲の広いほうが適用される([選択なし]と[ユーザー]では[ユーザー]が適用される)。

権限レベルの意味合いは下記である。

選択なし:権限なし

ユーザー:所有者が自分の場合可

部署:所有者が自分と同じ部署のユーザーの場合可

部署配下:所有者が自分の部署と同じかその配下の部署に所属している場合可

組織全体:すべて可

対象アクションに関しては下記である。

作成:レコードを作成する

読み取り:レコードを表示する

書き込み:変更が加わったレコード保存する

削除:レコードを削除する

追加:追加先とセットでLookupの制御をする。Lookupが表示されるエンティティに権限付与

追加先:追加とセットでLookupの制御をする。Lookupが表示されないエンティティに権限付与

割り当て:所有者を変更する

共有:レコードを共有する

追加、追加先以外はそれほど理解に苦しむものではないと思われる。

追加、追加先に関しては平易な表現にした。次回詳しく動作を確認する。

また、各タブの下部には[その他の特権]というものがある。

これは、単純に機能が使えるかというものの制御である。

例えば、[コアレコード]タブにある[一括削除]は、エンティティに関わらず、

一括表示のボタンを表示するかいなか(実行できるか否か)を制御している。

二択であるため、[選択なし]か[組織全体]のどちらかしか選択できない。

以上。次回は権限の選択と実際の制御を詳細に確認する。

【Tips】サーバサイジングに関する一考

サイジングに関して記載をする。むずかしいテーマであるため、

Tipsという軽いカテゴリーに位置づけてみた。

 

Dynamics CRMにおいてサイジング何をどのように検討し、どうすればよいのであろうか。

困ったときはまず実装ガイド(http://www.microsoft.com/ja-jp/download/details.aspx?id=40322)を参照する。

「Microsoft Dynamics CRM 2013 のシステム要件と必須テクノロジ」の章に以下のような記述がある。

①Microsoft Dynamics CRM Server 2013 のハードウェア要件

プロセッサ:クアッドコア x64 アーキテクチャの 2 GHz CPU 以上

メモリ:8 GB 以上の RAM

ハード ディスク:40 GB 以上のディスク空き容量

②Microsoft Dynamics CRM Server 2013 の Microsoft SQL Server ハードウェア要件

プロセッサ:クアッドコア x64 アーキテクチャの 2 GHz CPU 以上

メモリ:16GB 以上の RAM

ハード ディスク:SAS RAID 5 または RAID 10 ハード ディスク アレイ

※いずれも推奨要件

※ユーザー数 320 人の場合のロード シミュレーション テストを前提

細かい記述がないのでどう解釈するかに答えはないが、私は以下のように解釈している。

 

「320人が利用した場合(※1)、CRMAPサーバとCRMDBサーバを構築し(※2)、

上記のリソースを割り当てた場合動作する(※3)。」

 

解釈と共に3点の疑問が発生する。

※1 どのような利用をした場合か。例はないのか。利用頻度が少なければ500人でも大丈夫なのか

※2 1台のケースはないのか。単純にリソースの足し算でよいものなのか

※3 どの程度動作するのか

 

※1に関してはDynamics CRMのサイジングに関するホワイトペーパーの

前提と同じと考えてよいのではないかと思ってる。

Dynamics CRMの性能測定に全く異なる前提を置くことは考え難いと思われるからである。

http://technet.microsoft.com/ja-jp/crm/gg712381#crm2013

・BladeSymphony と Hitachi Storage Solutions を利用した Microsoft Dynamics CRM 4.0 with SQL Server 2005 EE

パフォーマンス・サイジング検証

・Microsoft Dynamics CRM 2011 スケーラビリティとパフォーマンス

上記2つが有益と考えている。残念ながら最新の2013に関するものは存在しない。

2011のものに関しても同時15万ユーザーでの利用というものであり、実践的なケースでは大きすぎる想定である。

結果としては類似的なサイジングとなっているため、この程度と考えてよいと思う。

また、上記を踏まえるならば、320というユーザー数は目安であり、ポイントはトランザクション数であることが分かる。

※2に関しては記述が存在しないが、サポートされるサーバ構成である。

コストをかけられない小規模展開ではよく発生する構成ある。

誤解を恐れず私見を述べると、1台構成は100ユーザー程度までがよいのではないかと考える。

経験則ではこの程度まで環境ではパフォーマンスに問題が発生したことがほぼない。

100ユーザーというのはせいぜい2、3部門(モジュール)が小規模で利用し、

データとしても数万件から数十万件を扱うというケースがほとんどである。

仮に問題が発生した場合としても、メモリやCPUの追加で回避が可能な範囲と思われる。

最後に※3である。

ホワイトペーパーP.11にはサーバでの平均応答時間が記載され、ミリ秒の単位で応答していることが分かる。

つまり、上述の前提とサイジングであれば、平均1秒もかからずにサーバサイドでは応答を行えるということがわかる。

逆に言うとこれ以外はサーバではなく、クライアント等その他の要素の性能に依存するというように理解できる。

 

以上。数回推敲したが、あまりよいまとめにならなかった。とりあえず参考までにしてもらいたい。

最後にパフォーマンスに問題が発生した場合の回避案を記載しておく。

■クライアントPCでの描画に関する問題。

・最新のブラウザバージョンを利用する

・他ブラウザを検討する(IEならChromeなどへ)

■データの抽出に時間がかかる問題。

・インデックスの追加(ホワイトペーパーP.30以降)

・そもそも取得方法変更する(対象データを変更。テーブルにクエリを実行し、JOINを減らすなど)

経験則であるが、この程度のことを実施しないと大概は改善しない。

実践 カスタマイズ (8) ボタンカスタマイズ

ボタンのカスタマイズに関して記述する。

Dynamics CRMのカスタマイズ機能では、ボタンのカスタマイズはできない。

Dynamics CRM標準機能内での制御としては権限がない場合、表示されないというような制御となる。

以下のツールを利用することでもう少し多くのカスタマイズが可能となる。

 

■Visual Ribbon Editor

https://crmvisualribbonedit.codeplex.com/

※フリーのツールであるが、利用制限や免責事項はリンク先Licenseを参照

 

利用方法は上記サイトのdownloadからプログラム一式をダウンロードし、

圧縮を解凍する。VisualRibbonEditor.exeを実行する。

20140922_101

[Open]をクリック

20140922_102

認証情報を入力し、[OK]をクリック

20140922_103

[取引先企業]に変更し、[OK]をクリック

20140922_104

20140922_105

アイコンは2011のまま。

20140922_106

[Ribbon Type]にて、どの画面のボタンを変更するかを選択する。

ここでは、フォーム画面の[Save]のタブを非表示にしてみる。[Save]を選択し、[Hide Tab]をクリック

20140922_107

20140922_108

[Save]をクリック

20140922_109

[OK]をクリック。このタイミングで変更処理が開始される。

20140922_110

公開不要。画面にアクセスしてみる。

保存ボタンなどが表示されなくなった。

20140922_111

サンプル的操作は以上とする。ツール画面上にあるとおり、ボタン単位の削除も可能であるし、

ボタンの追加も可能である。また、追加したカスタムボタンに対してアクションを含めたりすることも可能である。

一方注意も必要である。以下3点である。

1点目はサイトマップエディター同様、同時カスタマイズができない点である。

詳細は前回の投稿を確認して頂きたい。

2点目は「Hide」であるという点である。削除しているわけではない。

先ほど変更画面では全く保存ができなくなったわけではない。[Ctrl]+[S]で保存は可能である。

3点目は1処理でデフォルトに戻すということができない点である。

サイトマップエディターには存在したが、こちらにはない。ある程度慎重に変更する必要がある。

以上。

実践 カスタマイズ (7) サイトマップカスタマイズ

サイトマップに関して記述する。

ここでいうサイトマップとは画面上部のタイル形式の部分を意味する。

Dynamics CRMのカスタマイズ機能では、[営業][サービス]などを非表示にすることはできない。

※権限がない場合、表示されないことはある。

以下で紹介するツールを利用すると上記のような制御が可能となる。

様々な機能を備えているという点は当然よいのだが、

最もよい点は不具合修正が早いことであると私は考える。

Dynamics CRM Onlineは認証形式が頻繁に変更されたりする。

このような変更に素早く対応してくれることはすばらしい。

 

■Toolbox for Dynamics CRM 2011/2013

https://xrmtoolbox.codeplex.com/

※フリーのツールであるが、利用制限や免責事項はリンク先Licenseを参照

 

利用方法は上記サイトのdownloadからプログラム一式をダウンロードし、

圧縮を解凍する。XrmToolBox.exeを実行する。

[SiteMap Editor]をクリック

20140922_001

[はい]をクリック

20140922_002

[New connection]をクリック

20140922_003

以下はOnlineの場合。URLを確認して接続先を選択。[Get Orgs.]をクリック。

20140922_004

時々この接続で失敗することがある。大凡の原因は以下の2つ

・上記画面の接続情報が間違っている。URLはcrm5なのにcrmにアクセスしているなど。

・接続に必要なソフトが端末にインストールされていない。

後者のケースに関しては補足する。

問題が発生した場合は不足のソフトをインストールすればよいのだが

明確に分からない場合がある。

この場合はOutlookクライアントを一度インストールしてみると楽かもしれない。

基本的には以下の3点がよくあるケースである。

・サポートされないOS(XPなど)

・.net frameworkがインストールされていないもしくはバージョンが低い

・Windows Identity Foundationがインストールされていない。

二番目と三番目のものに関してはOutlookクライアントをインストールする過程でインストールされる。

当然、それぞれのOSに対して正しいバージョンのソフトウェアなどを確認してインストールしてもよい。

上記3点はこのツールだけでなく、Onlineにアクセスするソフトウェア一般に言えるものである。

さて、正常にアクセスできると組織が表示される。[OK]をクリック

20140922_005

[Load SiteMap]をクリック。サイトマップ情報が取得される。

20140922_006

[Area(SFA)]以外を削除してみる。それぞれを右クリック[Delete]

20140922_007

[Area(SFA)]を展開

20140922_008

[Group(MyWork)]と[Group(Customers)]を逆にしてみる。

[Group(MyWork)]選択、↓クリック

20140922_009

反映させてみる。[Update SiteMap]クリック。以下の画面で5秒程度待つ。

20140922_010

公開不要。アクセスしてみる。タイルが変更されている。

20140922_011 20140922_012

ミスがあっても問題ない。設定を戻すことも可能。

[More actions]>[Reset CRM 2013 SiteMap to default]をクリック

[はい]クリック。

※クリックしただけでは、Onlineの環境は変更されない。

20140922_013

[Update Sitemap]クリック。実際にアクセスしてみる。

20140922_015

 

非常に簡単なツールであり、また簡単にデフォルトへ戻すことができる。

サイトマップはデータベース構造に影響を与えるようなものではない。

様々なことにトライしてみるとよい。

例えば、[営業]と同じ単位に[Yahoo]を作成し、http://www.yahoo.co.jpを入力すれば、

Yahooにアクセスできるタイルボタンが作れたりする。

イントラやBIグラフを表示させてもよいかもしれない。

ただし、1点注意が必要である。

このツールを利用すると同時にDynamics CRM標準の画面カスタマイズは行えないという点である。

このツールは最初に接続し、取得したサイトマップを含むソリューションに対して、

Updateを実行する。途中でカスタマイズを行ったとしても最後に上書きされてしまう。

以上。

実践 カスタマイズ (6) 関連設定のカスタマイズ

関連設定に関して記述する。

関連設定とはエンティティとエンティティとの関連を設定するものである。

Dynamics CRMで実装可能な関連設定と設定方法、マッピング、伝播に関して記載する。

 

設定可能な関連設定は、「1:N」「N:1」「N:N」の3種類である。

「1:N」「N:1」に関しては以下のとおりである。どちらが先かというだけで同義である。

1に該当するエンティティには関連先のエンティティのデータを

N個関連できるように関連ビューが設定可能となる。

Nに該当するエンティティには関連先のエンティティのデータを

1個関連できるように検索(Lookup)型のフィールドが追加される。

「N:N」に関しては両エンティティに関連ビューが設定可能となる。

以下3点を補足する。

・Lookupに表示される値はプライマリーフィールド。

・1:1の関係は作成できない。1:Nのような形式をとり、

N個作成できないようPluginを利用したコーディングで制御するような方法をとるしかない。

・N:Nのデータを作成する際は既存のデータを関連づけるしかない。

関連ビューのボタンを見れば分かるが、作成というボタンは存在しない。

 

次に私の設定方法である。N:Nは割愛し、1:N、N:1のケースを記載する。

・どちらのエンティティにLookupがくるか考える

・フォームのカスタマイズからLookup型を作成する

1:N、N:1の関連設定は、下記のエンティティのカスタマイズから作成が可能である。

20140912_001

しかしながら、フィールドの追加と同様フォーム上から実施するほうが

作成から配置までを一貫して操作が可能であるため、私は以下の方法をとっている。

取引先企業に[営業アシスタント]というユーザーエンティティのLookupを作成する場合とする。

取引先企業のフォームにアクセスする。[フォーム]をクリック

20140912_002

[新しいフィールド]をクリック

20140912_003

 

以下のように入力し、[保存して閉じる]をクリック。

[関連付け名]はデフォルトの値で困ったことはないため変更不要。

20140912_004

 

任意に配置する。

20140912_005

 

保存して公開すれば、フォームへ反映完了。

逆のユーザーエンティティでの状態を確認する。

ユーザーエンティティのフォームのカスタマイズ画面を起動する。

左側の関連ナビゲーションに[取引先企業]が追加されている。

自動的にリボン上に表示するのがデフォルトであるため、不要な場合は削除する。

20140912_006

 

次はマッピングに関してである。

※マッピング及び次の伝播に関してはあまり意識をされていないように思われる。

マッピングとは1エンティティのフォーム上に表示されるN関連したエンティティのデータを

作成する場合、1エンティティ側のフィールドの値をNエンティティ側に反映する機能である。

取引先企業と取引先担当者は1:Nの関係となっていて、取引先企業上に表示されている

取引先担当者関連ビューから取引先担当者のレコードを作成することができる。

また、取引先企業と取引先担当者は住所フィールドを持っている。

所属する取引先企業と取引先担当者の住所は業務上同じであると仮定した場合、

マッピング機能がなければ双方のデータを作成する際、双方の住所データを入力する必要がある。

取引先担当者が1000名存在したら、1000回住所を入力する必要がある。

しかしながら、マッピング機能を使うと、取引先担当者の住所には常に所属する取引先企業の

住所データが反映される。入力する手間が省ける。

初期設定でこのようになっているため、設定されている箇所を確認する。

エンティティのカスタマイズで、[取引先企業]>[1:Nの関連付け]

>関連エンティティが取引先担当者のものをダブルクリック。

20140912_007

 

[マッピング]をクリック。

マッピングされている情報が表示。追加が必要な場合は[新規]をクリックして追加していく。

20140912_008

実際の動きは下記。

住所が入力され、保存されている取引先企業のフォームを起動し、

取引先担当者関連ビューの[+]をクリックして取引先担当者を追加する

20140912_009

 

右列の住所情報に値がセットされていることが分かる。

 

20140912_010

 

初期値をセットするだけであり、取引先企業での変更ごとに同期が取られるわけではないという点に注意が必要である。

 

最後に伝播である。

伝播とは、1側のエンティティの割り当て等変更が発生した場合、

この変更をN側エンティティにどう反映するかというものである。

例えば、ある取引先企業とその取引先担当者を管理していたとする。

あるとき、その取引先企業が廃業し、今後一切この取引先企業の情報を参照しないことになり、

取引先企業を削除する必要が発生したとする。

伝播が全く行われない場合、取引先企業を削除しても取引先企業のみが削除され、

取引先担当者は削除されない。一方、伝播が行われる場合は同時に取引先担当者も削除される。

こういったイメージのものであり、所有者の変更や共有などといった

変更アクションに対しても設定が可能となる。

設定箇所はマッピングの上の情報という部分である。

20140912_011

 

上記は[割り当て(所有者変更)]が発生した場合、どのような範囲で伝播をさせるかを選択している。

SFAの場合は、所有者を営業担当のようにして利用することが多々ある。

取引先企業の営業担当者が変更となった場合、取引先担当者や営業案件の所有者をどうするかは

業務次第である。実は重要な設定のひとつである。

ここではこれ以上の詳細は割愛する。実際に様々な設定をして動きを確認しておくことをお勧めする。

あまりドキュメントが見当たらないため、cascade(=伝播)、relationship behavior(=関連付けの動作)

などで検索したblogなどを参考にするとよい。

以上。