- microsoftのログイン判断がちょっとややこしいので、開発環境を開くとき、現在と違うユーザやシークレットモードに入った方がいい
- 勉強材料Microsoft Dynamics 365 (CRM) &Power Platform Training (2023)
目次:
- はじめに
- Dataverse
- relationships
- views
- side map
- field types
- form types
- Business Rules
- Security
- reporting
- powerBI
- processes
- power automate(microsoft flow)
- data management
- search capabilities
- localization
- Solution
- portal
Dynamics 365 and PowerApps紹介
-
Dynamics 365 appsはmicrosoftが作った、デフォルトの機能アプリ(sales、customer service、ERPなど)、PowerAppsは使用者自身が作るカスタムAPP(common data service=CDS)
-
Dynamics 365 appの無料試しの申請URL、アカウント作成後
-
もし、すでにMicrosoftアカウントに登録されたメールアドレスをdynamics365試し版を申し込む場合
申請URL:https://dynamics.microsoft.com/ja-jp/sales/overview/- まず申請画面で”example@example.com”を入力、errorを起し
- この画面に入り、メールアドレスを入力
- 新アカウント作成をクリック
- 初期のユーザを作成の時、”admin”をつけた方が分かりやすい
- まず申請画面で”example@example.com”を入力、errorを起し
-
Power Platform admin centerに新しい環境を追加(デフォルト環境にはデータベースが少ない為)、Dynamics 365 appsを環境に追加したい場合、チェックを入れ、すべての「企業アプリ」を選択
-
-
環境が準備されたら、環境名クリックし、入った後URLをクリック、サービス一覧画面に入る。「Dynamics 365 — custom」には他すべてのサービスが入っているもの
power platform紹介
- power apps & dynamic365(common data service):アプリ開発用
- power automate(microsoft flow):ワークフロー作成或いは機能一体化
- power BI:レポート作成とデータ分析
- power view agents:BOT(ボット)などの自動化処理(客対応チャットなど)の開発
- 追記:
power platform admin center
Components of Dataverse
- dynamic365のデータ名詞と従来のデータベースの名詞の比較:
・entity == table
・attribute == column
・record == row
・relationship == relationship - 「solution」は各設定(データベースの設定、組織設定、コード、ダッシュボード、セキュリティロール、など)を一つのパッケージに入れ、他環境へ反映できる、salesforceの「変更セット」用途と似ている。
Creating Solution and Publisher
開発の時、直接「defult solution」を弄るのは避け、プロジェクト開始前、「customize solution」一個作成し、開発段階では、defult solutionから内容をcustomize solutionに追加し、そしてカスタマイズ。
-
publisher
solutionの所有者を表示、普通は会社名を使用。一個のsolutionには一個のpublisher必要。publisherはprefixを提供、awsの「tag」と似ている。以下は新規publisher作成画面
Solution新規作成の時、デフォルトの設定上「パッケージの種類」は「unmanaged」
-
作成後、solutionは空白状態、「既存を追加」機能でdefult solutionから内容を追加できる、環境既存の資材を編集の場合、ここで追加し、さらにカスタマイズ
Creating a Model Driven app
Customizing an Existing Table
データ種類
テーブルに列(field)を追加
レコードの表示画面をカスタマイズ
creating a relationship
ブラウザの開発者モードで、参照関係にマウスを乗ると、参照先recordのdivが表示される
例として、「Expense Request」と「Expense Item」の1:Nの関係をを作成
「Expense Request」のrelationship設置画面で「一対多」を選ぶ、或は「Expense Item」画面で「多対一」を選ぶ
保存すると、「Expense Item」テーブル上、「Expense Request」recordを参照するattributeが作成される
「Expense Request」のフォーム上、「コンポーネント」の「サブグリッド」で関連先を追加
「Expense Item」のフォーム上、テーブル列を直接画面に追加
作成済みのrelationshipを公開するには、relationship画面の「テーブルを公開」をクリック、この場合、フォーム上の変更も一緒に公開される
relationship behaviour
relationship種類によって、提供する「action」も違う
- referential(参照)、この種類はrecord間の所属関係がない(No cascading)
- parental(親子)、この種類はrecord間の所属関係がある(cascading)、親record変更されるとき、子recordにも影響がある。
例えば親recordが削除されると子recordも削除される、親recordが別ユーザにアサインされると子recordもアサインされる - custom
- cascade active(active状態の子recordのみ影響を受ける)
- cascade all
- cascade none
- remove link(親recordが削除されると、子recordとの関係をたつ)
- restrict(子record持つかぎり、親recordを削除できない)
- cascade user owned(現在のユーザが所有している子recordのみ影響される)
例として、「Expense Request」record中に「Expense Item」recordを持つ時、「Expense Request」recordが削除できない様にする。削除以外の動作には影響を受けない
Relationship Mapping
mappingがあるrecord間では、内容もある程度共有できる。
例えば取引先record画面で、取引先担当者新規の時、住所が自動入力される
mappingを設置するには、classicUIに切り替え、
例として、「Expense Request」record画面で「Expense Item」を新規の時、「Title」項目が自動入力するの設置
特定のテーブルを公開する
Hierarchy Relationship
テーブルはsalf relationshipを持つことができる、例えば取引先には親会社と子会社の関係を表示
テーブル「Location」を作成、salf relationshipを設置
設定後、階層を表示するとエラー出た、これは階層表示用のフォームが設定されていないため、classicUIに入り、階層表示用フォームを作成
「保存」と「公開」を忘れずに
N to N relationship
例として学生とコースの関係はN:N、この場合両方のテーブルを参照用の結合テーブル追加する必要がある(この結合テーブルは直接アクセスしない)。
Connections and Connection Roles
「Connection」を使って、テーブル間でrelationship作成せず、関係性を持たせる。主に既存relationshipの上に、更に関係性を表示する為使う
- 1:N relationship
テーブル間で関係性が存在するのを表示だけ、具体的どんな関係なのかを説明しない、例えば同じ会社(1)下の各社員(N)のそれぞれの関係を表示出来ない。
Connection(つながり)ではテーブル種類に縛られず、より柔軟的関係性を表示
connection(つながり)の種類を追加したい場合、「接続ロール」で追加
Introduction to Views
viewsの種類
- personal(ユーザ自身で設置する)
- system(「Solution」の中で設置できる)
- public
- Non-public
例として、「Expense Request」の二つ公開viewをカスタマイズ
viewをデフォルト表示にする
検索欄では特定の項目しか検索できない。
同時に、”*”でwildcard検索できる
検索できる項目を追加するには、「簡易検索ビュー」で設置、だが項目多いほどシステムが遅くなる、特に「discription」項目を設定しないように
一般ユーザもフォルダーでrecordを整理し、自分用のviewとして保存。
関連された別のテーブルrecordの項目も検索出来る
side map
アプリの左側で表示される内容を追加の場合、solutionの中「サイドマップ」を設定、画面表示範囲は エリア(赤)⇨グループ(緑)⇨サブエリア(青)になる
field types
- standard(default)
- calculated field(values、dates、text)
- roll up field(関連されるrecordの総計値を計算する:sum、min、max、count)
- 例として、「Expense Request」の「Total Amount」に関連された「Expense Item」の「Item Amount」の合計にする
- 設置完了後、「Expense Request」recordに合計値が計算されるまで時間が掛かる、手動で計算する場合「再計算」をクリック。
- もし反応がない場合、それは「通貨」種類が決めていないため、「通貨」項目をフォームに追加、正しい通貨種類を選ぶ(組織言語設定により、通貨の表示名が変わる)。保存後もう一回「再計算」を押す
個人持つrecord全体的に通貨を設定する場合、「個人設定」に入り、通貨種類を設定。注意必要のは、設定修正前作成されたrecordでは「通貨」が空白のまま
- 自動計算などの詳細を見たい場合、「詳細設定」画面に入り、「設定」のプールダウンで「system jobs」をクリック
定期実行のリストで計算jobをクリック、現在定期実行のスケジュール変更の機能が除去されたかも、或は開発者バージョンだけ変更できないかも
- 例として、「Expense Request」の「Total Amount」に関連された「Expense Item」の「Item Amount」の合計にする
form types
-
main form
-
quick create form
-
quick view form
-
card form
Business Rules
コードなしで業務ロジックを設計出来る(salesfroceのフローと似ている)。
-
例として、もし取引先担当者の「婚姻区分」項目が”単身”の場合、その人の「記念日」項目を無効化にする。
左上の条件欄をクリック、「ルール」に条件入力、「適用」クリックと、右下には条件が表示され
「コンポーネント」欄から「ロック」をTRUEの結果へドロップ。「記念日」項目をロック、FALSEの結果に「ロック解除」動作を入れる
名前を入れる、検証、保存し、有効化する
-
上記ルールの上、もし「記念日」には既存の値がある場合、「婚姻状況」が”単身”のなる場合、その値を削除し、同時に無効化にする。
先ずはルールを無効化、そして「記念日」無効化動作の前に、「フィールド値の設定」動作を追加、「記念日」の値を削除
-
ビジネスルールの作用範囲
adding user
基本各ユーザに権限を持つ「role」を振り分けてで、アクセス出来るデータの範囲をコントロール。
ユーザのマネージメントはoffice 356(microsoft 365)レベルで発生し、Azure active directoryが処理を行う。
-
ユーザを新規
使用したいサービスのライセンスを上げる
注意必要なのは、ここのroleはMicrosoft365のroleで、dynamic365のroleではない。一般ユーザにはadmin権限を付与しない様に。
Users and Ownership
Business Units
business unitは会社の部門と似ている、会社の機能やロケーションをベースに、いくつのbusiness unitを分ける。ユーザがそれぞれ自分のunit(部門)に所属べき
- 設置方法
- ユーザをunitに追加
Introduction to Security Roles
Security Rolesはいくつの権限を含め、ユーザがSecurity Roleをもらった後で、Security Role内すべとの権限がユーザに付与される(salesfroceの権限セットと似ている)。
Security Rolesは二種のprivilegesがあり、record-level privileges(recordのcreate、update、shareなど)、task-based privileges(メース送信、組織設定の変更など)
Deep Dive into Security Roles
- level of access(組織内、特定テーブルのrecordについて、該当権限がどのレベルで制限されているか)
-
user level
-
business unit level
-
parent-child business unit level
- 同じ部署と該当部署の子部署のrecordも全て見れる(salesforceの上下ロール関係の効果と似ている)
-
organization level
-
none-no privileges given
-
teams
チームもroleを持っている
recordの所有者もチームに設置出来る
- owner team
- Azure Active Directory Group team
- access team
Field Security
特定のfieldをアクセス出来るかどうかをコントロール。
- 特定のfieldのfield securityをONにする
- Solutionの画面に入り、「field security profile」を作成
- 作用対象のユーザやチームを入れる。
- profileで管理しているfieldを確認、このprofileにあてたユーザやチームはfieldの内容が見れない
Hierarchy Security Manager
HierarchyはSecurity roleやField Securityの補充機能として使う、機能上二種類があり
-
Manager Hierarchy
例として、階層は「director → マネージャー → 社員」になり、マネージャーが自分下の社員所有するrecordを閲覧編集削除出来る、directorが自分下のマネージャー所有するrecordを閲覧編集削除出来る、だがdirectorが社員所有するrecordを閲覧でき、編集削除出来ない、みたいな機能が欲しい場合
有効化後、ユーザrecordの管理タブに「上司」項目を設定できる
-
position Hierarchy
効果としてManager Hierarchyと似ているが、position Hierarchyはユーザ毎上司を設置するではなく、いくつのpositionを用意し、ユーザにこのpositionに充てて、そしてposition間の関係で、誰か誰のrecordを見れるのかを管理する
Charts
chartはdynamic365とpowerBI両方から作成できる。
viewと同じ、system用とpersonal用両方がある。
- 例として、system chartを作成
- 月毎のTotal Amountを見るための図を作成(「Total Amount(基本)」の意味は”基準通貨を使用”、ユーザの設置による通貨単位の違いを避けるため)。
もっと複雑の図を作成の場合、powerBIを使用
Dashboards
二種類があり
-
global dashboard(at the solution level)
-
entity dashboard(interactive dashboard)
powerBI
powerBIはビジネス分析サービス、dashboardやreportなどを提供
free版の試し教材
Introduction to Processes
type of processes
- action
- busniess process flow
- workflow
workflows
- workflowを新規
既存のworkflowから作成の場合、「テンプレート」を選ぶ
- 例として、取引先recordが作成された時、ownerにそれを確認のtaskを投げる
- workflowの動作の「同期(realtime)」や「非同期(background)」を変換できる
- workflowのlogを見る場合
Email using Workflow
-
例として、employeeがExpense Request作成の時、managerに通知メールを送信
受信先を該当recordの所有者の上司に設定
メール内容を設定
アプリの中で、「活動」のテーブルでworkflowなどの記録が見える
-
例として、Expense Requestの「status」変更された時、「approval date」を更新
power automate
-
part of power platform
-
online workflow & intergration service(can take data from one APP to another App) to automate tasks
-
例として、手動でflowを起動し、dynamicの中でrecordを作成
dynamic365の機能は放棄されたため、使えない。代りに「dataverse」を使用
import data wizard
-
supported files (zip maximum 32M, others maximum 8M)
- .csv
- .txt
- .xml
- .zip
- .xlsx
duplicate decation
重複チェック、例えば営業員が取引先新規の時、もし新規内容の名前と住所が既存のrecordとの重複がある場合、作成を制限する。
auditing
組織内データの変更を追跡、logに保存。
- how to enable auditing
Search Capabilities and Categorized Search
types of search in CDS
-
relevance search(20230817時点提供されない)
デフォルトは無効、先ず有効化必要。relevance searchはAzure Search Serviceにベースした
language
「基本言語」と「基本通貨」は組織(instance)作成の時選び、そして変更できない。変更できるのはユーザ個人interfaceの言語のみ
field translation
APP levelの翻訳をダウンロード
テーブル(entity)の翻訳
Solution
solution is a group of configurations / customizations of CDS components.
- default solution
- すべてのCDS(common data Service)のコンポーネントを持つ
- 直接default solutionの変更は推奨しない、custom solutionを作成そして変更
- 資材が多すぎ、変更内容の追跡が困難
- managed solution
- 開発完了のsolution、分配とインストール用
- rollbackできる
- 目標環境に導入後、変更不可にするのは出来る(managed properties)
- 削除される場合、中身の資材も環境から削除される、つまりrollback
- unmanaged solution
- custom solution作成の時、デフォルトはunmanaged
- このsolutionをexportし、別の環境に移行可能。移行後、目標環境内もこのsolutionが変更可能
- 一般的、development環境間でunmanaged solutionを使用、test、UAT、predation環境へmergeの時、managed solutionを使用
- rollback出来ない
小さな追加やbug修正を他環境へ反映したい場合、solution patchを使用
portal
websiteみたいなもの、外部ユーザはcontactとして保存される
- powerAPP portal = dynamic365 portal
- dynamic365やPowerAppへアクセスする為に、ライセンスが必要
- 外部ユーザへデータ共有や入力の時、portalを使用、ライセンス不要
二種類のportal
- dataverse starter portal
- portals within environment with customer engagement apps
Provisioning a Portal
dataverse starter portalを作成
作成出来るまで20分ほどかかる
作成できたwebsiteを管理