Oracle Integration 3へのアップグレード: フェーズ2

有効にすると、プロセス・インスタンスにOracle Integrationインスタンスが自動的にプロビジョニングされます。このような場合、2つのサービスは相互に関連付けされ、Oracle Cloudコンソールの相互の関連サービス・ページにリストされます。

プロセス・インスタンスを管理するためのIAMポリシーの設定

Oracle Integrationでプロセスを有効にするには、指定したIAMグループに属するOracle Integration管理者がプロセス・インスタンスを管理できるようにするOracle Cloud Infrastructure Identity and Access Management (IAM)ポリシーを作成する必要があります。

プロセスに対して次のIAMポリシーを設定します:

Oracle Cloud Infrastructure Process Automationの管理のプロセス自動化のIAMポリシーについておよびアイデンティティ・ドメインでのIAMポリシーの作成を参照してください。

Oracle IntegrationのIAMポリシーの詳細は、Oracle IntegrationのIAMポリシーについておよびOracle Integrationのアイデンティティ・ドメインでのIAMポリシーの作成を参照してください。

プロセスの有効化

Oracle Integrationインスタンスでプロセス・インスタンスを有効にするには:

1. ナビゲーション・メニューを開き、「開発者サービス」をクリックします。「アプリケーション統合」で、「統合」をクリックします。
2. 「コンパートメント」ドロップダウン・リストから、プロビジョニングするコンパートメントを選択し、Oracle Integrationインスタンスでプロセス・インスタンスを有効にします。ページがリフレッシュされ、選択したコンパートメント内の既存のサービス・インスタンスが表示されます。
3. 既存のインスタンスを選択するか、Oracle Integrationインスタンスを作成して選択します。統合インスタンスの詳細ページが開きます。
4. 統合インスタンス情報タブで、プロセスの「有効化」リンクをクリックします。
5. プロンプトが表示されたら、「有効化」をクリックして、プロセスを有効にすることを確認します。次の点に注意してください。
   • Oracle Integrationアイコンがオレンジ色に変わり、そのステータスが「更新中」に変わります。
   • 有効化が完了するまでに数分かかる場合があります。
   • 完了すると、つまり、プロセス・インスタンスが有効化され、Oracle Integrationインスタンスでプロビジョニングされると、Oracle Integrationアイコンが緑色に戻り、「アクティブ」ステータスになり、「プロセス」は「有効」と表示されます。
6. 作成したばかりのプロセス・インスタンスに移動するには、「リソース」の下の「関連付けられたサービス」をクリックします。
7. プロセス・インスタンスを選択して、その詳細を表示します。

アクセスを管理するためのIDCSアプリケーション・ロールの割当

プロセス・インスタンスを有効にしたら、事前定義済のIDCSアプリケーション・ロールをユーザーに割り当てて、プロセス・インスタンスの機能を操作できるようにします。

プロセスには、ServiceDeveloperとServiceAdministratorの2つの事前定義済IDCSアプリケーション・ロールがあります。これらのロールは、Oracle Identity Cloud Service (IDCS)管理コンソールからプロセス・サービス・インスタンス・アプリケーションのユーザーまたはグループに割り当てる必要があります。

ベスト・プラクティスとして、個々のユーザーではなく、これらのロールをグループに割り当てることをお薦めします。たとえば、Oracle Identity Cloud Service管理コンソールから、Oracle Integrationおよびプロセス・サービス・インスタンス・アプリケーションの両方で、ServiceDeveloper IDCSアプリケーション・ロールをグループに割り当てます。このようにして、グループのメンバーであるユーザーはOracle Integrationおよびプロセスの設計時にアクセスできるため、ユーザー・アクセスの管理が容易になります。

1. 移行するアプリケーションを決定します。

   この機会に、不要なアプリケーションをクリーンアップできます。本番環境にあるアプリケーションのみを移行するかどうかを検討してください。

   個々のアプリケーションを移行する場合は、移行するアプリケーションおよびそれらの依存関係に注意してください。

2. 次のいずれかの方法を使用してアプリケーションを移行します。
   • すべてのアプリケーションを一括移行
     1. Oracle Cloudコンソールで、オブジェクト・ストレージ・バケットを作成します。オブジェクト・ストレージ・バケットの作成を参照してください。

        次のステップに必要なストレージ・バケットURLは、次の形式です。

        https://swiftobjectstorage.region.oraclecloud.com/v1/namespace/bucket

        ここで:

        • regionは、Oracle Cloud Infrastructure (OCI)データ・センターの識別子です。
        • namespaceは、バケットを作成したテナンシです。
        • bucketはバケット名です。
     2. Oracle Integration Generation 2インスタンスに対してPOSTリクエストを行い、アプリケーションをエクスポートします:

        curl -X POST https://Generation2_hostname/ic/api/process/v1/exportArtifactsInternal

        次のペイロードを使用します。

        {
            "jobId": "enter_a_descriptive_ID",
            "storageInfo": {
                "storageUrl": "Swift_storage_bucket_URL",
                "storageUser": "OCI_Console_user",
                "storagePassword": "OCI_Console_user_password"
            }
        }

        バケットにprocess_status.jsonファイルを表示すると、エクスポート・ジョブが完了したことがわかります。このファイルには、ジョブのステータス、完了率、および失敗した場合はエラー・メッセージが含まれます。バケットに次のコンテンツも表示されます。

        • Process/project folder— すべてのプロセス・アプリケーションが含まれます。
        • Process/dmn folder— すべての意思決定モデルが含まれます。
     3. アプリケーションがバケットにエクスポートされたら、アプリケーションを移行するためにOracle Integration 3インスタンスにPOSTリクエストを行います:

        curl -X POST https://Integration3_hostname/process/api/v1/oic-migration/jobs/

        テナントID:

        x-tenant-id: tenant_OCID

        バケット情報:

        {
            "bucketInfo": {
                "region": "region",
                "namespace": "namespace",
                "bucket": "bucket"
            }
        }

        Oracle Cloud Infrastructure Process Automation開発者APIのセキュリティ、認証および認可を参照してください。

     4. 移行ジョブが完了するまで待機します。移行ジョブのステータスを確認するには:

        curl http://localhost:8080/process/internal-api/v1/oic-migration/jobs/job_ID

   • 個々のアプリケーションの移行
     1. Oracle Integration Generation 2プロセス・アプリケーションをエクスポートします。

        移行するアプリケーションを含むOracle Integration Generation 2インスタンスで、移行する各アプリケーションをエクスポートします。Oracle Integration Generation 2でのプロセスの使用のアプリケーションのエクスポートを参照してください。

     2. プロセス・アプリケーションをOracle Integration 3プロセスにインポートします。

        Oracle Integration 3プロセスで、Oracle Integration Generation 2プロセス・アプリケーションをインポートします。Oracle Cloud Infrastructure Process Automationの使用のアプリケーションのインポートを参照してください。

        Oracle Integration 3プロセスは、レガシー・プロセス・アプリケーションを最新の製品バージョンに変換します。

3. 移行レポートを確認します。

   インポートおよび変換が完了すると、正常にインポートされた内容、追加の作業が必要な内容、および移行できなかった項目を示す移行レポートが表示されます。これにより、処理する必要がある移行の問題がわかります。

   メイン・メニューの元の移行レポートを参照できます。Oracle Cloud Infrastructure Process Automationの使用のアプリケーションのインポートを参照してください。

インポート済プロセス・アプリケーションの検証およびアクティブ化

プロセス・アプリケーションを検証およびアクティブ化するには、次のステップを実行します。

1. 各アプリケーションを検証し、エラーや警告を修正します。

   をクリックし、メニューから「検証」を選択して、デザイナから各アプリケーションを検証します。

   検証の問題を解決するには、アップグレードがプロセス機能に与える影響を参照してください。

2. アプリケーションをアクティブ化します。

   すべての検証エラーを解決したら、アプリケーションをアクティブ化できます。Oracle Cloud Infrastructure Process Automationの使用のアプリケーションのアクティブ化を参照してください。

新規アプリケーション・ロールへのユーザーおよびグループのマップ

Oracle Integration 3でアプリケーション・ロールが大幅に変更されました。ProcessOwner、AnalyticsViewerおよびProcessReviewerロールがアプリケーションごとに明示的に定義され、メンバーおよび権限を制御できるようになりました。

次の表に、Oracle Integration Generation 2ロールがOracle Integration 3プロセス・ロールにどのようにマップされるかを示します。

新しいロールは移行後に使用可能ですが、メンバー(ユーザーおよびグループ)を追加する必要があります。各ロールに割り当てるメンバーを確認するには、Oracle Integration Generation 2環境を参照する必要がある場合があります。

Oracle Integration 3プロセスが既存のOracle Integration Generation 2インスタンスと同じアイデンティティ・ドメインを共有している場合、既存のユーザーおよびグループを選択できます。

デザイナでアクティブ化する前に、またはワークスペースでアクティブ化した後に、メンバーを追加できます。

• Designerでのロールの処理
• ワークスペースでのロールの管理

Oracle Integration 3プロセスの詳細は、Oracle Cloud Infrastructure Process Automationの使用のプロセス・アプリケーションのロールの構成を参照してください。

• 統合コール・プロセス
• プロセスによって呼び出される統合
• Visual Builderのアプリケーション
• Oracle-Integration以外のクライアント
• 検証

統合コール・プロセス

Oracle Integration 3でプロセスをコールする統合は、新しいプロセス・アクションを使用するように更新する必要があります。これを行うには、統合の新しいメジャー・バージョンを作成し、新しいプロセス・アクションを追加して、Oracle Integration 3から開始するプロセスを参照します。レガシー・プロセス処理を削除し、統合をアクティブ化します。

プロセスによって呼び出される統合

Oracle Integration 3プロセスは、サービス登録を介したRESTベースの通信のみをサポートします。つまり、SOAPベースの統合への接続はできなくなります。

SOAPトリガーを使用する統合があり、これらがOracle Integration Generation 2のプロセスによってコールされる場合は、追加のステップを実行して、Oracle Integration 3プロセスへのRESTベースのインタフェースを提示する必要があります。これは、次の1つを実行する必要があることを意味します。

• RESTベースのラッパー統合を作成します。

  または

• 既存のトリガーをSOAPからRESTに変更します。

移行されたプロセス・アプリケーションのすべての統合接続を確認します。接続メタデータをリフレッシュして、最新の定義がプロセス・アプリケーションに組み込まれていることを確認します。無効なデータ・マッピングを更新し、新しいバージョンでプロセスを再デプロイします。

Visual Builderアプリケーション

プロセスおよびデシジョン・アプリケーション用の開発者APIは、アップグレード後に変更されます。そのため、対話するVisual Builderアプリケーションを更新し、非推奨の統合パターンを置き換える必要があります。Visual Builder Studioを使用したレスポンシブ・アプリケーションの構築のビジネス・プロセスの使用を参照してください。

そのためには、現在のプロセスの使用状況を評価する必要がある場合があります。Visual Builderの各アプリケーションを調べ、アクション・チェーン、直接コール、または埋込み可能なプロセス・コンポーネント(CCAとも呼ばれる)を使用して、プロセス用の開発者APIをコールしているかどうかを判断します。

アプリケーションがプロセス・エンドポイントをコールしている場合は、次のステップを実行します。

1. Oracle Integration 3プロセスに接続します。

   Oracle Integration 3プロセスへのバックエンド接続を作成します。このバックエンドは、新しいOracle Integration 3プロセス・インスタンスへの接続を確立するために使用されます。Visual Builder Studioを使用したレスポンシブ・アプリケーションの構築のプロセス自動化のための開発者APIへの接続を参照してください。

2. アプリケーションの新しいバージョンを作成します。

   Oracleでは、必要な変更を実装するために、Visual Builderアプリケーションの新しいバージョンを作成することをお薦めします。『Oracle Visual Builderによるアプリケーションの開発』のアプリケーションのバージョンの作成方法に関する項を参照してください。

3. アクション・チェーン

   アプリケーションでアクション・チェーンを使用してプロセスを開始する場合、またはタスクに対してアクションを実行する場合は、これらをそれぞれRESTベースのサービス接続に置き換える必要があります。プロセス・アクション・チェーン・タスクごとにこれらのステップを繰り返します。

   プロセスのトリガー

   「プロセスの開始」アクション・チェーンを「カタログ・ベースのサービス接続」に置き換えます。

   1. Oracle Integration Generation 2にナビゲートし、コールしているプロセスをノートにとります。これは、アクション チェーン プロセス ステップまたは左側のアプリケーション メニューの[プロセス]タブから決定できます。
   2. Visual Builderアプリケーションの新しいバージョンで、プロセスへのカタログベースのサービス接続を作成します。Visual Builder Studioを使用したレスポンシブ・アプリケーションの構築のOCI Process Automationカタログからのサービス接続の作成を参照してください。前に参照していたプロセスと同じプロセスを選択してください。
      ノート
      
      プロセスはすでにアクティブ化されている必要があります。
   3. 前述のプロセスのエンドポイントに基づいてタイプを作成します。『Oracle Visual Builderによるアプリケーションの開発』のエンドポイントからのタイプの作成を参照してください。
   4. 前述のタイプに基づいて変数を作成します。『Oracle Visual Builderによるアプリケーションの開発』の変数の作成に関する項を参照してください。
   5. アクション・チェーンにナビゲートし、次のアクションを実行します。
      1. 現在の開始プロセス処理の上に「変数の割当」処理をドラッグします。
      2. プロセスを起動するために必要なデータ・フィールドおよび入力パラメータをマップします。例は、Oracle Process AutomationとVisual Builderの統合を参照してください。
      3. 「Call REST Action」を現在の「Start Process Action」の上にドラッグします。
      4. POST/Instancesエンドポイントを選択して、コールRESTアクションを構成します。
      5. 前述の変数をRESTアクションのリクエスト本文にマップします。
      6. レガシー開始プロセスActonを削除します。
   6. コールをテストし、Oracle Integration 3プロセスでプロセスが正常にコールされていることを確認します。

   GETプロセス・インスタンス

   「Get Process Instance」アクション・チェーンをカタログベースのサービス接続に置き換えます。

   前述のステップに従ってプロセスにカタログベースのサービス接続を作成した場合、Get Process Instanceエンドポイントがサービス接続で使用可能になったことがわかります。

   レガシーのGet Process Instanceプロセス・アクションを、前述のエンドポイントで構成されたコールRESTアクションに置き換え、instanceIDフィールドを再マップします。

   ノート
   
   ここでのレスポンス・ペイロード値が変更されました。

   その他のプロセス処理

   「タスクの実行」や「タスクの取得」など、他のすべてのプロセス処理に対して次のステップを実行します。

   1. Oracle Integration Generation 2にナビゲートし、使用しているプロセス処理を書き留めます。
   2. これらのアクションをエンドポイントベースのサービス接続に置き換えます。

      次の表に、これらの各アクションを対応するDeveloper API for Processにマップします。

      Visual Builderアクション	開発者向けAPI	説明
      タスクを実行	POST /process/api/v1/tasks/{id}/complete	承認、否認などの承認処理。
      タスクを実行	PUT /process/api/v1/tasks/{id}	タスク優先度、ペイロード、タイトルなどを更新します。
      タスクを実行	/process/api/v1/tasks/{id}/payloadを入れます	タスク・ペイロードを更新します。
      タスクを実行	POST /process/api/v1/tasks/{id}/claim	タスクを要求します。
      タスクを実行	POST /process/api/v1/tasks/{id}/release	タスクをリリースします。
      タスクを実行	POST /process/api/v1/tasks/{id}/request-for-info	タスクに関する情報を要求します。
      タスクを実行	POST /process/api/v1/tasks/{id}/submit-info	タスクに対して要求された情報を発行します。
      タスクを実行	POST /process/api/v1/tasks/{id}/reassign	タスクを再割当します。
      タスク収集の取得	/process/api/v1/tasksの取得
      タスクの取得	GET /process/api/v1/tasks/{id}
      デプロイ済プロセス収集の取得	/process/api/v1/instancesの取得
      プロセス・インスタンス収集の取得	POST /process/api/v1/instances

4. 直接コール

   プロセスおよびデシジョン・アプリケーション用の開発者APIは、アップグレード後に変更されます。そのため、直接サービス接続を更新する必要があります。Oracle Cloud Infrastructure Process Automationの開発者APIを参照してください。

5. CCAコンポーネント

   Oracle Integration Generation 2 Process CCAコンポーネントを使用している場合は、同等のOracle Integration 3プロセス・コンポーネントに置き換える必要があります。

   構成部品名	Oracle Integration Generation 2のCCA	Oracle Integration 3の同等のプロセス
   タスク・リスト	oj-pcs-taskリスト	oj-opac-task-list
   タスクの詳細	oj-pcs-task-detail	oj-opac-task-detail
   アプリ一覧	oj-pcs-app-list	oj-opac-applist
   開始フォーム	oj-pcs-start-form	oj-opac-start-form
   DPリスト	oj-pcs-dplist	oj-opac-instance-list (構造化プロセスと動的プロセスの両方を表示)
   視覚化	oj-pcs-visualization	oj-opac-analytics (ビジュアライゼーションを保存できない)

Oracle-Integration以外のクライアント

Oracle Integrationの外部からプロセス・アプリケーション(たとえば、独自のカスタム・アプリケーション)をコールする場合は、新しく構成されたOracle Integration 3プロセス・インスタンスのコールに使用されるRESTエンドポイントおよび認可ポリシーを更新する必要があります。新しいAPIエンドポイントおよびサポートされている認可ポリシーの詳細は、Oracle Cloud Infrastructure Process Automation開発者APIを参照してください。

検証

システム統合テストを実施して作業を検証すること。

新しいプロセス環境への接続をテストします。このテストでは、使用状況に基づいて次の相互作用パターンの検証に重点を置く必要があります。

• Oracle Integration 3プロセス- Oracle Integration 3 - 統合
• Oracle Integration 3 - Oracle Integration 3への統合- プロセス
• Visual Builder - Oracle Integration 3プロセスに対するアプリケーション- プロセス

次のステップを実行します:

1. クライアントの変更をアクティブ化してデプロイし、前述のようにすべての新しいシステムドリブン・リクエストがOracle Integration 3プロセスに送信されるようにします。
2. 新しいOracle Integration 3プロセス・ワークスペースURLをユーザーと通信し、ユーザーが次のことを実行できるようにします。
   • Oracle Integration 3プロセス・ワークスペースをブックマークします。
   • Create new processes only in Oracle Integration 3 Process.
   • Oracle Integration 3プロセスで新しいタスクを完了します。
3. 新しいプロセスを作成できず、既存のプロセスを完了できるように、Oracle Integration Generation 2アプリケーションをリタイアします。Oracle Integration 2でのプロセスの使用のアクティブ・アプリケーションの管理を参照してください。

この期間中:

• 新しいプロセス・インスタンスは、Oracle Integration 3プロセスによって提供されます。
• 既存のプロセス・インスタンスは、完了するまでOracle Integration Generation 2プロセスで実行されます。

この期間中、プロセス・ユーザーは次を実行する必要があります。

• 主にOracle Integration 3プロセス・ワークスペースから作業します。
• Oracle Integration Generation 2の「自分のタスク」リストをチェックする場合があります。
• 電子メール内のリンクによってタスクを実行するのに適した場所に移動するため、可能なかぎり電子メールベースの承認を利用します。

共存期間は、Oracle Integration Generation 2で作成されたすべてのトランザクションが完了するまで続きます。なるべく、この期間の短縮を目指すべきです。次に一部のガイドラインを示します。

• Oracle Integration Generation 2で除・売却機能を使用して新しいトランザクションを作成しないようにします。これは、receiveアクティビティを含まないすべての構造化プロセスに適用されます。除・売却機能により、新しいインスタンスを作成できなくなり、既存のトランザクションを完了することもできます。Oracle Integration 2でのプロセスの使用のアクティブ・アプリケーションの管理を参照してください。
• Oracle Integration Generation 2インスタンスの完了を可能なかぎり積極的に促進するために、完了までのアクションを実行するユーザーをフォローアップします。「プロセス」、「管理」、「移行レポート」の順にナビゲートすると使用可能な新しいレポートを使用して、プロセス当たりのオープン・トランザクションの数および関連タスクの割当先を確認できます。
• 非常に長時間実行されているプロセスの場合、数か月以内に完了できないインスタンスについては、次のオプションを確認してください。
  • Oracle Integration 3プロセスでインスタンスを再作成し、フローの変更機能を使用してペイロードを更新し、プロセス・インスタンスを現在のアクション(現在Oracle Integration Generation 2 Processにある)に移動します。これが完了すると、既存のOracle Integration Generation 2インスタンスを終了できます。Oracle Cloud Infrastructure Process Automationの使用のプロセスのフローの変更を参照してください。
  • 既存のOracle Integration Generation 2プロセス・インスタンスの最新の状態を使用して開始できるように、移行されたアプリケーションを変更します。

Oracle Integration Generation 2の残りのプロセス・トランザクションを追跡するには、「自分のタスク」をクリックし、Oracle Integration Generation 2インスタンスで「プロセス」を選択します。サービス管理者ロールを持つユーザーでサインインする必要があります。

Oracle Integration 3でプロセスを有効にすることで、2026年12月31日より前にプロセス・アプリケーションをOracle Integration 3に移動できます。「Oracle Integration 3でのプロセスの有効化」を参照してください。プロセス・アプリケーション設計時アーティファクトのエクスポートまたはインポートの詳細は、「すべてのアプリケーションのRESTエンドポイントの移行」を参照してください。

Oracle Integration Generation 2 Processからランタイム・データを保存します。このステップは、完了済トランザクションの履歴が失われないようにするために重要です。これはアップグレードの前に行う必要があります。Oracle Integrationでのプロセス自動化データのアーカイブおよびパージを参照してください。

これらのステップの一環として、Oracle Storage Serviceを構成し、アーカイブおよびパージのためにインスタンスをスケジュールします。次の点に注意してください。

• アーカイブされた情報は、構成されたオブジェクト・ストレージ・バケットで使用可能になります。
• 添付はアーカイブ・ファイルには含まれません。これらを手動でエクスポートする必要があります。Oracle Integration 2のREST APIのストリームとしてのプロセス添付の取得を参照してください。