アプリと書籍の MDM 配布を改善する

ハイライト

新しい Apps and Books Management API では、リアルタイム通知と非同期処理が導入され、250,000 件のアプリ割り当てに必要なリクエスト数を最低 25,000 件からわずか 10 件まで削減できます。1 回のリクエストで最大 25 個のアプリを 1,000 台のデバイスに割り当てられ、割り当てステータスは通知で配信されます。

主要内容

企業や教育機関におけるアプリ配布の管理は、常にスケールの課題を抱えています。10,000 人の生徒がいる学校で、各生徒が 1 台のデバイスを使い、25 個の主要アプリを配布する場合、合計 250,000 件の割り当てが必要です。従来の API は 1 リクエストにつき 1 アプリを最大 10 台のデバイスにしか割り当てられず、少なくとも 25,000 件の HTTP リクエストが必要でした。

WWDC2021 で導入された Apps and Books Management API の新バージョンは、2 つの主要な改善でこの問題を解決します。リアルタイム通知によって継続的なポーリングが不要になり、非同期処理によってサーバー側で割り当て操作を並列実行できるようになります。同じ 250,000 件の割り当てに必要なリクエスト数は、わずか 10 件になります。

詳細

リアルタイム通知タイプ

API の新しいバージョンは 4 つの通知タイプをサポートしており、クライアント設定の sToken によって個別にサブスクライブする必要があります (01:20)。

資産管理に関する通知

アソシエート (割り当て)、関連付け解除 (割り当て解除)、取り消し (リボーク) など、割り当てステータスが変化したときにイベントが発火します (01:44)。

{
  "notification": {
    "assignments": [
      {
        "adamId": "408709785",
        "pricingParam": "STDQ",
        "serialNumber": "C02Y402HLCM6"
      }
    ],
    "eventId": "87cbc650-16cc-4f9e-a833-e622f377a9f7",
    "result": "SUCCESS",
    "type": "ASSOCIATE"
  },
  "notificationType": "ASSET_MANAGEMENT",
  "uId": "2049025000431439"
}

通知を受信したら、すべてのバッチ操作が完了するのを待たずに、対応するデバイスにインストールコマンドを送信できます。

アセット数の通知

購入、転送、または払い戻しの結果としてアプリの数量が変更されるとトリガーされます (03:37):

{
  "notification": {
    "adamId": "408709785",
    "countDelta": 50,
    "pricingParam": "STDQ"
  },
  "notificationType": "ASSET_COUNT",
  "uId": "2049025000431439"
}

countDelta の正の値は購入または移管を、負の値は返金または移管を表します。MDM は同期エンドポイントを呼び出さず、この差分でローカルの数量を直接更新できます。

ユーザー管理通知

作成、更新、および引退イベントを含む、登録済みユーザーのステータスが変更されるとトリガーされます (05:34):

{
  "notification": {
    "users": [
      {
        "clientUserId": "client-100",
        "idHash": "leSKk3IaE2vk2KLmv2k3/200D3=",
        "status": "Associated"
      }
    ],
    "eventId": "e0def1f8-9158-4343-9c52-8dd32da50b9b",
    "result": "SUCCESS",
    "type": "UPDATE"
  },
  "notificationType": "USER_MANAGEMENT"
}

ユーザー関連の通知

ユーザーが招待を受け入れ、個人の Apple ID を登録済みアカウントに関連付けるときにトリガーされます (08:33):

{
  "notification": {
    "associatedUsers": [
      {
        "clientUserId": "client-100",
        "idHash": "leSKk3IaE2vk2KLmv2k3/200D3=",
        "inviteCode": "f551b37da07146628e8dcbe0111f0364",
        "status": "Associated"
      }
    ]
  },
  "notificationType": "USER_ASSOCIATED"
}

通知サブスクリプションの構成

クライアント設定で通知受信を設定します (09:00):

notificationAuthToken: 通知の Authorization ヘッダーで Apple によって使用される共有シークレット
notificationUrl: 通知を受信する HTTPS エンドポイント

通知の受信後に HTTP 200 が返された場合は、配信が成功したことを示します。 200 以外の応答またはタイムアウトの場合、Apple は数回再試行します (ベストエフォート)。通知を長期間受信できない場合は、期限切れの可能性があるステータスについてポーリングと同期を実行する必要があります。

非同期処理

従来の API のすべての操作は同期的でした。リクエストを送信し、Apple が割り当てを完了するまで待ってからレスポンスを返していました (10:07)。新しいバージョンでは非同期処理に変わっています。

古いバージョンのプロセス:
リクエスト→Apple Sync実行配信→結果返却（一度に最大10台×1アプリ）

新版流程：
リクエスト → Apple が即時にeventIdを返す → バックグラウンドでの非同期処理 → 通知を通じて結果をプッシュ
（最大1,000台×同時25アプリ）

非同期処理の利点 (10:25):

処理速度を最適化するためにサーバー側で強制並列処理
秩序ある処理により、断続的な失敗と再試行が減少します。
大規模な導入の信頼性が向上し、教育機関が新学期中に導入しやすくなります。

実例比較: 250,000 件の割り当て

10,000 ユーザー × 25 アプリケーションのシナリオを例に挙げます (11:08):

メトリクス	古い API	新しい API
単一リクエストの処理能力	1アプリケーション×10台	25 アプリケーション × 1,000 デバイス
リクエストの最小数	25,000	10
応答モード	同期待ち	すぐにeventIdを返す
結果取得	レスポンスボディから直接取得	通知プッシュまたはクエリイベントステータスエンドポイント

リクエスト形式の変更

新しい API は、バージョン管理された URI と正しい HTTP メソッドを使用します (04:34)。すべてのリクエストは、Authorization ヘッダーにベアラートークン形式で sToken を運びます。

Authorization: Bearer <sToken>

アセットのステータスを取得します (GET リクエスト):

GET /v1/assets?adamId=408709785&pricingParam=STDQ

応答には、ページネーション情報とアセット数が含まれます。

{
  "assets": [
    {
      "adamId": "408709785",
      "pricingParam": "STDQ",
      "assignedCount": 5000,
      "availableCount": 10000,
      "totalCount": 15000
    }
  ],
  "currentPageIndex": 0,
  "size": 1,
  "totalPages": 1
}

リクエストを投稿:

// 请求
{
  "assets": [
    { "adamId": "361309726", "pricingParam": "STDQ" }
  ],
  "serialNumbers": [
    "serial-1", "serial-2", ..., "serial-1000"
  ]
}

// 响应
{
  "eventId": "92467a8e-8a50-4df9-9b30-f7ff4a99dea7",
  "tokenExpirationDate": "2021-07-06T14:12:10+0000"
}

秩序ある処理

新しい API により、同じイベント内の操作が送信された順序 (13:49) で実行されることが保証されます。たとえば、再配布: 最初に関連付け解除リクエストを送信してeventId1を取得し、次に関連付けリクエストを送信してeventId2を取得します。 Apple は、eventId2 の操作を開始する前に、eventId1 のすべての操作が完了していることを確認します。

Sync API のバージョン識別

すべての同期 API 応答には次のものが含まれますversionId(07:28)、基礎となるデータが書き込まれると変更されます。多数のページ分割された応答を走査する場合、versionId を使用して、前のページのデータが変更されたかどうかを検出できます。

重要ポイント

新しいバージョンの API にすぐに移行します: 古いバージョンの API は引き続きサポートされますが、同じ sToken の古いバージョンと新しいバージョンを混在させることは正式にサポートされていません。新しい API の非同期処理とバッチ機能が前進する唯一の方法です。
展開通知受信エンドポイント: 構成notificationUrlそしてnotificationAuthToken、4 つの通知タイプすべてを購読します。これは、ポーリングを排除し、リアルタイムの状態同期を可能にする鍵となります。
バッチリクエストを使用して呼び出し数を削減します: 1 回のリクエストで最大 25 アプリケーション × 1,000 デバイス。リクエストの数を最小限に抑えるためにバッチを合理的に編成および配布します。
eventId で非同期操作を追跡する: 割り当てリクエストを送信したら、返された eventId を記録し、通知またはイベントステータスエンドポイントで進行状況を追跡します。通知の受信に失敗した場合も、eventId があれば補完できます。
通知配信失敗の処理: Apple の通知はベストエフォート配信です。サービスが利用できず、通知が失われた場合は、完全同期ではなく、期限切れの可能性があるステータスを対象としたポーリングを実行します。

アプリと書籍の MDM 配布の改善