共通ドキュメント

開発ガイドライン

 

開発ガイドラインについて

MobileSUITE mBaaS機能を、より上手くご活用頂けるように、ご利用の際のガイドラインをまとめました。

APIについて

 項目            内容   
レスポンスタイムの保証      レスポンスタイムの保証はございません。
パフォーマンスが出ない場合はリクエスト内容の見直しや、対象クラスの保持オブジェクトの数やサイズの見直し、追加インデックス(有償オプション)の利用などをお客様にてご検討ください。 
レスポンスの保証      100%の保証は行っておりませんので、アプリ側で適切なエラーハンドリングとリトライを実装してください。
エラーについては[REST API リファレンス > エラーコード一覧]をご覧ください。 
タイムアウト時間 APIのタイムアウト時間は公開しておりません。
同時接続数制限 MobileSUITE mBaaS機能では同時接続数に制限を設けておりますが、制限数の公開はしておりません。
サポートしているSSL/TLSのバージョン      現状 (2020/06/30時点)
・SSLv1, v2, v3、TLSv1.0, v1.1 使用不可
・TLSv1.2 使用可
複数件処理について MobileSUITE mBaaS機能では複数オブジェクト更新APIは提供しておりません。

内部データベースについて
(データストア/会員管理/プッシュ通知等共通)

 項目            内容   
オブジェクトサイズの制限      システム制限:16MB
登録可能なサイズ上限の目安:10MB程度
巨大なオブジェクトに対して更新処理を行うと高負荷が発生する恐れがあるので実施を控えるよう推奨いたします。  
オブジェクト数の制限      システム制限:なし
ただし、多数のオブジェクトを登録すると更新や検索における性能劣化が予想されます。
そのため、1クラスあたり数十万件程度のオブジェクト数に抑えることを推奨いたします。

※なお、データ構造・検索条件によっては、推奨値であっても性能劣化となることがございます。
性能向上のために、下記のような対策もご検討ください。
  1)定期的なデータのバックアップのうえ、不要データを削除していただく
  2)日時でクラスを分けるなど、複数クラスへのデータ分散を実施していただく
データのバックアップについては、弊社にてデータストアからのエクスポートを実施することも可能ですので、ご相談ください。
フィールドサイズの制限 フィールドのサイズ・文字数には制限はございません。
※各フィールドサイズの合計が、オブジェクトサイズの制限(16MB)を超えないようご注意ください。
インデックスが無いフィールドでのソート制限      システム制限:ワーキングメモリ32MB以下
内部データベース上でのソート処理で使用するメモリが32MBを超えた場合、ソートができませんので、インデックス機能のご利用をご検討ください。
登録および更新後、参照に反映されるまでの時間 内部データベースはレプリケーション構成を採っているため、登録/更新後すべてのデータベースに反映される時間にはタイムラグが存在します。
また、更新中のオブジェクトを参照した場合は、更新前の値を返却します。
更新失敗時の挙動について 基本的にエラーが返却された際は、データの更新は行われておりません。(データは更新前の状態でございます。)
但し、SDKのタイムアウト発生時や、バックエンドの過負荷、インフラ側のトラブル等が重なった場合などは上記の限りではなく、必ずしもデータのロールバックを保証するものではございません。予めご了承ください。
objectIDについて objectIDはクラス内で一意性を保っておりますので、クラス間・アプリケーション間では同一のobjectIDが存在する可能性がございます。

なお、自動生成されるobjectIDの桁数は、最大16桁・最小1桁です。
※生成処理上、稀に桁数の少ないIDが生成されることがございます。
また、フォーマットは「0~9,a~z,A~Z」を含む文字列です。

検索クエリについて

 項目            内容   
$relatedTo     $relatedToで検索した際に、参照先オブジェクトが存在しないポインタが対象に含まれた場合はそのポインタが無視されるだけなので、そのリレーションにポインタが100件登録されているにも関わらずlimit=10で検索した際に8件しか返却されないことなどが発生します。 
include     1つだけ指定する利用方法を想定しています。
カンマ区切りで複数指定することも可能ですが、前に指定されたものから順に検査され最初に置き換えができたものだけが子要素に置き換えられます。2つ以上指定した場合に1つ目が正常に子要素に置き換えられると、2つ目はポインタのまま返却されます。 
order     orderを指定しない場合の並び順は「natural order」であり、DB上のデータ並び順に従います。
更新等の書き換え処理によって順番が変わることがあるため順序の保証はありません。
内部データベースの制限事項にもある通り、ソート処理には制限事項があるためインデックスのあるフィールドをorderに指定することを推奨します。 
limit     0-1000を指定できます。
limit&skip     skipの分だけ読み飛ばして、limit分を返却するため、skipが大きくなるに従ってパフォーマンスが劣化します。 

リレーション型について

 項目            内容   
データ保持形式       リレーションは「ポインタの配列」としてオブジェクト内に保持されるため、巨大なリレーションを作成すると、それを保持するオブジェクトも巨大化します。  
参照先オブジェクトが削除された場合のリレーション型の挙動       リレーション型の参照先オブジェクトが削除されても、リレーション型内部の当該オブジェクトへの参照ポインタは削除されません。  

ACLについて

 項目            内容   
共通仕様(会員管理を除く)       許可されている人/ロールを列挙する(deny/allow)
明示的に全体(public=*)への許可を設定することもできます。
誰も登録されていない場合は全許可とみなされます。
拒否する人/ロールを設定することはできません。
会員管理特有の仕様      共通仕様に準じるが、「誰も登録されていない場合は本人のみ許可」となります。  

プッシュ通知について

 項目            内容   
配信の品質保証       配信処理はベストエフォートであり端末への到達を完全に保証するものではありません。  
配信の責任範囲       MobileSUITE mBaaS機能ではAPNs(Apple Push Notification services)とFCM(Firebase Cloud Messaging)を使用してプッシュ通知を実現しております。MobileSUITE mBaaS機能からAPNs/FCMへ通知の配信依頼が完了した時点で「配信済み」となります。APNs/FCMへの配信依頼完了以降、端末への通知到達まではAPNs/FCMの責任範囲となり富士通は一切の責任を負いません。
内部システム 大量のプッシュ通知配信処理を短時間に処理するため、システムは非同期(ジョブキュー)かつ並列で構成されています。
非同期かつ並列なシステム構成のためステータス(配信中、等)の変更に時間がかかることがあります。
配信速度 ベストエフォートであり配信速度の保証はありません。お客様の用途に適するか、事前検証をお願いいたします。
配信速度目安 iOS/Android両OSともに、数十万端末であれば数分程度で配信処理は完了いたします。なお、こちらはあくまで目安であり、その速度を保証するものではございません。

※MobileSUITE mBaaS機能からAPNs/FCMへプッシュ通知配信依頼が完了することを、配信処理の完了と定義しています。実際に端末にプッシュ通知が届くことではございません。
※配信遅延が見られる場合は、"配信遅延"をご参考ください。
配信遅延 配信遅延が発生した場合、下記要因が考えられます。
・MobileSUITE mBaaS機能 障害による影響(障害発生有無については、お問い合わせください)
・他ユーザー様の負荷影響(共通PF上、他ユーザー様の影響を受ける場合がございます)
・絞り込み配信による遅延(絞り込み条件やinstallationクラス内のデータ数によっては検索に時間を要する場合がございます)
・APNs/FCM側での遅延発生(MobileSUITE mBaaS機能側でプッシュ通知配信依頼完了後に、APNs/FCM側で遅延が発生する場合がございます)
配信可能端末数 1つのプッシュ通知登録リクエストにて登録可能な配信端末数については、"内部データベースについて>フィールドサイズの制限" 同様特に制限はございません。
※プッシュ通知を登録した際、登録したプッシュ通知情報は内部データベースに1オブジェクトとして登録されます。配信端末を含めた各項目の合計サイズが、オブジェクトサイズの制限(16MB)を超えないようご注意ください。
即時配信 即時配信は、「プッシュ通知の登録時刻を配信時刻として設定した予約配信」です。順次キューへの登録が行われます。登録と同時に配信されるわけではありませんのでご注意ください。
配信のキャンセル プッシュ通知配信システムの保全および性能確保のため、一定の条件下においてプッシュ通知の配信がキャンセルされることがあります。
キャンセルされたプッシュ通知は、キャンセルされた時点で配信処理が停止し、その時点で未配信の端末への配信処理は行われません。
配信キャンセルとなる条件は事前の告知なく変更されることがあります。

■配信がキャンセルされる条件(例)
プッシュ通知の配信においてinvalidTokenエラーが頻発した際にキャンセルされることがあります
  理由(1)→invalidTokenエラーが発生した場合、APNsとのコネクションが切断され再接続処理が行われます。配信処理においてAPNsとの接続処理が最もコストが高い処理です。再接続が頻発すると配信システムの品質低下を招き、配信遅延などを引き起こすため、配信処理をキャンセルします。
  理由(2)→invalidTokenエラーが短期間に頻発した場合、APNsへ短期間に大量の不正トークン利用および再接続処理が発生します。APNsに対する攻撃と受け取られる可能性があるため配信処理をキャンセルします。
APNs特有の注意事項
(invalidTokenエラーについて)
APNsにはDebugビルド用のSandbox環境と、AdHocビルドおよびAppStoreビルド用のProduction環境の2つの配信システムが存在し、MobileSUITE mBaaS機能ではダッシュボードにて設定頂いたAPNs証明書の種類によって使用するAPNsのシステムを決定しています。Sandbox証明書の場合はSandbox環境へ、Sandbox&Production証明書の場合はProduction環境へ接続します。
APNsではdebugビルドのアプリで取得されたデバイストークンはSandbox環境でのみ、AdHoビルドおよびAppStoreビルドのアプリで取得されたデバイストークンはProduction環境でのみ有効であり、異なる組み合わせの場合は不正なデバイストークンとしてinvalidTokenエラーが発生いたします。(例:Debugビルドで取得したデバイストークンを使ってAPNsのProduction環境に配信依頼をする)

■invalidTokenエラーの回避方法(例)
・MobileSUITE mBaaS機能上のアプリを2つ(development/production)作成し、ビルドタイプに応じて使い分けることでinstallationクラスにSandbox/Productionのデバイストークンが混在することを予防することができます。
FCM特有の注意事項
(カノニカルIDの扱いについて)
・「アプリケーションのアップデート」や「アプリケーションの再インストール」などに起因して、同じデバイスに対してFCMサーバが複数のRegistration ID(デバイストークン)を割り振る場合があります。このとき、FCMサーバーが正規のIDと認識しているデバイストークンがカノニカルIDと呼ばれています。

・同じデバイスに対して複数のデバイストークンが払い出された場合、FCMの仕様上、払い出されたデバイストークンの全てで正常にプッシュ通知が届きます。このため、同じデバイスを示す複数のデバイストークン宛にプッシュ通知を配信すると、重複受信が発生します。
なお、カノニカルID以外のデバイストークン宛にプッシュ通知を配信した場合、FCMはフィードバックとしてカノニカルIDへの更新依頼を返却します。

・MobileSUITE mBaaS機能ではこの依頼に従い、対象のデバイストークンを持つinstallationのdeviceTokenフィールドをカノニカルIDへ更新します。ただし、installationクラスのdeviceTokenフィールドはユニーク制約が課されているため、カノニカルIDが既に別のinstallationとして登録されている場合は更新に失敗します。この場合、対象のデバイストークンを持つinstallationを削除することで対応します。
アプリがアンインストールされた端末情報(installation)の自動削除 MobileSUITE mBaaS機能はAPNs/FCMより、アプリ利用者がアプリを端末からアンインストールした等の理由により配信先が喪失したという内容の情報を受け取った場合、MobileSUITE mBaaS機能では対象の端末情報(installation)を自動で削除致します。
・APNsの場合はFeedbackサービスを使用した際に受領した情報に従い対処します
・FCMの場合は配信依頼時のレスポンスとして返却されたNotRegisteredエラーに従い対処します。
配信済みのプッシュ通知オブジェクトについて プッシュ通知の配信に伴い、配信済みのプッシュ通知オブジェクトが累積いたします。
こちらはプッシュ通知の登録ごとに作成されますので、個通のプッシュ通知を多用されるなど、プッシュ通知登録数が多い場合につきましては、オブジェクトの容量肥大が考えられます。
容量が肥大しますと、プッシュ通知の配信パフォーマンス低下やストレージ容量の逼迫に繋がりますので、定期的にお客様にて削除頂くことを推奨いたします。
※内部データベースのオブジェクト数の制限と同様に、数十万件程度のオブジェクト数に押さえることを推奨いたします。
なお、プッシュ通知開封率は配信済みオブジェクトを元データとし表記する為、オブジェクトを削除しますと開封率の確認が不可となりますこと、ご了承ください。

※ FCMはGCM(Google Cloud Messaging)の新バージョンです。GCMは2019年3月中に使用不可となります。GCM対応のプッシュ通知を使用しているお客様はMobileSUITEが提供する移行手順を参考に、FCM対応したプッシュ通知への移行をお願いいたします。

ファイルストアについて

 項目            内容   
CDNとしてのご利用について MobileSUITE mBaaS機能のファイルストア機能はCDNではないため、これを用いた大規模なコンテンツ配信などには適しません。
十分な帯域は準備しておりますが、過度な帯域の専有が確認された場合は利用規約に則り対応いたします。  

SDKについて

 項目            内容   
ライセンス      Apache License, Version 2.0 です。
SDKに同梱されているライセンスが上記と異なる場合は、SDKに同梱されているライセンスを優先します。 
タイムアウト時間 SDKのタイムアウト時間は10秒です。