この投稿では、Bitrixインポートモジュールの開発における経験を開発者コミュニティと共有したいと考えています。

インポートモジュールには次の機能があります。

• Bitrix MySQLデータベースと直接動作します（つまり、商品のBitrix CMSオブジェクトモデル全体が内部的に再作成されています）。
• 次の方法でデータベースに接続できます。
  
  • 直接接続;
  • SSH;
  • HTTPブリッジ接続。
• データをインポートするソースは、CLPファイル（CatalogLoaderデータモデルを備えたsqliteデータベース）です。
• プログラミング言語C＃/。NET 4.0。

必要条件

モジュールにはいくつかの要件がありました。

充填速度

モジュールはできるだけ早く動作するはずです。 第一に、クライアントは常に結果を「ここと今」、さらに良い「昨日」に見たいと思っています。 そして、そうです。 クライアントのリクエストに応じて、いくつかのテスト製品を直接入力することがよくあります。これにより、クライアントはどのように機能するかを評価し、必要に応じて、必要な変更をすぐに判断できます。

第二に、多くの商品とその組み合わせがある場合、データのロードには非常に長い時間がかかる可能性があります。 写真のアップロードには特に時間がかかります。 各製品には数十枚の写真、さまざまな色の組み合わせ（トレーディングオファー）、各製品には複数の写真が含まれ、さらに各写真にはサイトで正しく表示するために複数のサイズが必要です。 ただし、サイトの継続的な変更とインポートによるサイト速度の低下は望ましくありません。

環境の変化に強い

モジュールは、サイト自体の変更に耐える必要があります。 Bitrixも静止していません。 新しいバージョン、新しい拡張機能が定期的に表示されます。 また、このサイトは、デザイナーとWebプログラマーによってファイナライズが行われている可能性があります（現時点では一部のページにアクセスできなくなるまで）。 しかし、私たちは待つことができません、私たちはここで、そして今、私たちの仕事を実行し、より明るい未来に移動する必要があります。

これらの要件を考慮して、最適なソリューションは独自の独立したモジュールを開発することでした。これにより、データベースにデータを直接ロードし、追加コンポーネントの使用を最小限に抑えることができます。

充填プロセス

だから私たちは最もおいしい=）になりました

ストアモードでのBitrixデータの簡略化されたスキームは次のとおりです。

これらの表の簡単な説明：

• b_iblock-情報ブロック参照
• b_iblock_section-カテゴリガイド
• b_iblock_element-商品とその組み合わせのディレクトリ
• b_iblock_section_element-一致するカテゴリと製品のディレクトリ。 1つの製品をいくつかのカテゴリに分類できます。
• b_iblock_property-特性リファレンス
• b_iblock_element_property-製品の機能
• b_file-写真に関するデータと商品の追加ファイル（データシートなど）を格納するテーブル。 Bitrixのコンテキストでは、すべてのファイルは別の機能であり、特別なタイプ（VALUE_TYPE = 'F'）のみです。 ファイル自体は、データベースとは別にディスク上に物理的に保存されます。
• b_iblock_34_index-インフォブロック34のファセットインデックス。
• b_iblock_34_index_val-インフォブロックNo. 34のファセットインデックスの値のテーブル。

ストアを埋めるプロセスは、次の順序で実行されます。

• 必要な情報ブロックの作成
• 塗りつぶしカテゴリ
• 充填品

製品ごとに、特性、組み合わせ、写真、検索インデックスも記入する必要があります。

情報ブロックの作成

通常、取引カタログには1つのインフォブロックのみが割り当てられ、それに応じて設定する必要があります（名前、場所、表示方法、取引オファーに子インフォブロックが必要かどうか）。 これがデフォルトの動作です。 しかし、一部の顧客はより複雑な構造を作ります。インフォブロックは基本的にトップレベルのカテゴリであり、完全なストアツリーを正しく構築するには、インフォブロックのデータとカテゴリテーブルのデータを組み合わせる必要があります。

塗りつぶしカテゴリ

入れ子セット

カテゴリツリーは、ネストされたセットに基づいています。 PrestaShopとShopScriptでも同様のものが使用されます。 アルゴリズムの観点から非常に美しいものを作ることができ、分岐して、データベースから素早く便利な選択をすることができます。

ネストされたセットは、要素自体に加えて、ネスト領域が格納されるツリー構造で、2つの数値フィールドで表されます。これは、文献では一般にLEFTおよびRIGHTと呼ばれます。 Bitrixでは、LEFT_MARGINおよびRIGHT_MARGINという名前です。 サブカテゴリの数に関係なく、すでにソートされた順序で、またはすべての親で、1つのリクエストですべての子を取得できます。 接続を取得するために各カテゴリを再帰的に移動する必要がないため、これらの操作に費やされる時間とサーバーリソースが大幅に削減されます。

以下は、ライブプロジェクトの2つのカテゴリの簡単なサンプルの例です。 ソート順とネストレベルを明確に確認できます。LEFT_MARGINおよびRIGHT_MARGINフィールドが、標準のDEPTH_LEVEL（深さ）、SORT（ソート順）、およびIBLOCK_SECTION_ID（親カテゴリへのリンク）とどのように接続されているかを明確に確認できます。

サンプルには、2つの最上位カテゴリとそのサブカテゴリがあります。 ツリーの形式では、この構造は次のようになります。

「シャンデリア」と「壁取り付け用燭台」は第1レベルのカテゴリであり、2つの隣接する支店を表しています。 カテゴリブロックの左の数字はLEFT_MARGINで、右の数字はRIGHT_MARGINです。 親カテゴリの場合、LEFT_MARGINは現在のブランチの最小キーであり、RIGHT_MARGINは最大です。 LEFT_MARGINとRIGHT_MARGINの間の範囲外にあるものはすべて、必要なブランチには適用されません。 同じレベルの2つの隣接する（および行に表示される）カテゴリでは、インデックスに連続した番号が付けられていることがわかります。次の要素の左キーは、常に現在の要素の右キーよりも1つ大きくなります。 カテゴリが連続して並んでいるはずなのに、キー値が連続していないことがわかった場合、これはキーの構築に関する問題の最初の兆候です。

すべてが素晴らしく見え、インデックスが完全に読み込まれるまで問題なく動作します。 インデックスに何かが発生するとすぐに-せいぜい、カテゴリが「ダンス」を開始します。最悪の場合、レイアウトが崩れるか、カテゴリが消えます。 カテゴリが消えると、ユーザーはその中の製品を見ることができず、作業が無駄になってしまうため、非常に慎重に作業する必要があります。

そして、この構造を台無しにすることは非常に簡単です。 データベースのレコードを単に挿入または削除するだけでは不十分です。 レコードを挿入、削除、またはドラッグ（ソート順を変更）した場合、インデックスの一貫性を保つためにカテゴリツリーを再構築する必要があります。 多くの場合、理解可能なフィールドDEPTH_LEVEL、SORT、およびIBLOCK_SECTION_IDを見た後の新規ユーザーは、入力するのに十分であると信じていますが、ネストされたセットをまったく認識していないため、インデックスは再構築されず、カテゴリツリーはゆっくりですが確実にミンチミートに変わります。 あまり変化しないカテゴリーが少数しかない場合、これにより最小限の問題が発生します。多くの場合、人々はそれを把握するよりもすべてを削除して再作成する方が簡単です。 しかし、改善後、ストアに数千のカテゴリの作業データがロードされると、問題は喉全体に広がります。

さらに悪いことに、プロジェクトが既に壊れている新しい開発者に行った場合、問題の原因を突き止めるのに多くの時間が費やされます。

データベースをチェックするのに役立つSQLクエリをいくつか紹介します。これらは、ネストされたセットの正当性をチェックするのに役立ち、問題を探してコーヒーかすの富を読む時間を無駄にしません。

--         , ,     ; SELECT * FROM `b_iblock_section` WHERE LEFT_MARGIN >= RIGHT_MARGIN; --    (),       ,    = 1;  =  * 2 SELECT COUNT(ID), MIN(LEFT_MARGIN), MAX(RIGHT_MARGIN) FROM `b_iblock_section`; --         , ,     ; SELECT * FROM (SELECT ID, MOD((RIGHT_MARGIN - LEFT_MARGIN), 2) AS ostatok FROM `b_iblock_section`) t WHERE ostatok = 0; --         , ,     ; SELECT * FROM (SELECT ID, MOD(LEFT_MARGIN - DEPTH_LEVEL + 2, 2) AS ostatok FROM `b_iblock_section`) t WHERE ostatok = 1; --   ,    , .     ,       SELECT ID, CONCAT(REPEAT('--', DEPTH_LEVEL - 1), `NAME`) as `NAME`, LEFT_MARGIN, RIGHT_MARGIN, DEPTH_LEVEL, IBLOCK_SECTION_ID as PARENT FROM `b_iblock_section` ORDER BY IF(ISNULL(IBLOCK_SECTION_ID), ID, IBLOCK_SECTION_ID), LEFT_MARGIN; --     SELECT ID, CONCAT(REPEAT('--', DEPTH_LEVEL - 1), `NAME`) as `NAME`, LEFT_MARGIN, RIGHT_MARGIN, DEPTH_LEVEL, IBLOCK_SECTION_ID as PARENT FROM `b_iblock_section` WHERE LEFT_MARGIN IN (SELECT LEFT_MARGIN FROM `b_iblock_section` GROUP BY LEFT_MARGIN HAVING count(*)>1) ORDER BY LEFT_MARGIN; --    ,              ,        SELECT CHILD.ID, CHILD.DEPTH_LEVEL, CHILD.`NAME`, CHILD.LEFT_MARGIN, CHILD.RIGHT_MARGIN, PARENT.LEFT_MARGIN as PARENT_LEFT_MARGIN, PARENT.RIGHT_MARGIN as PARENT_RIGHT_MARGIN FROM `b_iblock_section` AS CHILD JOIN `b_iblock_section` AS PARENT ON PARENT.ID = CHILD.IBLOCK_SECTION_ID WHERE (CHILD.LEFT_MARGIN <= PARENT.LEFT_MARGIN) OR (CHILD.RIGHT_MARGIN >= PARENT.RIGHT_MARGIN) OR ((CHILD.DEPTH_LEVEL - 1) <> PARENT.DEPTH_LEVEL) OR (CHILD.LEFT_MARGIN >= CHILD.RIGHT_MARGIN); 

充填品

「箱から出してすぐに」商品を完全に表示できない

これが「機能」です。 インポートして管理パネルに表示する内容や方法に関係なく、フロントエンドのプロパティはまだ表示されないため、手で編集モードで表示することはできません。

このCMSに初めて出会ったとき、この動作はやや混乱を招き、同じデフォルトの動作を持つ他のCMSを覚えていません。 情報ブロックを設定するデザイナーは強力ですが、デフォルトでは誰も彼について知らないので、ドキュメントを読むのに多くの時間を費やすか、あなたのために時間を費やすBitrixスペシャリストに多くのお金を費やすか、CMSを探す必要があります時間がかかります）。

ファセットインデックス

ファセットインデックスには、商品の各特性のインデックスの作成が含まれます。これにより、非常に迅速な検索を行うことができます。 タイプb_iblock_{IBLOCK_ID}_indexおよびb_iblock_{IBLOCK_ID}_index_val 2つのテーブルが、各製品が検索可能な特性を記述する各インフォブロックのデータベースに追加されます。 上の図では、これら2つのテーブルのインデックスは34でした。なぜなら、 取得したデータベースの取引提案を説明するために、34番目の情報ブロックが使用されました。 このようなブロックは多数存在する可能性があるため、各情報ブロックに対してファセットインデックス付きのテーブルのペアが作成されます。 ブランチの各カテゴリにエントリが追加されます。 つまり 必要なすべてのカテゴリの指定されたフィールドで製品を検索するには、この製品を検索する各カテゴリのエントリを複製します。 原則として、これは下位レベルのカテゴリです-製品では、すべてのカテゴリがこのブランチ（すべての親）でより高いため、たとえば上位レベルのカテゴリではサブカテゴリから製品を検索できます。

ファセットインデックスの外観は、私たちにとって不快な驚きでした。 冬の更新の1つの後、フロントエンドの商品は姿を消しました。 間違いなし。 すべてが管理パネルに表示されます。 しかし、フロントエンドには新製品はありませんでした。 形成された沈黙を通して、プログラマーが灰色に変わるのを聞くことができました。 ファセットインデックスが満たされていない製品は、現在も永久にも表示されないことが判明しました。 これらの非常にファセット化されたインデックスを誰も望んでいなくても、意図的に含めた人はいませんし、さらに、フロントエンドで何も選択していません。 つまり ユーザーによるフィルタリングのフィールドが入力されていなくても、何らかの理由でフィルターが機能します。 動作は奇妙です。 そのような導入の結果-人々は死にかけていました。 人々は損失を被った。 充填方法に関係なく。

それとは別に、特性の識別子の計算に言及する価値があります。 魔法を信じますか？ これは魔法です。 まず、ドキュメントによれば、このフィールドは、特性の一般リスト（特性によるフィルタに対して論理的）の識別子に対応するべきではなく、特性の一般リストに2を掛けた識別子でなければなりません。 「この魔法の意味は何か」という質問に対する明確な答えは見つかりませんでした。 42を掛けると、はるかにうまくいくようで、少なくともある程度は意味があります。 第二に、管理パネルを介してサイトを埋めることは、この一見些細な魔法に準拠していない可能性があることが繰り返し指摘されました。

魔法の実装についてはここで説明しますが 、何に何を掛けるのかを説明すべきドキュメントへのリンクもありますが、残念ながら、執筆時点では4の数字の魔法があります。

ファセットインデックスの詳細と対処方法については、Bitfilter開発者フォーラムのトピック「 スマートフィルターは非常にファセットされてきれいです」 を参照してください 。

その他のニュアンス

過剰なキャッシングは悪いです

Bitrixは、デフォルトで有効になっている独自のキャッシュを持っています。 このキャッシュが強制的にフラッシュされるまで、サイトへの変更は表示されない場合があります。 これにより、すべてが明確になり、CMS API自体を使用してリセットできます。 ただし、場合によっては追加のキャッシュツールが含まれることがあり、ホスティングプロバイダーはそれらをオンにすることもできます。最終的には、たとえば、クロムキャッシュが状況を悪化させる可能性があります。

システム要件はストアとともに拡大します

モジュールを可能な限り最適化しましたが、これは常にサーバー容量を増やす必要性からお客様を救うわけではありません。 商品の量と特性の大幅な増加に伴い、Bitrixは通常の動作のためにサーバー容量、特にRAMの増加も必要とします。 CMSが起動され、多数のデモ製品で動作する最も安価なホスティングを使用した構成では、10,000個の製品を入力すると、すべてが正常に動作します。 これはそれぞれビジネス向けの強力な多機能CMSであり、名刺サイトよりも真剣にホスティングする必要があることを理解しておく必要があります。

何に来たの

Bitrixは、CMSと連携するフレームワークと、顧客とやり取りするフレームワークの両方で、多くの興味深い経験を提供してくれました。 間違いなく、これは優れた機能を備えた優れたCMSです。 しかし、初心者には重すぎます。 はい、初心者のために何がありますか。プログラマーでさえ、このCMSを初めて使用する場合、すぐにフルサイトを立ち上げるのに多くの時間と神経を費やすことができます。 ニュアンスが多すぎます。 自分のビジネスを始めたばかりで、スタッフに経験豊富なBitrixプログラマーがいない場合、より理解しやすいCMSを選択するか、少なくとも購入前にサービスVirtual Labでデモバージョンを試してみる価値があります。
すでにBitrixを購入している場合、最初に行う必要があるのは、コンテンツでそれを埋め、完全なバックアップを作成することです。 後で、デザイナーにメイクを注文し、商品の表示やその他の編集を構成できます。 このアプローチの利点は、ストアを完了した人が、説明、必要なすべての属性、組み合わせ、写真を使用して、ライブ製品の編集結果をすぐに視覚的に評価できることです。 最初はサイトがデザイナーによってばらばらに引き裂かれ、それが初めて私たちに引き裂かれ、クライアントがストアを立ち上げる前の最後の瞬間にレイアウトの問題に遭遇したというケースが何度もありました。

また、モジュールを介したBitrixへのインポート速度の小さなベンチマークを作成しました。 テストセットには、23298枚の写真を含む1495個の製品と組み合わせが含まれていました。

ローカルデータベース接続（MySQLへの直接接続）

HTTPブリッジ経由でサイトにインポートする

作業マシンからのテストのインポートは、テストストアbitrixlabs.ruで行われました。 インポート用の写真はサプライヤのサーバーにあり、httpプロトコル経由で入手できました。 このテストでは、写真のダウンロードとネットワーク速度が充填速度にどのように影響するかを確認できます。

このモジュールは現在、次のプログラムおよびサービスで使用されています。

• 価格処理のためのPriceMatrix ;
• サイトCatalogLoaderのパーサー。