開始ボタンを押す、または統合が自動で起動するのはトラブルシュート不要に思えますが、実は統合サイクルの最初の重要なステップです。このステップで統合はトリガーの監視を開始します。何か問題があったり、トリガーの場所が利用できなくなっている場合、統合は無限に待機し続けたり、エラーになることがあります。

統合の種類ごとに、この情報の名称は異なりますが、統合ファイル内で設定が必要です。すべての統合タイプで、統合の設定はIntegrationセクションの最初のサブセクションにあり、何を監視しているかが記載されています。このスクリーンショットではファイル統合なので、「File Detection」と表示され、ファイルをトリガーとして監視しています。

このステップでよくある問題は、権限、ファイル名、トリガー設定に関するものです。Integration Builderで統合を開始しようとすると、問題があればすぐにエラーが表示されます。

このステップでよくある統合タイプごとのシナリオを紹介します：

ファイル統合

ファイル統合では、権限とファイルの場所が非常に重要です。

• スキャンフォルダの場所は正しく入力されていますか？
• クラウドストレージの場合、ユーザー名やパスワード、シークレットキーは正しいですか？
• 現在のユーザーにこのフォルダへのアクセス権がありますか？「マイドキュメント」やネットワークドライブのマッピング先などは、権限が複雑になるため推奨されません。
• 統合は、ファイルをドロップしている正しいフォルダを監視していますか？

統合がフォルダにアクセスできない場合、権限エラーやアクセスエラーで停止することが多いです。スキャンフォルダには仮想ドライブレター（物理ドライブでないもの）やマイドキュメント、デスクトップは使用しないことを推奨します。

また、スキャンフォルダはWindowsベースのシステム上にホストすることをおすすめします。UnixやLinuxなど他のOSでスキャンディレクトリをホストする場合は、FTPなどのクラウドロケーションの利用を検討してください。

ネットワークフォルダの場合は、統合の権限を昇格させて適切なアクセス権を持たせてください。

データベース統合

データベースへのアクセスが重要です。以下を確認してください：

• データベースはオンラインですか？
• ユーザー名とパスワードは正しいですか？

これらの設定はすべて接続設定ダイアログで確認できます。ラベルのデータベース接続のトラブルシューティングと同様に、「Database Connection Setup...」ボタンからダイアログを開くことで、正しく接続できているか確認できます。接続できない場合はエラーが表示されます。

ソケット統合

ネットワーク接続が非常に重要です。接続できない場合は、まず接続自体を確認しましょう。

• ポートは開いていますか？
• ファイアウォールやウイルス対策ソフトが干渉していませんか？
• 同じポートを他の何かが使用していませんか？

統合には空いているポートが必要です。他のものがポートを使用している場合、統合は通常エラーとなり、ポートが利用できないと表示されます。他の統合と同様に、エラーメッセージが原因と対処法を教えてくれることが多いです。

ポイントまとめ

このステップは統合タイプごとに異なりますが、すべてに共通するトラブルシューティングのポイントがあります：

• 権限が非常に重要です。
• 統合がトリガーにアクセスできることを必ず確認してください。
• 失敗すると、統合開始時にエラーとなることが多いです。

統合が開始されたら、トリガーが届くのを待つ段階です。一見トラブルシューティング不要に思えますが、もし永遠に「待機中」から進まない場合はどうしますか？トリガーが全く届かない場合は？「何も起こらない」状態で止まっている場合、このステップのトラブルシューティングが役立つかもしれません。

すべての統合タイプは、何かが発生するのを待ちます。ファイル、ネットワークポート経由のデータ、テーブル内のレコード、特定の時刻などです。トリガー検出の設定は、前のステップと同じく、Integrationヘッダー直下の最初のサブセクションに記載されています。

よくある統合タイプごとに、以下の点を確認してください：

ファイル統合

• トリガーファイルは、統合で指定されたスキャンフォルダに配置されていますか？
• トリガーファイルは、期待されるファイルパターンと一致していますか？（例：.csvを監視しているのに.cssを置いた場合、パターンが一致しません）
• 他の統合が先にファイルを取得していませんか？

データベース統合

• データは正しいテーブルに挿入されていますか？
• データ検出方法は正しいですか？（例：増分値を監視しているのに、日付時刻スタンプを更新している場合、検出方法が一致しません）
• 監視しているフィールドが増分されている、または日時スタンプが更新されていますか？

ソケット・Webサービス統合

• データは正しいアドレスに送信されていますか？
• ファイアウォールがポートをブロックしていませんか？

ポイントまとめ

• トリガーが正しい場所に届いているか確認してください。
• 検出前にトリガーをブロックしたり取得しているものがないか再確認してください。

前のステップと同様に、このステップも単純に動作するように思えますが、時にはエラーが表示されることもあり、また別の時には統合サイクルが繰り返されて初めて問題が明らかになることもあります。

このアクションは、統合がデータを受け取った後に何をするかに関わります。検出後アクションを使用する統合は2種類のみで、他のタイプはこのステップをスキップできます。以下は、検出後アクションがある統合で確認すべき点です：

ファイル統合

すべての統合タイプの中で、このステップで最もエラーが発生しやすいのがファイル統合です。検出後アクションで問題が発生すると、統合はエラーを出して原因を教えてくれます。よくある問題は、ファイルやフォルダの変更権限やファイルパスの誤りです。

ファイル統合の検出後アクションはここに表示されます：

ソケット統合

このステップでのソケット統合の問題は、ファイル統合ほど明確ではありません。比較的静かなソケット統合の場合は問題がないかもしれませんが、忙しい場合は「Error: Cannot access disposed object.」というエラーが時々表示されることがあります。

これは、データ受信後にソケットが閉じられず、新しいデータが次々と押し寄せている状態です。統合が新しいデータを処理できず、ゴミデータとみなして破棄してしまうため、印刷が抜け落ちることがあります。

このような現象が見られる場合は、こちらの記事を参考にしてください：ソケット統合実行時の統合エラー。

ポイントまとめ

• このステップは特定の2種類の統合に該当します。
• このステップでのエラーは必ずしも明確に現れるとは限りません。

インテグレーションアクションとは、ラベルを処理・印刷するためにインテグレーションが実行するすべてのステップのことです。すべてのアクションはアクションヘッダーの下に一覧表示されます。

この例は非常にシンプルで、印刷アクションのみが含まれています。しかし、インテグレーションによっては、ループ処理、データ解析、メッセージやメールの出力、条件分岐など、複数のステップが含まれる場合もあります。以下は、トリガーからデータを一連の「検索」と「削除」アクションで抽出し、そのデータを「ドキュメント印刷」アクションで使用する、より複雑な例です。

このようにステップが複雑になると、問題が発生するポイントも増えます。最善の方法は、まずシンプルに始めることです。アクションを最小限に絞り込み（通常は「新規」メニューから新しいインテグレーションを作成した際に使われるアクションと、データ処理に最低限必要なものだけ）、そこから始めましょう。

• 余分なステップを省き、まずは最小限に抑えましょう。
• 1つずつステップを追加し、そのアクションに問題がないかテストしましょう。

このステップで最大の課題はテストです。もしインテグレーションサイクルの後半に問題がある場合、すべてのステップをテストしても問題は残り続けます。それでも、このステップで全てを再確認することは非常に重要です。インテグレーションの最小限のステップでよく発生する問題を以下に挙げます。

ドキュメントの場所

ラベルを印刷するには、インテグレーションがドキュメントを開ける必要があります。ドキュメントの場所や名前が無効な場合、インテグレーションはドキュメントエラーを出し、ドキュメントのオープンに問題があることを示します。ドキュメント名は以下の場所で確認できます。

• ドキュメント印刷アクション：ドキュメントタブの「ドキュメント」セクション。ドキュメントが変数で決まる場合は、その変数がどこから来ているか（通常はデータベースのフィールド名、変数設定アクション、または検索アクションのいずれか）をたどり、その変数のデータが正しいか確認してください。
• コマンドスクリプト印刷アクション：トリガーデータ内の /AF パラメータ
• BTXML印刷アクション：トリガーデータ内の <Format> タグ

ドキュメント印刷アクションにドキュメントが指定されていない場合、インテグレーションを開始しようとすると、ドキュメントが見つからないというエラーメッセージが表示され、すぐに停止します。

プリンター名

ドキュメントがなければ印刷できないのと同様に、有効なプリンターがなければ印刷できません。多くの場合、インテグレーションは無効なプリンターエラーや Windows エラーコード1801（Windowsがこのプリンターで問題を検出）を出します。後者はWindows側の修正が必要なため、このトラブルシューティングの範囲外です。前者は以下の場所で確認できます。

• ドキュメント印刷アクション：印刷オプションタブの「プリンター」欄
• コマンドスクリプト印刷アクション：トリガーデータ内の /P パラメータ
• BTXML印刷アクション：トリガーデータ内の <Printer> タグ

プリンターが指定されていない場合、インテグレーションはラベルに保存されているプリンターを使用します。インテグレーションでプリンターを指定していない場合は、BarTender Designerでラベルを開き、ファイル > 印刷 を確認してください。これがインテグレーションで使用されるプリンターです。

時々、ラベルが予期しないプリンターで印刷されたり、どこにも出力されないことがあります。これはプリンターのリダイレクト機能が働き、最初に利用可能なプリンターに印刷ジョブが送られるためです。このような現象が見られる場合は、以下の記事を参照して問題を解決してください：インテグレーション印刷が誤ったプリンターやランダムなプリンターに送信される場合。

データベースの種類やフィールド名の不一致

インテグレーションでデータベースを使用し、データを受け取る場合、データベースの種類が一致している必要があります。例えば、ラベルがカンマ区切り（CSV）のデータベースに接続されているのに、インテグレーションがタブ区切りやXMLなど全く異なる形式のデータを送信している場合、データベースの種類が一致せず、ドキュメントがデータを正しく認識できません。これにより、データベースやフィールド、空データに関するさまざまなインテグレーションエラーが発生することがあります。

また、データベースの種類が一致していても、フィールド名や順序が異なる場合も同様のエラーが発生します。

データベースが正しく一致しているか再確認するには、以下の方法があります。

• BarTender Designerでラベルファイルを開き、ファイル > データベース接続の設定 を選択します。このダイアログで、ラベルに接続されているデータベースの種類やフィールド名を確認できます。
• さらに、この設定ダイアログで接続されているデータベース名を確認し、パソコン上で開いて形式（例：CSVかタブ区切りか）やフィールド名を再確認してください。
• 接続されているデータベースとトリガーに含まれるデータを比較してください。

ラベルのデータベースがテキストファイル以外（またはBarTender 2019 R5以降のExcelファイル以外）の場合、インテグレーションは必ずデータベース不一致で失敗します。サポートされていないデータベースに接続されている場合は、サポートされているものに接続し直し、ラベル上のオブジェクトも新しいフィールドを参照するよう再設定してください。

ラベルが初期値データのみ表示される

これは、印刷時にインテグレーションがラベルにデータを渡していない場合に発生します。多くの場合、インテグレーション側でその指示がされていない（デフォルト動作）ことが原因で、「ドキュメント印刷」アクションでのみ発生します。以下はこの問題が起きる2つのケースとその対処法です。

• データベース情報の受け渡し：インテグレーションで情報を上書きするよう指示する必要があります。これは「ドキュメント印刷」アクションの「印刷オプション」タブ内の「データベースの上書き」セクションで設定できます。トリガーデータをラベルに渡すには、インテグレーションデータ または EventData でデータベースを上書きしてください。
• 名前付きデータソースが定義されていない：インテグレーションでは、変数とラベル上の名前付きデータソースをどのように対応させるかを指定する必要があります。同じ名前の名前付きデータソースが「名前付きデータソース」タブに表示されていない場合は、「ドキュメント」タブの「ドキュメント設定のインポート」ボタンをクリックし、インポートした名前付きデータソースとインテグレーション変数を対応させてください。

ポイントまとめ

• このステップのトラブルシューティングは、アクション数を最小限に減らし、1つずつ追加して問題箇所を特定するのが効果的です。
• このステップではデータに関する問題が多いので、ここで修正しておくと次のステップでのトラブルを防げます。

インテグレーションサイクルの印刷部分は、BTXMLと呼ばれるフォーマット済みXMLデータに依存しています。BTXMLには、ドキュメントやプリンターの情報、トリガーファイルからラベルに渡すデータなどが含まれます。

自分でBTXMLを作成し、「BTXML印刷」アクションでインテグレーションに送信することもできますが、その必要はありません！インテグレーションは、印刷アクションで設定したデータや設定を自動的にBTXMLに変換します。

前のステップまでのトラブルシューティングをすべて終えていれば、BTXMLは問題なく変換され、次のステップに進むことができます。

インテグレーションサイクルの最後のステップ（繰り返しの前）は、実際の印刷処理です。これはすべてPrint Schedulerサービスによって自動的に処理され、シンプルな流れに従います。この記事冒頭のフローチャートの一部を以下に示します。

サイクルの前のステップからBTXMLスクリプトがPrint Schedulerに送信されると、すぐにこの処理が始まります。サービスはPrint Engineを起動し、どのラベルファイルを開くべきか（すでにエンジンで開かれていない場合）を判断します。ドキュメントが開かれると、インテグレーションから送信されたデータが、データベースの上書きや名前付きデータソースを通じてラベルの正しい場所に配置されます。データ処理が終わると、BTXMLで指定されたプリンター、またはラベルにリンクされたプリンターにラベルが送信されます。

これらがすべてサービスで自動的に行われますが、問題が発生した場合はどうすればよいでしょうか？どのようにトラブルシューティングすればよいでしょうか？前のステップでほとんどの作業を終えているため、このステップのトラブルシューティングは思ったより簡単です。

このガイドの冒頭でも触れましたが、Print Schedulerサービスが使用するPrint Engineは、実際にはサービスとして動作するBarTender Designerです。つまり、このステップのトラブルシューティングはDesigner自体を使って行うことができます。

基本的なトラブルシューティング

印刷時、Print EngineはBTXMLスクリプトの指示通りにラベルファイルを自動で印刷します。このスクリプトを模倣するには、ラベルを開いてファイル > 印刷を選択し、プリンター名を変更してドキュメントを印刷します。BTXMLスクリプトには他にもいくつか追加の処理がありますが、このシンプルな操作だけでも、見えないPrint Engineで何が起きているか多くのことが分かります。

ドキュメントのオープンと印刷

Print Engineの最も基本的な動作は、ドキュメントのオープンと印刷です。前のステップでドキュメントが正しい場所にあることを確認しましたが、実際に開いてみることで、印刷時にPrint Engineがドキュメントを正しく扱えるか確認できます。

• ドキュメントを開いてみてください。正常に開きますか？エラーやメッセージが表示されますか？
• ドキュメントを印刷してみてください。正常に印刷されますか？エラーや警告が表示されますか？

どちらかで警告やエラーのダイアログが表示された場合、それが自動印刷処理の妨げになっている可能性があります。次のセクションでこれらのダイアログへの対処法を説明します。

エラーや警告のダイアログ

Print Engineは多くのダイアログボックスを自動でスキップできますが、中には印刷をスキップしたりエラーで停止させるものもあります。Print Engineがこれらの情報をインテグレーションのログに正しく伝えない場合もあるため、ここでダイアログが表示されていないか確認することが問題解決の手助けになります。

以下は、スキップされることがあるものの、インテグレーションの問題の原因となりうるダイアログの例です。

• ページ調整ダイアログ：プリンターの用紙が少し異なる場合、BarTenderは自動でラベルを調整します。ラベルの見た目がおかしい場合は、用紙の違いが原因かもしれません。ラベルを調整し、インテグレーションで使用するプリンターで保存して、このダイアログが表示されないようにしましょう。
• クリッピング警告：BarTender 2019の初期バージョンでは、この警告が印刷を停止させるエラーでした。ここで印刷が止まる場合は、ソフトウェアを最新版にアップデートしてください。
• TrueTypeフォントの代替メッセージ：このメッセージは印刷ダイアログでオフにできます。スキップできないため、ダイアログをオフにすることをおすすめします。

以下は、印刷を停止させたりエラーを発生させる可能性があるダイアログです。これらはインテグレーションのメッセージにも表示される場合があります。

• ページサイズダイアログのエラー：テンプレートが固定サイズに設定されている場合や、プリンターの仕様を超えるサイズの場合、インテグレーションが自動でドキュメントサイズを変更できず、このメッセージが表示されることがあります。この場合は、ファイル > ページ設定でページダイアログを開き、「ページ」タブの詳細や設定を確認してください。「レイアウト」タブで列や行が多すぎないかも確認しましょう。
• データベース接続エラー：データベースファイルが移動されたり利用できなくなった場合に発生します。ファイル > データベース接続の設定でリンクを再設定し、ドキュメントを保存してください。
• テンプレートがデータベースフィールドを参照していない：詳しくはエラー3600：テンプレートがデータベースフィールドを参照していませんをご覧ください。
• 画像やリンクオブジェクトの欠落：リンクされた画像やオブジェクトが移動されたり、ネットワーク上の場所が利用できなくなった場合にこのエラーが表示されます。BarTenderは、オブジェクトや画像が再リンクされるまで印刷しません。
• TMPに関するエラー：ラベルやリンクされたリソースが破損している可能性があります。ラベルのバックアップから復元するか、作り直すことをおすすめします。

ここに挙げたのは一部ですが、トラブルシューティング時によく遭遇する問題をカバーしています。

ポイントまとめ

• この自動処理のステップは、BarTender Designerを使って確認できます。
• ダイアログが問題の手がかりになることが多いです。

問題が統合サイクル内で直接見つからない場合もあります。この記事で紹介していないさまざまな状況に対応するための追加リソースを以下にご案内します。

一般

統合が突然停止する

統合が停止する理由はさまざまですが、主な原因の多くは上記の記事で説明しています。ここで挙げていない最も一般的な理由は、リソースが突然利用できなくなることです。これは特にデータベース統合やクラウドストレージを利用したファイル統合でよく見られます。BarTender 2021ではリソースが再び利用可能になった際に統合を再起動しようとしますが、以前のバージョンでは統合がそのまま停止してしまいます。

統合が突然停止した場合は、ログで直近のエラーを確認し、原因を特定してください。

ファイル統合

統合の動作が遅い

ファイル統合が遅くなる要因はさまざまですが、このタイプの統合には特有の要因があります。スキャンフォルダのサイズが重要です。ファイル統合は新しいファイルを探してスキャンフォルダを監視するため、ファイル数が増えるほどスキャンに時間がかかるようになります。

処理が終わったトリガーファイルを削除または移動する設定になっていない場合、これらのトリガーファイルがフォルダ内にどんどん溜まっていきます。統合の動作が遅いと感じた場合は、処理済みのトリガーファイルをスキャンフォルダから削除して、速度が改善するか確認してください。

データベース統合

重複レコードや複数回の印刷

データベース統合でテーブルをスキャンし、ラベルも同じテーブルに接続されている場合、重複したラベルが出力されることがあります。この状況の対処方法や、正しいデータベース統合とラベルの設定方法については、以下の記事をご参照ください。

• データベース統合から選択レコード数分の印刷が行われる場合 
• データベーストリガーを使ったドキュメント印刷（動画・7:27） 

統合がレコードを拾うのが遅い

統合が遅くなる理由はさまざまですが、データベース統合特有の状況もあります。データベース統合は、トリガーセクションで指定された条件に合う新しいレコードを探すためにテーブル全体をスキャンします。テーブルのレコード数が増えると、その分スキャンに時間がかかり、クエリごとにデータベースサーバーに負荷がかかります。

定期的なメンテナンスで不要なレコードを削除したり、処理後にレコードを削除する設定にすることで、データベースや統合への負荷を軽減することをおすすめします。

ソケット統合

Cannot Access Disposed Object エラー

統合でラベルがスキップされる場合、ログに「Cannot access disposed object」エラーが記録されていることがあります。これは、ジョブ間でソケットが正しく閉じられていないことを意味します。この問題の解決方法については、ソケット統合実行時の統合エラーをご覧ください。