Foundry Rules への移行

Taurus の長期サポートは続きますが、一部の組織では、既存の Taurus ワークフローを Foundry Rules に移行し、変更やパイプラインメンテナンスの容易さの向上、開発のさらなるアップデートなど、追加の機能を活用することを希望するかもしれません。Taurus は引き続き長期サポートを受けていることに注意してください。

Taurus のユースケースを Foundry Rules に移行することで、以下の利点が得られるかもしれません：

単一の Foundry Rules 設定ページから数分で完了する簡易化されたデプロイメント。
Foundry Rules の設定への単一ステップの変更を通じた修正とメンテナンス。
パイプラインコードとのやり取りを必要とせずにボックスから出るとすぐに実行可能。
カスタムパイプラインコードを必要とする高度な Foundry Rules ユースケースをサポートする組み込みのコードジェネレータ。

最適な Foundry Rules ワークフローは、ユーザーが作成したい特定のルールを持つ特定のユースケースを対象とします。複数のユーザーグループと複数のルール作成アプリケーションがある場合は、移行ウィザードを複数回使用して複数のルールワークフローを作成することを検討してみてください。

移行の考慮点

Foundry Rules への移行を考える前に、以下の点を考慮してください：

Taurus を供給チェーン最適化、反マネーロンダリング、自動車業界の QMOS などの大規模な製品提供として使用している場合、現時点では移行を実施する必要はありません。
次の組み合わせを含む複雑な Taurus ユースケースを持っている場合、移行には一部のリファクタリング作業が必要となり、以前に説明した利点と必要な変更の範囲との間のトレードオフを考慮する必要があります：
- Taurus のワークショップモジュールには、さまざまなユーザーグループに対して異なる設定を持つ複数のルールエディタウィジェットがあります。
- Taurus のリポジトリは Taurus パッケージの高度な機能を使用するか、特定の方法でルールロジックを適用します。高度な機能の使用例として、リポジトリが提案を実行して潜在的な影響分析を作成する場合があります。
- ユーザーのルールアクションは、オプションの表示、オブジェクトロケーター、オブジェクトセット、アタッチメントフィールドタイプの使用を実装します。
Taurus のユースケースに更に入力データセット、オブジェクトタイプ、ルール出力を追加している場合、Foundry Rules によって提供される新しい設定インターフェースが保守性を向上させるかもしれません。Java リポジトリを Foundry Rules ワークフローと組み合わせて使用することを選択したとしても、部分的なコード生成の利点を享受できます。

Taurus ワークフローを Foundry Rules ワークフローに移行

以下のプロセスでは、既存のオブジェクトタイプとワークショップモジュールを使用しますが、運用中のパイプラインに影響を与えないように、並行パイプラインと新しい出力データセットを作成します。

V2 へのアップグレード時には、次のプロセスが実行されます：

ワークフロー内の時系列を確認します
既存のアプリケーションをアップグレードします
必要に応じて古いアプリケーションのリンクを解除します
移行を完了するために必要な手動操作

開始するには、以下の手順に従ってください：

Foundry ワークスペースのナビゲーションサイドバーから Foundry Rules に移動し、次に Old Workflows タブに移動します。
オントロジーを選択し、リストから V1 アーキタイプを見つけるか、検索フィールドを使用します。
Migrate from older Version を選択します。
主要なルールエディタのワークショップリソースを選択し、新しい Foundry Rules ワークフローを保存する先のフォルダーを確認します。必要に応じてワークフローの名前を変更します。次に、Start を選択します。
Foundry Rules の移行ウィザードは、既存のセットアップに時系列が含まれているかどうかを確認します。含まれている場合は、リンクタイプと時系列の同期を設定する必要があります。追加の設定が完了したら、Save Rules workflow を選択します。
プロジェクトにインポートする必要があるリソースがいくつかあります。リソースのリストを確認し、確認のために展開し、必要な画面上の操作を完了したら Save を選択します。
Upgrade rules application を選択します。
必要に応じて、Unlink old application を選択します。
最後に、画面上のガイドを確認し、新しくアップグレードされたパイプラインのユースケースに基づいて適切な指示に従います：
- 私の Foundry Rules の出力は直接オントロジーオブジェクトタイプにフィードします。
  - 出力がオントロジーオブジェクトタイプにフィードする場合（例えば、追加の変換なしで）、新しいバージョンの Foundry Rules からアラートが来るように、このオブジェクトタイプのオブジェクトの元データセットを置き換える必要があります。

このオプションは、オブジェクトタイプが V1 の場合にオブジェクト編集が失われる結果となります。それ以外の場合、編集を保持する必要がある場合は、元データセットを保持し、その内容が新しいルール出力の直接のコピーであることを確認します。

私は Foundry Rules の出力に追加の変換を適用します。
- 新しい出力データセットを使用して、変換で前のルール出力を置き換える必要があります。高度なユースケースの場合、ルール出力を計算するためのカスタムリポジトリを登録することができます。
私は他のルールエディタワークショップアプリケーションを持っています。
- ルールエディタがすべて同じ入力と出力を持つ場合、すべてのエディタをこの Rules ワークフローを参照するようにすることができます。Archetype のデプロイメニューを使用して、左側の Applications タブでより多くのルールエディタワークショップアプリケーションをデプロイすることができます。ルールエディタが異なるユースケースに対応し、異なる設定を持つ場合、新しい Rules Archetype をデプロイして、それぞれを専用のワークフローに移行する必要があります。

手順がすべて完了したら、Mark migration completed を選択します。ユースケースは新しい Foundry Rules の設定で稼働しています。

移行の確認

Foundry Rules への移行が成功したかどうかを確認するには、ルール出力データセットが保存されたプロジェクトへのリンクにアクセスします。

ルール出力データセットを開き、Build を選択するか、スケジュールタブに移動して Add build schedule を選択します。

ビルドが成功した場合、Foundry Rules へのアップグレードプロセスが成功したことを示します。

よくある質問

私の出力には V2 で異なる設定を含んでいると警告されました。これを解決するにはどうすればよいですか？アクションタイプのフォームは、さまざまなタイプの入力を受け入れるように設定することができます。これは単純な数値や日付だけでなく、添付ファイル、オブジェクトのプロパティ、他のフォームパラメーターから導出された値なども含むことができます。移行ウィザードは、可能な限り元の設定に近い設定を再作成しようとしますが、このメッセージの警告は設定に変更があった可能性を示しています。

解決するには、ルール効果の出力設定を確認します：

その後、移行のステップ五を完了した後のルールエディタフォームを確認し、ユースケースに従って動作し続けることを確認します：

なぜ私のデータセットのビルドは成功するのに、データが含まれていないのですか？

ビルドジョブには、各ルールについてそれが正しく実行されなかった理由を含む情報を含む別のデータセット、ルールステータスデータセットが含まれています。また、まだ書き戻しデータセットを再実行していない場合があります。詳細は、ルールの作成と実行ガイドのステップ4を参照してください。データセットはまた、Build ページの Transforms Configuration セクションで見つけることもできます：

なぜ他の人が Rules アプリケーションに同時に変更を加えると、移行をキャンセルできないのですか？

このエラーは、Rules アプリケーションのアップグレード段階を完了し、別のユーザーが Rules アプリケーションに変更を加えたときに、移行を Cancel しようとしたときに発生します。

解決するには、Rules Workshop アプリケーションを開き、手動で加えられた変更を元に戻すために古い移行バージョンを公開します。その後、アップグレードプロセスを正常にキャンセルすることができます。

なぜ移行は、ルールエディタと提案レビューウィジェットがそれぞれ正確に1つある場合にしか進行しないのですか？
- Rules アプリケーションは、任意の数のルールエディタウィジェットと任意の数の提案ウィジェットを設計できますが、Taurus と Foundry Rules の間で異なる設定が可能です。Taurus では、ウィジェットに各々異なる入力を利用可能ななど、一意の属性を設定することが可能です。移行は複数のウィジェットの設定を結合せず、むしろ1つのルールエディタウィジェットを1つの Rules ワークフローに変換します。しかし、新しい Foundry Rules の設定では、異なる設定はそれぞれが自身の Rules ワークフローであるべきです。
- 移行のこの問題を解決するために、以下のシナリオと適切な解決策を考慮すべきです。その後、再度移行ウィザードを完了します。ワークショップの変更はバージョン管理されているため、必要に応じて変更を元に戻すことができます：
  - あなたは偶然に複数のルールエディタウィジェットを持っており、1つだけが関連しています。あなたはワークショップモジュールから関連性のないウィジェットを削除し、再度移行を試みるべきです。
  - 同じ設定を持つ複数のウィジェットを持っています。1つを除いてすべてのウィジェットを削除すべきです。移行後、アプリケーションのデザインを再現するために、更新されたウィジェットをコピーして貼り付けることができます。
  - 異なる設定を持つ複数のウィジェットを持っています。この場合、ワークショップモジュールを1つのルールエディタウィジェットを持つ複数のモジュールに分割し、それぞれに Rules アーキタイプを作成すべきです。ウィザードで Migrate from older version を選択し、各ワークショップモジュールから設定を作成して時間を節約します。