MID サーバーのファイル同期の仕組み - トラブルシューティングガイドいくつかの機能とアプリケーションは、インスタンス内のレコードと添付ファイルを MID サーバー上のファイルに同期させるために、同じ MID サーバープラットフォームコードを共有しています。この記事では、トラブルシューティングに役立つ手順とコードについて説明します。 目次 関連するテーブル同期ジョブのトリガー方法 添付ファイルフィールドアクティブフラグ このシステムを使用するアプリケーションMID サーバーでのジョブの処理方法 ファイルの変更を認識する方法スクリプト済み SOAP サービスECC エージェントスクリプトファイルの [チェックサム] フィールドドメインセパレーション トラブルシューティングと既知の問題 クローンによって削除された添付ファイル添付ファイルをフォームにアップロード中に問題が発生しましたMID サーバーエージェントログの確認再同期を強制ディスクをチェックして、何が同期されたかを確認します変更を行わずにテーブルの再同期を強制するMID サーバーは、フォルダーとフィールドからのファイルは同期するが、添付ファイルからのファイルは同期しないレコードフィールドまたは添付ファイルは変更されたが、sys_updated_onは変更されなかった同じレコードの複数の添付ファイルスクリプトファイルと JAR ファイルには一意の名前が必要です一般的なヒント既知の制限関連問題 関連するテーブル テーブルでシステムを使用するには、MID サーバー同期ファイル [ecc_agent_sync_file] を拡張する必要があります。以下は、ITOM プラグインがインストールされている、Orlando の MID サーバー同期ファイルテーブルの拡張のスキーママップです。それ以来、さらに追加されています。 同期ジョブのトリガー方法 添付ファイル これらのいずれかのテーブルのレコードに添付ファイルが追加されると、そのファイルはすべての MID サーバーの MID サーバーインストールフォルダーツリー内のディスクに自動的に配置されます。インスタンスでファイルが変更されると、ファイルはすべての MID サーバーと自動的に再同期されます。 通常、同期は、添付ファイル [sys_attachment] テーブルでレコードが追加/変更/削除されたときに作成されるシステムイベントによってトリガーされます。イベント [sysevent] の名前は次のとおりです。イベントの Parm1 は添付ファイルが属するテーブル名です。 attachment.uploadedattachment.renamedattachment_deleted イベントごとにスクリプトアクション [sysevent_script_action] があり、すべて「MID サーバーファイル同期チェック」という名前で、MID サーバーにそのテーブルを再同期するように指示します。 スクリプトアクションは、イベントの Parm1 のテーブル名を使用して「MIDServerFileSync」スクリプトインクルードの「notifyMIDServers」関数を呼び出して、ECC キューテーブル [ecc_queue] 出力レコードを挿入します。 エージェント = mid.server.*ソース = FileChangename = <添付ファイルが含まれているテーブル>topic = SystemCommandキュー = 出力ステータス = 準備完了優先度 = 0 (インタラクティブ) ecc_queue の「プローブ - すべての MID」ビジネスルールは、その「mid.server.*」レコードをコピーし、各 MID サーバーに固有の出力を挿入します。すべての MID サーバーでは、稼働中かどうか、またはキュー内に準備完了ステータスの既存の重複があるかどうかに関係なく、ジョブが作成されます。 フィールド 2013 年以降、フィールドの内容を MID サーバー上のファイルにも同期できるようになりました。この場合、特定のテーブルに対するビジネスルールによって FileChange ジョブがトリガーされます。 アクティブフラグ 新しい MID サーバーは非アクティブなファイルを同期しません。MID サーバーの再起動時に同期が行われ、その時点で前回の同期以降に非アクティブになったレコードはすべて削除されます。 TODO - 少なくともWashingtonのJARファイル表では、「アクティブ」がオフになっている場合、同期はトリガーされません。これは欠陥である可能性があります。回避策:MID サーバーを再起動します。起動時に、非アクティブなレコードのファイルが削除されます。 このシステムを使用するアプリケーション 次の表に、各拡張テーブルクラス、その名前、それらを使用するアプリケーション、および上記の通常のイベントトリガー同期とは異なるものを示します。他の多くのものは MID サーバーのメモリキャッシュに同期されますが、ファイルとして終了しません。 テーブル使用場所添付ファイルまたはフィールドディレクトリエージェントクライアントコレクタープラグイン [sn_agent_asset]ITOM 機能、統合ハブ、脆弱性対応など添付ファイルstatic\acc_plugin\sn_agent_assetエージェント資産の変更時に MID に通知する」ビジネスルールは、「MIDNotificationHandler」スクリプトインクルード「notifyMIDServers」を呼び出して、上記と同様の ECC レコードを挿入します。エージェントクライアントコレクター構成ファイル [sn_agent_configuration_file]ACC プラグインのデータファイル添付ファイルstatic\acc_configディスカバリーパターン [sa_pattern]DiscoveryService Mappingフィールド:パターン [ndl]作業\NDL sa_pattern の「NDL 変更時に MID サーバーに通知する」ビジネスルールは、「PatternLibrary」スクリプトインクルード「notifyMIDs」関数を呼び出します。 sa_pattern の [MID サーバーと同期] UI アクションは、パターンのsys_updated_on値を更新して強制的に同期させます。これは、「PatternLibrary」スクリプトインクルードの「notifyMIDs」関数も呼び出します。これはリストアクションで、/sa_pattern_list.do リストのパターンでチェックボックスにチェックを入れると利用可能になります。 MID サーバーフォームの [MID にパターン同期] UI アクションは、「PatternLibrary」スクリプトインクルード関数を使用して、パターンやその他のパターン関連の同期を同期します。 これらの 3 つのメソッドはすべて、"MIDNotificationHandler" スクリプトインクルード "notifyMIDServers" 関数を呼び出して、上記と同様の ECC レコードを挿入する "PatternLibrary" スクリプトインクルード "notifyMIDs" 関数を使用します。 MID サーバー拡張 JAR ファイル [ecc_agent_ext_jar]TBC添付ファイルTBCMID サーバー JAR ファイル [ecc_agent_jar]インポートセット JDBC ドライバーOrchestration外部の認証情報ストアCloud Management (クラウド管理)添付ファイルextlibMID サーバー MIB ファイル [ecc_agent_mib]SNMP ディスカバリー添付ファイルwork\MIBMID サーバースクリプトファイル [ecc_agent_script_file]DiscoveryOrchestration 添付ファイルまたはスクリプト [script] フィールド。 scripts\<parent directories> ターゲットディレクトリは、レコードの親によって異なります。directory=true のレコードはフォルダー構造を定義するもので、実際のファイルではありません。 添付ファイルテーブル内の他のいくつかのビジネスルールによって、同期されたファイルレコードが更新されます。 挿入/更新:添付ファイルの変更時に MID スクリプトを更新します削除:添付ファイル削除時に MID スクリプトを更新します これにより、同期されたファイルレコードの次のフィールドが更新またはクリア/非アクティブ化されます。 script_attachment:添付ファイル [sys_attachment] レコードを参照するsys_id。これは、複数のファイルが添付されている場合に重要です。チェックサム:添付ファイルテーブル内のファイルの MD5 チェックサムuse_attachment - フィールド値ではなく添付ファイルを使用するように MID サーバーに指示しますアクティブ:ファイルが添付されていない場合は false を設定 アップロードされたファイル [sa_uploaded_file]Discovery and Service Mapping Patterns (ディスカバリーとサービスマッピングパターン)添付ファイル work/uploaded_files [MID サーバーと同期] UI アクションを使用すると、同期を強制できます。これにより、「SaUploadedFiles」スクリプトインクルードが呼び出され、「MIDNotificationHandler」スクリプトインクルード「notifyMIDServers」関数が呼び出され、上記と同様の ECC レコードが挿入されます。 「GetAllUploadedFiles」スクリプト化 SOAP サービスは、サービスマッピングがアップロードされたすべてのファイルを取得するために MID サーバーによって使用されます。 MID サーバーでのジョブの処理方法 各 MID サーバーでは、ecc_queueに独自の FileChange 出力があります。これはテーブルに固有のものです。 MID サーバーが稼働中で、インスタンスに接続されていて、利用可能なインタラクティブスレッドがある場合、MID サーバーは ECC キューからジョブをパックアップして実行します。 注:以下はすべて MID サーバーにコンパイルされた Java コードに含まれており、顧客が検査できるコードではありません。この処理の進行に伴い、MID サーバーエージェントログにログが追加されます。 SystemCommand オブジェクトは、ECC キュー出力の name フィールドをチェックし、これらが FileChange の場合は、タイプが同期するテーブルである SyncedFileChangeEvent を作成します。これにより、タイプに固有のSyncherを使用して、実際のSync用の新しいFileSyncWorkerスレッドが作成され、useAttachment、ターゲットフォルダ、使用するフィールドなどの属性が事前定義されます。 JarSyncer、MIBSyncer、ScriptFileSyncer、AssetFileSyncer 拡張 AFileSyncerNdlFileSyncer と SaUploadedFileSyncer は、DelayedFileSyncer を拡張します。遅延ファイル同期は、enabled フラグが変更されるまでファイルを同期しません。 その後、MID サーバーの FileSyncWorker コードがプロセスを管理します。まず、MID サーバーに同期する指定されたファイルセットのスナップショットを取得します。これは、インスタンスの「MIDFileSyncSnapshot」スクリプト化 SOAP サービス [sys_web_service] から要求されます。その要求が発生している証拠は、トランザクションログ [syslog_transaction] で URL「/MIDFileSyncSnapshot.do?SOAP」と書かれています。 ディレクトリを一度に 1 ディレクトリずつ再帰的に処理します。ディレクトリ内では、各ファイルは個別に処理され、スナップショットから次の属性を認識します。 useAttachment - 添付ファイルが存在する場合は true。これにより、使用されるモードが決まります。添付ファイルがスクリプトフィールドよりも優先されます (両方が存在する場合)。MIDFileSyncSnapshot は、ファイルの最新の添付ファイルが複数ある場合にのみ返します。代わりにフィールドを使用する場合は、False が指定されます。名前:sys_attachmentのfile_name、または添付ファイルがない場合は同期されたファイルレコードの名前。ID:sys_attachmentのsys_id、または添付ファイルがない場合は同期されたファイルレコードのsys_id時間:sys_attachmentのsys_updated_on/sys_created_on、または添付ファイルがない場合は同期されたファイルレコードのsys_updated_on。チェックサム:[同期されたファイル] レコードフィールドの sys_attachment の MD5 チェックサム (ecc_agent_script_fileレコードの場合)。 モードに応じて、IDownloadedFileWriter 関数は InstanceFormFieldToFileDownloader または InstanceFileDownloader を使用して、インスタンスからフィールドまたは添付ファイルを取得するようにスクリプト化された SOAP サービスから要求します。これは、インスタンストランザクションログでも確認できます。 MIDFieldForFileProvider - InstanceFormFieldToFileDownloader によって要求されました。MID サーバーがファイルとして書き込むために指定されたフィールドの値を、フィールドレコードの作成時刻および更新時刻とともにフェッチしますMIDServerFileProvider - InstanceFileDownloader によって要求されました。MID サーバーに同期されるファイルのファイルコンテンツを提供します。 /sys_attachment.do を使用して、インスタンスから MID サーバーに添付ファイルをダウンロードすることもできます。 インスタンスレコードにチェックサムが含まれている場合 (チェックサムはすべての添付ファイルecc_agent_script_file)、MID サーバーはダウンロードしたファイルと照合します。 ファイルの変更を認識する方法 ファイルを置き換える必要があるかどうかを判断するロジックは、ローカルファイルが存在し、その「最終変更」時間が インスタンス内のファイルのタイムスタンプ(レコード/添付ファイルsys_updated_on値)と4秒以上異なる(古いまたは新しい)場合、異なると見なされます。チェックサムまたはサイズは、ファイルを置き換えるかどうかを決定するために使用されません。 手動で削除されたためにディスクから欠落しているファイルは、このプロセスに置き換えられます。 次の場合、このプロセスによってファイルとディレクトリーを MID サーバーから削除することもできます。 ファイルが残っているか、MID サーバーフォルダーの 1 つに手動で配置されており、インスタンス内にありません。これらは許可されていないファイルと見なされ、削除されます。添付ファイルまたはレコードがインスタンスから削除されているか、フィールドのあるレコードが削除されています。ディレクトリレコードがインスタンスで削除されている場合、その親を持つすべてのレコードがインスタンスでカスケード削除されます。ディスク上で、フォルダとその内容が削除されます。ファイルが置き換えられました。ファイルは最初に削除され、次に新しいファイルに置き換えられます。 Windows では、起動時に JVM クラスローダーによってファイルロックが実行されるため、MID サーバーのシャットダウン後に JAR ファイルを削除する必要があります。このようなものは、Powershellスクリプトを使用して外部から削除され、この自動削除および置換プロセスにより、完了する前に最大3回の再起動が発生する可能性があります(バッチファイル、PSスクリプトTBCを使用)。インスタンスのトランザクションログを確認する場合は、再起動後に MID サーバーのセッション ID が異なることに注意してください。 San Diego、Rome パッチ 4、Quebec パッチ 10 より前のバージョンでは、代わりにバッチファイル「bin\filesyncdelete.bat」が使用されていました。 その外部削除 PowerShell スクリプト/バッチファイルのログは、 agent/logs/filesyncdelete.log に保存されます スクリプト済み SOAP サービス MIDFileSyncSnapshotディレクトリツリーを含む、一般的な同期の内容を MID サーバーに通知します。次に、各ファイルについて、次のいずれかが個別に要求されます。 MIDFieldForFileProviderフィールドにコンテンツがあるレコードの場合MIDServerFileProvider添付ファイル付きのレコードの場合 ECC エージェントスクリプトファイルの [チェックサム] フィールド Utah リリース以降、[チェックサム] フィールドの値を持たない (添付ファイルではなく) スクリプトフィールドに基づく MID サーバースクリプトファイルには、以下によって追加されます。 ビジネスルール「Generate Checksum For Scripts」修正スクリプト「スクリプトファイルのチェックサムを生成」アプリのインストール/アップグレードに関連するイベント:- plugin.upgraded、スクリプトアクション「プラグインのアップグレード時にチェックサムを生成」によって処理されましたplugin.activated、スクリプトアクション「プラグインアクティベーション時にチェックサムを生成」によって処理されました 添付ファイルを含むすべての ECC エージェント スクリプト ファイルの場合、MID サーバーはファイル同期中にこれらのチェックサムを検証します。これにより、ディスク上に作成されたファイルのチェックサムがインスタンス レコード フィールドから計算されたものと一致するようになります。 問題がある場合は、次のメッセージを含むMID サーバーの問題レコードが作成されます。"Checksum validation on MID server for <filepath> failed with checksum - <checksum>" ドメインセパレーション ecc_agent_script_fileテーブルには [ドメイン] フィールドがなく、指定された MID サーバーのみに同期を制限するためのフィールドもありません。すべてのインスタンスで、すべてのレコードは常にすべての MID サーバーに同期されます。 つまり、異なる MID サーバーまたは異なるドメインがそれぞれ同じファイルの異なるバージョンを持つことはできません。MID サーバーをすべてのファイルの取得から除外することはできません。 ideas portal で既存の拡張要求に賛成票を投じてください。 トラブルシューティングと既知の問題 単一のレコードを更新すると、そのテーブル内のすべてのレコードを再同期するジョブが作成されます。多数の MID サーバーで多数のレコードが同時に更新されると、重複によってパフォーマンスの問題が発生する可能性があります。 クローンによって削除された添付ファイル 添付ファイルが除外され、クローンによって保持されていない場合、クローン後に添付ファイルが欠落する可能性があります。これはsa_uploaded_file何度か確認されています。次を参照してください。KB0786475 MID サーバーとクローン 添付ファイルをフォームにアップロード中に問題が発生しました 添付ファイルのアップロードで考えられるエラー: ファイルタイプが許可されていないか、mime タイプがファイルコンテンツと一致しません。JAR ファイルを添付ファイルとして許可するようにインスタンスが構成されていない場合、jar がシステムプロパティ glide.attachment.blacklisted.extensions にリストされていることが原因である可能性があります。 フィールドペイロードに対してコンテンツが大きすぎます。最大長 (ストレージ): 16,777,215、圧縮長: 16,940,311 (またはファイルが何であれ)たとえば、大規模なJDBCドライバーから。これにより、添付ファイルの追加や MID サーバーへの同期は妨げられません。これは更新セット/バージョンシステムからのプラットフォームエラーであり、sys_update_xml/sys_update_versionテーブルのミディアムテキストの「ペイロード」フィールドを参照します。これは、ecc_agent_jarテーブルのバージョン管理/更新セット追跡をオフにすることで回避できますが、エラーは無視できるため、必須ではありません。MID サーバーケーストラッキングPRB1499103の問題チケット。 MID サーバーエージェントログの確認 MID サーバーを再起動すると、起動時にすべてのテーブルが再同期されます。すべてのテーブルが同期され、そのテーブル内ですべてのファイルがチェックされ、必要に応じて同期されます。特定のフォルダーのファイルは一緒に行われます。 エージェントログには、デバッグがなくても、起動時またはFileChange SystemCommandの実行時に同期されている各テーブルが表示されます。 2023-10-09T18:37:44.430+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:81] Starting file synchronization: sn_agent_asset...2023-10-09T18:37:45.231+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:141] Synchronizing 2 files to C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all2023-10-09T18:37:45.231+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:174] Synchronizing C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\app-ci-metrics-acc-commons.tar.gz2023-10-09T18:37:45.241+0200 INFO (FileSync:sn_agent_asset) [FileDownloader:35] Downloading C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\app-ci-metrics-acc-commons.tar.gz from https://<instance>.service-now.com/sys_attachment.do?sys_id=ae33d183530221102f10ddeeff7b124b2023-10-09T18:37:45.241+0200 DEBUG (FileSync:sn_agent_asset) [AAttachmentFileDownload:45] Downloading attachment using UnsignedAttachmentFileDownload2023-10-09T18:37:45.610+0200 INFO (FileSync:sn_agent_asset) [AAttachmentFileDownload:84] Attachment successfully downloaded 1908 bytes2023-10-09T18:37:45.610+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:174] Synchronizing C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\acc-f-commons.tar.gz2023-10-09T18:37:45.610+0200 INFO (FileSync:sn_agent_asset) [FileDownloader:35] Downloading C:\MID SERVER\ServiceNow MID Server mid_server_dev\agent\static\acc_plugin\all\all\all\all\acc-f-commons.tar.gz from https://<instance>.service-now.com/sys_attachment.do?sys_id=f0378b99d1047110f877eca2213bddee2023-10-09T18:37:45.610+0200 DEBUG (FileSync:sn_agent_asset) [AAttachmentFileDownload:45] Downloading attachment using UnsignedAttachmentFileDownload2023-10-09T18:37:45.833+0200 INFO (FileSync:sn_agent_asset) [AAttachmentFileDownload:84] Attachment successfully downloaded 12619 bytes...2023-10-09T18:38:05.534+0200 INFO (FileSync:sn_agent_asset) [FileSyncWorker:92] Finishing file synchronization: sn_agent_asset 再同期を強制 このようなecc_queueレコードを手動で挿入して、インスタンス内の何も変更したり MID サーバーを再起動したりすることなく、強制的に再同期することができます。 エージェント = mid.server.*ビジネス ルールは、各 MID サーバーに対してこのレコードを自動的に複製します。ソース = FileChange名前 = <添付ファイルがあるテーブル>例:ecc_agent_jartopic = SystemCommandキュー = 出力ステータス = 準備完了優先度 = 0 (インタラクティブ)標準の優先度でも正常に機能しますが。 これは、たとえば、JAR ファイルが非アクティブとマークされ、すぐに再同期をトリガーしなかった場合 (潜在的な欠陥) に役立ちます ディスクをチェックして、何が同期されたかを確認します この DIR コマンドを使用した mid.server.* のecc_queue出力には、入力内のさまざまなフォルダーに何が同期されたかが表示されます。 エージェント:mid.server.*[トピック]：コマンドName (名前)： dir /b /s static\*.*dir /b /s scripts\*.*dir /b /s work\mibs\*.*など キュー:出力ペイロード:<parameters><parameter name="skip_sensor" value="true"/></parameters> dir、ls、chmod、またはその他のコマンドとスイッチの組み合わせを使用して、日付、サイズ、権限などを確認できます。 変更を行わずにテーブルの再同期を強制する この SystemCommand を使用した mid.server.* のecc_queue出力では、顧客インスタンスを変更することなく、テーブルの再同期が強制されます。 エージェント:mid.server.*トピック:SystemCommandName (名前)： sn_agent_assetecc_agent_jarecc_agent_script_fileなど ソース: FileChangeキュー:出力 コード署名 Xanadu以降、同期されたテーブル内のほとんどのOOTBレコードには、OOTB署名が付与されるようになりました。Washington DC以降、ファイルに署名が生成されていない場合、次のようなエラーが表示されます。 SOAPProcessorThread... SignatureUtil SEVERE *** ERROR *** Unable to find the signature with the sys id, bb3d1f433ca68210b1b3fd8eb2644ca6, for the table, sn_agent_asset. com.glide.codesigning.exception.CodeSigningException: Cannot just-in-time load the signature record: Couldn't find pluginId for documentId: bb3d1f433ca68210b1b3fd8eb2644ca6 with signatureRecordSysId: 16b5e7ab6a3d44b8849161d672273e91 at com.glide.codesigning.output.JustInTimeLoadingEngine.loadSignatureRecordJustInTime(JustInTimeLoadingEngine.java:89) インスタンスでコード署名を有効にしていても署名がない場合、同期がブロックされ、署名に依存するすべての機能が動作しなくなります。 一般的な詳細と、この機能がまだサポートされていないものについては、こちらを参照してください。KB1646201 MID Server and Code Signing - Unable to find the signature / Cannot just-in-time load the signature record / Failed to verify signature MID サーバーは、フォルダーとフィールドからのファイルは同期するが、添付ファイルからのファイルは同期しない 添付ファイルは存在するが同期されていない場合は、MID サーバーログインユーザーの添付ファイルの ACL の問題が原因である可能性があります。 MID サーバーのログインユーザーは、テーブルレコードの ACL だけでなく、添付ファイルのsys_attachmentテーブル ACL にも合格する必要があります。 たとえば、sn_agent_assetの場合、すぐにディレクトリツリーが定義され、いくつかの添付ファイルがあります。 セキュリティのデバッグをオンにするアドミン/メンテナンスとして、テーブルが「はテーブル」でフィルタリングされたsys_attachmentのリストを開き、添付ファイルが存在することを確認しますMID サーバーユーザーの代理操作を行います (Web サービスアクセスのみで代理操作できるようにするには、ユーザーに対して = false を行います)リストを更新し、失敗している ACL を確認します。CONTEXT が添付ファイル名である「レコード/sys_attachment/読み取り」ACL を探します。これらの ACL をクリーンなインスタンスと比較します 初期設定では、添付ファイルが添付されているレコードを読み取ることができる場合、添付ファイルを読み取る権限を付与するのはこの ACL です。/sys_security_acl.do?sys_id=0bcf23740a6a38d400c7e02590038464 その ACL にはスクリプトがあるだけです。条件はありませんが、インストールされている他のプラグインによってはロール要件がある場合があります。 明示的なロールプラグインがインストールされている場合、MID サーバーユーザーはsnc_internalを追加する必要があります。 クエリービジネスルールにも注意してください。 レコードフィールドまたは添付ファイルは変更されたが、sys_updated_onは変更されなかった このシナリオには、次の製品機能拡張の問題が存在します。 PRB1639539 MID サーバーは、新しい挿入/更新 xml の [sys_updated_on] フィールドに基づいてのみインスタンスとファイルを同期します つまり、ServiceNow 開発によって初期設定のレコードが変更されても、sys_updated_on値を変更しないと、MID サーバーはそのレコードが変更されたことを認識しません。 既存の MID サーバーは、古いバージョンのファイルに残ります。変更以降初めて同期された新しい MID サーバーにのみ、新しいファイルがあります。 同じレコードの複数の添付ファイル 最終的に同じレコードに複数の添付ファイルがある場合、どの添付ファイルが MID サーバーに同期されるかはランダムになります。それらはすべて同期されるわけではありません。 添付ファイルを使用する場合は、レコードごとに 1 つの添付ファイルのみを設定できます。 スクリプトファイルと JAR ファイルには一意の名前が必要です オーケストレーションワークフローアクティビティは、sys_idではなく MID サーバースクリプトファイルレコードの名前で PowerShell スクリプトを参照します。つまり、これらのレコードの名前は一意である必要があります。 JAR 添付ファイルは添付ファイルと同じ名前を保持し、最終的に同じ extlib フォルダーに格納されるため、一意である必要があります。Windows のファイル名では大文字と小文字が区別されないため、チェックでは大文字と小文字が区別されません。 ビジネスルール「Prevent Duplicate,Spaces & Colon in name」および「Validate MID Jar filename uniqueness」は、挿入と更新を中止することによってこれを強制します。ただし、XML としてインポートされたレコード (場合によっては更新セット) は、これらのチェックをバイパスする場合があります。 JAR は extib に手動でコピーされましたか、それとも lib に配置されましたか？ extlib 内の ecc_agent_jar テーブルに存在しないファイルは、次回の同期時または MID サーバーの再起動時にディスクから削除されます。これはセキュリティ上の理由です。インスタンスに JAR ファイルレコードを作成するための管理者ロールを持つユーザーのみが、MID サーバーに Java クラスを追加できます。 jar を手動で lib フォルダーにコピーした場合、これも次回の自動アップグレード時に自動的に削除されます。 一般的なヒント 通常、上記の UI アクションをクリックすると、ほとんどの同期の問題が解決します。 ecc_queue出力が表示されない場合は、セッションデバッグを使用してビジネスルールが実行されていることを確認できます。sysevent テーブルをチェックすると、添付ファイルイベントが作成されたかどうかが表示されます。 ecc_queue出力が表示された場合は、準備完了状態でスタックしていませんか?MID サーバーは稼働しており、正常ですか?エージェントログには、実行中のジョブが表示されますか?ジョブの開始と終了のログエントリについて、エージェントログにsys_id ecc_queue出力レコードが表示されます。FileSyncWorker スレッドからのログには、スナップショット、ダウンロード、およびファイル操作に関する問題が表示されます。 ecc_queue入力には、MID サーバーコードからのエラーメッセージが表示される場合があります。mid.log.level MID サーバーパラメーターがデバッグに設定されている場合、MID サーバーエージェントログには多くのログが記録されます。 レコードごとに 1 つの添付ファイルのみが存在することを確認してください。 Package=MID サーバーまたはパターンデザイナーの関連するすべての Scripted SOAP Services が、現在の OOTB バージョンであることを確認します。 同じホスト上の他の MID サーバーまたは他のホストとの動作を比較します。インスタンスとサービスのユーザーが同一または異なる MID サーバー。新しいクリーンな MID サーバーをインストールすると、問題がある場所を絞り込むのにも役立ちます。 フォルダーの権限が MID サーバーの起動時にチェックされるようになりましたが、古いバージョンではその原因である可能性があります。 gs.log() をスクリプト化された SOAP Services のさまざまな場所に追加して、処理されているファイルや添付ファイルをより明確に把握できます。 Topic=Command ecc_queue出力を使用して、"dir /s" や "ls -lsR" などの [名前] フィールドでコマンドを使用して、ターゲット フォルダー内のファイルをリモートで確認でき、ecc 入力にはタイムスタンプとファイル サイズを含む直接リストが含まれます。 既存のインストールフォルダーをコピーして新しい MID サーバーをインストールすることは避けてください。最初からインストールし、起動時に MID サーバーが完全同期を実行できるようにすることをお勧めします。 ある顧客のケースでは、古い外部JVMを実行したためにパターンの更新に失敗し、エージェントログに明らかなエラーはありませんでした。これを解決するために、代わりにバンドルされた agent/jre/bin を使用するように wrapper-override.conf を編集します。 添付ファイルを完全にダウンロードできない、または破損した添付ファイルをダウンロードする場合は、インスタンスデータベースに問題がある可能性があります。インスタンスレコードから添付ファイルを手動でダウンロードして、ファイルが正しいことを確認できます。SOAP Web サービスへの要求はトランザクションログに表示されますか?アプリノードのlocalhostログにエラーが表示されますか? 既知の制限 KB0813383 JAR ファイルをすべての MID サーバーではなく、特定の MID サーバーにプッシュできますか - クイックアンサー:いいえ。これは、ドメインごとのJARファイルにも適用されます。KB1182832 インスタンスからの JAR ファイル同期を使用せずに、MID サーバーで Java クラスを追加または置換します 関連問題 PRB1433170 / KB0862383 MID サーバー上の Oracle/MSSQL/MySQL JDBC ドライバーの jar ファイルは、JAR ファイルテーブルではなく lib フォルダーにあるため、これらのデータベースのすべてのバージョンと互換性を持たせるために、異なるバージョンと入れ替えることはできませんMID サーバーの lib フォルダーに含まれている PRB1441208/KB0862614 Oracle JDBC ドライバー 11.2.0.3.0 は古く、Oracle 8i 以降と互換性がありませんサードパーティの Evanios EVAgent JAR ファイルKB1192296、log4j クラスと slf4j クラスが無限ループで相互に呼び出すため、さまざまなスレッドの MID サーバースタックがクラッシュするまた、新しいバージョンのパターンが古いバージョン (TBC) と同じupdated_on値になるパターンの問題も発生しています。