マイクロアプリ

統合の計画

統合する対象の業務アプリケーションを選択し、統合ユースケースを識別してAPIを特定します。

Citrix Workspaceに統合できるアプリケーションは無数にあります。Citrix Workspaceユーザーが関心のある情報を保持するターゲットアプリケーションを選択します。特に関心があることは、クイックタスクに定期的に使用され、ユーザーにとって直感的にアクセスできないアプリケーションです。ユーザーがCitrix Workspace内から直接対話できるようにするアクション可能なアプリケーションは、ユーザーの通知を有効にするだけのアプリケーションよりもはるかに価値があります。たとえば、承認、作成、追加を行います。

統合のターゲットビジネスアプリケーションの選択

Citrix Workspaceユーザーが関心のある情報を保持するターゲットアプリケーションを選択します。

特に関心があることは、クイックタスクに定期的に使用され、ユーザーにとって直感的にアクセスできないアプリケーションです。また、ユーザーがCitrix Workspace内から直接対話(アイテムの承認など)できるようにするアプリケーションは、ユーザーの通知を有効にするだけのアプリケーションよりもはるかに価値があります。

ターゲットシステムがJSON RESTおよび一般的な認証メカニズム(OAuth 2.0、NTLM、Basic Auth、Bearer Auth)を使用している場合、システムをCitrix Workspaceとシームレスに統合できる可能性が高くなります。HTTP統合をターゲット統合のSoR(system of record)で使用できるようにするには、SoRが以下の前提条件を満たしていることを確認します:

  • ターゲット統合アプリケーションのSORが、JSON形式でデータを返すREST APIを使用している。

  • 製品が、すべてのユーザーのデータにアクセスし、サービスアクションでユーザーに代わってライトバックできるサービスアカウントの使用をサポートしている(2つの個別のアカウントの場合もあり)。

  • 製品が、単一のエンドポイントからのオブジェクトのすべてのインスタンスの取得をサポートしている。たとえば、すべてのJiraチケットをGET /searchを使用して取得できますが、O365では、ユーザーごとにメールを取得する必要があります。

  • SORに典型的なデータが入力されている(データテーブルの自動生成を行うには、結果を取得し、その構造を識別します。ネストされたJSONフィールドがSORのデータで見つからない場合、そのテーブルは作成されません)。

  • 製品で次の認証形式のいずれかがサポートされている:なし、基本、OAuth 2.0、NTLM、またはベアラー/トークン認証。OAuth 2.0が使用可能な場合は、必ずこの方法をデフォルトで使用して、最大限のセキュリティコンプライアンスを確保します。

  • 製品が、ページネーションの以下の形式のいずれかをサポートしている:なし、ページ、オフセット、リンク、ヘッダーリンク、カーソル、OData。

統合のユースケースの特定とAPIの特定

次に、Citrix Workspaceに統合する厳選されたターゲットビジネスアプリケーションの重要なユースケースを特定します。このアクティビティは創造力を必要とするプロセスであり、次のことを考慮する必要があります:

  • ユースケースを統合することで達成できる、潜在的な時間の節約
  • ユースケースの実装に必要な労力

ユースケースを識別したら、次の手順は、関連情報をターゲットシステムから抽出することやそのシステム内に戻すことができるAPIの特定です。この手順には、ユースケースの特定との間を行き来する繰り返しを伴う場合があります。これは、ターゲットシステムがユースケースの実装に適したAPIを提供しない可能性があるためです。

現在最も一般的なAPI標準はRESTful APIであり、JSONを使用して書式設定された応答を提供します。ほぼすべての最新のエンタープライズSaaSアプリケーションは、そのようなAPIを実装しています。

次のステップ

統合を計画したので、次のように統合の作成と構成を行います:

統合の計画