Skip to main content

 

 

 

 
Language:

 

 

 

 
 
OutSystems

データ移行の概要

このガイドは、OutSystemsアプリケーションのデータ移行サポートの開始点になります。ケースごとのシナリオに応じて個別にソリューションを定義する必要があります。

データ移行の目的

このガイドの目的は、1つのアプリケーション(またはソリューション)の純粋なアプリケーションデータとハイブリッドデータを、ソースとなるProduction環境からターゲットとなるNon-Production環境に移行することです。

推奨事項(ソース環境とターゲット環境間)

  • プラットフォームのバージョン: OutSystemsではリスクを避けるために、ソースとターゲットのプラットフォームバージョンを同じにすることを推奨しています。ただし、ソリューションツールによっては、バージョンが同じであることは必須ではありません。

  • データベースエンジンとバージョンが同じである必要があります。

  • データベース定義:ソースとターゲットのデータベース定義が同じであることが望ましいです。定義が同じではない場合は、違いを管理する必要があります。たとえば、ターゲットの新しいアトリビュートの処理内容(デフォルト値の有無にかかわらない)やソフトデリートされたアトリビュートの処理内容を確認します。また、ターゲットの新しいエンティティやソフトデリートされたエンティティの処理内容も忘れずに確認します。

  • ビジネスプロセステクノロジー(BPT)のプロセス定義の違い:定義が異なるプロセスやアクティビティのデータを環境間で移行することは可能ですが、新しいBPT定義では不要なデータが移行される可能性やデータが失われる可能性が高くなります。

  • ターゲットのエンティティデータ - 移行前に削除するという選択肢: テストのためにProduction環境とNon-Production環境のデータを同じにすることが目的の場合、計算、メトリック、ダッシュボードなどに変更を加える可能性のある不適切なデータや重複するデータが含まれないようにすることが重要です。選択肢の1つとして、移行プロセスの最初のステップでターゲットのデータとその依存関係を削除するという方法があります。この場合、削除する必要があるデータコンシューマがある可能性があることを忘れないようにしてください。

  • ターゲットのアプリケーションのダウンタイム:移行プロセスの実行中、ターゲット環境で関連するアプリケーションを無効にし、ユーザーがアプリケーションにアクセスできないようにし、ビジネスデータやアプリケーションデータに影響を及ぼす可能性のあるアプリケーションアクティビティをすべて停止することを推奨します。ただし、これは必須ではありません。移行プロセスの実行中に実行してはいけないタイマー、プロセス、連携がこれに該当します。この場合は、Service Centerでアプリケーションを必ず無効にしてください。

その他の注記および注意事項

  • サイトプロパティ、設定、構成、連携エンドポイントをProductionからNon-Productionに移行しないでください。

  • 移行プロセスでターゲットのデータを削除しない場合は、繰り返すことができない一意のインデックスに注意する必要があります。

  • Cloudでは、権限がData-reader(データ読み取り者)とData-writer(データ書き込み者)に限られます。

  • ソフトキー(SK)は、外部キー(FK)のようには自動的にマッピングおよび置換されません。そのため、アプリケーションの実行時の動作に影響を及ぼすおそれがあります。

データの移行

アプリケーションおよびハイブリッドデータエンティティドメイン

移行プロセスでは最初に、ターゲットに移行するデータのソースとなるすべてのエンティティのリストを詳細に調べて取得します。

移行データドメインには、通常のビジネスアプリケーションデータに加え、ビジネスプロセスインスタンスやユーザー情報、グループ情報などのハイブリッドデータが含まれます。

これは、ソリューション、複数のアプリケーション、1つのアプリケーション、eSpaceに基づく場合がありますが、依存するすべてのプロデューサを含むようにする必要があります。

この情報を取得する方法については、「データの移行方法」をご覧ください。

エンティティとアトリビュートの物理名を照合する

プロセスのこのステップでは、アクティブなエンティティとそれらのアトリビュートを照合する必要があります。

アクティブなエンティティとそれらのアトリビュートの物理名は、環境間で異なる場合があります。名前が一致していないだけではなく、エンティティやエンティティ内のアトリビュートが重複している場合もあります。しかし、環境間で一致しているアクティブなエンティティやアトリビュートは1つのみです。

クエリを使用してソースエンティティやソースアトリビュートから対応するターゲットの関連するエンティティやアトリビュートにデータをプッシュする際、この照合に留意することが非常に重要です。この照合には、SS_keyを使用するか、エンティティアトリビュートのSS_Keyと関連するeSpaceのSS_keyを常に組み合わせて使用します(エンティティのSS_Keyを繰り返すことはできますが、eSpaceのSS_Keyと組み合わせた場合はできません)。

プラットフォームの開発インフラ管理の詳細については、「開発インフラのアプリケーションモジュール」および「開発インフラのデータベース」をご覧ください。

システム静的エンティティレコードの識別子を照合する

次にプロセスでは、移行するエンティティデータに外部キーを持ち、使用中の静的エンティティレコードのデータ識別子を照合する必要があります。

静的エンティティはOutSystemsプラットフォームで管理され、変更できません。環境間で同じアプリケーションバージョンがパブリッシュされた場合、両方の環境に同じアクティブな静的エンティティレコードが存在し、OSUSR物理テーブルに対応する識別子が存在します。

列挙されたエンティティレコードに対応する識別子は、環境間で異なっている可能性があります。そのため、データ移行時にこれらを操作して変更するために照合し、環境間でビジネスコンセプトや意図が同じになるようにする必要があります。

移行するデータに基づき、プロセスで以下を実行する必要があります。

  1. 外部キーを持ち、使用中のすべての静的エンティティのリストを取得します。
  2. エンティティレコードのSS_KeyとseSpaceのSS_Keyを使用して、静的レコードの識別子を照合します。
  3. 環境間で異なる場合は、照合した識別子の値を保持して外部キーを置き換えます。

詳細については、「静的エンティティ」をご覧ください。

BPTトリガーを無効にする

BPTによってトリガーされるエンティティには、直接関連するTriggeredと対応するOSEVTエンティティがあり、すべてのエンティティイベントがサブスクライブされます。

BPTトリガーを停止する解決策の1つは、すべてのBPT Triggeredエンティティを検索し、ターゲットのOSEVTエンティティのすべてのデータを削除することです。この場合、トリガーが実行されます(最適な解決策ではありません)が、BPTイベントのサブスクリプションを確認しても何も見つからないため、スケジュール設定されたシステムによって処理されるシステムイベントキューには何も挿入されません。 この回避策ではシステムトリガーは無効になりませんが、無効になっているときと同じような結果と動作が得られるように試みています。

次のステップでは、イベントエンティティデータを移行して通常の動作を再確立します。

ユーザーとグループを作成または更新する

移行プロセスのこのステップでは、移行するアプリケーションとデータに関連するすべてのユーザーがターゲット環境で作成されたかどうかを確認します。

通常、ユーザーはアプリケーションデータ全体で最もよく使用される外部キーであり、ユーザーのロールと権限に基づいてアプリケーション動作を変更することができます。ユーザーは、ロールが割り当てられたグループに属することができます。

この目的を実現には、移行プロセスで以下を実行する必要があります。

  • 移行するアプリケーションで使用するユーザーのドメインを取得します。
  • その後、様々なアプローチでユーザーを移行することができます。

    1. アプリケーションで何らかの形でユーザーデータが使用され、変更できる場合(電話番号やメールなど)、ターゲットにすでに存在するユーザーのデータを更新する必要があるときは、ターゲットで一致するユーザーをすべて削除してからそれらのユーザーを再度作成するアプローチが推奨されます。
    2. ログインでのみユーザーが使用され、アプリケーションデータに外部キーがある場合は、ターゲットで作成する必要があるユーザーを確認することができます。

アプローチに応じて、以下が作成または更新されます。

  • ユーザー
  • ユーザーロール - ユーザーに直接割り当てられたロール
  • グループ
  • グループロール - グループに割り当てられたロール
  • グループユーザー - グループに割り当てられたユーザー。グループに割り当てられたロールが間接的にユーザーに割り当てられます

ユーザーをユーザー名で、グループを名前でそれぞれ照合し、環境間の識別子のマッピングを維持します。そうすることで、以降のステップで移行する際にコンシューマエンティティの外部キーを置き換えるときにこれらを使用できるようになります。

ユーザーおよびグループのメタモデルの詳細については、「アプリケーションのユーザー、グループ、ロール」のセクションをご覧ください。

アプリケーションデータを移行する

移行プロセスのこのステップでは、最初にソースからエンティティデータを取得してターゲット環境にプッシュします。

移行するエンティティのリストを事前に設定しておきます。最初に、以下に関連するすべてのエンティティを取得します。

  • 1つのeSpace - eSpaceに関連するすべてのエンティティ
  • 1つ以上のアプリケーション - アプリケーションに関連するすべてのeSpaceに関連するすべてのエンティティ
  • 1つのソリューション - ソリューションに関連するeSspaceに関連するすべてのエンティティ

移行するエンティティのドメイン(OSUSR*)があり、このドメインに関連するイベントエンティティ(OSEVT*)を消去すると、データの移行を開始できます。

前のステップに基づき、このデータ移行のガイドでは、データ移行プロセスで、ソース環境とターゲット環境のエンティティ識別子のマッピングと照合を行う補助サポートテーブル(一時的または非一時的)を設定することを検討します。これを使用して、ターゲットの外部キーをマッピングに基づいて置き換えることができます。この外部キーマップ(「FKマップ」)は、各タイプに応じて異なるステップで処理することができます。

  • 静的エンティティレコードの識別子

    データはプラットフォームで管理され、開発されたソリューションが変更されたときにのみ変更されるため、静的な識別子の照合は早いステップで行うことができます。

  • ユーザー識別子

    ユーザー識別子の照合は、環境間でユーザーを調整するステップで行うことができます。

  • その他のすべての外部キーマップ

    この識別子の照合は、データ移行プロセスの実行中および進行中にのみ行われます。

データ移行プロセスの実装方法によっては、エンティティが外部キーの依存関係に基づく優先順位に従う必要があります。外部キーの優先順位が原因で、まだ移行されておらずFKマップでマッピングされていない外部キーを持つレコードを挿入できないということが発生します。このため、移行ソリューションではエンティティ間の依存関係と間接的な循環依存関係について最適な処理方法を特定する必要があります。移行プロセスでエンティティの循環依存関係を処理する方法の1つとして、オプションの外部キー(FK)を特定し、そのFKを挿入時は空にしておき(最初のステップ)、後で更新します(2番目のステップ)。

エンティティデータの一般的な移行プロセス

外部キーの依存関係によって順序付けられたエンティティごとに以下を実行します。

  • 環境間で物理テーブル名とアトリビュートの照合を検討します。

  • ソースからレコードを取得して以下を実行します。

    • FKマップのソースIDを、対応するeSpaceのSS_Key、エンティティのSS_Key、アトリビュートのSS_Keyで挿入します。
    • すべての外部キーをソースIDからFKマップにあるターゲットIDに置き換えます。
    • レコードの外部キーがレコード自体のIDである場合は、挿入後、新しいIDを使用してレコードを更新する必要があります。
    • FKマップの新しいターゲットIDを、同じeSpaceのSS_Key、エンティティのSS_Key、アトリビュートのSS_Keyで挿入します。

DBエンティティの関係の複雑さの度合いによっては、各レコードを処理する前に、一時テーブルで外部キーの一括置換を試行してからことでプロセスを改善できます。

ハイブリッドBPTインスタンスデータ(OSSYS_BPM_*インスタンス)を移行する

プロセスのこのステップでは、プロセスアプリケーションインスタンスデータを移行します。定義はプラットフォームによって保持され、変更できません。

以下のリストは、BPTハイブリッドテーブルを示しています。

  • OSSYS_BPM_PROCESS
  • OSSYS_BPM_PROCESS_INPUT
  • OSSYS_BPM_PROCESS_OUTPUT
  • OSSYS_BPM_ACTIVITY
  • OSSYS_BPM_ACTIVITY_OUTPUT

BPTインスタンスデータを移行する前に、データ移行プロセスがまだマッピングされていない場合は、ソース識別子とターゲット識別子を外部キーマップ(FKマップ)にマッピングする必要があります。

  • プロセス定義識別子
  • プロセス入力定義識別子
  • プロセス出力定義識別子
  • アクティビティ定義
  • アクティビティの出力定義識別子
  • ロール識別子
  • テナント識別子

BPTインスタンスの移行手順は、アプリケーションデータの移行手順と同じです。外部キーの依存関係によって順序付けられたエンティティごとに以下を実行します。

  • 環境間で物理テーブル名とアトリビュートの照合を検討します。

  • ソースからレコードを取得して以下を実行します。

    • FKマップのソースIDを、対応するeSpaceのSS_Key、エンティティのSS_Key、アトリビュートのSS_Keyで挿入します。
    • すべての外部キーをソースIDからFKマップにあるターゲットIDに置き換えます。
    • レコードの外部キーがレコード自体のIDである場合は、挿入後、新しいIDを使用してレコードを更新する必要があります。(*)
    • FKマップの新しいターゲットIDを、同じeSpaceのSS_Key、エンティティのSS_Key、アトリビュートのSS_Keyで挿入します。
    • FKマップの新しいターゲットIDを、同じeSpaceのSS_Key、エンティティのSS_Key、アトリビュートのSS_Keyで挿入します。

(*)注記:FKを持つプロセスインスタンスのエンティティPARENT_ACTIVITY_IDでは、特殊な外部キーにご注意ください。 * PARENT_ACTIVITY_ID - プロセス移行後に移行されます。この場合、アクティビティの移行後にプロセスを更新する必要があります。 * TOP_PROCESS_ID - ルートプロセスでは、最上位のプロセスIDはそれ自体になります。この場合、プロセスレコードの移行後に最上位のプロセスIDを更新する必要があります。

BPTトリガーを「有効化」する - ハイブリッドBPTイベントデータ(OSEVT_*)を移行する

移行するデータが含まれている可能性があるOSEVTテーブルをすべて検索します。

これらのOSEVTエンティティには独自の識別子がありませんが、明確に定義された共通のストラクチャがあります。

  • _ESPACE_ID
  • _TENANT_ID
  • _ACTIVITY_ID
  • _PROCESS_DEF_ID
  • _IS_UPDATE
  • _IS_LIGHT

関連するエンティティの特定のフィールドが後ろに続きます。

  • エンティティID
  • エンティティの外部キー(複数のフィールド)

この移行プロセスでは前のプロセスと同様に、ソース環境からデータを取得し、外部キー(_ID)をターゲット環境にマッピング済みの既知の識別子を使用して置き換えます。

最後のステップ

移行後は、忘れずにターゲット環境でアプリケーションを有効にします。

これで、ユーザーがアプリケーションにログインしたり連携を呼び出したりできるようになり、タイマーやプロセスを再度実行できるようになります。

  • Was this article helpful?