Caché 2015.2

DeepSee の改善

今回のリリースでは、DeepSee 機能に以下の改善が行われています。

ダッシュボード・エディタで以下の新しいコントロールを提供 :

• タイトル・バー : 色、不透明度、非表示/表示

• ツール・バー : 色、不透明度、非表示/表示

• ウィジェットの境界線 : 非表示/表示

• 凡例 : 色、不透明度

• ダッシュボードの背景 : イメージ、色、不透明度

今回のリリース以前では、リストはキューブの一部として定義する必要がありました。他のユーザが新しいリストを作成できるようにするには、そのユーザにキューブ定義編集用アクセスを提供して、キューブ定義内の項目の変更を可能にする必要がありました。

今回のリリースでは、キューブ定義へのアクセスを提供せずに、他のユーザに新しいリストの作成を許可することが可能になりました。リストは、グループのリストと呼ばれる新しいエンティティの一部にできます。 グループのリストは、1 つ以上のリストを含むクラスです。グループのリストは、DeepSee の [ツール] メニューの [スタジオ] または新しい [グループのリスト・マネージャ] を使用して編集できます。[グループのリスト・マネージャ] へのアクセスは、セキュリティ・リソースを使用して制御されます。 グループのリストの詳細は、DeepSee の資料を参照してください。

今回のリリースでは、現在のユーザへの影響を最小限に抑えつつキューブをアップグレードするための新しい機能が提供されています。

キューブ定義の変更には、キューブを再構築することが必要です。今回のリリース以前は、キューブの再構築の最初の手順として、既存のキューブを削除する必要がありました。 そのため、キューブの再構築中、キューブに対するクエリは禁止されていました。再構築が完了すると、キューブで再びクエリを実行できるようになりました。キューブのサイズと再構築の行われるタイミングによっては、ユーザが許容できないくらい長い時間キューブが使用できなくなる場合がありました。

今回のリリースでは、キューブのバージョンを定義するための新しいオプションの機能が提供されています。キューブのバージョンによって、既存のキューブは再構築の開始時に削除されなくなります。キューブの新しい (保留中の) バージョンを構築中、現在の (古い) バージョンのキューブでクエリを実行できます。新しいバージョンのキューブの構築が終了したら、保留中のキューブを現在のキューブにして古いキューブを削除するメソッドを実行します。

QR コードのサポート

QR (Quick Response) コードは、簡単に処理できる形式で情報を表示するための一般的なメカニズムとなっています。URL、名刺、設定情報、およびその他の短いセグメントに使用されます。今回のリリースの Caché では、アプリケーション開発者は %SYS.QRCodeOpens in a new tab クラスのメソッドを使用して独自の QR コードを生成できるようになりました。インターシステムズ社自体も、新しい 2要素のタイムベース・ワンタイム・パスワード (TOTP) の実装で QR コードを使用しています。

iKnow のための新しい iKnow 言語モデル : ロシア語およびウクライナ語

iKnow には、既にサポートされている言語 (英語、スペイン語、ポルトガル語、ドイツ語、オランダ語、およびフランス語) に加えて、ロシア語とウクライナ語の言語モデルが含まれるようになりました。また、語幹解析もサポートされるため、ロシア語やウクライナ語のような完全な大文字小文字システムを持つ言語では、エンティティの上の抽象化レベルとして語幹を処理できます。

iFind での複合検索文字列のサポート

フルテキスト検索に iFind を使用する場合、単一の検索文字列で複雑な条件を表現するために、括弧とブーリアン演算子 (AND、OR、および NOT) を使用して、複合検索文字列を送信できるようになりました。例えば、SQL で文字列 “(long strings) AND (memory OR disk*) AND NOT {error reference}” を search_index() メソッドに渡すと、“long strings” という単語の並びと、“memory” という単語または “disk” で始まる単語を含むすべてのレコードが返され、エンティティ “error reference” を含むレコードが除外されます。

iKnow および iFind のその他の改善

今回のリリースでは、iKnow および iFind において、構造化されていないデータを処理するうえでその他多数の改善および簡略化が行われました。その中には次の新機能も含まれます。

• iFind では、すべてのインデックス・レベルで語幹解析および複合語分解をサポートするようになりました。

• iKnow 言語モデルが指定されていないか利用できない場合、スペースを区切り文字として使用するすべての言語において、iFind 基本インデックスを定義およびクエリできるようになりました。

• iKnow および iFind の両方で、レコード内のエンティティの意味的優位性を計算するために改善されたアルゴリズムが利用され、これらのメトリックスを格納するためのディスク容量が少なくなります。

• 意味的属性の存在と範囲を特定する際にエンジンに含める必要のあるマーカ用語を指定することによって、属性検出 (否定、感情) をカスタマイズできます。

イスラム暦の日付のサポート

今回のリリースでは、Caché にイスラム暦Opens in a new tab (ヒジュラ暦) に従って表現された日付のサポートが追加されました。日付は、計算または観測システムに従って指定できます。どちらのシステムもサポートされます。ユーザは観測結果を判断および保存して、指定された月の長さを特定できます。この機能はアプリケーション開発者に提供されるだけでなく、DeepSee でもこの新機能を活用します。

データベース・キャッシングの内部最適化

今回のリリースでは、データベース・キャッシュの管理における実行時の競合を大幅に減らすことによって、大規模なマルチコア・システムでのデータベース参照のスケーラビリティが拡張されています。

グローバル・ベクトルの動的割り当て

今回のリリースでは、32 個以上の異なるグローバルに繰り返しアクセスするプロセスのグローバル参照のパフォーマンスが大幅に向上しました。パフォーマンスの向上は、プロセスが割り当てるグローバル・ベクトルの数の増加によってもたらされます。各グローバル・ベクトルには、最近プロセスがアクセスした異なるグローバルについての情報が含まれ、この情報はそのグローバルに対する次の参照を最適化するために使用されます。以前は、プロセスは 32 個のグローバル・ベクトルに限定されていました。これからは、必要に応じてプロセスは最大 1000 個のグローバル・ベクトルを動的に割り当てるようになります。詳細は、"アップグレード・チェックリスト" を参照してください。

ECP の並行処理の向上

今回のリリースでは、大規模なマルチコア ECP データ・サーバのスケーラビリティが拡張されました。サーバに行われた変更により、ECP クライアントに代わってデータベース・キャッシュを管理する際に関連する実行時の競合が軽減されました。

Power 8 暗号化ハードウェアの使用

IBM AIX® プラットフォーム上で実行すると、Caché は暗号化ハードウェアが存在するかどうかチェックします。存在する場合、暗号化されたデータを処理する際に新しい Power 8 インコア・オプションが使用され、パフォーマンスが最大化されます。ハードウェアが存在しない場合、Caché は以前のリリースの場合と同じようにソフトウェアで暗号化を実行します。

ホストの障害後の最新のデータベース・ブロックの高速認証

今回のリリースでは、Windows および UNIX® における Caché 起動時の追加の認証が導入され、ホストの障害後にリカバリでの物理データベースの矛盾をチェックできるようになりました。可用性に影響が及ばないよう、認証は制限された時間内で実行されます。通常の運用手順が変更されることはありません。矛盾が検出された場合、通常それはストレージ・デバイスの問題があることを示唆し、システムが不明な状態で実行することを防ぐため、起動ではユーザの介入を待機します。詳細は、"Caché データ整合性ガイド" の “WIJ ブロック比較” を参照してください。

ミラーリングの改善

このリリースの Caché では、以下のミラーリングのサポートと機能が改善されています。

• より迅速なフェイルオーバー

  自動ミラー・フェイルオーバーが完了する時間が改善されました。 改善は、プライマリのホストがクラッシュしたりネットワーク分離したイベントにおいて最も顕著です。 そのような状態になると、フェイルオーバー時間は約 15 秒短縮されます。 多くの環境では、これはフェイルオーバー時間の大部分を占めることになり、停止の検出から、新しいプライマリでデータベースが利用可能になるまでの時間が数秒にまで短縮されます。

• SSL/TLS を使用した新しいメンバの認証の単純化

  SSL を使用した非同期ミラー・メンバは、メンバシップの認証のために手動で識別名を入力する必要がなくなりました。 その代わりに、2 番目のフェイルオーバー・メンバが追加されるのと同じ方法でミラーに追加されるようになります。つまり、管理者が新しい非同期メンバをプライマリから承認します。

非 root インストール

今回のリリースから、Caché および Ensemble のインストーラは、root または Administrator 権限なしで実行できるようになりました。この場合、インストールはインスタンスへのフルアクセス権限と制御を持つインストール・ユーザに属します。このインスタンスのレジストリ・エントリも、このユーザ・アカウントにのみ属します。他のユーザまたは root ユーザと共有されることはありません。詳細な手順および情報は、"インストール・ガイド" を参照してください。

新しい起動の既定値とジャーナル・データベース暗号化キーの管理

Caché のデータベース暗号化機能には、既定のキー使用動作を定義する 2 つの設定があります。

1. 新しい暗号化データベース (CACHETEMP を含む) の作成時に使用されるデータベース暗号化キー、および

2. 新しい暗号化ジャーナル・ファイル用のキー。

Caché インスタンスでは、これらの設定の初期値は、データベース暗号化キーが最初にアクティブ化されるときに決定され、使用される暗号化キー・ファイルのマテリアルから派生されます。これらの設定値は、管理ポータルまたは ^EncryptionKey を使用することで、いつでも変更できます。現在の値は、Caché のシャットダウンと再起動を繰り返しても保持されます。

2 要素のタイムベース・ワンタイム・パスワード認証

今回のリリースから、Caché では 2 要素のタイムベース・ワンタイム・パスワード認証 (TOTP) をサポートします。詳細は、"2 要素認証向けの構成" を参照してください。

^SECURITY または Security.UsersOpens in a new tab クラスを使用して、ユーザを作成または変更するスクリプトがある場合は、この機能に必要な新しいフィールドを追加する変更が必要になる場合があります。

ECP システム ID になったリモート・システム ID

管理ポータルおよびルーチンの ^JRNDUMP では、これまで “リモート・システム ID” というラベルが付けられていたフィールドに、“ECP システム ID” というラベルが付けられるように変更されました。そのフィールドの値は、Remote System ID ではなく、ECP System ID になりました。2 つの値は上位の数ビットのみが異なります。この上位の数ビットは、ECP システム ID ではゼロになり、リモート・システム ID ではゼロ以外になります。 また、ECPSystemID は、%SYS.Journal.RecordOpens in a new tab オブジェクトの新しいプロパティとして示されるようになり、クラスの List クエリでは新しい列として示されるようになりました。

システム・モニタの変更

システム・モニタは、新しい 2 つのクラス %SYS.Monitor.Sensor() と %SYS.Monitor.SensorItem() を通じて、ヘルス・モニタのセンサ・オブジェクトを %SYS に拡張しています。これらのクラスでは、センサに関する警告を行うだけでなく、警告をオンにして個別のセンサ項目に警告値を設定することもできます。例えば、DiskPercentFull (重大 = 99%、警告 = 90%) は、すべてのデータベースに対する既定値です。ただし、この値は、/mgr/cachelib などの個別のデータベースに対して変更することも、オフにすることもできます。

また、Notifications と SensorReadings は、多次元の項目 SensorReadings と Notifications に保存されなくなりました。代わりに、通知にアクセスするインタフェース %SYS.Monitor.AbstractComponent.GetNotification() と、センサにアクセスするインタフェース %SYS.Monitor.AbstractSubscriber.GetNextSensor() を使用する必要があります。

ミラーリング

• ミラー・メンバ名に対するより厳格なチェック

  以下に示す文字 (および、2 つの文字の組み合わせ) は、ミラー・メンバ名として有効ではなくなりました。これらの文字があると、構成クラスを保存するときの検証に失敗し、今後の問題発生を避けるために、ユーザにエラーが返されます。

  #    ;    //    /*    =    ^    ~    "    <space>    <tab> 
  

  Important:

  ミラー・メンバ名に禁止されている特殊文字を使用するシステムは、アップグレード前にメンバ名を変更する必要があります。メンバ名を変更しないと、.cpf ファイルの検証に失敗するため、アップグレードが失敗します。

• 新しく作成したミラーが使用する長くなったサービス品質のタイムアウト

  今回のリリースでは、新しく作成したミラーに対するサービス品質の既定値が 8 秒になりました。 これまでの既定値は 2 秒でしたが、特定のイベントに対して、ホストまたはネットワーク・レベルでシステムが一時的に応答しなくなっていると見なすには時間が短すぎました。そのために、警告や不要なフェイルオーバーが発生していました。 アップグレードされた既存のミラーは、これまでの状態を維持し、変更されることはありません。 一部のハードウェア構成、特に仮想環境では、これまでの既定値である 2 秒は、ホストまたはネットワーク・レベルでのイベントのタイミングと見なすには短すぎました。このために、システムが応答しなくなり、警告と不要なフェイルオーバーが発生します。詳細は、"サービス品質 (QoS) タイムアウトの構成" を参照してください。

• ミラー・ジャーナル・ファイルの削除ポリシー

  ジャーナル・ファイルの削除ポリシーには、2 つの変更が加えられています。これらの変更は、ミラーが必要とするジャーナル・ファイルを保持しながら柔軟性を高くすることを目的としています。

  1. 以前のバージョンでは、プライマリが保持しているジャーナル・ファイルをバックアップ・フェイルオーバー・メンバが削除することはありませんでした。これからは、ジャーナル・ファイルを保持する日数は、それぞれのメンバの個別の処理に任されるようになります。この方法では、ミラーの別のメンバがジャーナル・ファイルを必要としなくなるまで、異なる量のジャーナル履歴をメンバは保持できます。

  2. さらに、以前のバージョンでは、災害復旧 (DR) メンバを含めて、すべての非同期ミラー・メンバは、ジャーナル・ファイルがデータベースに適用された直後に、そのジャーナル・ファイルを削除することもできました。DR のメンバの場合は、これが問題の原因になることがありました。この問題は、DR メンバが昇格された後で、その DR メンバに別のメンバが接続しようとしたときに発生します。これからは、DR メンバはフェイルオーバー・メンバと同じミラー・ジャーナルの削除ルールに従うようになります。

  システム管理者は構成を調べて、構成された量のジャーナル・ファイルを保持するための十分な領域を DR メンバが確保していることを確認する必要があります。DR メンバは、災害時にプライマリの役割を果たすために十分なジャーナル空き領域を確保するように構成する必要があります。この要件は、今回のバージョンの新しい要件ではありませんが、以前のバージョンで十分な空き領域が確保されていない DR メンバは、そのメンバが昇格されるまで気付かれないことがあります。

• レポートから DR 非同期メンバ・タイプへの変更に対する制限の強制

  Caché は、メンバ・タイプ間の変換 (DR、読み取り専用レポート、および読み書き可能のレポート非同期メンバ) に制限を実施するようになりました。DR は制限なしでレポート非同期メンバに変更できます。また、読み取り専用と読み書き可能のレポート・メンバ間の変更にも制限はありません。ただし、ミラーリングされた DB が存在していて、その DB の FAILOVERDB 属性がクリアされている場合は、レポート・タイプを DR タイプに変更することはできません。 また、Caché は、ISCAgent が実行されていない場合に、レポート非同期メンバを DR にすることを許可しません。

• 大文字/小文字のみが異なるミラー名の禁止

  Caché では、既存のミラーリングされたデータベースの名前と大文字/小文字のみが異なる名前のミラーリングされるデータベースをユーザが作成できなくなりました。例えば、“Test” という名前の既存のミラーリングされたデータベースがある場合、“TEST” という名前のデータベースの作成は Caché によって防止されます。今回のリリースから、ミラー名は大文字に変換されるようになります。

既定のシグニチャ・ハッシュとして追加された SHA256

DefaultSignatureHash プロパティが System.Security クラスに追加されました。このクラスにより、既定で使用されるハッシュ・アルゴリズムを指定できます。既定値は、SHA256 です。 XML シグニチャは、明示的な指定がない場合に、新しい System.Security プロパティを使用して、既定のハッシュ・アルゴリズムを判断するように機能が強化されています。 また、管理ポータルも強化されています。“[システムワイドセキュリティパラメータ]” ページに DefaultSignatureHash が表示されるようになり、変更できるようになっています。 さらに、SOAP 構成ウィザードの AlgorithmSuite の既定値は、Basic128Sha256 に変更されています。

新しい既定値の SHA256 で作成されたシグニチャの受け取り側が、SHA256 をサポートしていない場合は、自分のコード内で明示的に DigestMethod を設定するか、DefaultSignatureHash が “SHA1” になるように変更する必要があります。実際の XML シグニチャは、自己記述型であるため、受け取り側が “SHA256” をサポートしている場合は (すべての標準ツールキットに該当します)、これまでどおりにコードが機能し、安全性が向上します。

エラー・テキストの相違点

添え字付き変数へのアクセスの失敗について説明するエラー・メッセージのテキストには、これまでよりも詳細な情報が示されるようになりました。例えば、以前のリリースでは、以下のようにエラーが表示されていました。

    <SUBSCRIPT>TEST1+5^TEST1 *a(1,"hello","")    

これは、3 番目の添え字が空の場合です。今回のリリースでは、エラー・テキストは以下のように表示されます。

    <SUBSCRIPT>TEST1+11^TEST1 *a() Subscript 3 is "" 

別の形式のメッセージを以下に示します。

    <SUBSCRIPT>TEST1+65^TEST1 *a() Subscript 5 > 511 chars
    <SUBSCRIPT>TEST1+24^TEST1 *a() Encoded subscript 1 > 511 bytes 

このような新しいメッセージにより、配列の不適切な添え字と、その添え字が不適切な理由についての詳細情報が得られます。

シャドウイング DejrnCOS 設定の削除

以前のバージョンでは、ドキュメント化されていない “DejrnCOS” という設定が使用できました。この設定は、デジャーナリングの古い代替実装です。今回のリリースでは、この設定が削除され、使用できなくなっています。 この設定で開始されるシャドウイングが存在する場合、その設定は削除され、デジャーナリングの標準実装に変換されます。この方法で変換されたシャドウは、ゼロ事前フェッチのジョブで実行するように設定されます。これは、“DejrnCOS” の実行時特性と最も厳密に一致します。

Monthlist の区切り文字として無効な $CHAR(1) の使用

ヒジュラ歴 (イスラム暦) 機能に対応するための変更の結果として、$ZDATE、$ZDATEH、$ZDATETIME、および $ZDATETIMEH に渡される monthlist の区切り記号として、$CHAR(1) を使用することが禁止されるようになりました。月名を区切るために $CHAR(1) を使用しているアプリケーションは、区切り文字として新しい文字を選択する必要があります。

更新されたアプリケーション・ライセンスのエントリ

以前のバージョンでは、$System.License のメソッド TakeApplicationLicense() と ReturnApplicationLicense() は、CSP サーバ・プロセスのみが CSP セッションのアプリケーション・ライセンスを取得すると仮定していました。 この仮定は、正しくありません。 このクラスと基礎になるメソッドが修正されました。 引数リストと動作についての説明は、クラス %SYSTEM.LicenseOpens in a new tab のオンライン・ドキュメントを参照してください。

現在のロールを使用して実行するエラー・トラップ・コード

$ZTRAP * (または $ETRAP *) は、エラー・トラップのコードが、エラーを引き起こしたコードと同じレベルで実行される必要があることを指示しています。以前のバージョンでは、エラー・トラップ・コードに制御が渡されると、$ROLES はプロセスが開始されたときの状態にリセットされていました。つまり、アプリケーション・ロールが割り当てられているときに、そのアプリケーション・ロールがあることを想定するエラー・トラップをアプリケーションで設定していても、その想定が満たされることはなく、エラー・トラップは正しく機能していなかったということです。

今回のリリースから、エラー・トラップは、そのエラー・トラップが設定された実行レベルに対して有効であったロールで実行されるようになりました。

アップグレードによって上書きされる手動で更新した Zen Mojo

Caché インスタンスをアップグレードすると、そのインスタンスを最後にインストールまたはアップグレードした後で、手動で更新したインストール済み Zen Mojo をダウングレードする場合があります。以下に示す一連のイベントについて考えてみます。

• Zen Mojo バージョン <N> が事前にインストールされた Caché 2015.1 が出荷される。

• Zen Mojo バージョン <N+1> がリリースされる。

• Zen Mojo バージョン <N+1> が含まれた、Caché 2015.1.1 がリリースされる。

• Zen Mojo バージョン <N+2> がリリースされる。ユーザが Zen Mojo バージョン <N+2> を使用して、Caché 2015.1 のインスタンスを手動で更新する。

• その後、そのインスタンスが Caché 2015.1.1 に更新される。インストーラによる更新で Zen Mojo のバージョンが <N+1> に戻される。

この場合、ユーザは Zen Mojo バージョン <N+2> を手動で再インストールする必要があります。

オブジェクトに移動されたリレーションシップのストレージ

オブジェクト間のリレーションシップ (例えば、親子テーブルの索引) を記録する一時的な構造は、以前のバージョンとは異なり、プロセス・プライベート・グローバルには保持されなくなりました。今回のリリースでは、その構造は親オブジェクトと子オブジェクトの一部として割り当てられるようになりました。これにより、パーティション内で占有される領域がわずかに増えるというコストで、アクセス速度が向上します。メモリが厳密に管理されているシステムでは、パーティションへのメモリ割り当てを増やすことが必要になる場合があります。

グローバル・ベクトル・キャッシュのサイズの拡大

各プロセスは、パフォーマンスを最適化するために使用するグローバルに関する情報をキャッシュしています。 このキャッシュは、グローバル・ベクトルと呼ばれ、プロセス・メモリに保存されます。このメモリは、プロセスのメモリ使用量として加算されます。 以前のバージョンでは、プロセスごとのグローバル・ベクトル数は 32 個に限られていました。 今回のリリースから、上限が 1000 個に引き上げられました。さらに、動的に割り当てられるようになり、別のグローバルが使用されるように拡張します。(グローバル・ベクトルは、グローバル名の異なるグローバルごとに使用されるか、個別の物理データベースに保存されます)。 この変更により、1 つのプロセスが 32 個を超える別々のグローバルに繰り返しアクセスする場合のパフォーマンスは大幅に向上します。

多数の異なるグローバルを参照するアプリケーション・プロセスは、以前のバージョンよりも多くの物理メモリを消費するようになりました。グローバル・ベクトルのエントリごとに、約 750 バイトのメモリが割り当てられます。 固有のグローバル名を最も多く参照するプロセスには、最大 1000 個のグローバル・ベクトル (750 KB) を割り当てできます。 アプリケーションで個別のグローバルを多数使用するときに、プロセスあたりの最大メモリまたは $ZSTORAGE の設定に余裕がない状態でアプリケーションが構成されている場合は、その設定を引き上げて、<STORE> エラーが発生しないようにする必要があります。追加の情報は、"Caché プロセスのメモリ" の項目を参照してください。

この変更の一環として、vectors 構成パラメータが無視されるようになりました。将来のバージョンでは削除される予定です。

既定で無効化されている TLS v1.1 および v1.2

Caché 2015.2 では、TLS v1.0 や v1.1、v1.2 を [SSL/TLS構成] ページで明示的に有効化できます。Caché 2015.1 では、[SSL/TLS構成] ページで有効化できるものは TLS v1.0 に限られていましたが、TLS v1.1 と v1.2 は既定で有効化されていて、どちらも使用できました。

Caché 2015.1 から Cache 2015.2 にアップグレードするときに、既存の SSL/TLS 構成があると、その構成の TLS v1.1 と v1.2 は初期状態で無効化されます。 そのような構成で TLS v1.1 や v1.2 を使用する場合は、[SSL/TLS構成] ページに移動して、TLS v1.1 や TLS v1.2 を有効化する必要があります。

SSL/TLS 構成の TLS v1.1 や TLS v1.2 を有効にするには、以下の操作を行います。

1. [システム管理]→[セキュリティ]→[SSL/TLS 構成] を選択します。

2. 更新する必要がある SSL/TTL 構成ごとに [編集] リンクを選択します。

3. [TLSv1.1] や [TLSv1.2] のチェック・ボックスにチェックを付けて、[保存] を選択します。

Windows

• インストール・アクセス許可の変更

  Windows に Caché をインストールすると、インストール・ディレクトリには、認証されたすべてのユーザにフル・アクセスを許可する、アクセス制御エントリ (ACE) が追加されます。 この ACE は、ICACLS コマンドで表示できます。以下のような出力が得られます。

  
  C:\intersystems\latest NT AUTHORITY\Authenticated Users: (F)
  NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(DE,Rc,WDAC,WO,GW,
      GE,GA,RD,WD,AD,REA,WEA,X,DC,RA,WA)
  
  

  インストールにより、Cache_Instance_<インスタンス名> という名前の Caché インスタンス・グループが作成されるようになりました。そのインスタンス・グループには、インストール・ディレクトリへのフル・アクセス権を付与する ACE が追加されます。 インストール・プロセスにより、Caché サービス・アカウントは、このグループのメンバになり、インストール・ディレクトリの完全な制御権が付与されます。

  Caché サービス・アカウントが、以下に示すように割り当てまたは変更されると

  cinstall setserviceusername <InstanceName> <username> <password>
  

  

  新しいサービス・アカウントは、インスタンス・グループのメンバになります。必要な場合は、グループが作成されて、まだ存在しない場合は、インストール・ディレクトリに ACE が追加されます。 そのため、Caché サービス・ユーザ・アカウントを変更するには、Windows のコントロール・パネル・アプレットではなく、cinstall setserviceusername を使用する必要があります。

  認証されたすべてのユーザにアクセス権を付与する ACE を削除することで、Caché インストール・ディレクトリにアクセスする Windows ユーザに、より厳しい制限を強制できるようになりました。 ACE の削除には、以下のコマンドが使用できます。 %CACHE_INSTALL_DIRECTORY% は、Cache インスタンスがインストールされているパスを表します。例えば、“C:\InterSystems\Cache” などになります。

  icacls %CACHE_INSTALL_DIRECTORY% /remove "NT AUTHORITY\Authenticated Users"
  

  

  “NT AUTHORITY\Authenticated Users” にインスタンス・ディレクトリへのアクセス権を付与している ACE を削除した場合は、ローカル・ターミナルで Windows 上の Caché に接続しているユーザを Caché インスタンス・グループのメンバにすることで、インストール・ディレクトリへのアクセス権を付与する必要があります。または、該当するユーザを管理者にすることで、インスタンスのインストール・ディレクトリに含まれるファイルへの適切なアクセス権を保証する必要があります。 ローカル・ターミナルの接続は、タイトル・バーの TRM:PID (InstanceName) の表示で確認できます。

  Important:

  ここで説明したインストール・ディレクトリ・ツリーに対する変更は、以前のバージョンの Cache でインストールしたインスタンスに適用してはいけません。ただし、この変更が行われているバージョンにアップグレードした場合を除きます。

• グローバル・アセンブリ・キャッシュへのインストール

  今回のリリースから、既定では、CacheProvider アセンブリがグローバル・アセンブリ・キャッシュに配置されなくなりました。アセンブリが GAC にインストールされるようにするには、ISCINSTALLINTOGAC プロパティを 1 に設定する必要があります。このように設定するには、コマンド行引数 “ISCINSTALLINTOGAC=1” を渡すか、Orca などのツールで MSI ファイルを編集します。

• マルチコア Windows システムでの $NOW の動作に対する変更

  以前のリリースの Caché は、複数のコアを搭載しているシステムで $NOW の値の一貫性を保とうとしていました。このために、状況によっては複数の CPU が同時に時刻をリセットしようとすることがあります。その結果として、$NOW は <FUNCTION> エラーを生成します。

  今回のリリースでは、Windows システムのマイクロ秒クロックを調整するコードが修正され、Caché インスタンスで実行するどのプロセスも調整値を確認できないようになりました。 その代わりに、それぞれの Caché Windows プロセスは、その調整を個々のプロセスにローカルにするようになります。 その結果、異なる Caché プロセスの $NOW(...) から返される値は、相互に一致しないことがあります。 これにより、詳細なタイミングを調査するアプリケーションには、いくらかの影響が現れる場合がありますが、$NOW(...) を呼び出したときに Caché が <FUNCTION> エラーを生成することはなくなります。

UNIX®

• Linux プラットフォームに対して推奨される TZ 環境変数の設定

  Linux プラットフォームでは、TZ 環境変数の設定をお勧めします。この変数はタイムゾーンを示します。この変数が設定されていないと、Caché の時間関連関数のパフォーマンスが大幅に低下することがあります。この変数の設定の詳細は、tzset のマニュアル・ページを参照してください。

• ABRT と Caché (Red Hat Linux インストール)

  RHEL 6.0 以降の Red Hat には、ABRT (自動バグ報告ツール) というユーティリティが導入されています。ABRT の目的は、プログラムのクラッシュを捕捉して、詳細な分析を行うための関連情報 (存在する場合は、コア・ダンプを含む) を一元化された場所に保存することです。通常、これが Caché と相互にやり取りすることはなく、単に無視できます。ただし、以下の 2 つの状況では、サイト管理者の必要性に応じて、既定の構成を変更することをお勧めします。

  • Caché カーネルのクラッシュ — プロセスのクラッシュにつながる Caché の障害が発生した場合は、インターシステムズに問い合わせする際に役に立ちます。可能であれば、分析のために、コア・ダンプを送信してください。コア・ダンプが作成されるかどうかは、Caché のインストール・オプション、クラッシュ時にプロセスを実行していたユーザ、および現行ディレクトリのアクセス許可によって決まります。コア・ファイルが作成されない場合に、分析のためにコア・ファイルが必要になったときには、後述する推奨事項を参照してください。

  • cstat ユーティリティのクラッシュ — cstat ユーティリティ (ccontrol stat) は、共有メモリ内の複数のテーブルにアクセスします。このテーブルは急速に変更される場合があります。システムの負荷などの状況によっては、メモリ・スナップショットが矛盾して、cstat のクラッシュを招くことがあります。この種のクラッシュには実害がないため、cstat にはコア・ダンプが作成されないようにするコードが組み込まれています。ただし、ABRT は、そのイベントを記録し、コア・ファイルを一元化されたデータベースにコピーします。ディスク領域を確保するために、サイト管理者は、これに該当するクラッシュが記録されないようにすることを望んでいます。

  以下に、ABRT に関する基本情報の一部を示します。

  • ABRT には、2 つのメジャー・バージョン 1.x および 2.x が存在します。どちらを実行しているかを判断するには、'abrt-cli' コマンドを使用します。

    $ abrt-cli --version
    

    

  • クラッシュが発生したときに、ABRT ディレクトリを確認して、そのイベントが記録されているかどうかを調べます。そのためには、該当するバージョンに固有のコマンドを使用します。

    ABRT 1.x	$ abrt-cli --list
    ABRT 2.x	$ abrt-cli list

  • それぞれのイベント (クラッシュ) に対して、ベースの ABRT ディレクトリの下に専用のディレクトリが割り当てられます。

    ABRT 1.x	/var/spool/abrt
    ABRT 2.x	/var/tmp/abrt

  • ABRT は大量のメッセージを /var/log/messages に送信します。そのため、特定のクラッシュで発生した内容を調べるときには、このファイル (通常は一番最後のファイル) の内容を確認することが有効です。

  • ABRT のオンライン ドキュメントは、https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-abrt.htmlOpens in a new tab から入手できます。

  • 何らかの原因で ABRT が Caché に干渉している場合や、その他の理由で ABRT が不要な場合は、ABRT を無効にすることでその状況が簡単に解決します。そのためには、以下のコマンドを使用します。

    # service abrtd stop
    

    

    ABRT 2.x (RHEL 6.2 以降) を実行している場合は、以下のようにして関連サービスも無効にする必要があります。

    # service abrt-ccpp stop
    

    

    さらに、システムに対してコア・ファイル名の形式を指示する「コア・パターン」を変更する必要があります。通常は、"core.<pid>" が使用されています。このパターンは、以下のようにして取得します。

    # cat >/proc/sys/kernel/core_pattern 
      core.%p 
      <CTRL+D>
    

    

    ABRT を永続的に (再起動後も) 無効にするには、以下の操作も実行します。

    ABRT 1.x および ABRT 2.x	# chkconfig abrtd off
    ABRT 2.x	# chkconfig abrt-ccpp off

  • ABRT に対して Caché のコア・ダンプを保存するように指示するには、以下の該当する手順をすべて実行します。

    • 構成ファイルを編集します。

      ABRT 1.x	/etc/abrt/abrt.conf
      ABRT 2.x	/etc/abrt/abrt-action-save-package-data.conf

    • cinstall スクリプトで Caché をインストールした場合は (最も一般的な方法)、次のパラメータを 'no' から 'yes' に変更します。ProcessUnpackaged = yes

    • RPM で Caché をインストールした場合は、次のパラメータを 'yes' から 'no' に変更します。OpenGPGCheck = no

  • cstat コア・ダンプを保存しないように ABRT に指示を出すには、以下の操作を行います。パッケージ化されていない実行可能ファイルを ABRT で処理できるようにしている場合は、Caché 実行可能ファイルだけでなく、cstat 実行可能ファイルについてのコア・ダンプも作成されるようになります。cstat についてのコア・ダンプが不要な場合は、以下の両方の操作を実行して、このコア・ダンプを除外します。

    • 構成ファイルを編集します (前述の手順を参照)

    • cstat へのフル・パスが含まれるように、BlackListedPaths パラメータを更新します。

      BlackListedPaths = [retain existing list], <installation dir>/bin/cstat
      

      

  • ABRT デーモンのステータスを取得するには、以下のようにします。

    $ service abrtd status
    

    

  • ABRT を再起動するには、以下のようにします。

    # service abrtd restart
    

    

• UNIX® プラットフォームでのデータベース書き込みに対する非同期入出力と直接入出力

  Caché は、AIX、HP-UX、Solaris、および Mac OS X 上のデータベース・ファイル (ファイル名 CACHE.DAT) への書き込みに、非同期入出力を使用するように機能が強化されています。これは、これらのプラットフォームのサブセットのバッファ型入出力ではなく、直接入出力 (適切な場合は同時入出力) の自動的な使用と組み合わされています。 この変更は、データベース・ファイルに合わせてディスク入出力の特性を最適化することを目的としていて、使用率の高いシステムでは最大負荷時のスループットを向上させられます。当然のことですが、データ整合性を確保するために、要所ごとに同期が行われます。

  データベース・ファイルに対して、バッファ型入出力ではなく、直接入出力 (または同時入出力) を使用するには、特定の構成に注意を払う必要があります。以下は、それぞれの UNIX プラットフォームに対する変更点と、該当する考慮事項についての説明です。

  • AIX

    非同期書き込みを使用するようになったことに加えて、Caché では、データベース・ファイルに対して自動的に同時入出力を使用するようになりました (同時入出力は、AIX での直接入出力に推奨される形式です)。多くの AIX サイトでは、cio マウント・オプションによって、同時入出力を使用するようにデータベースが構成されています。そのように構成されていないサイト (以前のバージョンのバッファ型入出力を使用するサイト) では、以下の点に注意する必要があります。

    • 十分なデータベース・キャッシュが構成されていることを確認します。ファイル・システム・バッファリングにより、Caché は、以前のバージョンで不十分に構成されたデータベース・キャッシュでも、許容できる程度の性能を実現できることがあります。

    • Caché の実行中に、データベース・ファイルを読み取るために外部コマンドが使用されるという特殊な構成では、その外部コマンドが失敗する可能性があります。これは、同時入出力のために、データベース・ファイルが Caché によって開かれているためです。例を挙げると、高度なバックアップまたはスナップショット・ユーティリティではなく、cp コマンドを使用して外部バックアップを実行する場合です。cio オプションを使用してファイル・システムをマウントすると、すべてのプログラムが同時入出力でファイルを開くように強制されるため、この問題が解決します。

  • HP-UX

    Caché は、これまでどおりにデータベース・ファイルに対してバッファ型入出力を使用します。これは、HP-UX が同時入出力 (HP-UX での直接入出力に関する推奨形式) に関するプログラムレベルの制御を提供していないためです。同時入出力は、cio マウント・オプションを使用して、OnlineJFS または VxFS ファイルシステムをマウントすることで、有効化できます。今回のバージョンの Caché は、非同期入出力を使用して、以前のバージョンよりも優れた書き込み特性を実現しています。同時入出力が使用されている場合は (同時入出力が必要とされていない場合でも)、その優秀性が顕著に現れます。

  • Solaris

    Caché は、UFS ファイルシステムに配置されたデータベース・ファイルに対して、直接入出力を自動的に使用するようになりました。これは、NFS にも適用されます。ただし、NFS は、Solaris の推奨ファイルシステムではありません。UFS (または NFS) を使用する場合は、十分なデータベース・キャッシュが構成されていることを確認してください。ファイルシステム・バッファリングにより、Caché は、以前のバージョンで不十分に構成されたデータベース・キャッシュでも、許容できる程度の性能を実現できることがあります。直接入出力は、ZFS ファイルシステムには関係しません。

    どのような場合でも、Caché は、データベース・ファイルへの書き込みに、非同期入出力を使用するようになりました。

  • Linux

    Caché は、データベース・ファイルに対して、これまでどおりにバッファ型入出力を使用し、非同期入出力は使用しません。これについて、以前のバージョンからの変更はありません。

  • Mac OS X

    Caché はバッファ型入出力を使用しますが、データベース・ファイルには非同期入出力を使用します。そのほかに適用される考慮事項はありません。

• 追加ライブラリがない場合、AIX での Caché 2015.2 へのアップグレードは失敗

  Caché 2015.2 のインストール、または Caché 2015.2 へのアップグレードを行う前に追加の C/C++ ランタイム・ライブラリを AIX にインストールする必要があります。これらのファイルが存在しない場合、インストーラはアップグレードを完了しません。

  Caché 2015.2 AIX は、バージョン 13 でコンパイルされています。IBM のサポート・ドキュメントによると、プログラムはバージョン 13 でコンパイルされていて、そのプログラムでは、以下に示す 3 つのランタイム・ファイルセットが必要になる暗号化機能を使用しています。このファイルセットは、Caché がインストールされているマシン上のランタイム・パッケージ IBM_XL_CPP_RUNTIME_V13.1.0.0_AIX.tar.Z に含まれています。

  • xlC.aix61.rte 13.1

  • xlC.rte 13.1

  • xlC.msg.en_US.rte 13.1

  パッケージについての詳細は、"IBM XL C/C++ Runtime for AIX 13.1Opens in a new tab" から入手できます。

Mac OS X

コールイン機能を使用するプログラムで、cache.o を組み込んでいる場合は、C++ コンパイラなどの C++ 対応リンカでリンクするか、makefile に手動で “-stdlib=libstdc++” を追加する必要があります。

無効な既定の引数の診断

これまでは、仮引数の既定値が長すぎたり、無効な式であったりしても、その状況を ObjectScript コンパイラが特定しないことがありました。その代わりに、エントリ・ポイントが呼び出されたときに、<LIST> エラーがスローされました。

これからは、コンパイラがエントリ・ポイントでコンパイル・エラーを出力するようになります。エントリ・ポイントが呼び出されると、その呼び出し方法に応じて、<PARAMETER> または <SYNTAX> がスローされます。

クラスの削除

以前のバージョンに存在していた以下のクラスは、このリリースで削除されています。

• %CSP.UI.Portal.Dialog — MirrorAuthorizedAsync

• %CSP.UI.Portal.Mirror.Dialog — AddFailover

• %Collection.MV — ArrayOfObjCN、ListOfObjCN

• %SYS.Monitor — AbstractAsyncSensor

• %iFind — EntityI

• %iFind.Stemmer — AbstractStemmer

• %iKnow.Objects — Utils

• SYS.Monitor — CSPGateway、TestAsync

• SYS.Monitor.Health — AbstractCallback

クラス・コンポーネントの削除

このバージョンでは、以下のクラス・コンポーネントが、以前に存在していたクラスから移動または削除されています。

メソッド返り値の変更

今回のバージョンの Caché では、以下のメソッド返り値が変更されました。

• %Compiler.UDL.TextServices — GetTextAsFile

• %Library.RegisteredObject — %ConstructCloneInit

• %Library.RoutineMgr — getGlobalList

• %SYSTEM.Process — StoreErrorReason

• %UnitTest.Manager — LogStateEnd

• %iKnow.Filters.Filter — GetNextSrcId

• Config.CommonMultipleMethods — Create

• SYS.Database — Copy

• SYS.Shadowing.Shadow — GetLatency、LatencyGet

メソッド・シグニチャの変更

今回のバージョンの Caché では、以下のメソッドのシグニチャが変更されました。

ADO.Net の TCP/IP に追加された先行読み取り

以前のリリースの Caché は、大量のメッセージに対して、xDBC メッセージを同期的に処理していました。つまり、クライアントが処理しているときには、サーバがアイドル状態であり、サーバが処理しているときには、クライアントがアイドル状態だったということです。 これは、同一マシン上のクライアントとサーバで xDBC をベンチマークしたときに明らかになりました。 2 つのプロセスがあったとしても、アプリケーションが両方のプロセスに CPU を 100% を超えて使用することはありません。

このバージョンでは、クライアントがサーバ・メッセージ “A” のヘッダを読み取った直後に、次に送信されるサーバ・メッセージ (“B”) を要求します。クライアントはアプリケーションの指示どおりにサーバ・メッセージ “A” の処理を続けます。それと同時に、サーバは結果セットの次の部分を準備します。 アプリケーションが結果セットの処理を続けると、いずれはバッファ “A” の終端に到達し、アプリケーションはメッセージ “B” のヘッダを読み取ります。 プロセスはメッセージ “B” の処理を繰り返し、クライアントは “C” を要求します。 …

データの処理は、今までと同じ順序で論理的に発生しますが、この新しい動作により、タイミングの問題が現れる可能性があります。これは、先行読み取りの特性によるものです。

TCP/IP データ転送におけるスループットの向上

以前のバージョンでは、インスタンスとやり取りするデータのリストを転送するときに、リストを繰り返すために使用される共有値を適切に管理するために、Caché は大量のロックを使用していました。 このようなロックは、アクセス数がデータ項目数になることがあるため、パフォーマンスの低下につながっていました。 今回のバージョンでは、データにアクセスする方法に変更を加えて、読み取り (取得) をロックする必要性をなくしました。また、書き込みは単一のスレッドによるチャネリングで保護されます。これにより、TCP/IP を介してサーバにデータを置いたり、データを取り出したりする操作から、ほとんどのロックが取り除かれています。これにより、パフォーマンスは向上しますが、これまで隠れていたタイミング問題がアプリケーションで顕在化する可能性があります。

Double 値の転送における相違点

今回のリリースでは、以前のリリースを実行するクライアントに転送される $DOUBLE 値の形式に、わずかな変更が加えられています。この変更により、無意味な桁が抑制されます。以前のバージョンでサーバが “0.93” という形式で転送していた値は、“.93” という形式で送信されるようになりました。また、丸め処理のアルゴリズムが変更されたため、$DOUBLE 値の最下位の桁数が、以前のリリースとは異なることがあります。

これまでに送信されていたものと完全に同じ文字数または値であることに依存するアプリケーションは、変更が必要になる場合があります。

SQL 統計ロギングの変更

SQLStats のエラー・ログが変更されています。以前のバージョンでは、SQLStats のログを記録している間に発生したすべてのエラーが、^%sqlcq($Namespace, "PTools", "Error", $JOB, counter) に保存されていました。すべてのプロセスについてのエラーをグローバルに保存すると、グローバルが巨大化してしまいます。エラー・トラップのログ処理が変更され、今回のリリースからは、各ジョブの最終エラーのみが ^%sqlcq($Namespace, "PTools", "Error", $JOB) に保存されます。

また、ネームスペースの SQLStats を以下のように削除すると、

Do ##class(%SYS.PTools.SQLStats).Purge("SAMPLES")

エラーも削除されます。指定したルーチンの統計のみを削除する場合、エラーは削除されません。

Note:

SQLStats のエラーをループ処理するコードは、変更が必要になります。構造体の添え字レベルが 1 つ少なくなっています。以前の動作は以下のとおりでした。

^%sqlcq($Namespace, "PTools", "Error", $JOB, counter)

現在は、以下のとおりになっています。

^%sqlcq($Namespace, "PTools", "Error", $JOB)

ゼロが返されるようになった無効な日付と時刻の CAST

以前のリリースでは、無効な値を日付または時刻にキャストしようとすると、結果は “” になっていました。今回のリリースから、

CAST( x AS DATE )

または

CAST( x AS TIME )

は、x が無効な %String 値、%TimeStamp 値、または %FileMan.TimeStamp 値の場合、ゼロを返します。返り値が NULL であることに依存するアプリケーションは、変更が必要になります。

空文字列の長さの修正

SQL 空文字列は 0 の長さを持ち、$LENGTH は長さ 0 を報告するようになりました。SQL $LENGTH('') から 1 が返されることを予期するアプリケーションは、0 が返されるようになったことを認識するように調整する必要があります。

統計の収集に関する既定値の変更

以前のリリースでは、$SYSTEM.SQL.SetSQLStatus の既定値は 1 でした。この既定値で生成された SQL コードでは、クエリがクエリの実行に関する追加データをログに記録する必要があるかどうかを確認します。これにより、実行速度が低下します。今回のリリースでは、既定値が 0 に変更され、クエリは不要な確認 (クエリが追加データをログに記録する必要があるかどうか) を生成しなくなりました。

このようなログ記録を必要とする状況が発生した場合は、システム全体の値またはプロセス固有の値を変更してから、対象のクエリを削除するか、クエリを含んでいるルーチン/クラスをリコンパイルすることで、以前と同様のログ情報を取得できます。

SQL プランのオプティマイザに対する変更

以前のリリースでは、最適なクエリ・プランを選択しようとするときに、オプティマイザは同等の速さになると予想される 2 つのプランの選択に迫られることがありました。今回のリリースでは、プランに対する “コスト” の計算が改善され、以前は同等と予想された選択肢に違いが現れるようになりました。この場合、関与するテーブルについて表現するメタデータによっては、オプティマイザが、ある種のクエリに対して実際には間違った選択を行うことがあります。

既定でオンになったレベル 2 の SQLStats の生成

今回のリリースでは、ルーチン内で SQLStats コードを生成するという既定の動作が復元されています。 既定では、生成されたコード内にレベル 2 の SQLStats 呼び出しのみが生成されます。 これは、クエリ OPEN 内の 1 行と、クエリ CLOSE 内の 1 行になります。 SQLStats には、モジュール・レベルごとに情報を収集するレベル 3 オプションもあります。このオプションは、一般に、問題のあるクエリが特定されて、詳細な調査が必要になったときにのみ使用します。

また、以前は SQLStats = 2 から SQLStats = 3 への切り替え時に、SQL のリコンパイルは必要ありませんでした。 今回のリリースでは、SQLStats をレベル 3 に切り替えるときには、SQL のリコンパイルが必要になります。

CP1251 の $CHAR(152) のマッピング

Cyrillic スクリプトを採用しているユーザの便宜を図るために、Windows コード・ページ (CP1251) の未定義のコード・ポイント 152 を Unicode に変換した場合は、そのコード・ポイント自体 (152) にマップされるようになりました。それとは逆に、U+0098 (152) を Unicode から CP1251 に変換した場合も、結果は 152 になります。 この変更は、ロシア語のユーザにとって便利なものです。その理由は、例えば Unicode と CP1251 の変換時に、$C(152) のラウンド・トリップが可能になるためです。

システム・ロケールに対する変更の禁止

Config.NLS クラスの Modify() メソッドは、システムのロケールまたはテーブルを編集しようとするとエラーを返すようになりました。このメソッドは、カスタムのロケールおよびテーブルに対しては、これまでと同様に動作します。システムのロケールはインターシステムズが提供するものであり、その内容が前提とされています。そのため、お客様による変更は禁止されています。

EntOccId に保存されるようになった無関係なテキスト

今回のリリースでは、無関係な文の部分がエンティティの出現回数と同じデータ構造に格納されるようになりました。これにより、文のすべての構成要素に対する透過的な SQL アクセスが可能になり、将来の拡張機能 (新しいエンティティ・タイプや、エンティティ以外の文の部分にアノテーションを付けるなど) に簡単に対応できるようになります。

エンティティの出現 ID がエンティティのみを表しているという暗黙の規則 (決してドキュメント化されない規則) に依存するアプリケーションは、対応するエントリのロールを考慮に入れて、無関係のエントリではなく、エンティティを確認していることを確実にする必要があります。

新しい優位性アルゴリズムの実装

今回のリリースでは、優位性の定義に対する改善と、該当するエンティティの関連メトリックを計算する新しいアルゴリズムが、iKnow および iFind に導入されています。さらに、基礎になるデータ構造の一部が合理化されています。これにより、完全に生成された iKnow ドメインが使用するストレージを最大 15% 削減できる可能性があります。さらに、この変更では、フィルタ処理をサポートする DominanceAPI と ProximityAPI に対応する新しいクエリも導入しています。

エンティティに対する新しい「ローカル優位性」の値は、ドキュメントから得られる情報全体に基づいて計算されます。この値の範囲は 0 から 1 になります (内部の効率性を高めるために 100 万倍されて、丸められます)。そのため、ドキュメント間の比較が可能になります。

iFind ユーザの場合は、実際の優位性の値のみが変わります。

iKnow ユーザの場合は、その他にも新しいアルゴリズムに伴ういくつかの変更点があります。

• 優位性プロファイルは、上側四分位数 (上位 25%) のうちの関連のある一部分 (常に最上位値を含む) を選択する、新しい式に基づいて生成されます。

• CRC とパスについての優位性の値も (それらを構成するエンティティの加重平均として) 生成されますが、それぞれ別の CRC またはパスとの関連性を比較することを主な目的として使用してください。

• そのため、優位性プロファイルを取得するクエリの既定値は、集約プロファイルではなく、概念プロファイルを取得するように更新されています。

• DominanceAPI には、GetTop() という単純な形式の新しいエントリ・ポイントが加わりました (フィルタ処理をサポートしています)。ProximityAPI のメイン・エントリ・ポイントは、GetProfile() または GetProfileById() になりました。

ユーザ・ディクショナリでカスタマイズされる感情と否定の属性

今回のリリースでは、ユーザ・ディクショナリを通じて感情と否定の検出をカスタマイズするメカニズムのうち、試用公開の実装からユーザ可視部分に変更が加えられています。%iKnow.UserDictionaryOpens in a new tab クラスの 3 つの新しいメソッド AddNegationTerm()、AddPositiveSentimentTerm()、および AddNegativeSentimentTerm() を使用することで、特定の単語に否定または感情を表すものとしてアノテーションを付けることができます。これにより、iKnow エンジンは、それらの単語を適切に扱って、文の関連部分に拡張します。

既定の CSP エラー・ページの変更

以前のバージョンでは、CSP アプリケーションにエラー・ページが指定されていない場合は、Caché によって %CSP.Error.cls が既定として設定されていました。このエラー・ページには問題のデバッグを支援するために、%request、%response、%session オブジェクトに関する多くの情報が表示されていました。今回のリリースでは、お客様が専用のエラー・ページを用意していない場合は、%CSP.ErrorLog.cls が既定のエラー・ページになります。このエラー・ページには、エラーが発生したことを伝える簡単なメッセージのみが表示され、すべての情報は ^%ETN エラー・ログに記録されます。Caché は、アプリケーション・エラーの発生時に情報が漏えいしないように、これを行います。

%CSP.ErrorLogOpens in a new tab クラスは %CSP.ErrorOpens in a new tab のスーパークラスであり、メソッド LogError が含まれています。このメソッドは、%ETN が適切にログ記録できるように情報を取得します。

既定では Base64 エンコードの XML 出力に含まれなくなった改行

以前のリリースでは、Caché は base64 エンコードの XML 出力 (特に、XML 対応クラスの %BinaryOpens in a new tab または %xsd.base64BinaryOpens in a new tab タイプのプロパティ用の出力) を生成するときに、既定で改行を含めていました。この既定の動作は、Caché 以外の Web サービスおよび Web クライアントとの連動時に問題を起こしていました。今回のリリースでは、該当するプロパティ用に出力を生成するときに、Caché は改行を含めないようになりました。

SOAP Web サービスまたは Web クライアントのバイナリ出力に、こうした改行を含めるには、Base64LineBreaks プロパティを 1 に設定するか、BASE64LINEBREAKS パラメータを 1 に設定します。Base64LineBreaks プロパティと BASE64LINEBREAKS パラメータの両方が設定されている場合は、パラメータよりもプロパティが優先されます。

プロパティの既定の出力順序の変更 (多重継承の場合)

場合によっては、1 つの特定のクラスが複数の XML 対応スーパークラスに基づいていることがあります。以前のリリースでは、対応する XML スキーマがプライマリ・クラスからの継承によって作成され、それに続けて 2 番目以降のスーパークラスから各プロパティが作成されていました。 エクスポートとインポートの場合は、プロパティの順序が矛盾していて、Caché は右端のスーパークラスのプロパティを先頭にしていました。今回のリリースから、既定では、プロパティのエクスポートとインポートも左から右への順序で生成されます。以前のリリースの動作を実現するには、サブクラスの XMLINHERITANCE パラメータに "right" を指定します。

サブクラスを持つシリアル・クラスに必要とされる CLASSNAME=1

SOAP または XML のスキーマ・ウィザードを使用してアプリケーションを開発する場合は、サブクラスを持つシリアル・クラスを参照するプロパティに対して、CLASSNAME=1 プロパティ・パラメータを使用してください。 プロパティ・パラメータとして、参照するプロパティに CLASSNAME=1 が追加されていないと、オブジェクトを保存しようとしたときにエラーが生成されます。このプロパティ・パラメータがない場合、生成されたコードでは、参照されるオブジェクトのサブクラスが特定できなくなります。

REST 内の CORS の実装

今回のリリースから、REST アプリケーションが認証を必要とする場合に、Caché は HTTP OPTIONS 動詞を処理するようになりました。ブラウザは、プリフライトの OPTIONS 要求時に認証ヘッダを送信しないため、アプリケーションのログインが必要になったときに、OPTIONS 要求を処理する方法がありませんでした。 これからは、許容される HTTP 動詞のリストを格納する Allow: ヘッダと、要求の ORIGIN ヘッダから派生した origin を指定する ACCESS-CONTROL-ALLOW-ORIGIN ヘッダを返すようになります。

%CSP.RESTOpens in a new tab クラスには、新しいコールバック・メソッド HandleCORSRequest(pUrl) が含まれるようになりました。アプリケーションでは、CORS 準拠を実現するために必要とされる、アクセス制御ヘッダを設定できます。既定の実装では何も実行されませんが、メソッドの本体にサンプル・コードが記載されています。

計算メジャーと通常メジャーを矛盾なく処理するピボット・テーブル

以前のリリースでは、アナライザは、ある特殊なシナリオで、通常メジャーと計算メジャーに形式の異なるピボット・テーブルを生成していました。この相違が修正され、アナライザは、両方の種類のメジャーを同様に扱うようになりました。

特殊なシナリオとは、ピボット・テーブルが、レベルなどの [列] で使用されている項目、および [メジャー] で使用されている 1 つのメジャー (または計算メジャー) で定義されているシナリオです。このシナリオでは、列ヘッダに含まれる可能性のある情報が 2 つあります。1 つは [列] で指定した項目の名前で、もう 1 つはメジャーの名前です。以前のリリースでは、以下のようにしていました。

• メジャーが計算されていない場合は、ピボット・テーブルにメジャーの名前を示すヘッダが含まれません。

• メジャーが計算メジャーの場合は、ピボット・テーブルにメジャーの名前を示すヘッダが含まれます。このヘッダは、[列] で指定した項目のヘッダの下側に表示されていました。

今回のリリースの既定では、このシナリオの場合、ピボット・テーブルにはメジャーのヘッダが含まれません。アナライザには、メジャーのヘッダを表示するかどうかの制御に使用できる、新しいオプションが用意されています。このオプションにアクセスするには、[メジャー] ボックスの [オプション] アイコンをクリックします。このオプションは、ここで説明したシナリオにのみ適用されます。

多重軸に対するメジャーの使用に関する制限

以前のリリースでは、多重軸に対してメジャーを使用するピボット・テーブルが作成できました。その結果は不確定になりますが、DeepSee はエラーを表示しませんでした。今回のリリースでは、MDX エンジンが調整され、多重軸に対するメジャーの存在が防止されます。例えば、アナライザでは、ユーザは多重軸にメジャーをドラッグ・アンド・ドロップできなくなっています。多重軸に対してメジャーが定義されると、“多重軸にメジャーは存在できません” というエラーがスローされます。

この調整の一環として、多数の MDX 関数が内部的に形式化されています。例えば、これらの関数は、スカラー値またはメンバを返します。"DeepSee MDX リファレンス" には、各関数の返りタイプが記載されています。

関数が数値を返す場合、その値は実際にはメジャーであるため、ここで説明した制限が課せられます。この変更の結果として、これまで動作していた一部のピボット・テーブルは、エラー ERROR #5001: Two measures cannot be crossjoined (2) を表示するようになりました。

以下の例外に注意してください。

• エンジンは、関数 %CELL および %CELLZERO をメジャーとして扱いません。これらは、クエリ実行の最終ステップとして実行され、適切に使用すれば、あいまいさを生じないためです。

• エンジンは、SUM などの集約関数をメジャーとして扱いません。ただし、そのような関数がオプションの expression 引数を使用する場合を除きます。

例えば、以下のクエリは正当です。

>>SELECT Measures.[Amount Sold] ON 0, AVG(Product.P1.[Product Name].MEMBERS) ON 1 FROM HOLEFOODS
                                   Revenue
AVG                               $5,199.61

>>SELECT AVG(Product.P1.[Product Name].MEMBERS,Measures.[Units Sold]) ON 1 FROM HOLEFOODS

AVG                                  997.82

一方、以下は正当ではありません。

>>SELECT Measures.[Amount Sold] ON 0, AVG(Product.P1.[Product
Name].MEMBERS,Measures.[Units Sold]) ON 1 FROM HOLEFOODS

ERROR #5001: Measures cannot exist on multiple axes
[%Prepare+174^%DeepSee.Query.query.1:SAMPLES]

ダッシュボードの凡例パディングの処理の向上

今回のリリースでは、ダッシュボードに示されるグラフの凡例のパディングに対する実装が異なっています。グラフの凡例に既定以外のサイズやパディングを指定しているダッシュボードがある場合は、そのダッシュボードの再調整が必要になることがあります。特に、これまでは表示されていたグラフの凡例が表示されなくなる可能性があります。このようになった場合は、ダッシュボード・エディタを使用して、グラフの凡例のサイズとパディングを修正してください。

メジャーのキャプションやラベルの非表示化

ピボット・テーブルに含まれるメジャーの取り扱い方法に関する問題は、現在進行中の問題です。単一メジャーは、表示されるいずれかの軸 (行/列) ではなく、スライサに配置されていました。スライサでは意味をなさないものがあるため、これが計算メジャーに関わる問題の原因になっていました。そのため、計算メジャーは表示される軸に配置されていました。単純なメジャーと計算メジャーとの違いが、ユーザの混乱を招くことがありました。計算メジャーはスライサに配置されることがないため、計算メジャーのラベルを非表示にする手段はありませんでした (スライサ内の項目が、ピボット・テーブルに表示されることはありません)。

今回のバージョンでは、メジャーのヘッダ/ラベルの表示がピボット・テーブルの構成可能部分になりました。[メジャー] ダイアログは、新しい設定の “[メジャーのヘッダの表示]” が含まれるように拡張されています。この設定には、3 つのオプション [複数のメジャーが使用される場合]、[常時]、および [なし] があります。 この設定は、ピボット・テーブル定義と共に保存され、そのピボット・テーブルが表示されるときには常に有効になります。既定の設定は、[複数のメジャーが使用される場合] です。

%ZEN.Component.Group Layout Property に対するクライアント側での変更の禁止

Javascript から任意のメソッドが実行されないようにするために、%ZEN.Component.group とサブクラス (%ZEN.Component.menu 以外) の layout プロパティは、クライアント側では暗号化されるようになり、サーバ側でのみ変更できるようになりました。Zen グループ (つまり zen('myGroup').setProperty('layout','horizontal')) の layout プロパティにクライアント側で変更を行うと、その次にコンポーネントのプロパティがサーバで処理されるときに、<ILLEGAL VALUE> エラーが発生します。

UTF-8 で生成されるようになった Javascript のドキュメント

以前のリリースでは、Zen で生成されたファイルは明示的なエンコードが行われていませんでした。このようなファイルは、生成されたインスタンスのロケールになると想定されていました。この動作は、アプリケーションが別のエンコーディング (Unicode など) のファイルを想定している場合や、別のロケールで使用される場合に、問題が発生する場合がありました。

今回のリリースから、Zen の生成するファイルは、UTF-8 形式で明示的にエンコードされます。特定のロケールを想定しているアプリケーションは、新しいエンコーディングに対応するように変更する必要があります。

jQM: Id 属性の変更

レイアウト・オブジェクト $panel の id 属性は、非推奨になりました。この属性は、その他のレイアウト・オブジェクトとの一貫性を確保するために、key 属性に置換する必要があります。つまり、以下のような以前のコードは

{type:'$panel’, id:'leftPanel', displayMode:'push', children:[]}

以下のように書き換える必要があるということです。

{type:'$panel’, key:'leftPanel', displayMode:'push', children:[]}

今回のリリースでは、id が指定されていても $panel は動作しますが、この属性は将来のバージョンではサポートされなくなる予定です。