Dynamicsポータルの民族大移動的な移行

今使用している試用期間が切れそうになったので、この辺りで話の腰を折ってポータルの移行の話をします。

スポンサーリンク

ポータルの移行について考える

試用版を使っている時や開発環境から本番環境へ移さないといけない時にありがちな話。

環境を変更してポータルの設定を維持した状態で移行する時は話がややこしくなります。

同一テナントへの移行

こちらはそれほど難しくありません。

こちらはDynamics管理センターからインスタンスをコピーすればOK。
一部ポータルのURLなどの設定変更こそありますが、ポータル関連のレコードのインポートは必要ないのでだいぶ楽です。

異なるテナントへの移行

ここからが本題!

同一テナントではインスタンスのコピーで一応何とかなりそうですが、別テナントへ同じような設定をすると結構大変だったりします。

別テナント以降のために何をやらないといけないか?
大きくは以下の4つとなります。

  1. 移行先テナントへポータルの初期構築
  2. ソリューションの移行
  3. ポータル関連データの移行
  4. ポータルで使用しているデータの移行

移行先テナントへポータルの初期構築

こちらは移行前と同じようにDynamicsのポータルアドオンでポータルを構築

ソリューションの移行

これは従来のDynamics開発などをやっている方はお馴染みかと思いますが、プロジェクト単位なので管理したソリューションをエクスポートして移行先の環境にインポートすればOKです。

移行先テナントへポータルの初期構築

これが一番厄介。
ポータルを要さないDynamicsの設定は大抵ソリューションに含まれているため、前述のソリューション移行で済んでしまうものなんですが、ポータルの設定は今まで設定していて分かるように、レコード単位での設定となります。
つまり、メタデータではなくレコードでの設定なので、このレコードデータも一緒に移行しておかないとダメなんですね。

レコードの移行だったら、Excelエクスポート→インポートでええやんと思うかもしれませんが、ポータルの設定で使用されるエンティティはたくさんあります。
どれだけたくさんあるかというと、これくらい。

  • 広告(adx_ad)
  • 広告配置(adx_adplacement)
  • アラート サブスクリプション(adx_alertsubscription)
  • J\\’Çhåñgé pâsswõrð för pörtäl çóñtªçt瑞갂偁略瑞갂偁略瑞?J(adx_bpf_c2857b638fa7473d8e2f112c232cebd8)
  • コンテンツ スニペット(adx_contentsnippet)
  • エンティティ フォーム(adx_entityform)
  • エンティティ フォーム メタデータ(adx_entityformmetadata)
  • エンティティ リスト(adx_entitylist)
  • エンティティのアクセス許可(adx_entitypermission)
  • 外部 ID(adx_externalidentity)
  • 招待状(adx_invitation)
  • 招待状の引き換え(adx_inviteredemption)
  • ページ アラート(adx_pagealert)
  • ページ通知(adx_pagenotification)
  • ページ タグ(adx_pagetag)
  • ページ テンプレート(adx_pagetemplate)
  • アンケート(adx_poll)
  • アンケート オプション(adx_polloption)
  • アンケート配置(adx_pollplacement)
  • アンケート送信(adx_pollsubmission)
  • ポータル コメント(adx_portalcomment)
  • ポータル言語(adx_portallanguage)
  • 公開状況(adx_publishingstate)
  • 公開状況移行ルール(adx_publishingstatetransitionrule)
  • リダイレクト(adx_redirect)
  • 設定(adx_setting)
  • ショートカット(adx_shortcut)
  • サイト マーカー(adx_sitemarker)
  • サイト設定(adx_sitesetting)
  • タグ(adx_tag)
  • URL 履歴(adx_urlhistory)
  • Web ファイル(adx_webfile)
  • Web ファイル ログ(adx_webfilelog)
  • Web フォーム(adx_webform)
  • Web フォーム メタデータ(adx_webformmetadata)
  • Web フォーム セッション(adx_webformsession)
  • Web フォーム ステップ(adx_webformstep)
  • Web リンク(adx_weblink)
  • Web リンク セット(adx_weblinkset)
  • Web 通知エンティティ(adx_webnotificationentity)
  • Web 通知 URL(adx_webnotificationurl)
  • Web ページ(adx_webpage)
  • Web ページ アクセス制御ルール(adx_webpageaccesscontrolrule)
  • Web ページ履歴(adx_webpagehistory)
  • Web ページ ログ(adx_webpagelog)
  • Web ロール(adx_webrole)
  • Web サイト(adx_website)
  • Web サイトのアクセス(adx_websiteaccess)
  • Web サイト バインド(adx_websitebinding)
  • Web サイト言語(adx_websitelanguage)
  • Web テンプレート(adx_webtemplate)

その数なんと51エンティティ
(一部よくわからないものもありますが)

そしてもっと厄介なのが、これらのエンティティ同士でリレーションが繋がっているので入れる順番も考えないといけません

一旦、順番は置いておいて、まずは上記51エンティティを全データ全カラムをエクスポートで抜いておきましょう。

エクスポート作業はPowerApps上から行うのがおすすめ。
もうお分かりかと思いますが、ポータルの設定に関わるエンティティには全て頭文字が「adx_」で始まっています。

PowerAppsではエンティティから一覧が見れる上、直接エクスポートすることができるため、画面を切り替えることなく次々とエクスポートができます。

PowerAppsのエンティティから名前でソートしましょう。
PowerAppsからポータルのエンティティを一括取得

あとは「adx」で始まるエンティティを上から順にエクスポートしましょう。
ここまでは何も考えなくても大丈夫です。
ポータル関連エンティティをエクスポート

そして、バックアップをとったデータを移行先へインポート。
ここがらが難しい!

お互いに参照関係があるので、うまく親のエンティティを先に入れるようにしないといけません。

なんとなく順番分けするとこのような感じ
実際にやった訳ではなく、各エンティティの参照関係から出来るだけロスの少ないように組み立ててみました。
もっといい方法があるかもしれません。

第1群:ポータル設定系

対象エンティティ:Web サイト、設定、ポータル言語、公開状況

ここはポータルの核となるエンティティ。
自分でインポートするというよりも、ポータル作成時点でレコードが作成されていることが多いです。

第2群:サイト設定系

対象エンティティ:Web サイト言語、Web テンプレート、サイト設定、Web サイト バインド、コンテンツ スニペット

こちらはポータルではなくサイトに対する設定などが含まれているエンティティ。
こちらもデフォルトの時点で作成されていることが多いんですが、サイト設定などは手を入れがちなのでアップデートが必要なところは更新しておきましょう。

第3群:ロール系

対象エンティティ:Web ロール、公開状況移行ルール、エンティティのアクセス許可、Web リンク セット、ページ テンプレート

この辺りからややこしくなります。
Webロール系を入れる訳ですが、Webロールは他のエンティティと多:多になっていることが多く、一発では入りません。
Web ロールに関してはとりあえず登録だけ

第4群:ページ系

対象エンティティ:Web ページ、Web ファイル

ここが最難関!
Webページは特に参照するエンティティ、参照されるエンティティ共に多いので、一発でのインポートは無理です。
レコード登録と手動設定で分けたほうがいいかも。

第5群:コンテンツ系

対象エンティティ:エンティティ リスト、エンティティ フォーム、Web フォーム、ページ アラート、ページ通知、ページ タグ、リダイレクト、ショートカット、サイト マーカー、タグ、Web ページ アクセス制御ルール、広告、アンケート、Web リンク

ここはWebページに付いてくるコンテンツ系になります。
この辺りも一筋縄では行かないので、インポートと手動設定を使い分けて行きましょう。

第6群:コンテンツ詳細系

対象エンティティ:広告配置、エンティティ フォーム メタデータ、アンケート オプション、アンケート配置、Web フォーム メタデータ、Web フォーム セッション、Web フォーム ステップ

こちらはコンテンツ系に対する細かい設定などなどWebページやサイトに直接つくケースは少なく、親エンティティが定まっているのでまだ移行しやすい部類です。
Web フォーム ステップが自己参照あり、多:多ありでややムズかな。

第7群:トランザクション系

対象エンティティ:Web ページ履歴、Web ページ ログ、Web サイトのアクセス、URL 履歴、Web ファイル ログ、招待状、招待状の引き換え、アンケート送信、ポータル コメント、アラート サブスクリプション、J\\’Çhåñgé pâsswõrð för pörtäl çóñtªçt瑞갂偁略瑞갂偁略瑞?J

こちらはポータルの設定に直接関わらないものや依存関係の無いものなどです。
ポータルを使っていく際にログをとったりユーザを作る過程でできたレコードなので、特に過去履歴にこだわりがなければ移行しなくてもOKです。
(文字化けしているエンティティがなんなのか分からなかった)

最後にシメの作業

全部データをインポートしたら、インポートでは入りきれない多:多、相互参照、自己参照などを整理する必要があります。

多:多のエンティティ

お互い複数のレコードで結びついている状態です。
これはインポートではできないので、手動設定かな。

多:多のポータルエンティティ

  • 公開状況⇔Web ページ アクセス制御ルール
  • Web ロール⇔公開状況移行ルール
  • Web ロール⇔Web ページ アクセス制御ルール
  • Web ロール⇔エンティティのアクセス許可
  • Web ロール⇔Web サイトのアクセス
  • Web ロール⇔招待状
  • Web ページ⇔タグ
  • Web ページ⇔ページ タグ
  • 広告⇔広告配置
  • アンケート⇔アンケート配置

やはり、Webロール周りが多いですね。

相互参照

こちらは多対多と違って、異なる項目で互いのエンティティを参照しあっている関係。
使用用途によってはどちらか一方にしか向いていないことも多いので、レコードの使用状況を見ながら必要に応じて手動設定していく感じで。

  • Web ページ←→エンティティ フォーム
  • Web ページ←→エンティティ リスト
  • Web ページ←→Web ファイル
  • Web フォーム←→Web フォーム ステップ

Webページはやはり参照し合ってる関係が多くて慎重な設定が必要です。

自己参照

同一エンティティで参照しているものは、親を先に入れないと、子レコードに参照項目が入れられないので、1回のエクスポートではできません。
一度、親レコードへの参照を外した状態でインポートして、再度インポート(Upsert)するといいでしょう。

自己参照対象のポータルエンティティ

  • エンティティのアクセス許可
  • Web ページ
  • Web ファイル
  • Web リンク
  • Web フォーム ステップ

添付ファイル

Webファイルなどはレコードの登録だけでなく、ファイルを添付して機能するエンティティなので、レコード登録後ファイルを添付する作業を忘れずに。

ポータルで使用しているデータの移行

最後にポータルの設定ではなく、ポータルで使用しているデータ(取引先担当者など)。
これは従来のDynamicsのインポートと同じなので割愛。

ポータルの移行には時間がかかる

最終的な結論として、ポータルの移行はデータの移行作業が大きく入ってくるので、手順が複雑で時間がかかります。
もし、開発において移行作業に出くわした場合は、移行期間は多くみておいた方がいいでしょう。
少なく見積もっても1週間はかかるんじゃないかと思います。

コメント