機械翻訳について

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

次のタスクを実行して、プロセス・アプリケーションをOCIプロセス自動化に移行します:

1. OCIプロセス自動化インスタンスのプロビジョニングおよび準備
2. 新規インスタンスへのプロセス・アプリケーションの移行
3. 新規アプリケーション・ロールへのユーザーおよびグループのマップ
4. インポート済プロセス・アプリケーションの検証およびアクティブ化
5. プロセス・アプリケーションをコールするクライアントの更新

「OCIプロセス自動化」インスタンスのプロビジョニングおよび準備

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

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

重要:

これらの残りの手順は、「OCIプロセス自動化」スタンドアロン・インスタンスの使用に基づいています。 代替の移行計画が設定されていないかぎり、この推奨事項から逸脱しないでください。

1. 新しい「OCIプロセス自動化」スタンドアロン・インスタンスを作成します。

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

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

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

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

     これらの権限は、「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プロセス自動化の場合:

     • 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プロセス自動化」へのアクセス権を付与します。

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

3. テスト用にnon-production Oracle Integration Generation 2インスタンスを登録します。

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

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

   1. 登録するnon-production Oracle Integration Generation 2インスタンスを選択します。
   2. Oracle Cloudコンソールで、選択したOracle Integration Generation 2インスタンスのOCIDを見つけてノートにとります。
   3. 「OCIプロセス自動化」で、Oracle Integration Generation 2インスタンスを登録します。 「Oracle Cloud Infrastructure Process Automationの使用」の「サービスの登録」を参照してください。

      ノート:

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

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

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

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プロセス自動化」にインポートします。

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

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

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

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

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

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

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

次の表に、Oracle Integration Generation 2ロールが「OCIプロセス自動化」ロールにどのようにマップされるかを示します。

Oracle Integration Generation 2	OCI Process Automation
<application-name>.ProcessOwner	プロセス所有者
<application-name>.AnalyticsViewer	該当なし
<application-name>.<swim-lane>	<swim-lane>
<application-name>.ProcessReviewer	プロセス・レビューア

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

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

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

• デザイナでのロールの操作
• ワークスペースでのロールの管理

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

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

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

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

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

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

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

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

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

使用方法によっては、クライアントを更新するために様々なステップを実行します。

実装に適用するステップを実行します:

• 統合コール・プロセス
• プロセス別インテグレーション
• Visual Builderアプリケーション
• Oracle統合以外のクライアント
• 検証

統合コール・プロセス

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

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

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

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

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

  または

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

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

Visual Builderアプリケーション

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

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

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

1. 「OCIプロセス自動化」に接続します。

   「OCIプロセス自動化」へのバックエンド接続を作成します。 このバックエンドは、新しい「OCIプロセス自動化」インスタンスへの接続の確立に使用されます。 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プロセス自動化カタログからのサービス接続の作成」を参照してください。 前に参照していたプロセスと同じプロセスを選択してください。

      ノート:

      プロセスはすでにアクティブ化されている必要があります。
   3. 前述のプロセスのエンドポイントに基づいてタイプを作成します。 「Oracle Visual Builderを使用したアプリケーションの開発」の「エンドポイントからのタイプの作成」を参照してください。
   4. 前述のタイプに基づいて変数を作成します。 「Oracle Visual Builderを使用したアプリケーションの開発」の「変数の作成」を参照してください。
   5. アクション・チェーンにナビゲートし、次のアクションを実行します:
      1. 変数の割当てアクションを現在の開始プロセス・アクションの上にドラッグします。
      2. プロセスを起動するために必要なデータ・フィールドと入力パラメータをマッピングします。
      3. 「コールRESTアクション」を現在の「開始プロセス・アクション」の上にドラッグします。
      4. POST/Instancesエンドポイントを選択して、コールRESTアクションを構成します。
      5. 前述の変数をRESTアクションのリクエスト本文にマップします。
      6. レガシー開始プロセス処理を削除します。
   6. コールをテストし、プロセスが「OCIプロセス自動化」で正常にコールされていることを確認します。

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

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

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

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

   ノート:

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

   その他のプロセス処理

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

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

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

      Visual Builderアクション	プロセス自動化のための開発者API	説明
      タスクの実行	POST /process/api/v1/tasks/{id}/complete	承認、却下などの承認アクション。
      タスクの実行	PUT /process/api/v1/tasks/{id}	タスク優先度、ペイロード、タイトルなどを更新します。
      タスクの実行	PUT /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プロセスCCAコンポーネントを使用している場合は、それらを同等の「OCIプロセス自動化」コンポーネントに置き換える必要があります。

   Component Name	Oracle Integration Generation 2 CCA	「OCIプロセス自動化」相当
   Task List	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-visualization	oj-opac-analytics (ビジュアライゼーションを保存できません)

Oracle統合以外のクライアント

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

検証

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

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

• 「OCIプロセス自動化」 - Oracle Integration Generation 2へのプロセス - 統合
• Oracle Integration Generation 2 - 「OCIプロセス自動化」への統合 - プロセス
• Visual Builder - 「OCIプロセス自動化」へのアプリケーション - プロセス