Servicenowのインポート機能は強力なのだが、時に躓くことがある。
この例も実際自分が躓いた例。Type がReferenceになっていて同名レコードが元テーブル（参照先テーブル）に存在するフィールドの正しいインポート方法。
例えばであるがsys_userに「山田 太郎」という名前の人物が2名いる。
例えばこんなケース。
yamada.taro1とyamada.taro2は「User ID」や「Sys_ID」では区別ができるので、sys_userテーブルに対するインポートや更新では特に問題になる事はない。
問題になるのはこの同名のエントリをルックアップしているテーブルのインポートを行うときである。
例えばグループとユーザの関係性を定義している、sys_user_grmemberテーブルを見ると次のようになっている。
Help Deskグループに山田 太郎が二人とも所属している場合こうなる。
インポート機能を使った事がある方はお分かりと思うが、このようなデータをインポートしようとして、テーブルをエクスポートしたり、更新インポート用のエクセルフォーマットを出力したとしても、次のようなフィールドが得られるだけである。
要するにこのままでは、「山田 太郎」がyamada.taro1とyamada.taro2のいずれなのかを区別して扱う事が出来ない。
当然ながらこのようなデータをインポートしても、１と２どちらの山田太郎が選択されたデータが出来上がるかが不明である（ちゃんと検証していないがSys_IDが若い方が勝手に選ばれていた様な気がする）。
これでは困るので、SYS IDなりユーザIDなり一意の情報を指定してインポートしたいわけだが、User列にyamada.taro1のIDなりSYS_IDなりを記載してインポートしてもエラーになるだけなのである。
色々と検索してみても（どこかにはあるのかもしれないが）なかなかこれを解決するためのドキュメントが見つからず困った。
で、この同名レコードのルックアップ元テーブルからのインポート問題（Type がReferenceになっていて同名レコードが元テーブルに存在するフィールドの正しいインポート方法）、を解決するには、結論としてはインポート用のデータを少し工夫した上で、変換マップでそれに応じた定義をしてやる必要がある。
ちなみに↓この辺の記事を検索して、もしかしてScriptを書かなきゃいけないのか？とかいろいろ逡巡したが・・・よく読んだらこれは別件。
↓こっちの最後の方のやり方で解決。
まずyamada.taro1とyamada.taro2を一意に特定可能なカラムをインポート元のファイルに用意する。
ここではUser IDを使用したが、sys_id等を使っても基本的に考え方は同じ。
このデータをインポートすると、
・yamada.taro1がApplication Developmentに、
・yamada.taro2がTeam SNOWとApplication Developmentの両方に、
・Helpdeskへの所属は両名とも上書きで無くなる、
という変化を想定する。
では実際定義を進めてみたい。
まずSystem Import Sets -> Load Dataからこのファイルをロードする。
Submit。しばらく待って次の画面で、Create transform map。
次のようにしていったん保存。
Auto Map Matching Fieldsでいったん簡単にマッピングできるところはしてしまう。
更新インポートにしたいのでSYSIDもマッピングする必要がある。NewボタンでField MAPの定義を出し、次のようにSys_IDのマッピングを定義。Submit
また、User列も問題になるので、画面下部のリストから〇にiマークのアイコンからOpen Record。
次のような定義になっているのを、
次の通り変更する。
Source field：User_ID ←こちらはExcelファイル上のカラム名
Referenced value field name：User_ID ←こちらはsys_userテーブル上のカラム名
これでExcelのUser_ID列を、sys_userテーブルのuser_idカラムをリファレンスにしてsys_user_grmemberテーブルのuserフィールドに対応付けるという定義が出来たので、Update。
次の画面に戻るので、Create new record on empty coalesce fieldsにチェックしておき、Save。
Transform。
今度はTransformボタン。
完了。
sys_user_grmember.listで確認してみると・・・
あれ、追加は正しくされている物の、アップデートが変化してないぞ。。。
うーん。Application Development に yamada.taro2が所属、という新規レコードは正しく反映されているのと、ほかの2レコードもレコードの最終更新日時は上書きされているので、インポート手順とは別問題の様な気がする。
そもそもsys_user_grmemberの既存エントリって、編集不可なんだよな、フォームで直接開いても。。。
・・・という事で消化不良ながら、この方法でSysIDなり、その他のUser IDの様な一意の値を使って、参照タイプのフィールドも適切に設定する事自体は可能な事がわかった。
sys_user_grmemberテーブルに更新インポートが通らないのは別問題として調査継続としたい。
0 件のコメント:
コメントを投稿