このテーマに関する最初の投稿では、オンラインストアの所有者が直面しているタスクの分析方法、データ交換の概念の選択、1Cとオンラインストア間の交換のプロトコルの開発について話しました。
トピックの続きとして、1Cバックオフィスとインターネットサイトの両方から、交換とその構成がどのように見えるかをさらに詳しく説明します。 また、大量のデータで作業を最適化するためにタスクがどのように解決されたかを示します。
一般的に、次の統合スキームが選択されたことを思い出させてください。
1）サイトと1Cは独立して動作し、CommerceML形式でデータを交換します
2）サイトは1Cに直接アクセスできません
3）1Cは、サイト上の公開スクリプトに定期的にアクセスし、データの授受を行います
3）交換と接続のイニシエーターは常に1Cです
実際にこの概念の実装を考えてみましょう。
したがって、前述したように、1C：Trade Management構成には、サイトとデータを交換するための専用モジュールが含まれています。 これは、前の投稿で説明したプロトコルに従って動作し、CommerceML形式を使用する汎用モジュールです。
モジュールは、標準配信1Cにあります：バージョン10.3とバージョン11（プラットフォーム8.2）の両方の貿易管理。 1C：Trade Managementに加えて、サイトとの交換機能は、ローカライズされた構成を含む他の構成にも存在します。 1C構成のサイトとの交換機能のサポートに関する情報を、特別なテーブル1c.1c-bitrix.ru/ecommerce/require_1C.phpにまとめました 。
1C：Trade Management 11の構成に含まれるモジュールの機能を検討してください。
モジュールインターフェイスの最初のタブには、基本的な相互作用設定が含まれています。
[交換モード]セクション-このプロファイルで使用される交換モードを指定できます。 または、簡単に言えば-交換セッションで解決されるビジネスタスクの種類：商品の荷下ろし、注文の交換、またはその両方。
[ Destination]セクションには、交換が行われるサイトのパラメーターが表示されます。交換スクリプトのURL、交換が許可されるアカウントです。 接続の成功をすぐに確認できます。
変更管理を使用すると、サイトとの交換に関連付けられたオブジェクトへの変更を記録し、以前の交換セッション以降に1Cで変更されたデータのみを交換に含める内部1Cログを使用できます。 もちろん、これによりデータ量が削減され、1Cとオンラインストアのサーバーの両方の負荷が軽減されます。
自動交換セクションでは、ユーザーの介入なしに交換機能が自動的に起動されるスケジュールを非常に柔軟に設定できます。
最初の統合問題の解決策をより詳細に検討しましょう-
1CからオンラインストアWebサイトへの商品のアンロード（命名参照）
これを行うには、交換モードで、「商品の荷降ろし」オプションを追加します。その結果、同じ名前のタブが使用可能になります。
1Cでの荷降ろし用の商品と荷降ろしの設定の選択
ここで最も重要な主なセクションはディレクトリテーブルで 、これを使用してサイトにアップロードするものを作成できます。
「デフォルト」オプションでは、命名ディレクトリ全体がそのままダウンロードされます。すべてのグループとすべての製品が制限なしでダウンロードされます。 もちろん、誰もがこのオプションを好むわけではなく、柔軟な選択が可能です-何を正確にどのような条件下でサイトにアップロードするか。
そのため、たとえば、カタログのグループとサブグループを選択したり、特定の倉庫などから特定のタイプの価格（小売、卸売、ディーラー）で、非ゼロ残高の商品をアンロードしたりできます。
次に、デフォルトでは、すべての製品が単一のディレクトリ（<Catalog>タグ）のXMLファイルにアップロードされます。 各カタログには、製品のグループとサブグループの構造、このカタログ内のすべての製品のプロパティなど、独自の分類子があります。
独自のグループツリーと独自のプロパティセット（特性）を持つさまざまなタイプの商品をサイトにアップロードする場合は、それぞれのタイプを個別のディレクトリにアップロードすることをお勧めします。 したがって、1C-Bitrix：Site Managementシステムでは、これにより、各ディレクトリが個別の情報ブロックにアップロードされ、独自のグループ、プロパティ、権利、設定などが含まれます。 その結果、オンラインストア内のさまざまな種類の製品（階層、プロパティによるフィルター、製品比較など）に対して異なるプレゼンテーションを作成できます。
この場合のディレクトリ設定は次のようになります。
サイトにアップロードされるディレクトリ構造を形成する別の可能性があります-アイテムの種類の使用。 アイテムの種類-これは本質的に商品の種類の代替ルーブリックです。 命名法ディレクトリのグループの構造がサイトへのアップロードの設定に適していない場合、命名法のタイプを作成し、それらに商品をバインドし、新しい見出しに従ってサイトにアップロードできます。
1Cに高品質の製品説明、画像、関連ファイル（指示など）がある場合、「画像ファイルのアップロード」と「他のファイルのアップロード」をチェックすることは理にかなっています。 オンラインストアの所有者の多くは、製品の説明、プロパティ、品質の説明を1Cに保存していません。 1Cではあまり必要ありません。サイトには通常、説明用のHTMLエディターと、画像処理と透かしのさまざまなユーティリティがあります。 さらに、コンテンツエディターのリモート作業を整理することは、1C内に配置するよりも、Webサイトで作業する場合に最も便利です。 それにもかかわらず、物語全体を1か所に保存することを好む人がいます-1Cで、サイトを視覚化ツールとして使用します。 別のタスクがあります-同じ商品が同時に複数のオンラインストアにアップロードされるとき。 その後、1Cで一度説明を作成し、それを複数のサイトに自動的にアップロードすることをお勧めします。
エンドユーザーは、選択するディレクトリ管理モデルを決定します。 主なことは、統合機能により許可されることです。
アップロードプロセス
ここでアンロードを開始すると（[データ交換の実行]ボタンをクリック）、1Cがアップロードされたデータの準備を開始します。
2つのファイルが生成されます：import.xmlおよびoffers.xml（アップロードされた各ディレクトリ用）。 最初のファイルには製品カタログに関する情報（構造、製品、プロパティ）が含まれ、2番目のファイルにはこの製品のトレードオファーが含まれています。 1つの製品に特性（色、サイズなど）に応じたオプションがある場合、それらはすべてオファーファイル内のオファーになります。 詳細は、標準のCommerceML 2.04にあります。
画像またはファイルが商品に関連付けられている場合、それらはimport_filesサブフォルダーに配置され、XMLのデータはそれらを参照します。
たとえば、1Cの2つの商品カタログがアップロードされました。
次に、これらのファイルをサーバーに転送する必要があります。 交換プロトコル（パート1を参照）には、http：// <site> /bitrix/admin/1c_exchange.php?type=catalog&mode=file&filename= <file name>という特別なモードがあります。
データ量が大きい場合（大規模な命名ディレクトリの最初のアンロードが行われる場合）、もちろんファイル転送を最適化したいと思います。
まず、 ZIP圧縮を使用します。 思い出すと、ファイルの転送を開始する前に、1Cはサイトに交換パラメーターを要求しますが、その中にはZIP圧縮をサポートするためのフラグがあります。 すべてのファイルが圧縮され、1つのzipアーカイブが取得され、サイトに送信されます。 圧縮がサポートされていない場合、フォルダのすべてのファイル（写真を含む）が順番に送信されます。
第二に、多くのホスティングプロバイダーは、POST要求によって送信されるデータの量を制限します。 また、数十メガバイトの場合、zipアーカイブでも簡単に失敗する可能性があります。 この場合、 1Cは 、サイズが最大許容値を超えている場合、アップロードされたファイルを部分に分割できます 。 サイト側では、番号が付けられた部分が受信され、単一のファイルに組み立てられます。 1Cデータ部分の最大サイズも、交換の初期化モードでサイトから受信されます。
次に、受信したファイルをサイト側で処理し、サイトデータベースにロードする必要があります。
ホスティング制限の瞬間もあります。 処理（XMLの解析とデータベースへのロード）は、PHPスクリプトによって処理されます。PHPスクリプトの実行時間は通常制限されています。 もちろん、スクリプトの先頭にはset_time_limit（0）がありますが、どこでも機能するわけではありません。 そのため、1C-Bitrixの設定では、スクリプトが動作できる最大時間（デフォルトでは30秒）を指定できます。 次に、この制限に達すると、スクリプトが再ロードされ、ファイル内の前の位置からインポートが続行されます。
さらに、インポートスクリプトは、処理中のファイル内の商品のXML記述のチェックサムを、前回のダウンロード以降のデータベース内のこの商品のチェックサムと比較できます。 チェックサムが一致する場合、製品はスキップされ、更新されません。 これは、カタログが既にサイトにアップロードされており、1Cから完全なアップロードがまだ行われている場合に必要です。 その後、データのインポートがはるかに高速に実行されます。
もちろん、変更されたアイテムのみをアップロードするように1Cで構成することを常にお勧めします。その後、完全なダウンロードは1回だけ実行され、その後、データのごく一部がサイトに非常に迅速にダウンロードされます。
サイト側のデータのインポート設定
1Cからのディレクトリインポートパラメーターは、特別なページ「Integration with 1C」の管理部分の1C-Bitrixで構成されます。
画像処理、商品のCNC生成、インポートファイルにはないがサイトで利用可能なデータの処理など、多くのインポート設定の詳細については詳しく説明しません。 一般に、1Cのディレクトリはサイトのディレクトリに完全に反映されます。
アンロード：
- ディレクトリグループ構造
- グループ製品一覧
- 製品のプロパティ（数値、文字列、タイプ「リスト」、日時、ブール値）
- 製品の説明（HTMLの説明を含む）
- 関連する画像とファイル
- 価格のセット（小売、卸売、ディーラーなど）
- 倉庫残高
- 特性が異なる一連の製品提供
最適化メカニズムにより、大量のデータを最初にアップロードして処理することで問題が解決します。 1Cで変更された位置のみのアンロードモードを使用すると、後続の交換セッションの負荷を実質的に考慮しないことができます。
また、1Cでは、サイトに商品をアップロードするための設定の多くのプロファイルが存在する可能性があることを伝えたいと思います。 それらはいわゆる交換ノードを形成します：
これにより、たとえば、さまざまなタイミングで商品のさまざまなカテゴリを更新したり、さまざまなサイトやさまざまなCMSシステムに商品をアップロードしたりできるなど、さらに柔軟性が高まります。 また、商品の荷降ろしとは関係のないさまざまな時点で、注文を交換することもできます。たとえば、5分ごとにサイトから注文を取ります。
しかし、最後の3番目の部分で注文の交換について説明します。