機械翻訳について

アップグレード後のタスクの完了

Oracleは、最初にOracle Integration Generation 2開発インスタンスをアップグレードします。 アップグレード日から3日以内にすべてのアップグレード後タスクを完了して、問題をレポートできるようにします。 Oracleは、開発インスタンスの約3週間後に本番インスタンスをアップグレードします。

アップグレード後のタスクの完了は、ユーザーが新しいインスタンスにアクセスできるようにし、統合との間で送受信されるデータをファイアウォールを介して送信し、統合が期待どおりに機能するようにするために重要です。

アップグレード後に問題が発生した場合は、My Oracle Supportにサービス・リクエスト(SR)を入力するか、問題をトラブルシューティングします。 「アップグレードの問題のトラブルシューティング」を参照してください。

ノート:

アップグレード後、停止したOracle Integration Generation 2インスタンスがOracle Cloudコンソールに表示されます。 このインスタンスを更新、起動または削除しないでください。 不要になった場合は、Oracleによってユーザーのかわりに削除されます。

これらのタスクを開始する前に、アップグレードが完了していることを確認してください。 「アップグレード時の作業」を参照してください。

アップグレード後のタスクのサマリー

影響	時期	完了するタスク
インスタンスへのアクセスの保証	アップグレード直後	新しいOracle Integration 3インスタンスを確認 新しいOCIDでIAMポリシーを更新 新規インスタンスのURLを取得し、共有
接続性を確保	アップグレード直後	完全なネットワーク・ルール構成 接続用の新しいアイデンティティ証明書のアップロード アップグレードされていないエージェントとの接続を取り戻す ファイル・サーバー: 内部ファイアウォール許可リストにファイル・サーバーIPアドレスを追加 アップグレード後1週間以内にこのタスクを完了します。 ファイル・サーバー: 新しいIPおよびポート値を使用するように統合およびSFTPクライアントを更新 アップグレード後1週間以内にこのタスクを完了します。
統合作業の確保	アップグレード直後	Oracle Integration 3コールのDeveloper APIを基本認証からOAuthに変更します アクティブ化失敗を無視または開始スケジュール失敗を無視を選択した場合、統合をチェック アップグレード・ダウンタイム中に拒否されたリクエストを処理 サービス・インスタンス名の変更 統合がサポートされている最新の形式に更新されていることを確認します
無視された事前チェック失敗に対するアップグレード後のタスクの完了	アップグレード直後	無視された事前チェック失敗のアップグレード後のタスクの完了
アップグレード後のVisual Builderタスクの完了	アップグレード直後	Visual Builderのアップグレード後のタスクの完了
アップグレード後の「プロセス自動化」タスクの完了	アップグレード直後	プロセス自動化のアップグレード後のタスクの完了
統合インスタンスIDのアップグレード後更新の完了	アップグレードから6か月以内	統合インスタンスIDの変更に必要な更新の実行
アップグレード後の検証の完了	2週間以内のアップグレード	組織の検証手順に従う

インスタンスへのアクセスの確認

タスク	作成者	時期	完了するタスク
新しいOracle Integration 3インスタンスを確認	管理者	アップグレード直後	既存の資格証明を使用してOracle Integration 3インスタンスにサインインします。 既存のOracle Integration Generation 2ブックマーク(新しいURLにリダイレクトされる)を使用するか、Oracle Integration 3インスタンスの新しいURLを使用します。 「Oracle Integrationインスタンスへのアクセス」を参照してください。 インタフェースが次のようになると、アップグレードが完了します: 次の場合は、アップグレードが進行中です: サインインすると、サービスが使用できないことがページに表示されます。 サインインすると、ユーザー・インタフェースは次のようになります:
新しいOCIDでIAMポリシーを更新	IAMポリシー管理者	アップグレード直後	組織がインスタンスのOracle Cloud ID (OCID)に基づいてOracle Integration Generation 2インスタンスへのアクセスを制限している場合は、IAMポリシーを更新して新しいOracle Integration 3インスタンスOCIDを指すようにします。 注意: IAMポリシーのOCIDを更新するまで、ユーザーはOracle Integration 3にサインインできません。 Oracle Cloudコンソールにサインインします。 Oracle Integration 3インスタンスの新しいOCID値を取得します。 「インスタンスの詳細の表示」を参照してください。 IAMポリシーのOCIDを更新します。 既存のポリシーで文を更新する手順は、Oracle Cloud Infrastructureドキュメントの「コンソールの使用」を参照してください。
新しいインスタンスのURLを取得し、共有	管理者	アップグレード直後	新しいOracle Integration 3インスタンスのURLを取得し、それを必要とするすべてのユーザーと共有します。 既存のブックマークも新しいURLにリダイレクトされますが、すべてのユーザーが新しいURLを持っていることを確認する必要があります。 これは、次の形式です: https://design.integration.region.ocp.oraclecloud.com/?integrationInstance=query_parameter_repersenting_instance 新しいURLを取得するには: Oracle Cloudコンソールにサインインします。 ナビゲーション・メニューを開き、「開発者サービス」をクリックします。 「アプリケーション統合」の下で、「統合」をクリックします。 新しいOracle Integration 3インスタンスの名前をクリックします。 「サービス・コンソールURL」フィールドの右側にある「コピー」をクリックします。 URLを必要とする人と共有します。

接続性の確保

タスク	作成者	時期	完了するタスク
完全なネットワーク・ルール構成	ネットワーク管理者	アップグレード前またはアップグレード直後	統合接続のいずれかで、Oracle Cloud Infrastructureオブジェクト・ストレージやOracle Autonomous Databaseなどのネットワーク・ルールをサポートするOracle Cloud Infrastructureサービスをターゲットとし、それらのルールを有効にした場合は、Oracle IntegrationサービスVCNをルールに追加するなど、ネットワーク・ルールの構成を完了する必要があります。 Oracle Cloudコンソールにサインインします。 Oracle Integration 3インスタンスのOCID値を取得します。 「インスタンスの詳細の表示」を参照してください。 ターゲット・サービスのルールに従います。 たとえば、Oracle Autonomous AI Database Serverlessの場合は、『Oracle Autonomous AI Database Serverlessの使用』のインスタンスのプロビジョニングまたはクローニング時のアクセス制御リストの構成に関する項を参照してください。 アクセスしているOracle Cloud InfrastructureサービスがOracle Integrationインスタンスとは異なるリージョンにある場合は、アップグレード前に「他の許可リストを更新しました」で収集した「OICアウトバウンドIP」アドレスを許可リストに登録します。
接続用の新しいアイデンティティ証明書のアップロード	アイデンティティ証明書を使用する接続を持つ開発者 これらのステップを実行する必要があるのは、組織の1人のユーザーのみです	アップグレード直後	アイデンティティ証明書は、双方向SSL通信中にクライアント・アイデンティティを確立します。 「AS2アダプタ」および「RESTアダプタ」に基づく接続では、アイデンティティ証明書を使用できます。 インスタンスにアイデンティティ証明書を使用する接続が含まれている場合、アイデンティティ証明書はアップグレード中に削除されるため、新しいアイデンティティ証明書を生成して新しいJKSを構成する必要があります。 次のステップを実行して、新しいアイデンティティ証明書をアップロードし、アイデンティティ証明書を使用する接続をテストし、接続を使用する統合をアクティブ化します: 新しい個人証明書をアップロードします。 「Oracle Integration 3での統合の使用」の「SSL証明書のアップロード」を参照してください。 アイデンティティ証明書を使用する接続をテストし、ステータスがドラフトから構成済に変わるようにします。 「Oracle Integration 3での統合の使用」の「接続をテスト」を参照してください。 接続を使用する統合をアクティブ化します。 「Oracle Integration 3での統合の使用」の「統合のアクティブ化」を参照してください。
アップグレードされていないエージェントとの接続を取り戻す	アップグレードされていないエージェントを持つ開発者	アップグレード直後	アップグレード中に到達できなかったエージェント、またはアップグレード要件を満たさなかったエージェントはアップグレードされませんでした。 アップグレード後に、一部のエージェントがアップグレード適格を満たしておらず、アップグレードされなかったことを示すメッセージが表示された場合は、次のステップを実行します。 前提条件 接続エージェントからOracle Cloud Infrastructure Identity and Access Management (IAM)およびOracle Integration 3への接続を確認します: 「許可リストの更新」の説明に従って、アップグレード前にIAMおよびOracle Integration 3 IPアドレスを許可リストに追加しておく必要があります。 Oracle Integration 3設計時IPアドレスを許可リストに追加します。 次のコマンドを使用して、設計時のIPアドレスを取得し、regionをOracle Integration 3 URLのリージョンに置き換えます: nslookup design.integration.region.ocp.oraclecloud.com エージェントを手動でアップグレードし、エージェントとの接続を再取得するには: 接続性エージェントを停止します。 エージェントの前提条件が完了していることを確認します: 接続エージェントがJDK 17を使用していることを確認します。 そうでない場合は、JAVA_HOMEおよびPATH環境変数をJDK17に設定します。 エージェントがPKCS12 KeyStoreを使用していることを確認します。 そうでない場合は、次のステップを使用して変換します。 接続エージェントをホストするサーバーで、次のフォルダにあるkeystore.jksファイルのバックアップを作成します: Agent_Install_Location/agenthome/agent/cert バックアップ・ファイルを別のフォルダに移動します。 コマンドラインから次のコマンドを実行して、JKS KeyStoreをPKCS12 KeyStoreに変換します: keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS12 -deststorepass changeit -srcstorepass changeit 次のロケーションのkeystore.jksファイルを削除します: Agent_Install_Location/agenthome/agent/cert エージェント・インストーラのZIPファイルをOracle Integration 3からダウンロードします。 ナビゲーション・ペインで、「設計」、「エージェント」の順にクリックします。 「ダウンロード」をクリックし、次に「接続エージェント」をクリックします。 oic_conn_agent_installer.zipを接続エージェント・サーバー上の新しいディレクトリに抽出します。 Agent_Install_Location/agenthome/の下にある既存の接続エージェントlibフォルダを削除し、ZIPファイルのlibフォルダに置き換えます。 Agent_Install_Location/agenthome/の下にある既存のversionファイルを削除し、ZIPファイルからversionファイルに置き換えます。 Agent_Install_Locationの下にある既存のconnectivityagent.jarファイルを削除し、ZIPファイルからconnectivityagent.jarファイルに置き換えます。 Agent_Install_Locationの下にある既存のcpi_upgradeutility.jarファイルを削除し、ZIPファイルからcpi_upgradeutility.jarファイルに置き換えます。 Oracle Integration 3の「エージェント」ページで、エージェント・グループにカーソルをあわせて「アクション」 をクリックし、「構成のダウンロード」を選択します。 このステップでは、エージェント・グループの事前構成済のInstallerProfile.cfgファイルがダウンロードされます。 Agent_Install_Locationの下にある既存のInstallerProfile.cfgファイルを削除し、前のステップでダウンロードしたInstallerProfile.cfgファイルに置き換えます。 次のコマンドを実行して、接続エージェントを再起動します: java -jar connectivityagent.jar アップグレードされたエージェント・グループにある「統合の再アクティブ化」。
ファイル・サーバー: 内部ファイアウォール許可リストにファイル・サーバー IPアドレスを追加	「ファイル・サーバー」管理者および開発者	アップグレードの1週間以内	組織で内部リソースがアクセスできるサイトが制限されている場合は、新しい「ファイル・サーバー」 IPアドレスを内部ファイアウォール許可リストに追加してください。 Oracle Integration Generation 2 IPアドレスは、アップグレード後4か月間機能し続け、その後Oracleによってリタイアされます。 ただし、Oracleでは、新しいIPアドレスを使用するようにファイアウォール許可リストを更新することをお薦めします。 これにより、将来許可リストを更新することを忘れるリスクはありません。 「ファイル・サーバー」 IPアドレスを取得するには: Oracle Integration 3にサインインします。 ナビゲーション・ペインで、「設定」、「ファイル・サーバー」、「設定」の順にクリックします。 「一般」で、「ファイル・サーバー」 SFTPサーバーのIPアドレスを取得します。
ファイル・サーバー: 新しいIPおよびポート値を使用するように統合およびSFTPクライアントを更新	「ファイル・サーバー」管理者および開発者	アップグレードの1週間以内	「ファイル・サーバー」を使用する場合は、新しいIPおよびポートの値を使用するように統合およびSFTPクライアントを更新します。 Oracle Integration Generation 2 IPおよびポートの値は、アップグレード後4か月間引き続き動作し、Oracleによってリタイアされます。 ただし、Oracleでは、新しい値を使用するように統合およびSFTPクライアントを更新することをお薦めします。 これによって、将来これらの値を更新することを忘れるリスクはありません。 Oracle Integration 3にサインインします。 ナビゲーション・ペインで、「設定」、「ファイル・サーバー」、「設定」の順にクリックします。 「一般」で、ファイル・サーバーSFTPサーバーのIPおよびポートの値を取得します。 ファイル・サーバーをコールするすべての統合を更新して、新しいIPおよびポートの値を使用するようにします。 新しいIPおよびポートの値を使用するように、すべてのSFTPクライアントを更新します。

統合作業の保証

タスク	作成者	時期	詳細
Developer API for Oracle Integration 3コールを基本認証からOAuthに変更します	開発者	アップグレード前またはアップグレード直後	前提条件またはアップグレード前のタスクの実行中にOAuthを使用するようにAPIコールをまだ更新していない場合は、アップグレード直後に実行します。 Oracle Integration Generation 2では、基本認証を使用してOracle Integration REST APIおよび「ファイル・サーバーREST API」を使用できます。 Oracle Integration 3では、OAuthを使用する必要があります。 OAuthを使用して接続するには、Developer API for Oracle Integration 3またはDeveloper API for File Serverを使用するクライアント、スクリプト、統合およびコマンドを更新する必要があります。 認証方法のサポートの詳細は、『Oracle Integration 3のプロビジョニングと管理』の「Oracle Integration 3での基本認証のサポート時期」を参照してください。 OAuthの使用方法の詳細は、Oracle Integration 3のDeveloper APIのセキュリティ、認証および認可またはOracle Integration 3のDeveloper APIのセキュリティ、認証および認可を参照してください。
「アクティブ化の失敗を無視」または「開始スケジュール失敗を無視」を選択した場合、統合を確認	管理者	アップグレード直後	Oracleで統合をアクティブ化できなかった場合やスケジュールを再起動できなかった場合でも、アップグレードを続行するには、「アップグレード設定を構成しました」で適切なステップを実行します: 「アクティブ化の失敗を無視」を選択した場合は、すべての統合のステータスを確認し、必要に応じて統合をアクティブ化します。 「開始スケジュール失敗を無視」を選択した場合は、統合のスケジュールを確認し、必要に応じて手動で開始します。
アップグレード・ダウンタイム中に拒否されたリクエストを処理	指定されたチーム・メンバー	アップグレード直後	Oracle Integrationは、アップグレードの停止時間中に送信されたリクエストをすべて拒否しました。 必要に応じて、停止時間中にクライアントがOracle Integrationに送信したリクエストに対してアクションを実行します。
サービス・インスタンス名の変更	開発者	アップグレード直後	Oracle Integration Generation 2からOracle Integration 3にアップグレードすると、サービス・インスタンス名(サービス・インスタンス表示名)の最後にテナンシ名が次の形式で追加されます: <service instance name>-<tenancy name>。 たとえば、サービス・インスタンス名がmyinstanceで、テナンシ名がmytenancyの場合、Oracle Integration 3にアップグレードすると、myinstance-mytenancyに変更されます。 そのため、統合でサービス・インスタンス名を使用する場合は、新しいサービス・インスタンス名を使用するように統合を更新してください。そうしないと、統合は失敗します。
統合がサポートされている最新の形式に更新されていることを確認します	開発者	アップグレード直後	アップグレード前にOracle Integration Generation 2で構成された状態で統合があった場合は、アップグレード後に次のステップを完了して、これらの統合がサポートされている最新の形式であるOracle Integration 3に更新されていることを確認します: 統合のキャンバスを開きます。 統合キャンバスの上にあるツールバーの「プライマリ情報」 をクリックします。 プライマリ情報パネルを閉じます(キャンバスをクリックするか、「プライマリ情報」 をクリックします)。 「保存」ボタンが統合に対して有効になります。 「保存」をクリックします。 前述のステップを実行せずに統合をアクティブ化すると、ランタイム・インスタンスで問題が発生する可能性があります。

無視された事前チェック失敗のアップグレード後のタスクの完了

事前チェックの失敗を無視するように選択した場合は、失敗した事前チェックに関連付けられたステップを実行します:

事前チェック	接続タスク	統合タスク	その他のタスク
遅延(非同期)レスポンス		アップグレード後、次のいずれかのアダプタを使用して、遅延(非同期)レスポンスを使用した統合を再処理または再作成する必要があります: Oracle CX SalesおよびB2B Serviceアダプタ Oracle ERP Cloudアダプタ Oracle HCM Cloudアダプタ Oracle Fusion Field Serviceアダプタ Salesforceアダプタ ServiceNowアダプタ アプリケーション主導の統合: アプリケーション主導の統合は、アップグレード中にドラフト状態に変更されます。 これらの統合は、次のステップを使用して再処理する必要があります: 成功コールバックの単純な起動を作成します。 障害ハンドラの下に障害コールバックの起動を追加して、正しい障害を捕捉します。 データ・マッピングを再作成します。 基本的なルーティング統合: 基本的なルーティング統合はOracle Integration 3ではサポートされておらず、空白のキャンバスが表示されます。 これらの統合を削除し、アプリケーション主導の統合として再作成する必要があります。
サポートされていないアダプタ	アップグレード中に、次のサポートされていないアダプタを使用した接続が削除されました: Automation Anywhereアダプタ Evernoteアダプタ Oracle Messaging Cloud Serviceアダプタ Oracle Monetization Cloudアダプタ Oracle Taleo Business Edition (TBE)アダプタ UiPath Robotic Process Automationアダプタ RESTアダプタ接続を作成して、削除されたサポートされていないアダプタ接続を置き換える必要があります。	アップグレード中、サポートされていないアダプタを使用した統合はドラフト状態に変更され、スケジュールされた実行は取り消されます。 これらの統合は、次のステップを使用して再処理する必要があります: サポートされていないアダプタ接続に対応する呼出しを削除し、新しいRESTアダプタ接続に置き換えます。 統合が構成およびアクティブ化されたら、スケジュールを起動します。
カスタム・アダプタ	アップグレード中に、カスタム・アダプタを使用した接続が削除されました。 削除されたカスタム・アダプタ接続を置き換えるには、同等のOracle Integration 3アダプタを使用して新しい接続を作成する必要があります。	アップグレード中、サポートされていないアダプタを使用した統合はドラフト状態に変更され、スケジュールされた実行は取り消されます。 これらの統合は、次のステップを使用して再処理する必要があります: カスタム・アダプタ接続に対応する呼出しを削除し、作成した新しい接続に置き換えます。 統合が構成およびアクティブ化された後、スケジュールを開始します。
複数読取りファイル		アップグレード中に、複数ファイルの読取り操作を使用した統合がドラフト状態に変更されます。 これらの統合は、このパターンを使用しないように再処理する必要があります。 たとえば、listFile操作を使用してファイルをリストし、for-eachアクションを使用して各ファイルを個別に読み取ります。
サポートされていないRESTタイプ	アップグレード中に、次のサポートされていないRESTタイプを使用した接続がドラフト状態に変更されました。 メタデータ・カタログURL Swagger定義URL RAML定義URL これらの接続は、次のいずれかのメソッドを使用して更新する必要があります: RAMLまたはOracleメタデータ・カタログを使用している場合は、RESTサービス・プロバイダにSwagger定義を依頼できます(使用可能な場合)。 これはすべてのOracle Fusion Applicationsのガイドラインであるため、Oracle Fusion ApplicationsにはSwaggerオプションを使用できる必要があります。 代替仕様が使用できない場合は、接続URLとしてREST APIベースURLを選択し、アダプタ・エンドポイント構成ウィザードを使用してターゲットAPIリクエストを定義することで、RESTアダプタの基本テンプレートを使用します。 RAMLを使用している場合の別のオプションは、RAMLをOpenAPI仕様に変換することです。 Swagger定義URLを使用している場合、RESTアダプタの新しい統合オプションを使用して、すべてのOpenAPI指定を単一のフィールドに指定できます。 このオプションは、Swagger/OpenAPI仕様に対するより堅牢で完全なサポートを提供します。 「Oracle Integration 3でのRESTアダプタの使用」の「起動接続の接続プロパティの構成」を参照してください。	アップグレード中に、サポートされていないRESTタイプを使用した統合がドラフト状態に変更され、スケジュールされた実行が取り消されました。 これらの統合は、次のステップを使用して再処理する必要があります: 統合をアクティブ化します 統合がアクティブ化された後、スケジュールを開始します。
基本ルーティング重複アプリケーション名		基本的なルーティング統合はOracle Integration 3ではサポートされておらず、空白のキャンバスが表示されます。 これらの統合を削除し、アプリケーション主導の統合として再作成する必要があります。
公開/サブスクライブの統合		メッセージの公開またはOracle Integrationからのメッセージのサブスクライブを行う統合は、イベント駆動型のオーケストレーションに変換する必要があります。 「パブリッシュ/サブスクライブ統合」の事前チェック手順に基づいて、統合を削除し、再作成する必要があります。
カスタム・エンドポイントURL			アップグレード中にカスタム・エンドポイントが移行されませんでした。 カスタム・エンドポイントを再作成する必要があります。

Visual Builderのアップグレード後のタスクの完了

移行を完了するには、次のステップを実行します:

タスク	作成者	時期	タスクの説明
カスタム・エンドポイントのDNSレコードの更新	管理者	アップグレード直後	Visual Builderを使用していて、インスタンスにWAF V2またはロード・バランサを使用するようにカスタム・エンドポイントが構成されている場合は、カスタム・エンドポイントDNSレコードのCNAMEをVisual Builderインスタンス・ホスト名またはVisual Builder Generation 2ロード・バランサのIPアドレスで更新します。 ロード・バランサを更新するには: ロード・バランサを使用してバックエンドを追加します。 パブリック・ロード・バランサCIDR (IP/32)のVCN (NAT Gateway)のルート表に新しいルールを追加します。 ノート: アップグレード後に、Visual BuilderとOracle Integrationの両方に同じカスタム・エンドポイントを使用することはできません。 同じカスタム・エンドポイントを使用すると、問題が発生する可能性があります。
アップグレード後の追加タスクの完了	開発運用チーム	アップグレード直後	「Oracle Integration 3でのOracle Visual Builderの管理」の「アップグレード後に完了するタスク」で説明されているタスクを実行します。

プロセス自動化のアップグレード後のタスクの完了

Oracle Integration 3の「プロセス自動化」への移行を完了するには、次のステップを実行します。

ノート:

「アクティブに使用されたプロセス・アプリケーションの手動移行」を実行した場合、これらのアップグレード後のタスクを実行する必要はありません。

統合の再構成

インスタンスがアップグレードされると、プロセス・アクションはOracle Integration Generation 2プロセス・アクションからOracle Integration 3プロセス・アクションに変換され、統合はOracle Integration 3プロセス・アクションになりますが、非アクティブ化状態になります。 そのため、プロセス自動化コール・ウィザードを使用して統合を再構成する必要があります。

プロセス自動化コール・ウィザードを使用して統合を再構成する方法の詳細は、「Oracle Integration 3での統合の使用」の「プロセス処理との統合からのプロセスの起動」を参照してください。

プロセス自動化のアプリケーション・レベルのアップグレード後タスク

プロセス・アプリケーションごとに次のタスクを実行します。

タスク	作成者	時期	詳細
ロール・マッピングの更新	開発者/管理者	アップグレード直後	Oracle Integration 3でロール割当てが変更されたため、既存のロールを新しいロールにマップする必要があります。 「Oracle Cloud Infrastructure Process Automationの使用」の「プロセス・アプリケーションのロールの構成」を参照してください。 プロセス所有者 次のロールを持つメンバーを、新しいアプリケーションの「プロセス所有者」ロールに追加します: <application-name>.ProcessOwner <application-name>.AnalyticsViewer auto-handler for the swim-lane レビューアの処理 <application-name>.ProcessReviewerロールを持つメンバーを、新しいアプリケーションの「プロセス・レビューア」ロールに追加します。 スイムレーン・ロールを持つメンバー swim-laneロールを持つメンバーを、新しいアプリケーションのスイムレーンに割り当てられたロールに追加します。 グループ 古いグループを新しいアプリケーションのロールに変更し、そのグループを新しいロールに追加するか、グループのメンバーを新しいロールに追加します。 ロール 新しいアプリケーションのロールに古いロールを変更し、新しいロールにメンバーを追加します。 プロセスを開始できるメンバー プロセス開始プロパティで、次のいずれかのオプションからプロセスを開始できるメンバーを選択します: 少なくとも使用権限を持つロール・メンバー: 「使用」または「管理」権限を持つロールを割り当てられたユーザーに、アプリケーションを表示および開始することを許可します。 構造化プロセスでは、プロセスを開始するためにユーザーがスイムレーンに割り当てられる必要はありません。 すべてのユーザーおよび外部アプリケーション: プロセス自動化へのアクセス権を持つユーザーまたは外部アプリケーションがアプリケーションを表示および起動できるようにします。 動的プロセス・ロール 動的プロセス・ロールを持つメンバーを、新しいアプリケーションの動的プロセス・ロールに追加します。
コネクタ資格証明の更新	開発者/管理者	アップグレード直後	資格証明はOracle Integration 3に移行しないため、RESTコネクタの認証を再構成する必要があります。 同じサーバーに接続するアプリケーションが複数ある場合は、アプリケーション間で再利用できるグローバル資格証明を作成できます。 「Oracle Cloud Infrastructure Process Automationの使用」の「Basic認証セキュリティの構成」を参照してください。
エラーおよび警告の修正	開発者/管理者	アップグレード直後	Oracle Integration Generation 2とOracle Integration 3の間には「プロセス機能の違い」があるため、アプリケーションを検証し、エラーや警告を修正する必要があります。 「Oracle Cloud Infrastructure Process Automationの使用」の「アプリケーション一覧」にある「アプリケーションの検証方法」を参照してください。
申請のアクティブ化	開発者/管理者	アップグレード直後	すべての検証エラーを解決したら、アプリケーションをアクティブ化して、新しいインスタンスをトリガーして処理できるようにします。 「Oracle Cloud Infrastructure Process Automationの使用」の「アプリケーションのアクティブ化」を参照してください。

「プロセス自動化」のサービス・レベルのアップグレード後のタスク

プロセスの使用方法に応じて、Oracle Integration 3へのアップグレード後に異なるサービス・レベルのステップを実行します。 実装に適用するステップを実行します。

タスク	作成者	時期	詳細
新しい「プロセス自動化」 URLの許可リスト	開発者	アップグレード直後	新しい「プロセス自動化」 URLを許可リストに追加します。 新しいURLを検索するには、Oracle Integration 3メニューの「プロセス」をクリックします。 「プロセス自動化」 URLにリダイレクトされます。
統合を更新して「プロセス自動化」をコール	開発者	アップグレード直後	アップグレード後に、プロセス自動化およびデシジョン・アプリケーション用の開発者APIが変更されました。 プロセス自動化コール・ウィザードを使用して統合を再構成する必要があります。 「統合の再構成」を参照してください。
「プロセス自動化」をコールするようにVisual Builderアプリケーションを更新	開発者	アップグレード直後	アップグレード後に、プロセス自動化およびデシジョン・アプリケーション用の開発者APIが変更されました。 その結果、Oracle Cloud Infrastructureプロセス自動化をコールするVisual Builderアプリケーションを更新し、非推奨の相互作用パターンを置き換える必要があります。 Visual Builder Studioを使用したレスポンシブ・アプリケーションの構築のプロセス自動化のための開発者APIへの接続を参照してください。
「プロセス自動化」をコールするように外部クライアントを更新	開発者	アップグレード直後	外部アプリケーションでプロセスCCAコンポーネントを使用している場合、Oracle Integration 3へのアップグレード後は動作しません。 APIを利用するには、新しい「プロセス自動化」 CCAコンポーネントの使用に移行する必要があります。 Oracle Cloud Infrastructure Process Automationの開発者APIを参照してください。
新しい「プロセス自動化」 URLを共有	管理者	アップグレード直後	「プロセス自動化」へのアクセスおよび操作に使用されるURLは、アップグレード後に変更されました。 新しいURLを、「プロセス自動化」の管理、新しいプロセスの開始、またはタスクの表示と操作を行う必要があるすべてのユーザーと共有します。

統合インスタンスIDの変更に必要な更新の実行

タスク	作成者	時期	詳細
統合インスタンスIDの英数字への変更に必要な完全な更新	開発者	アップグレード後6か月以内	「アップグレード設定を構成しました」を「アップグレード後の数値としてのflowidの有効化」にすると、統合インスタンスIDに必要な更新を数値から英数字に変更するために、アップグレード後6か月かかります。 この変更は、整数である統合インスタンスIDに基づく統合フローに影響します(たとえば、数値データ型を持つデータベース列で統合インスタンスIDが解析される場合)。 アップグレード後、これらの統合を変更せずに実行した場合、アップグレード設定で「アップグレード後の数値としてのflowidの有効化」を選択せずに、変換例外エラーが発生します。 Conversion Exception Description: The object […], of class [class java.lang.String], could not be converted to [class java.math.BigDecimal]. 変更に対応するために、影響を受ける各統合のマッピングを更新するか、データベースに統合インスタンスIDを格納する列のデータ型を更新できます。 ノート:ここで説明する推奨方法は、Oracleデータベース・サービス(Oracle Autonomous AI Databaseなど)に基づいています。 その他のデータベース・タイプには、追加のステップが必要になる場合があります。 方法1: 影響を受ける各統合でのマッピングの更新 影響を受ける各統合で、統合インスタンスID値を含むターゲット属性を新しい数値UNIX時間にマップします。 UNIX時間は、1970年1月1日のUTC 00:00:00から始まるUNIXエポックからの経過秒数です。 この値は毎秒増分されます。 値は整数として解析できるため、データベースの変更は必要ありません。 アップグレードする前に、「インスタンスIDアクション事前チェック」の説明に従って、影響を受ける統合に注意してください。 影響を受ける統合ごとに次のステップを実行します: アクティブな統合は編集できないため、統合がアクティブな場合は非アクティブ化します。 統合を開きます。 統合インスタンスIDを含むマップをダブルクリックします。 統合インスタンスID値を含むターゲット属性を検索し、それをクリックします。 式ビルダーで、をクリックします。 次の式を入力します。 floor (((fn:current-dateTime() - xsd:dateTime ("1970-01-01T00:00:00" )) div xsd:dayTimeDuration ("PT1S" )) )  をクリックして式を保存します。 統合キャンバスに戻り、変更を保存します。 方法2: データベース内の影響を受ける列のデータ型を更新 データベースで、統合インスタンスIDを保持する列のデータ型をstring (CHAR/VARCHAR)に変更します。 このアプローチには、統合に対する変更は含まれません。 ノート: 解決策は、操作SQL文の実行を使用して作成されたデータベース・アクションに限定されます。 データベース列はすでに移入されているため、列のデータ型を変更することはできません。 かわりに、次のステップを実行します。 SQL Developerで次のステップを実行します。 「インスタンスID」列名をノートにとります。 VARCHAR型の一時列(TEMPなど)を追加します。 SQL構文: ALTER TABLE table-name ADD temporary-column VARCHAR2(50); 例: ALTER TABLE FLOW_MANAGEMENT ADD TEMP VARCHAR2(50); ソース列(インスタンスIDを含む列)から一時列に値をコピーします。 SQL構文: UPDATE table-name SET temporary-column-name = source-column-name 例: UPDATE FLOW_MANAGEMENT SET TEMP = FLOWID; ソース列の値をNULLに設定します。 SQL構文: UPDATE table-name SET source-column-name = NULL; 例: UPDATE FLOW_MANAGEMENT SET FLOWID = NULL; ソース列の型をNUMBERからVARCHARに更新します。 SQL構文: ALTER TABLE table-name MODIFY source-column-name VARCHAR2(50); 例: ALTER TABLE FLOW_MANAGEMENT MODIFY FLOWID VARCHAR2(50); 一時列からソース列にインスタンスID値をコピーして戻します。 SQL構文: UPDATE TABLE table-name SET source-column-name = temporary-column-name 例: UPDATE FLOW_MANAGEMENT SET FLOWID = TEMP; 一時列を削除します。 SQL構文: ALTER TABLE table-name DROP COLUMN temporary-column-name; 例: ALTER TABLE FLOW_MANAGEMENT DROP COLUMN TEMP;
(オプション)フローIDを数値に設定	管理者	アップグレード後6か月以内	必要な更新が完了したら、オプションでフローIDを数値に設定できます。 管理者としてOracle Integrationにサインインします。 「設定」をクリックし、「その他」をクリックします。 フローIDタイプを「英数字」に変更し、「保存」をクリックします。

組織の検証手順に従う

タスク	作成者	時期	詳細
組織のアップグレード後の検証タスクの実行	指定されたチーム・メンバー	アップグレード後2週間以内	回帰テストの実行など、組織のアップグレード後の検証タスクを完了します。 統合を本番インスタンスに移動する前に、開発/ステージ・インスタンスで統合ロード・テストを実行します。