TIBCO EBX® テクニカルアーキテクチャの主な原則は次のとおりです。
EBX® を実行する Java プロセス (JVM) は、単一の EBX® リポジトリに制限されています。このリポジトリは、構成されたデータソースを介してアクセスされる、サポートされているリレーショナルデータベースインスタンスに物理的に永続化されます。
リポジトリは、常に複数の JVM で共有することはできません。ただし、フェールオーバーアーキテクチャを使用することもできます。これらの側面については、リポジトリごとに 1 つの JVM およびホットスタンバイによるフェールオーバーのセクションで詳しく説明しています。さらに、水平方向のスケーラビリティを実現するための代替手段は、分散データ配信 (D3) 環境を展開することです。
単一のリレーショナルデータベースインスタンスは、複数のEBX®リポジトリ (個別の JVM で使用) をサポートできます。次に、プロパティ ebx.persistence.table.prefix を使用して個別のテーブルプレフィックスを指定する必要があります。
永続化されたマスターデータの整合性を保証するために、データベースへの直接 SQL 書き込みを実行することは固く禁じられています。
構成済みデータソースで指定されたデータベースユーザーは、テーブル、インデックス、およびシーケンスに対する「作成/変更」権限を持っている必要があります。これにより、リポジトリの自動インストールとアップグレードが可能になります。
リポジトリを複数の JVM で共有することはできません。このような状況が発生した場合、予期しない動作が発生し、リポジトリ内のデータが破損する可能性があります。
EBX® は、この制限を適用するためのチェックを実行します。リポジトリが使用可能になる前に、リポジトリは最初にリレーショナルデータベースの排他的所有権を取得する必要があります。リポジトリーを開始した後、JVM は定期的にリポジトリーの所有権を保持していることを確認します。
これらのチェックは、リレーショナルデータベースのテクニカルテーブルに繰り返しタグを付けることによって実行されます。アプリケーションサーバーのシャットダウンコマンドは、このテクニカルテーブルのタグが削除されていることを確認します。サーバーが予期せずシャットダウンした場合、タグがテーブルに残っている可能性があります。これが発生した場合、サーバーは再起動時にさらに数秒待機して、テーブルが別のライブプロセスによって更新されていないことを確認する必要があります。
次回の起動時に追加の待機期間を回避するために、アプリケーションサーバーを常に適切にシャットダウンすることをお勧めします。
上記の除外メカニズムは、アクティブ/パッシブクラスター内で常に 1 つのサーバーのみがアクティブであるフェールオーバーアーキテクチャと互換性があります。これを確実に行うには、メインサーバーがプロパティ ebx.repository.ownership.mode=failovermain を宣言する必要があります。単一サーバーの場合と同様に、メインサーバーはリポジトリデータベースの所有権を主張します。
バックアップサーバーは引き続き起動できますが、リポジトリにアクセスすることはできません。バックアップサーバーとして機能するには、プロパティ ebx.repository.ownership.mode=failoverstandby を宣言する必要があります。さらに、両方のサーバーが ebx.repository.directory に同じ値を定義し、この値で定義されたディレクトリを共有するために必要です。(これは特に、Lucene インデックスを共有できるようにするためです。つまり、フェールオーバーサーバーの起動時にオンデマンドで再構築されません。) 起動すると、バックアップサーバーが接続ログに登録されます。そのステータスは、以下のリポジトリのステータス情報とログのセクションで説明されているように、JavaAPI または HTTPリクエストを介して取得できます。
バックアップサーバーをアクティブ化し、リポジトリの排他的所有権をサーバーに転送するには、HTTP リクエストによって、または Java API を使用して特定のリクエストを発行する必要があります。
HTTP を使用する場合、リクエストにはパラメーター activationKeyFromStandbyMode が含まれている必要があり、このパラメーターの値は、EBX® メイン構成ファイルのエントリ ebx.repository.ownership.activationkey に対して宣言されている値と同じである必要があります。フェールオーバーの構成を参照してください。
リクエスト URL の形式は次のようにする必要があります。
http[s]://<host>[:<port>]/ebx?activationKeyFromStandbyMode={value}
Java API を使用して、メソッド RepositoryStatus.wakeFromStandby を呼び出します。
メインサーバーがまだ稼働していてデータベースにアクセスしている場合は、以下が適用されます。バックアップサーバーはデータベースの所有権テーブルにマークを付け、メインサーバーのクリーンシャットダウンを要求します (ただし、実行中のトランザクションはすべて終了します)。メインサーバーが所有権を返した後でのみ、バックアップサーバーはリポジトリの使用を開始できます。
リポジトリへのすべての試行された Java プロセス接続のログは、[履歴とログ] > [リポジトリ接続ログ] の下の [管理] エリアにあります。
リポジトリのステータスは、RepositoryStatus API のメソッドを使用して取得できます。
次のいずれかの値を持つパラメーター repositoryInformationRequest を含む HTTP リクエストを使用して、リポジトリステータス情報を取得することもできます。
| 所有権登録に関するリポジトリの状態。
|
| データベースに関連付けられてからリポジトリが接続した回数。 |
| リポジトリの登録ステータスに関するエンドユーザー向けの詳細情報。この情報の形式は、明示的な警告なしに将来変更される可能性があります。 |
EBX® ユーザーインターフェイスの [管理] エリアから、いくつかのテクニカルテーブルにアクセスできます。これらのテーブルは内部使用のみを目的としており、古いデータや誤ったデータを削除しない限り、コンテンツを手動で編集しないでください。これらのテクニカルテーブルには次のものがあります。
自動インクリメント | リポジトリ内のすべての自動インクリメントフィールドを一覧表示します。 |
データベースアクセスとユーザー権限のルールに準拠することにより、リポジトリのインストールまたはアップグレードが自動的に行われます。
EBX® は、リポジトリの全コンテンツを別のデータベースにエクスポートする方法を提供します。エクスポートには、すべてのデータスペース、構成データセット、およびマップされたテーブルが含まれます。この移行を操作するには、次のガイドラインに従う必要があります。
ソースリポジトリをシャットダウンする必要があります：EBX® サーバープロセスがアクセスすることはできません。この要件に厳密に準拠していないと、ターゲットリポジトリが破損する可能性があります。
新しい EBX® サーバープロセスをターゲットリポジトリで起動する必要があります。ターゲットリポジトリは空である必要があります。従来の Java システムプロパティ -Debx.properties に加えて、このプロセスでは ebx.migration.source.properties (ソースリポジトリを指定する EBX® プロパティの場所) も指定する必要があります (ターゲットとソースの間に個別のテーブルプレフィックスを指定できます)。
その後、移行プロセスが自動的に実行されます。ただし、このプロセスはトランザクションではないことに注意してください。途中で失敗した場合は、最初からやり直す前に、ターゲットデータベースに作成されたオブジェクトを削除する必要があります。
移行が完了すると、例外がスローされ、ターゲットリポジトリにアクセスする EBX® サーバープロセスを強制的に再起動します。
制限：
マップされたテーブル (履歴、レプリケーション) を表すデータベースオブジェクトの名前は、データベースエンジンの制限 (最大長、予約語など) に準拠するために、ターゲットデータベースに移行するときに変更する必要がある場合があります。このような変更は、移行プロセス中にログに記録されます。
結果として、データモデル内のレプリケートされたテーブルに指定された名前は、データベース内の適合された名前と一致しません。このデータモデルの最初の再コンパイルでは、この不整合を修正する必要があります。
数値型の表現が異なるため、ターゲットデータベースエンジンがソースよりも精度が低い場合、xs:decimal 型の値が丸められる可能性があります。たとえば、Oracle の 10000000.1234567890123456789 の値は、SQL Server では 10000000.123456789012345679 に丸められます。
EBX® リポジトリのグローバルバックアップは、基盤となる RDBMS に委任する必要があります。データベース管理者は、基盤となるデータベースの標準のバックアップ手順を使用する必要があります。
アーカイブは、ebx.repository.directory 内の archives というサブディレクトリに保存されます (構成を参照) 。このディレクトリは、EBX® からの最初のエクスポート時に自動的に作成されます。
このディレクトリへのアクセスは、セキュリティのベストプラクティスで規定されているように慎重に保護する必要があります。また、手動でこのディレクトリを作成する場合は、EBX® プロセスが読み書き可能なアクセス権を持っていることを確認してください。さらに、EBX® はこのディレクトリを管理していないため、管理者はこのディレクトリをクリーンな状態に保つ責任があります。
2 つの EBX® 環境間でのファイルの転送は、FTP やネットワーク共有による単純なファイルコピーなどのツールを使用して実行する必要があります。
リポジトリには次の属性があります。
repositoryId | 会社の範囲内のリポジトリを一意に識別します。これは 48 ビット (6バイト) で、通常は 12 桁の 16 進数で表されます。この情報は、リポジトリに作成されたエンティティの UUID (Universally Unique Identifiers)、および履歴テーブルまたは XML 監査証跡に記録されたトランザクションを生成するために使用されます。この識別子は、RFC 4122 で指定されているように、「UUIDノード」の部分として機能します。 |
repository label | リポジトリの目的とコンテキストを識別するユーザーフレンドリーなラベルを提供します (例：「実稼働環境」)。 |
store format | 構造の現在のバージョンを含む、基盤となる永続化システムを識別します。 |
一部のエンティティは、EBX® の実行中に蓄積されます。
これらのエンティティを監視およびクリーンアップするのは、管理者の責任です。
リポジトリの永続性データソースは、RDBMS 監視を通じて監視する必要があります。
EBX® によって実行されるリクエストのパフォーマンスには、データベースがテーブルの最新の統計を計算している必要があります。データベースエンジンは定期的に統計の更新をスケジュールするため、これは通常問題にはなりません。ただし、テーブルが短期間に大幅に変更された場合 (たとえば、インポートによって多くのレコードが作成された場合)、統計を明示的に更新する必要がある場合があります。
履歴テーブルの場合、一部の UI コンポーネントは統計を使用して動作を調整し、ユーザーがコストのかかるリクエストを不本意に実行するのを防ぎます。
たとえば、テーブルに大量のレコードが含まれている場合、コンボボックスはユーザー入力を自動的に検索しません。この動作は、データベースの統計が最新でない場合にも発生する可能性があります。これは、実際にはそうではない場合でも、テーブルに大量のレコードが含まれていると見なされる可能性があるためです。
リポジトリからのデータスペース、スナップショット、および履歴の完全なクリーンアップには、いくつかの段階が含まれます。
キャッシュを最小サイズに保つために、未使用のデータスペースとスナップショットを閉じます。
データスペース、スナップショット、履歴を削除します。
削除されたデータスペース、スナップショット、および履歴に関連付けられている残りのエンティティをリポジトリから削除します。
キャッシュとリポジトリを適切なサイズに保つために、不要になったデータスペースとスナップショットをすべて閉じることをお勧めします。これは、次の方法で実行できます。
ユーザーインターフェイスの [データスペース] エリアを使用します。
[管理] エリアの [データスペース] の [データスペース / スナップショット] テーブルから、ワークスペースの [アクション] メニューを使用します。このアクションは、テーブルのフィルタリングされたビューで使用することができます。
Java API を介して、メソッド Repository.closeHome を使用します。
データサービスの [データスペースを閉じる] および [スナップショットを閉じる] 操作を使用します。詳細については、データスペースまたはスナップショットを閉じるを参照してください。
データスペースとスナップショットが閉じられると、データはリポジトリから安全に削除できます。
閉じたデータスペースとスナップショットは、[データスペース] の下の [管理] エリアで再度開くことができます。
データスペース、関連する履歴、スナップショットは、リポジトリから完全に削除できます。ただし、データスペースの削除は、必ずしもその履歴の削除を意味するわけではありません。2 つの操作は独立しており、異なる時間に実行できます。
データスペース、スナップショット、またはそれらに関連付けられた履歴の削除は再帰的です。Delete 操作は、選択したデータスペースのすべての子孫に対して実行されます。
データスペースまたはスナップショットの削除後、古いデータのリポジトリ全体の削除が実行されるまで、一部のエンティティが残ります。
特に、データスペースの完全な履歴は、リポジトリ全体の削除が実行されるまで表示されたままになります。データと履歴を完全に削除するには、削除とリポジトリ全体の削除の両方の手順を完了する必要があります。このプロセスは、パフォーマンスの問題のために 2 つのステップに分割されています。リポジトリの全体的なクリーンアップには時間がかかる可能性があるため、これにより、サーバーのオフピーク時に削除の実行を開始できます。
データスペースの履歴を削除するプロセスでは、削除が送信されるまで、またはユーザーが指定した日付までに記録されたすべての履歴トランザクションが考慮されます。削除操作が実行されると、後続の履歴操作は含まれません。新しいトランザクションを削除するには、データスペースの履歴を再度削除する必要があります。
今後、削除日を設定することはできなくなります。したがって、指定された日付は無視され、代わりに現在の日付が使用されます。
データスペース、スナップショット、および履歴の削除は、さまざまな方法で実行できます。
ワークスペースの [アクション] メニューボタンを使用して、[管理] エリアの [データスペース] の下にある [データスペース/スナップショット] テーブルから。このアクションは、テーブルのフィルターされたビューで使用できます。
Java API、より具体的にはメソッド Repository.deleteHome および RepositoryPurge.markHomeForHistoryPurge を使用します。
データサービスの [データスペースを閉じる] 操作 (パラメーター deleteDataOnClose および deleteHistoryOnClose を使用)、または [データスペースのマージ] 操作 (パラメーター deleteDataOnMerge および deleteHistoryOnMerge を使用) の終了時。
アイテムが削除されると、削除を実行して、その時点までに実行されたすべての削除から残りのデータをクリーンアップできます。削除は、次の方法で開始できます。
ユーザーインターフェイスから、ナビゲーションペインの [管理] エリアで [アクション] > [削除の実行] を選択します。
Java API、具体的にはメソッド RepositoryPurge.purgeAllを使用します。
タスクスケジューラを使用します。詳細については、タスクスケジューラを参照してください。
削除プロセスは、ディレクトリ ${ebx.repository.directory}/db.purge/ に記録されます。
次のエンティティを監視し、定期的にクリーンアップするのは管理者の責任です。
削除を実行して、すべての削除からの残りのデータ、つまり、その時点までに実行されたデータスペース、スナップショット、および履歴を削除できます。これには、廃止された永続的な検証レポート用に作成されたデータスペースとスナップショットが含まれます。削除は、ナビゲーション ペインの [管理] エリアで [アクション] > [削除の実行] を選択することで開始できます。
タスクスケジューラの実行レポートは、[管理] エリアの [タスクスケジューラ] セクションの [実行レポート] テーブルに保持されます。スケジュールされたタスクは、実行されるたびにこのテーブルに追加されます。実行が正常に終了しても、レコードは自動的に削除されません。したがって、古いレコードを定期的に削除することをお勧めします。
ユーザーインタラクションは、アプリケーションがサービス実行を開始して結果を取得するための信頼できる手段として、EBX® コンポーネントによって使用されます。これらは、ebx-interactions 管理セクションで保持されます。ユーザーインタラクションテーブルを定期的に監視し、必要に応じてクリーンアップすることをお勧めします。
ワークフローイベントは、[管理] エリアの [ワークフロー] セクションにあるワークフロー履歴テーブルに保持されます。データワークフローは、実行されるたびにこのテーブルに追加されます。実行が正常に終了しても、レコードは自動的に削除されません。したがって、古いレコードを定期的に削除することをお勧めします。
履歴をクリーンアップする手順は次のとおりです
プロセスの実行が削除されていることを確認します (ワークフローの [管理] エリアで [アクション] > [このワークフローを終了して消去] またはナビゲーションペインで [アクション] > [日付から消去する] を選択することで実行できます)。
履歴内のメインプロセスをクリーンアップします (ワークフロー履歴の [管理] エリアで [アクション] > [日付から消去する] またはナビゲーションペインで [アクション] > [選択したワークフローから消去する] を選択することで実行できます)。
「標準 EBX® パージ」を使用して、ワークフロー履歴の残りのエンティティを削除します。
EBX® の正しい動作を保証するために、EBX® は Lucene インデックスを除いてクリーンアップを実行しないため、次のディレクトリのディスク使用量とディスク可用性を管理者が監視する必要があります。
Lucene インデックス：${ebx.repository.directory}/indexes-(...)/
Lucene インデックス：インデックスには大量のディスクスペースが必要になる場合があります。これらは、EBX® が正しく機能するために重要です。名目上の使用法では、それらを直接削除または変更しないでください。ただし、これらのインデックスを削除する必要がある場合があります。
リポジトリが最初から再作成され、ディレクトリ ${ebx.repository.directory}/ が保持されている場合。データの一貫性を確保するために、インデックスのルートディレクトリを削除する必要があります。
より一般的には、インデックスがリポジトリデータと矛盾するようになった場合 (これはまれに不具合が発生する可能性があります)。
削除後、インデックスのコンテンツは、リポジトリのコンテンツから派生して、テーブルごとに遅延して再計算されます。削除はインデックスのルートフォルダーで行う必要があります。単一のディレクトリが下位レベルで削除されると、インデックスのグローバル構造に一貫性がなくなります。ただし、この操作にはコストがかかるため、通常は回避する必要があります。
XML 監査証跡：${ebx.repository.directory}/History/
アーカイブ：${ebx.repository.directory}/archives/
一時ディレクトリ：ebx.temp.directory
XML 監査証跡の場合、 (デフォルト設定とは逆に) 完全な更新の詳細をアクティブにして大規模なトランザクションを実行すると、必要なディスク容量が増える可能性があります。
データサービスの getChanges 操作でのページ付けには、一時ディレクトリで永続ストアが使用されます。大きな変更には、大量のディスク領域が必要になる場合があります。
一部のデータスペース管理タスクは、EBX® の [管理] エリアから [データスペース] を選択することにより、実行できます。
このテーブルには、開いているか閉じているかに関係なく、リポジトリ内の既存のすべてのデータスペースとスナップショットが一覧表示されます。このテーブルに含まれるデータスペースの情報を表示および変更できます。
このセクションから、開いているデータスペースを閉じたり、以前に閉じたデータスペースを再度開いたり、開いたデータスペースまたは閉じたデータスペース、関連する履歴、スナップショットを削除および削除したりすることもできます。
この表は、リポジトリ内のすべてのデータスペースで定義されているすべての既存の権限ルールを示しています。権限ルールを表示し、それらの情報を変更できます。
テーブル「削除されたデータスペース/スナップショット」には、リポジトリからすでに削除されているすべてのデータスペースが一覧表示されます。
このセクションから、削除されたデータスペースの履歴を削除することもできます。