本文へ移動
Wagby11
マニュアルのグループを選ぶ

WAGBY11 MANUAL / 28

定義が異なる環境へ業務データを移す

業務データの移送と同じ定義への完全復元を区別し、移行先のロール・権限・所有情報を保ってデータを引き継ぐ手順を説明します。

最終更新日:

運用の小目次へ

1. このページで伝える機能

業務データの移送と同じ定義への完全復元を区別し、移行先のロール・権限・所有情報を保ってデータを引き継ぐ手順を説明します。

2. Wagby11で実現できること

2.1 完全復元と業務データの移送を区別する

同じ定義の環境へバックアップを戻す場合と、モデルや権限を変更した環境へ業務データを移す場合では、取り込む対象が異なります。定義が異なる移行先では、原則として必要な業務モデルを選び、移行先の現行定義で作成された権限情報を維持します。

ZIPのスキーマ指紋が一致しないという警告は、定義の差を調べる手掛かりです。警告を確認しただけで、権限データを安全に置き換えられると判断しません。テーブル構造が同じでも、ロールや項目権限の内容は変わる場合があります。

2.2 移行先の権限情報を維持する

モデルID異なる定義へ旧データで置換した場合の影響
jrole現行定義のロールが旧データに置き換わります。
jpermissionモデル操作権限や項目権限などが失われることがあります。
jrole_jpermissionロールへの権限割当や非表示制限が旧内容に戻ります。
jauthorization_state認可情報の世代を管理する状態が旧値へ戻ります。

これらを旧ZIPから一括して入れ替えないでください。現行のファイル検査が自動的に除外するものではないため、管理画面では対象選択から外し、CLIでは--entityで業務モデルを明示します。再起動だけで現行定義の権限へ完全復旧するとは限りません。ZIPの検証後に対象を絞る例も参照してください。

利用者へのロール割当juser_jroleは、移行先に存在するロールIDとの対応を確認して別途移します。依存関係の検査に失敗しても、旧権限データの全件置換で回避せず、利用者・所属などの移行手順を先に整えます。

2.3 所有情報とログインを確認する

所有者は登録者の監査情報とは別です。個人所有のownerUserId、グループ所有の中間テーブルとグループを対応付けます。グループ所有の移送モデルは<モデルID>__owner_groupで、親JSONへ所有グループの配列を書く形式ではありません。必要なグループがない状態は、通常の更新時にエラーになることがあります。

利用者juserとパスワードの資格情報は別に保存されます。利用者・資格情報・ロール割当・所属を移す場合は、復元後も管理者がログインできる構成か確認します。ワークフローを移す場合は、経路・実行状態・履歴の整合性も必要です。

移送先の検証環境で、管理者と代表的な一般利用者のログイン、検索できる範囲、見える項目、通常の更新を確認します。データの所有と利用者へのロール割当も参照してください。

3. AIへの指示例

ここでは、標準で用意されている機能をAIに使ってもらう指示を示します。

最小限の指示例

標準のデータ移送機能を使って、定義を変更した検証環境へ業務データを移してください。

AIはモデル・項目と権限の差分、依存関係、利用者と所有情報の対応を調べ、移送するモデルと確認方法を補います。移行先、対象モデル、既存データを追加するか置き換えるかを明示すると、実行範囲が定まります。最小限の指示だけで次の詳細例と同じ対象・方式になるとは限りません。

より詳細な指示例

標準のデータエクスポートとインポートを使い、移送元から定義変更後の検証環境へ、指定した業務モデルのデータを移してください。移行先の対象モデルは入れ替えてよいものとし、既存データを事前にバックアップしてください。
移行先のjrole、jpermission、jrole_jpermission、jauthorization_stateは現行定義の初期データを維持し、旧ZIPでREPLACEしないでください。標準のWeb画面でZIPを検査し、業務モデルと必要な依存モデルだけを選んで取り込んでください。
利用者・資格情報・所属・所有情報を移す場合は、移行先に必要なIDと依存データがあることを確認してください。juser_jroleの割当は移行先のロールIDへ対応付けます。対応を決められない項目は取り込み前に報告してください。
ZIPのフォルダを削って対象を変えず、標準機能の対象選択を使います。処理後は管理者と代表的な一般利用者のログイン、データスコープ、項目可視性、通常更新を確認し、移送件数と結果を報告してください。

4. 編集されるAppSchemaの例

移送対象を決めるための新しいAppSchema項目はありません。移行先の現行AppSchemaと移送元の定義を比較し、取り込むモデルとロールIDの対応を決めます。ZIPや過去の権限データで、移行先のAppSchema自体を書き換える操作ではありません。

モデルの型・識別名を変更する場合は、既存項目の変更も確認します。既存のmigration_idは保持し、移送のためだけに再発行しません。

5. 参考資料

guide:データのインポートとエクスポート
designer/docs/appschema/html/guide/15-operations/02-data-import-export.html
REST API:データ移送
designer/docs/java/html/restapi/37_data_transfer.html