トピック 3、電子請求書発行
ケーススタディ
概要
これはケーススタディです。ケーススタディは個別に時間が設定されるわけではありません。各ケースを完了したいだけ試験時間を費やすことができます。ただし、この試験には追加のケーススタディやセクションが存在する場合があります。この試験に含まれるすべての質問を指定された時間内に完了できるように時間を管理する必要があります。
ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれる場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に回答する前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じです。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
既存の環境
アプリケーションアーキテクチャ
電子請求書発行は、シングルページ アプリケーション (SPA) と、請求書の管理および処理機能を提供するバックエンド Web サービスで構成されます。
電子請求では、各請求操作の詳細がすべてバックエンドのクラウド データベースに保存されます。電子請求書では、PDF 形式で請求書が生成され、生成後にユーザーはその PDF を OneDrive からダウンロードできるようになります。各請求書には、invoiceid という一意の識別子があります。
ユーザーには、電子請求書にサインインし、Web ブラウザーの複数のタブで電子請求書を開くという共通のワークフローがあり、アプリケーションのさまざまな部分を同時に使用できます。
セキュリティアーキテクチャ
A: Datum では、可能な限り最小特権の原則を使用します。A. Datum は常に最新のライブラリと統合エンドポイントを使用します。
要件
ビジネス目標
A: Datum は電子請求書発行を統合したいと考えています。Microsoft ID プラットフォームと Microsoft Graph により、顧客は電子請求書発行内から直接 Microsoft 365 サービスを利用できるようになります。
計画された変更
A: Datum は、電子請求書発行に次の機能を追加する予定です。
* 現在サインインしているユーザーに代わって、生成された請求書を顧客に電子メールで送信します。システムによって生成される電子メールには、請求書 ID が含まれます。
※ 電子請求書発行アプリケーションを終了せずに、ブラウザ上で可能な限り多くの操作を実行してください。
* Microsoft ID プラットフォームを使用して ID、認証、認可を管理します。
* 特定の請求書 ID を含むすべてのメールを表示します。
技術的要件
A: Datum では、予定されている電子請求機能について次の技術要件を特定しています。
* Microsoft 365 に対して電子請求書発行によって実行されるすべての操作がユーザーによって開始されていることを確認します。アプリケーションがユーザーに代わって Microsoft 365 データに初めてアクセスしようとするときに、電子請求書による Microsoft 365 データへのアクセスをユーザーが承認することを要求します。
* 支払い期日の前に、スケジュールされたリマインダーを顧客に送信します。管理ユーザー インターフェイスを作成して、スケジュールされたリマインダーを有効にします。
* Microsoft Graph 変更通知を実装して、指定されたメールボックスに到着するベンダーからの電子メールを検出します。
* シングル サインオン (SSO) を実装し、ブラウザーのタブ間でのログイン プロンプトを最小限に抑えます。
* Microsoft ID プラットフォームを使用して、バックエンド Web サービスへの安全なアクセスを実現します。
* すべてのソリューションで安全なコーディング手法が使用されていることを確認します。
バックエンドセキュリティの計画された変更
A: Datum は、カスタム アプリケーション ロールを使用して、ユーザーの機能をユーザーに付与された権限にマッピングしたいと考えています。
電子請求書には、ユーザーにバックエンド API の呼び出しを許可するかどうかを動的に識別する内部ロジックがあります。
SSO JavaScript スクリプト
次のコードを使用して、Microsoft Authentication Library (MSAL) で SSO を実装する予定です。

アクセストークンJavaScriptスクリプト
アクセス トークンを取得するには、次の JavaScript コードがあります。

変更通知 JSON
ベンダーの電子メールを検出するために Microsoft Graph サービスによって送信される次の JSON メッセージがあります。

説明
グラフィカル ユーザー インターフェイス、テキスト、アプリケーションの説明が自動生成される

ボックス 1: $count
次の例のように、$count をクエリ パラメーターとして使用して、グラフから返されたデータ値のページと一緒にコレクション内の項目の合計数を含めます。
GET https://graph.microsoft.com/v1.0/me/contacts?$count=true
ボックス 2: $select
グラフによって提供されるデフォルトのセットとは異なるプロパティのセットを返すように指定するには、$select クエリ オプションを使用します。$select オプションを使用すると、返されるデフォルト セットのサブセットまたはスーパーセットを選択できます。
ボックス 3: $filter
一連の基準に基づいて応答データをフィルタリングするには、$filter クエリ オプションを使用します。
次の例では、from プロパティのアドレス フィールドが次のメッセージに等しいメッセージを返します。
"[email protected]"。
from プロパティは、複合型の emailAddress です。
GET https://graph.microsoft.com/v1.0/me/messages?$filter=from/emailAddress/address eq '[email protected]' 参照: https://developer.microsoft.com/en-us /グラフ/ドキュメント/概要/クエリパラメータ

Microsoft Teams アプリのアプリ マニフェストでは、最大 10 個の異なるコマンドを含む単一のメッセージング拡張機能を定義します。各コマンドは、タイプ (アクションまたは検索) と、コマンドを呼び出すことができるクライアント内の場所 (メッセージ作成領域、コマンド バー、および/またはメッセージ) を定義します。
参照: https://docs.microsoft.com/en-us/microsoftteams/platform/messaging-extensions/what-are-messaging-extensions