アダプタの計画のガイドライン
次のトピックで説明するガイドラインを使用して、アダプタ開発プロセスを計画します。
トピック:
問題の特定
アダプタを計画する最初のステップは、アダプタを作成して解決しようとしている問題など、ビジネス・プロセスに精通することです。
現在、ソフトウェア開発ライフサイクルに従っている場合は、開発作業のためにこれらのタスクをすでに完了している可能性があります。 組織の要件とタイムラインに応じて、これらのタスクを調整します。
| タスク | 詳細情報 |
|---|---|
|
ユーザーと利害関係者の識別 |
次のような、アダプタのユーザーおよび利害関係者を識別します:
|
|
ユーザーおよび利害関係者のユース・ケースの理解 |
アダプタが解決しているビジネス上の問題に関する情報を収集します。 可能な場合は、ユーザーや利害関係者と会い、この情報を収集します。 この段階では、実装について考えないようにしてください。 その代わりに、解決する必要があるすべての問題を特定するためにあらゆる努力をしてください。 要件を特定し、優先順位を付けることで、開発中のスコープのクリープを防止できます。 |
|
現在のソリューションの確認 |
組織には、対処するユースケースに対応するプロセスがすでにある可能性があります。 ユーザーや利害関係者とのミーティング中に、プロセスについて話し合います。 問題点を収集し、現在のプロセスがニーズを満たさない理由を理解します。 |
ターゲット・アプリケーションの理解
アダプタを作成するアプリケーションについて理解します。 APIを理解し、Oracle Integrationの外部でそれらに接続できることを実証します。
| タスク | 詳細情報 |
|---|---|
|
アプリケーションの理解 |
アダプタを作成するアプリケーションについて理解します。 たとえば、ユーザーのインタビュー中に、自動化が必要なワークフローのデモを要求する場合があります。 |
|
アプリケーションのAPIの理解 |
各APIは、アダプタに含めることができる機能を表します。 ドキュメントを確認して、アプリケーションのAPIについて理解します。 |
|
収集したユース・ケースに関連するAPIの理解 |
アプリケーションには、数十または数百のAPIがあります。 ただし、アダプタはそれらのすべてを公開する必要がない可能性があります。 次に例を示します。
収集したユース・ケースに関連するAPIの特定に時間を費やします。 これらのAPIは、最初のリリース、2番目のリリースなどの候補です。 |
|
APIのテスト |
アダプタが公開する必要のあるAPIを理解したので、Oracle Integrationの外部でAPIに接続できることを実証します。 APIに精通していることで、開発作業の基盤が強化されます。 PostmanやRESTクライアントなど、選択した環境で作業します。 APIをテストするには、APIとその認証スキームを理解する必要があります。これは通常、OAuthやBasic認証などの標準に準拠しています。 ノート: このステップは、最も重要な準備タスクです。 アプリケーションのAPIに接続できない場合は、アプリケーションのアダプタを構築できません。 アプリケーションのAPIで認証する方法を学習するために必要な時間を費やします。APIのテストは、Postmanコレクションの作成の一部でもあります。 「APIリクエストを使用したPostmanコレクションの作成」を参照してください |
|
アプリケーションがwebフックをサポートしている場合は、Webフックをテスト |
まず、アプリケーションがwebフックをサポートしているかどうかを確認します。 アプリケーションでイベントが発生すると、webフックによってイベントに関する詳細がアドレスに送信されます(多くの場合、データが含まれます)。 クラウド・アプリケーションは、多くの場合、webフックをサポートしています。 次に、アダプタでwebフックを受信する必要がある場合は、Webフックが到達可能かどうかをテストします。 Postmanなどの統合開発環境(IDE)で、宛先に何かを投稿してwebフックをテストします。 宛先として機能し、HTTPリクエストを受信できるサーバーがない場合は、到達可能なエンドポイントとして機能するオンライン・サービスを使用します。 |
要件の定義
アダプタのユース・ケースに関する情報を収集し、各ユース・ケースのAPIを特定した後、要件を定義して優先順位を付けます。
| タスク | 詳細情報 |
|---|---|
|
要件の理解 |
各ユース・ケースの履行に使用されるユースケースとAPIを収集し、アダプタの要件を記述します。 好きなように具体的に作業し、チームで通常使用する形式で作業します。 たとえば、製品要件ドキュメントを作成したり、問題トラッキング・ソフトウェアでチケットを作成したりできます。 要件を特定する際は、要件に優先順位を付けるのではなく、包括的なリストの作成に重点を置きます。 |
|
要件の優先順位付け |
ユーザーや利害関係者と協力して、要件に優先順位を付けます。 OracleがOracle Integrationで使用するためにアダプタをリリースする場合、アダプタは堅牢な機能を提供するため、多くの組織がそれらを使用してビジネス・プロセスを自動化できます。 ただし、特に最初のリリースでは、同様の堅牢なアダプタを提供する必要はありません。 かわりに、少数のユーザー・セットに機能を提供して、迅速に反復することを目指しています。 たとえば、最初のリリースで4つのAPI、2番目のリリースで4つのAPIなどをサポートすることを目指すことができます。 提供する計画が何であれ、ユーザーと利害関係者に常に知らせます。 |
|
開発作業の計画 |
たとえば、開発エピックの習得、ストーリの作成、およびスプリントへの作業の割当てを行います。 または、4つのAPIを公開するなど、より大きな目標を特定し、期限を迎えることもできます。 |