Sender-Receiverの理解

インベントリサーバ上のSenderとReceiverは、下位のサーバから上位のサーバにスキャンファイルを転送します。詳細情報については、次の節を参照してください。

• Senderの理解
• Receiverの理解
• 圧縮されたスキャンデータファイルの理解
• Sender-Receiverのディレクトリ
• Str Converterの理解

Sender-Receiverは次の処理を実行します。

1. Service Managerが、Sender-Receiverコンポーネントを起動します。
2. Roll-Up Schedulerが、指定されたロールアップ時刻にSenderをアクティブにします。
3. Senderは、エンタープライズマージディレクトリ(entmergedir)からエンタープライズプッシュディレクトリ(entpushdir)にスキャンデータファイル(.str)を移動し、そのファイルを.zipファイルに圧縮します。
4. 各.zipファイルと.prpファイルが再度.zipファイルに圧縮されます。
5. Senderは、entpushdirディレクトリから次のレベルのインベントリサーバのReceiverに.zipファイルを送信します。
6. Receiverは、entpushdir\zipdirディレクトリに.zipファイルを保存します。
7. Receiverは、.zipファイルをentpushdirディレクトリにコピーし、entpushdir\zipdirディレクトリから.zipファイルを削除します。
8. データベースがサーバに接続されている場合、Receiverは、.zipファイルをデータベースディレクトリ(dbdir)にコピーします。
9. Sender-ReceiverはステータスをeDirectoryに記録します。

Senderの理解

Senderは、リーフサーバまたは中間サーバ上で実行されるJavaコンポーネントで、Service Managerによりロードされるサービスです。インベントリサーバ上のインベントリコンポーネントの概要のサーバコンポーネントの早見表を参照してください。

スキャンデータをロールアップする際のSenderからの情報の流れは次のとおりです。

1. Service Managerが、インベントリサーバ上のSenderを起動します。Senderは、ロールアップスケジュールで指定されている時刻に、エンタープライズマージディレクトリ(entmergedir)からエンタープライズプッシュディレクトリ(entpushdir)にスキャンデータ(.str)を移動します。

   Senderは、サーバのentpushdirディレクトリにあるこの.strファイルを.zipファイルに圧縮した後、.strファイルを削除します。この.zipファイルと.prpファイルは、再度.zipファイルに圧縮されます。詳細については、圧縮されたスキャンデータファイルの理解を参照してください。

2. Senderは、eDirectoryのInventory Serviceオブジェクト(ZenInvservice)のzeninvRollUpLog属性に、新しいレコードを作成します。このレコードには、Senderが.strファイルを圧縮したサーバおよび.zipファイルの名前とサイズなどの詳細情報が含まれます。
3. ReceiverのInventory Serviceオブジェクトプロパティの［Discard Scan Data Time］に基づいて、Senderは、指定されたスキャンデータ廃棄時刻より前に作成された.zipファイルをentpushdirディレクトリから削除します。これにより、ロールアップで送信される不要なスキャン情報を削除できます。
4. Senderは、圧縮した.zipファイルをReceiverに送信します。このとき、最も古い圧縮ファイルから送信します。
5. .zipファイルの転送後、Senderはentpushdirディレクトリ内の圧縮ファイルを削除します。
6. データのロールアップ後、Senderは圧縮ファイルを作成したサーバのzeninvRollUpLog属性を更新します。属性には、Senderがファイルを転送した送信元のサーバ、.zipファイル名、転送時刻、ファイルの転送に要した合計時間、送信先サーバなどの詳細情報が含まれます。

   Senderの全アクションのステータス情報は、ロールアップログとサーバステータスログに記録されます。詳細については、ステータスログを使ったWorkstation Inventoryの監視を参照してください。

Senderは、Receiverに接続できない場合、10秒後に接続を再試行します。再試行の間隔は、係数を2として指数的に増加します。 Receiverへの接続を14回再試行した後、再試行は中止されます。 中止まで、Senderは約23時間再試行を継続します。接続が確立している間、他のデータは処理されません。

Receiverの理解

Receiverは、中間サーバまたはルートサーバ上で実行されるJavaコンポーネントで、Service Managerによりロードされるサービスです。インベントリサーバ上のインベントリコンポーネントの概要のサーバコンポーネント早見表を参照してください。

Receiverは次の処理を実行します。

1. Receiverは、Senderからスキャン.zipファイルを受信します。受信したファイルはentpushdir\zipdirディレクトリに保存されます。
2. Receiverは、.zipファイルをentpushdirディレクトリにコピーし、entpushdir\zipdirディレクトリから.zipファイルを削除します。

   中間サーバで、ファイルはentpushdirにコピーされます。データベースが接続されている中間サーバ、またはデータベースとインベントリ対象ワークステーションが接続されている中間サーバで、ファイルは\entpushdirとデータベースディレクトリ(\dbdir)にコピーされます。

3. ルートサーバまたはインベントリ対象ワークステーションが接続されているルートサーバ上のReceiverは、Senderから.zipファイルを受信し、そのファイルをentpushdir\zipdirディレクトリに保存します。ファイルをサーバ上のDBDIRディレクトリにコピーします。
4. Receiverは、ステータス情報をロールアップログに記録します。詳細については、ステータスログを使ったWorkstation Inventoryの監視を参照してください。

圧縮されたスキャンデータファイルの理解

Senderはスキャンデータファイル(.str)を.zipファイルに圧縮します。この.zipファイルは、再度.prpファイルと共に圧縮され、さらに.zipファイルが生成されます。.zipファイル（.zipファイルと.prpファイルを含む)は、次の命名規則に従って名前が付けられます。

scheduledtimeinventoryservername_treename_storedstatus.zip

scheduledtimeは.zipファイルが作成された日付と時刻、inventoryservernameは.zipファイルが圧縮されたインベントリサーバ、treenameは.zipファイルが現在保存されているツリーの固有の名前、storedstatusは.zipファイルの保存ステータス、zipは圧縮ファイルの拡張子です。

storedstatusは、0、1、または2で示されます。0は、.zipファイルがまだ保存されていないことを示します。1は、.zipファイルがはじめてサーバに保存されることを示します。2は、.zipファイルが一度保存されたことがあることを示します。

.zipファイル名は、データベースがサーバに接続されているかどうかによって異なります。

.zipファイルには、.zipファイルとプロパティファイルが含まれています。プロパティファイルは、次の命名規則に従って名前が付けられます。

scheduledtimeinventoryservername.prp

プロパティファイルには、スケジュール設定されている時間、インベントリサーバ名、および署名が含まれています。署名は.zipファイルの認証に役立ちます。

各.zipファイルには最大1,000の.strファイルを含めることができます。

Sender-Receiverのディレクトリ

次の表は、Sender-Receiverが使用するディレクトリのクイックリファレンスです。

スタンドアロンサーバにはReceiverはロードされません。