予約した人のために会議室のドアを開ける
会議室のドアでは誰も何も読み取りません。入退室管理側が、誰がいつその部屋を 予約したのかを事前に知っている必要があります。各人のカード番号を保存し、 予約の変更を購読して、ドアの権限に変換します。
ロビーのゲートと会議室のドアは、同じ問題ではありません。ゲートでは来訪者がバッジをかざし、リーダーがそれで良いかを Offision に尋ねます — Offision の来訪者バッジでゲートを開けるを参照。会議室のドアでは誰も何も読み取りません。毎日持ち歩いている社員証のまま人が歩いてきて、ドアの側が「この人がこの時間この部屋を予約している」と既に知っている必要があります。
ですから流れは逆向きです。Offision が予約を事前にそちらのシステムへ伝え、そちらが誰かが着く前に権限へ変換します。
1. 各人のカード番号を保存する
社員証の番号を、アクセスカードの設定 呼び出しで Offision のユーザーに紐づけます
(UserCard、UserCard2、UserCard3 があり、1 人が複数枚を持てます)。カードが返却されたら アクセスカードの削除 で消します。
これをしないとドアは誰にも開きません。予約は人を指し、ドアはカードを読むので、両者をつなぐのはカード番号だけだからです。同じ番号は管理コンソールから手で発行・インポートすることもできます — アクセスカードの仕組み を参照してください。
2. 予約の変更を購読する
リソース予約の購読を登録し、コールバック URL と対象のリソースを渡します。そのリソースの予約が作成・移動・取り消しされると、Offision がその URL へ POST します。
3. コールバックを権限に変換する
コールバックごとに、予約可能リソースの ID をそちらが制御するドアに突き合わせ、主催者と参加者を読み取り、そのカード番号をその時間帯の権限に変換します。
そして、そちら側が再接続するたびにリソース予約の照会でその日を読み直してください。コールバックは合図、照会が真実です — 取りこぼしたコールバックはそれ以外の方法では見えず、変更を知らされなくなったドアは、正常に動いているドアとまったく同じに見えます。
4. ドアがカードではなくコードを受け付ける場合
予約可能リソースのアクセスキーがもう一つの道です。ルームのワンタイム・日次・固定のキーを読み取り、日次とワンタイムのキーを購読すれば、更新されるたびに新しいものが届きます。
5. 動作を確認する
- 自分でその部屋を予約し、開始時刻ではなく、その前に権限がそちら側に現れたことを確認します。
- 予約を 1 時間ずらし、権限も一緒に動いたことを確認します。
- 取り消し、権限が取り下げられたことを確認します。ここが飛ばされがちで、そして部屋を持っていない人にドアが開いたままになるのはここです。
- 参加者を追加し、その人もドアを開けられることを確認します。
うまくいかないとき
| 症状 | よくある原因 |
|---|---|
| コールバックが 1 時間で止まる | 購読の期限切れ。既定 60 分、最長 1 日で、更新が必要 |
| ドアが主催者には開くが参加者には開かない | ユーザーにカード番号が保存されているのが主催者だけ |
| 通信が切れたあと権限がずれていく | 再接続時にその日を読み直していない。取りこぼしたコールバックはエラーを出さない |
| すべての呼び出しが 403 を返す | 資格情報に user.readwrite か bookableResource.read が足りない |

