マイクロアプリ

マイクロアプリの作成

マイクロアプリを作成する際、ターゲットアプリケーションのデータベーススキーマを理解してワークフローを計画することが重要です。これにより、統合を構築するためのAPIを特定できます。これはカスタム統合を構築するために必要です。

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

次に、Citrix Workspaceに統合する厳選されたターゲットビジネスアプリケーションの重要なユースケースを特定します。次に例を示します:

  • 有給休暇/休暇要求の作成
  • 有給休暇/休暇要求の承認
  • 保留中の承認の検索
  • タスクを完了としてマーク
  • 作成または変更された割り当て済みタスクをユーザーに通知
  • インボイスの承認

ユースケースを識別したら、次の手順は、ターゲットシステムから関連情報を抽出したり、そのシステム内に戻したりできるAPIを特定することです。

以下に、インボイス承認のユースケースを使用してワークフローを設計するシナリオを示します。詳しくは、「サンプルシナリオワークフロー設計」を参照してください。

重要な注意事項

ワークフローを設計する前に、以下の考慮事項と制限を確認してください:

  • ページ上のデータにアクセスできる関係は1つだけです。これは、ページが作成されるとき、直接関係するデータのみをアドレス指定できることを意味します。
  • すべての個人設定は、ユーザーのメールのコンテキストから行われます。つまり、通知を作成したり、個人設定されたページを作成したりする場合、ユーザーのメールを最大1レベル離れた関係にできます。
  • 通知と同じテーブルに基づくページへの通知には、[移動先ページ]アクションリンクのみを設定できます。
  • 1つの変更で1つの通知が生成されます。宛先が関連テーブルにある場合、関係は1:1である必要があり、1:Nの関係はサポートされていません。
  • サーバーの制限のため、データベース構造は狭くする必要があります。このことは、エンドポイントを設計してデータベース構造を作成するときに考慮する必要があります。
  • 資格情報、APIキー、またはシークレットなどの機密性の高い機密データを含むカスタムフィールドを構成した場合、データは保護されません。そうしたデータは、デバッグログなどに表示されます。

注:

Citrix Workspaceマイクロアプリにアクセスできるすべての管理者は、キャッシュにあるデータにアクセスできます。管理者は、データソースの資格情報にアクセスできません。

マイクロアプリの基本の構築

マイクロアプリは、ページまたは行動通知で構成され、通常は両方です。

  • 通知は、イベント駆動型マイクロアプリであり、何らかの理由で注意が必要な場合、たとえば、Workspaceアクティビティのカードがフィードされるときに、自動的にユーザーに通知します。そのようなマイクロアプリには、「承認のための新しい経費レポート」「登録可能な新しいコース」 があります。以下は、使用可能なイベントトリガーの種類です:

    • 新しいレコード - ソースレコード(SoR)で新しいレコードが作成されたときに通知を送信します。
    • 変更されたレコード - SoRで既存のレコードが変更されたときに通知を送信します。
    • 一致するレコード - レコードがSoRの特定の時間に定義されたクエリに一致したときに通知を送信します。
    • 削除されたレコード - SoRで現在のレコードが削除されたときに通知を送信します。
    • 定期的な通知 -(ユーザーアクション)データによるトリガーではない通知を定期的に送信します。
    • 定期的なレポート - 指定された時間間隔で要約されたレポートデータ(グループ)を含む定期的な通知を送信します。
    • 日付リマインダー - レコードの日付列値の前または後の指定した時間に通知を送信します。
  • ページは、ユーザーが開始するマイクロアプリであり、Workspaceでアクションとして使用でき、アクションを簡単に開始できるようにします。たとえば、「有給休暇を申請する」「ヘルプデスクチケットを送信する」「ディレクトリを検索する」などです。以下は、ページの種類のテンプレートです:

    • 詳細 - SoRの個別レコードの静的な詳細を表示するページを作成します。
    • フォーム - ページにユーザーデータを入力する機能に加えて、静的な詳細を提供する編集可能なページを作成します。
    • テーブル - ターゲットアプリケーションのSoRから読み込む複数のデータテーブルに基づいて、ページを作成します。
    • 静的コンテンツ - 見出し、エラーメッセージ、リマインダーなど、静的で対応不可能な情報を表示するページを作成します。

新しいマイクロアプリの追加

この手順は、作成する空のマイクロアプリと同じです。

次の手順を実行します:

  1. [マイクロアプリ統合] ページで、マイクロアプリを追加する統合の横にあるメニューを選択します。
  2. [マイクロアプリの追加] を選択します。
  3. [空白のテンプレート] を選択し、ビジネスニーズに基づいて自身のマイクロアプリを構築します。 空のマイクロアプリを追加すると、[マイクロアプリ統合]ページの関連する統合の下に表示されます。
  4. [マイクロアプリの管理]ページに戻り、統合の下にあるリストから [空のマイクロアプリ] を選択します。 [プロパティ] ページが開きます。
  5. 適切な名前と説明を付けます。
  6. [マイクロアプリのアイコン] を選択し、メニューから適切なアイコンを選択します。[アプリアイコン][アクションと通知のアイコン]、および [マイクロアプリとデータ] のアイコンから選択できます。

サンプルシナリオワークフロー設計

インボイス承認システムがあり、ワークフローに次のユースケースを組み込む必要がある:

  • 新しい承認があったときに、承認者に通知する必要がある。
  • 要求が承認または拒否されたときに、要求者に通知する必要がある。
  • 承認者が、ステータス、合計金額、要求者の詳細(名前/メール/電話番号)などインボイスに関する情報と、ラインアイテムの詳細(名前/金額/数量)のリストを必要としている。
  • 要求者が、合計金額、承認者の詳細(名前/メール/電話番号)のリストなどインボイスに関する情報と、ラインアイテムの詳細(名前/金額/数量)のリストを必要としている。

次に、データベースとそのテーブルの関係を見てみましょう: データベーススキーマとそのテーブルの関係

マイクロアプリの設計

これから、4つの通知と5つのページが必要であることがわかります。

4つの通知を作成する必要があります。承認者用に2つ、要求者用に2つです。承認者と要求者のメールは、approversおよびinvoice-detailテーブルと直接関係のあるユーザーテーブルにあります。

5つのページを作成する必要があります。承認者のインボイスのリスト、承認者のインボイスの詳細、要求者のインボイスのリスト、要求者のインボイスの詳細、および承認者と要求者のラインアイテムの詳細に、それぞれ1つずつです。

通知の構築

まず、通知を作成します。考慮事項と制限はすべて通知に適用されます。通知はユーザーが送信する必要があります。ユーザーのメールは、テーブル内にあるか、最大1レベルの関係にある必要があります。

approversテーブルの承認者への通知を構築します:

  • テーブルの新しいレコードの通知
  • ステータス変更の通知

invoice_detailテーブルの要求者への通知を構築します:

  • テーブルの新しいレコードの通知
  • ステータス変更の通知

設計上の制限(承認者)

承認者フィードカードのデータは、次のテーブルからのみ取得できます:

  • approvers (プライマリテーブル)
  • invoice-detail(invoice_id関係)
  • users(approver_id関係のみ)

つまり、個人設定はユーザーのメールのコンテキストから行われるため、フィードカードへの要求者に関するデータを取得できません。たとえば、要求者名が必要な場合は、データベーススキーマを変更して、要求者名をinvoice_detail テーブルに追加する必要があります。

設計上の制限(要求者)

要求者フィードカードのデータは、次のテーブルからのみ取得できます:

  • invoice-detail(プライマリテーブル)
  • users(requestor_id関係のみ)

つまり、関係が1:Nであるため、line_itemsapproversからのデータを取得できません。たとえば、「要求がmanager@company.comによって承認されました」などのフィードカードテキストは取得できません。この情報が必要な場合は、データベーススキーマを変更し、この情報をinvoice_detailに追加する必要があります。

結論

これから、2つのinvoice_detailページが必要であることを判断できます:

  • approversテーブルに構築するインボイス詳細承認者
  • invoice_detailテーブルに構築するインボイス詳細要求者

ここで、インボイス書詳細承認者ページに制限があることを認識できます。approvers(プライマリテーブル)、invoice-detailinvoice_id関係)、およびusersapprover_id関係のみ)のテーブルから、すべてのデータを追加できます。ただし、通知と同じ問題があります。要求者情報が欠落しており、line_itemsテーブルが離れすぎています。これは、2つのレベルの関係です。

回避方法

2レベル離れた関係のテーブルからデータを取得する回避策があります。

オプション1 GotoPageを使用します。[詳細の表示] などの3番目のボタンを追加して、ユーザーをこのページからインボイス詳細要求者ページに移動できます。そのページをinvoice-detailテーブルに構築するので、requestorline_itemsテーブルは1レベル離れるだけになります。

オプション2 バインド解除されたテーブルコンポーネントを使用します:[詳細ページに関連するレコードを使用する] トグルを選択解除してline_itemsを選択できます。これにより、すべてのアイテムを含むテーブルが作成されます。特定のインボイスのアイテムのみを選択するには、フィルターを追加する必要があります。line_items invoice_id = approvers invoice_id。requestorにも同様のアプローチを使用できます。テーブルがline_itemsを超えているので、line_itemsと1:1またはN:1の関係をもつテーブルからデータを追加することもできます。

ページの構築

5つのページを構築する必要があります。次の各テーブルに1つずつです:

  • 承認者のインボイスのリスト
  • 承認者のインボイスの詳細
  • 要求者のインボイスのリスト
  • 要求者のインボイスの詳細
  • 承認者と要求者のラインアイテムの詳細

ユーザーの割り当てに基づいて詳細な権限を許可する必要がある場合は、別のマイクロアプリを使用します。たとえば、ワークフローで特定のユーザーのみが作成ページにアクセスする必要がある場合などです。ページビルダーのUIとそのコンポーネントの完全な概要については、「ページビルダーのコンポーネント」を参照してください。以下のクックブックには、コンポーネントを活用して種類が詳細およびリストのページを構築する方法について、詳細な手順が記載されています。

マイクロアプリクックブック

例に従って、記載の材料(コンポーネント)のリストを使用して、一般的な通知とページを構築できます。

通知

新しいまたは変更されたアイテムをワークフローからユーザーにプッシュする通知を構築します。イベントトリガーの種類から選択して、以下に示すように、ビルダーでイベントをカスタマイズします。詳しくは、「イベント通知の構築」を参照してください。

イベントトリガー:

  • 新しいレコード - ソースレコード(SoR)で新しいレコードが作成されたときに通知を送信します。
  • 変更されたレコード - SoRで既存のレコードが変更されたときに通知を送信します。
  • 一致するレコード - レコードがSoRの特定の時間に定義されたクエリに一致したときに通知を送信します。
  • 削除されたレコード - SoRで現在のレコードが削除されたときに通知を送信します。
  • 定期的な通知 -(ユーザーアクション)データによるトリガーではない通知を定期的に送信します。
  • 定期的なレポート - 指定された時間間隔で要約されたレポートデータ(グループ)を含む定期的な通知を送信します。
  • 日付リマインダー - レコードの日付列値の前または後の指定した時間に通知を送信します。

リストページ

ワークフローで使用可能なすべてのアイテムを表示するリストページを構築します。まず、次のコンポーネントを使用します。完成したページの外観と、このページを再現するための詳細な手順については、「リストページの構築」を参照してください。

コンポーネント:

  • テーブル - テーブルのソース、フィルターを定義し、列を定義して、テーブルを追加します。ページリンクアクションを追加できます。データの露出を制限するには、個人設定クエリを設定する必要があります。
  • テキスト入力 - データテーブル、列、値を指定することで、テキストソースを定義してユーザーが入力したページに読み込みます。このコンポーネントはオプションマークを付けることができます。フィールド幅は変更できます。検証規則は、最小または最大の長さやテキストパターンをベースにして構成し、ユーザー入力を識別できます。

詳細ページ

リストページを構築して、ワークフローで使用可能な1つのアイテムの詳細を表示します。まず、次のコンポーネントを使用します。完成したページの外観と、このページを再現するための完全な手順については、「詳細ページの構築」を参照してください。

コンポーネント:

  • テキスト - テキストソースと形式を定義して、キャッシュからページに読み込みます。
  • 戻るボタン - ユーザーが前のページに戻れるようにします。
  • 静的テキスト - 静的テキストを定義してページに表示します。
  • フレキシブルグリッド - ページ上のコンポーネントの配置をより詳細に制御できます。大画面を備えるデバイス向けにページを設計する場合に便利です。ラベルと、グリッドに含めるセルの総数を設定します。
  • テーブル - テーブルのソース、フィルターを定義し、列を定義して、テーブルを追加します。ページリンクアクションを追加できます。ユーザーのメールをベースにした個人設定クエリを設定して、データの露出を制限することができます。

ページの作成

作成ページを構築して、ワークフローにアイテムを追加します。まず、次のコンポーネントを使用します。完成したページの外観と、このページを再現するための完全な手順については、「作成ページの構築」を参照してください。

コンポーネント:

  • 静的テキスト - 静的テキストを定義してページに表示します。
  • フレキシブルグリッド - ページ上のコンポーネントの配置をより詳細に制御できます。大画面を備えるデバイス向けにページを設計する場合に便利です。グリッドアイテムで構成します。ラベルと、グリッドに含めるセルの総数を設定します。
  • テキスト入力 - データテーブル、列、値を指定することで、テキストソースを定義してユーザーが入力したページに読み込みます。このコンポーネントはオプションマークを付けることができます。フィールド幅は変更できます。検証規則は、最小または最大の長さやテキストパターンをベースにして構成し、ユーザー入力を識別できます。
  • 選択 - ユーザーが値の一覧から選択できるようにします。ソースシステムからデータが入力されるか、値の一覧を手動で入力できます。アクションを追加することができます。
  • 検索 - ユーザーが大量の値を検索できるようにし、何かを検索して値を選択できるようにします。
  • ボタン - クリックして使用する、アクションと論理が含まれたコンポーネントをページに追加します。

そのほかの参照先

ビデオ:マイクロアプリの概要にあるCitrix Workspace Intelligenceとマイクロアプリサービスの概要を確認してください。

ビデオ:マイクロアプリのカスタム統合でカスタム統合とマイクロアプリの作成について学習してください。

テストインスタンスの取得について詳しくは、Citrix Workspace開発者ポータルで確認してください。

RSSマイクロアプリ:Citrixセキュリティ情報がある場合に通知を受け取ります。にセットアップのためのクイックガイドがあります。

マイクロアプリディスカッションフォーラムにアクセスしてください。