Foundry Rulesへの移行

Taurusの長期サポートは継続されますが、いくつかの組織は既存のTaurusワークフローをFoundry Rulesに移行して、変更の容易さやパイプラインメンテナンスの改善、開発のさらなる更新などの追加機能を享受したいと考えるかもしれません。Taurusは引き続き長期サポートを受けています。

TaurusのユースケースをFoundry Rulesに移行することで、以下のメリットがあります：

1つのFoundry Rules設定ページから数分で完了する簡素化されたデプロイメント。
Foundry Rules設定への単一ステップ変更による修正およびメンテナンス。
パイプラインコードと対話する必要がなく、ストリーミングワークフローを含む即時実行。
カスタムパイプラインコードを必要とする高度なFoundry Rulesユースケースをサポートする組み込みコードジェネレーター。

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

移行の考慮事項

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

Taurusをサプライチェーン最適化、マネーロンダリング防止、自動車産業向けQMOSなどの大規模な製品提供の一部として使用している場合、現時点で移行を行う必要はありません。
以下のいずれかの組み合わせを含む複雑なTaurusユースケースがある場合、移行にはリファクタリング作業が必要となり、前述の利点と必要な変更の範囲とのトレードオフを検討する必要があります：
- Taurusワークショップモジュールに、さまざまなユーザーグループ向けの異なる設定の複数のルールエディタウィジェットがある。
- TaurusリポジトリがTaurusパッケージの高度な機能を使用している、または特定の方法でルールロジックを適用している。高度な機能の使用例として、リポジトリが提案を実行して潜在的な影響分析を作成する場合があります。
- ルールアクションがオプションの可視性を実装し、オブジェクトロケータ、オブジェクトセット、または添付フィールドタイプを使用している。
さらに多くの入力データセット、オブジェクトタイプ、またはルール出力をTaurusユースケースに追加している場合、Foundry Rulesが提供する新しい設定インターフェースにより、メンテナンス性が向上する可能性があります。たとえFoundry Rulesワークフローと組み合わせてJavaリポジトリを使用する場合でも、部分的なコード生成の恩恵を受けることができます。

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

次のプロセスでは、既存のオブジェクトタイプとWorkshopモジュールを使用しますが、並行するパイプラインと新しい出力データセットを作成して、運用中のパイプラインの中断を防ぎます。

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

ワークフロー内のtime seriesをチェック
既存のアプリケーションをアップグレード
必要に応じて古いアプリケーションのリンクを解除
移行を完了するために必要な手動アクション

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

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

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

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

手順が完了したら、Mark migration completedを選択します。ユースケースが新しいFoundry Rulesセットアップで稼働するようになります。

移行の確認

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

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

ビルドが成功すると、Foundry Rulesへのアップグレードプロセスが正常に完了したことを示します。

FAQs

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

解決するには、以下のようにルール効果のための出力設定を確認します：

次に、移行のステップ5を完了した後、ルールエディタフォームがユースケースに応じて引き続き動作することを確認します：

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

ビルドジョブには、各ルールとその実行に問題があった理由に関する情報を含むルールステータスデータセットという別のデータセットが含まれています。さらに、まだ書き戻しデータセットを再実行していない可能性があります。ルールの作成と実行ガイドのステップ4を参照してください。データセットはビルドページのTransforms Configurationセクションにあります：

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

このエラーは、Rulesアプリケーションのアップグレードステージを完了した後、他のユーザーがRulesアプリケーションに変更を加えた際に、移行をキャンセルしようとした場合に発生します。

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

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