私たちは最新のファストトラック版Nuxeo Platform FT 9.1をリリースしたばかりで、弊社のウェブサイト上で ダウンロードすることができます。このリリースでは、デジタル資産の価値を最大限に高めるために、プラットフォームに強力な新機能と拡張機能が追加されています。このリリースの特色は次のとおりです。
- MongoDBの完全なサポート：つまり、MongoDBをリポジトリデータベースとして使用するときに、追加のRDBMSが不要になります。
- 検索機能の向上：検索結果を強調表示することで検索の利便性を向上させるAPIを追加しました。この機能は、年内にWeb UIによって活用されます。
- Elasticsearchのセキュリティ：Elasticsearch Shieldを使用してElasticsearchサーバを保護できるようになりました。
しかし、FT 9.1の最も注目すべき機能は、ポリシーベースのバージョン管理です。この新機能によって、文書のバージョン管理が自動的に行われるため、文書のバージョン管理が必要かどうかや、文書の状態変更が必要かどうかをユーザが判断しなくても済みます。この機能を詳しく見てみましょう。
集中型自動リリースポリシー
FT 9.1では、ドキュメントのタイプ、プロパティ、およびユーザのプロパティに応じて、ドキュメントのバージョン管理動作を決定するルールを提供できます。これらのルールは、ドキュメントの変更に使用されるすべてのインタフェースに適用されます。API、Web UI、ドライブ、JSFアプリケーション、デフォルトのオートメーション操作、カスタムコードなどがあります。たとえば、次のようなシナリオのルールを作成できます：「ケースレポートが変更されるたびに、変更を含むバージョンがマイナーアップグレードで作成される」または「管理者以外のユーザが文書を更新するたびに、バージョンが作成される」。また、「『外部契約者』グループの誰かが変更を行った場合、仕様書を体系的にバージョン管理する必要がある」などが考えられます。
拡張ポイントを使用した貢献
ルールは、バージョン管理サービスの「ポリシー」拡張ポイントに貢献します。
<policy id="note-as-wiki" beforeupdate="true" increment="MINOR" order="50"><filter-id>note-filter</filter-id></policy>
「BeforeUpdate」は、変更の前か後かのバージョンを決定します。「increment」は、NONE、MAJOR、またはMINORになり、更新しなければならないバージョン番号を定義します。「order」は、いくつかのルールが適用されるときに使用され、ポリシーを考慮する必要がある順番（昇順で考慮される）を定義します。「filter」部分は、ドキュメントをバージョン管理すべき条件を定義します。
詳細は、バージョン管理マニュアルと拡張ポイント文書をご覧ください。
コラボレーションとWikiスタイルのスキーム
デフォルトでは、以下の自動バージョン管理スキームがプラットフォームに追加されています。
共同保存：誰かが作成または更新した資産を別の人が更新するたびに、変更前にその資産のバージョンを作成して、誤って情報が失われるのを防ぎます。（前提条件として、文書にファイルスキーマが必要です）。
wikiとして注記：注記書類タイプの場合、各保存アクションの後にバージョンが作成されます。
一貫性の強化
バージョン管理の一貫性を維持するために、この進化を優先させました。一部のお客様で、ドライブのバージョン管理動作とユーザインタフェースのドラッグ＆ドロップのバージョン管理動作が異なる事象が見られていました。これらのインタフェースにはそれぞれ、バージョン管理用に実装した異なる最適のアイデアが含まれていましたが、その動作を標準化して定義を中央管理するほうが合理的です。
この新しい動作がお気に召さない場合は、互換性のソリューションが用意されています。旧式の構成もプラットフォームによって検討されており、可能な限りシームレスに移行できることを確認しました。また、これはファストトラック版なので、次の長期サポート版をリリースする前に、皆様のフィードバックを得て改善する時間が十分にあります。