今回の注目点
今回は新機能というより不具合修正とブラッシュアップというのでしょうか。
今回の施策でさらに高速で動作するグループカレンダーとして機能向上を行えました。
- Graph APIを利用したイベント同期とイベント同期エンジンの堅牢性の向上
- 繰り返しイベントの編集機能の親和性の向上
今回もイベント同期とイベント同期エンジンで堅牢性の向上
「イベント同期」機能と「イベント同期エンジン」機能は別の機能です
Ver.6.4.4でもご説明しましたが、イベント同期の機能とイベント同期エンジンの機能は別の機能です。
詳細はVer.6.4.4の章を参照してください。
今回も中心はGraph APIに関連するのですが、Graph APIだけのチューニングだけでなく、Graph APIのテナントとEWS APIのテナントが共存するOnTimeサーバーでの動きをブラッシュアップした感じです。
Graph APIに移行する際のファインチューニング
まずGraph方式に移行時のイベント同期とイベント同期エンジンのチューニングについてです。
方式切り換え時の移行手順の改善
同期方式を切り換えてアプリケーションの停止/実行した際に、全てのイベント情報の同期を行います。この同期は必須で、いわばインデックスをEWS系のIDからGraph系のIDに切り換え処理をするようなイメージです。方式を切り換えた際に、SQL上のイベントデータのテーブルをGraph用に一括更新する処理を行います。その処理が完了するまではリアルタイム処理を実施するイベント同期エンジンは実行されないようにしておかないと、一括更新の最中にもリアルタイムによる更新を行うという指示が出てしまうことになります。この手順をテナント毎に完全に排他的に実施されるようにしました。一括更新が完了すると、その最中の未処理の更新分はすぐに処理を行います。
イベント同期エンジンの起動確認手順の改善
イベント同期エンジンが正常起動しない場合に正常起動するまで様々な対応を自動で行っています。EWS方式の場合は殆どの原因が同一箇所（クラウド側のリージョン単位や全体的なインシデント関連）のためどのテナントも繋がらない状態で待機していました。しかし、Graph方式の場合はイベント同期エンジンの個別の設定が起因して動作しない可能性が出てきました。なので、Graph方式の1つのテナントで正常動作しない場合でも、1つのテナントに集中せずにその他のテナントでの正常動作も並行して続けれるようにロジックを整理しました。
EWS方式のテナントとの共存のためのファインチューニング
次にGraph方式のテナントとEWS方式のテナントが共存する際のチューニングについてです。
複数の方式で相互利用が続く前提のロジックに改善
OnTimeはマルチテナントに対応しており、各テナント毎にGraph方式とEWS方式を選択できるのはご存じの通りです。会議招待の出席者や代理権限、アクセス権などをそれぞれ方式毎に管理していました。しかし、組織によっては全テナントを一斉にGraph方式に切り換えできない場合もあることを認識しました。なので、GraphとEWSを跨いだマルチテナントに準拠してGraphに対応したIDに統一して運用することでEWSテナント単体動作のOnTimeでない場合の即応性を更に向上させました。
全てのテナントが同一方式で運用されない想定の会議招待対応に改善
不具合修正になるのですが、例えば、Graph方式テナントのユーザーがEWS方式のテナントに会議招待した際も、即応性のために各方式毎に処理を行っていたため、参加者が今回の場合EWS方式の際に処理が行われずイベント同期エンジンで同期されるのを待つ必要がありました。修正されています。
繰り返し予約(定期的なアイテム)の対応
Outlookの定期的なアイテムの設定画面が変わってます
ご存じのように新旧のOutlookで定期的なアイテムの設定画面が違っています。
以下に新しいOutlook、ブラウザのOutlook、いわゆるOutlookクラシックの画像を表示します。新しい方には反復回数は既に見当たらないですね。
各Outlookクライアントの画面
反復回数の設定がなくなった？
どうやら設定から反復回数がなくなっているようなのですが復活しないようです。そして反復回数で指定している場合の編集では、新しいOutlookでは終了日が未登録の状態になってしまうようです。
OnTimeの画面
ちなみにOnTimeの定期的なアイテム（繰り返し）の編集画面では「反復回数での指定」「指定した日時まで(終了日)」のどちらの指定も可能です。
詳細はクライアントマニュアルの該当ページを参照ください。
どちらのOutlookにももちろん対応
内部的なExchangeデータモデルには依然として「numbered recurrence」と「end date recurrence」の両方が存在しますのでOnTimeではどちらも対応しています。
今回はこの対応に加えタイムゾーンの未処理などの部分も含め十分な検証をおこないました。
リリースノート
