「RESTアダプタ」ユース・ケース
「RESTアダプタ」は、次のようなユース・ケースの実装に使用できます。
ノート:
Oracle Integrationの新しいインスタンスをプロビジョニングすると、いくつかのサンプル統合が自動的に含められます。 これらのサンプルの多くは、「RESTアダプタ」で構成します。 完全に設計されたこれらのサンプルは、迅速に起動して実行し、エンドポイント間の統合のアクティブ化、呼出しおよび監視がいかに簡単かを示します。 「Oracle Integration 3での統合の使用」の「サンプル統合の実行」を参照してください。
既存の機能の最新性
パートナまたは社内のクライアント・アプリケーションがREST APIのみを使用できるシナリオがあります。 この機能は、JDBCなどのHTTP以外のインタフェースを介して公開されます。 また、この機能はSOAP APIとして公開されています。 たとえば、オーダーのステータスは、SQL問合せを使用して取得する必要があるオンプレミス・データベースに存在する場合があります。 オーダー・ステータスを取得して、「RESTアダプタ」接続をトリガーとして構成することで、REST APIとして公開する統合をビルドできます。
クライアント・アプリケーションのニーズに基づいたAPIの構成
パートナまたは社内またはチャネル固有のクライアント・アプリケーションでは、バックエンドのデータソースに公開されている情報と比較して、情報のサブセットはごくわずかです。 たとえば、バックエンドのOracle ERP Cloudアプリケーションによって公開されるGet Order SOAP操作は、数百の属性を戻すことができますが、クライアント・アプリケーションはその10分の1未満を必要とすることがあります。 SOAPサービスを使用する統合をビルドしてオーダーの詳細を取得し、「RESTアダプタ」接続をトリガーとして構成することによって、REST APIとして公開できます。 この新しいREST APIのレスポンス・メッセージは、クライアント・アプリケーションが必要とする属性セットのみを反映することができます。 バックエンドSOAPサービスからREST API固有のレスポンス・メッセージへのデータのマッピングは、属性のサブセットに対してのみ実行されます。
クライアント・ドメインに基づく大まかなAPIの提供
パートナまたは社内またはチャネル固有のクライアント・アプリケーションが、バックエンド・システムによって同じレベルの粒度で公開されない可能性のあるAPIを保証するシナリオがあります。 たとえば、アプリケーションに受注を登録するためにAPIをパートナに公開したいとします。 ただし、受注アプリケーションでは、1つのオーダーを作成するために複数のサービス呼び出しが必要な場合があります。 パートナへのオーダーを作成するための単一のAPIを公開すると、内部実装の詳細が抽象化されます。 これを行うには、複数のサービス呼出しをバックエンド・システムに送信できる統合を開発し、それらを単一のREST APIとして公開します。これを行うには、「RESTアダプタ」接続をトリガーとして構成します。
外部REST API用のアプリケーション・アダプタがありません
Oracle Integrationは特定のアプリケーションとの統合を容易にするために多くのアダプタを提供しますが、特定のアダプタが欠けているアプリケーション/機能はまだまだあります。 また、「RESTアダプタ」接続を起動として構成することによって、統合を構築して、これらの外部REST APIsを起動することもできます。
管理対象外APIのOAuth2保護APIへの変換
保護されていないAPIやAPIを使用するアプリケーションは、一般に公開されることはほとんどありません。 保護されていないAPIは誤用される可能性がありますが、ユーザーの資格証明を使用して保護されたAPIは、クライアントとの信頼性を高める必要があります。 また、ユーザー資格証明の変更は、クライアント・アプリケーションも資格証明を更新する必要があることを意味します。 このようなAPIsを起動し、OAuth 2を使用して保護されるトリガーとして構成された「RESTアダプタ」接続を介して公開する統合を作成できます。