フェーズ1: プロセス・アプリケーションのOCIへの移行プロセス自動化

OCI Process Automationインスタンスのプロビジョニングおよび準備

新しいOCI Process Automationインスタンスを作成します。Oracleでは、スタンドアロンのOCI Process Automation環境をプロビジョニングすることをお薦めします。

この推奨事項の詳細は、アップグレードのFAQを参照してください。

ノート

これらの残りの手順は、OCI Process Automationスタンドアロン・インスタンスの使用に基づいています。代替の移行計画が設定されていないかぎり、この推奨事項から逸脱しないでください。
  1. 新しいOCI Process Automationスタンドアロン・インスタンスを作成します。

    Oracle Cloud Infrastructure Process Automationの管理プロセス自動化インスタンスのプロビジョニングを参照してください。

    インスタンスを作成すると、次のようになります。

    • 実行パックに基づいてメータリング・モデルを選択し、アップグレード中に無料階層価格を活用します。
    • OCI Process Automationスタンドアロン・インスタンスを作成するユーザーは、Oracle Integration Generation 2インスタンスを作成したユーザーと同じアイデンティティ・ドメインからのものである必要があります。
    • OCI Process Automationスタンドアロン・インスタンスは、Oracle Integration Generation 2インスタンスと同じテナンシ、同じリージョンおよび(できれば同じコンパートメント)に作成する必要があります。

      同じコンパートメントを使用しない場合は、OCI Process Automationインスタンスを作成するユーザーに、Oracle IntegrationインスタンスとOCI Process Automationインスタンスの両方を管理する権限があることを確認してください。

      これらの権限は、IAMポリシーで管理します。

      Oracle Integrationの場合:

      • allow group domain-name/group_name to manage integration-instance in compartment compartment-name
      • allow group domain-name/group_name to manage integration-instance in tenancy

      次に例を示します:

      • allow group admin/oci-integration-admins to manage integration-instance in tenancy

      OCI Process Automationの場合:

      • allow group domain-name/group_name to manage process-automation-instance in compartment compartment-name
      • allow group domain-name/group_name to manage process-automation-instance in tenancy

      次に例を示します:

      • allow group admin/oci-integration-admins to manage process-automation-instance in tenancy
  2. 開発者にOCI Process Automationへのアクセス権を付与します。

    開発者が新しくプロビジョニングされたOCI Process Automationインスタンスにアクセスでき、後続のタスクで作業できるようにするには、インスタンスにアクセスするための適切なアプリケーション・ロールが割り当てられていることを確認します。Oracle Cloud Infrastructure Process Automationの管理アイデンティティ・ドメインのグループへのアプリケーション・ロールの割当てを参照してください。

  3. テスト用に非本番のOracle Integration Generation 2インスタンスを登録します。

    プロセス・アプリケーションが既存の統合をコールしている場合は、新しいOCI Process AutomationインスタンスにOracle Integration Generation 2を登録します。これにより、OCI Process Automationインスタンスが接続し、既存の統合を検出できます。

    このステップでは、サービス登録に非本番のOracle Integration Generation 2インスタンスを使用していることを確認してください。選択したOracle Integration Generation 2インスタンスを登録しても、本番のプロセスに悪影響を及ぼさないようにしてください。

    1. 登録する非本番のOracle Integration Generation 2インスタンスを選択します。
    2. Oracle Cloudコンソールで、選択したOracle Integration Generation 2インスタンスのOCIDを見つけてノートにとります。
    3. OCI Process Automationで、Oracle Integration Generation 2インスタンスを登録します。Oracle Cloud Infrastructure Process Automationの使用サービスの登録を参照してください。
      ノート

      この接続専用のServiceAccountユーザーを作成できます。

新規インスタンスへのプロセス・アプリケーションの移行

既存のプロセス・アプリケーションを新しいOCI Process Automationスタンドアロン・インスタンスに移行します。

  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. プロセス・アプリケーションをOCI Process Automationにインポートします。

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

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

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

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

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

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

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

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

Oracle Integration 第2世代 OCIプロセス自動化
<application-name>。ProcessOwner プロセス所有者
<application-name>。AnalyticsViewer 該当なし
<application-name>.<swim-lane> <swim-lane>
<application-name>。ProcessReviewer プロセス・レビューア

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

OCI Process Automationが既存のOracle Integration Generation 2インスタンスと同じアイデンティティ・ドメインを共有する場合は、既存のユーザーおよびグループを選択できるようにする必要があります。

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

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

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

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

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

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

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

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

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

プロセス・アプリケーションをコールするクライアントの更新

使用方法に応じて、様々なステップを実行してクライアントを更新します。

統合コール・プロセス

アップグレード後に、プロセス自動化およびデシジョン・アプリケーション用の開発者APIが変更されました。プロセス自動化コール・ウィザードを使用して統合を再構成する必要があります。統合の再構成を参照してください。

プロセス別インテグレーション

OCI Process Automationは、サービス登録を介したRESTベースの通信のみをサポートします。つまり、SOAPベースの統合への接続はできなくなります。

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

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

    または

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

また、サービス登録が期待どおりに機能するには、RESTトリガーでOAuth 2.0またはBasic認証セキュリティ・ポリシーが使用されていることを確認します。

Visual Builderアプリケーション

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

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

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

  1. OCI Process Automationに接続します。

    OCI Process Automationへのバックエンド接続を作成します。このバックエンドは、新しいOCI Process Automationインスタンスへの接続の確立に使用されます。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. 「コールRESTアクション」を現在の「開始プロセス・アクション」の上にドラッグします。
      4. POST/Instancesエンドポイントを選択して、コールRESTアクションを構成します。
      5. 前述の変数をRESTアクションのリクエスト本文にマップします。
      6. レガシー開始プロセス処理を削除します。
    6. コールをテストし、OCI Process Automationでプロセスが正常にコールされていることを確認します。

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

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

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

    従来のプロセス・インスタンスの取得プロセス・アクションを、前述のエンドポイントで構成されているコールRESTアクションに置き換え、instanceIDフィールドを再マップします。

    ノート

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

    その他のプロセス処理

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

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

      次の表に、これらの各アクションを、プロセス自動化用の対応する開発者APIにマップします。

      ビジュアル・ビルダー・アクション プロセス自動化のための開発者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 タスクの再割当て
      タスク・コレクションの取得 GET /process/api/v1/tasks
      タスクの取得 GET /process/api/v1/tasks/{id}
      デプロイ済プロセス収集の取得 GET /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コンポーネントを使用している場合は、それらを同等のOCI Process Automationコンポーネントに置き換える必要があります。

    コンポーネント名 Oracle Integration Generation 2 CCA OCI Process Automationと同等
    タスク・リスト oj-pcs-task-list 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可視化 oj-opac-analytics (ビジュアライゼーションを保存できません)

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

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

検証

システム統合テストを実行して作業を検証します。

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

  • OCI Process Automation - Oracle Integration Generation 2へのプロセス- 統合
  • Oracle Integration Generation 2 - OCI Process Automationへの統合- プロセス
  • Visual Builder - アプリケーションからOCI Process Automation - プロセス