オンラインストアと1C：Enterpriseの統合を開発した方法と、なぜそれが大量になったのか

ウェブサイトで商品とその在庫の最新のカタログを提供し、内部ビジネスプロセスに従って顧客の注文を処理する方法は？ オンラインストアの所有者の多くはこの問題に直面しています。



単一のオンラインストアを企業全体の会計システムと統合するのは簡単です。 CMSシステムのボックス配信に既製の統合を実装し、大量使用のためにシンプルで理解しやすく、さまざまなタスクに共通する-困難で興味深いタスク。 このトピックは、オンラインストアと一般的な1C：エンタープライズアカウンティングシステムとの統合を開発した経験についてです。







カットの下で、タスクの設定方法、アーキテクチャと技術的なソリューションの選択、最終的に何が起こったのか、それがどのように構成され動作するのかを説明します。



そのため、非常に多くの場合、既存のチャネルに加えてオンラインストアが作成されます：ショップ、小売店、ディーラー販売など。 また、原則として、すべてのチャネルは、企業の単一の取引および会計システム、または企業の主要なビジネスプロセスが実行されるERPシステムによって統合されます。

• ストックアイテム管理;
• 販売、購入;
• 財務、報告、分析など

この場合、オンラインストアを単一の企業会計システムまたはERPシステムに統合することが急務です。



統合の開発における最初の最も重要なことは、その目標とタスクを実現することです。 そして、このことから、何を、どのように、どこに移すかをすでに計画しています。 サイトをERPシステムと統合する場合、通常、次の3つの主要なタスクのソリューションを自動化する必要があります。

• 商品のカタログ（ERPで管理）のWebサイトへのアップロードを確実にし、その関連性をサポートする
• サイトからERPへの必要な情報を含む注文の転送
• ERPで処理が実行される注文の進行状況について顧客に通知する。

すべてが合理的でシンプルですが、あなたは認めなければなりません、私たちの多くは、サイトがそれ自身の生活と私たち自身の会計システムをどのように生きているかを目撃しました。 オンラインストアで商品を注文すると、マネージャーの電話後、商品の在庫がなく、価格が正しくない、新しい為替レート、またはサイトで公開された商品が同じ構成または異なるカラー写真ではないことがわかりました。



もちろん、このような店舗の結果は1つしかありません。それは、上司の努力にもかかわらず、返品を望みそうにない失望した顧客です。







2007年に戻った。 オンラインストアの人気の高まりと統合の問題を解決する需要の高まりを考えると、CMSシステムの開発者として、そのような統合のための信頼性の高いターンキーソリューションを提供する必要があることが明らかになりました。



最初の決定は、どの会計システムでこのようなすぐに使用可能な統合を構築するかです。 当時、そして今日でも、ロシアで最も人気のあるソリューションは1C：エンタープライズプラットフォームです。ほとんどのお客様は、サイトを1Cと統合したいと考えています。 商社の問題を解決するという点では、 1C：貿易管理の構成が最も需要があります。 それとの統合を行うことが決定されました。







もちろん、ここで書かれたすべては、他のERPおよびCMSシステムとサイトを統合する問題の解決にも適用できます。 アプローチとアイデアは普遍的であり、コードは常に適応できるため、アプローチとアイデアは重要です。



タスクは特異性を獲得し、私たちは（1Cの専門家と協力して）作業を開始しました。 まず、相互作用のアーキテクチャを決定する必要がありました。 一般に、2つの境界アプローチがあります。

1. 1Cへのサイトへの直接アクセス
2. 1Cとサイト間の定期的なデータ交換

最初のアプローチ-1Cシステムへの直接呼び出しを考えてみましょう

それを使用する場合、サイトは必要に応じて1Cから質問するか、データを提供します。



インターネット上でカタログを表示し、オンライン注文をCMSなしで実行できること、1CにはWeb拡張機能などの機能があり、プラットフォーム8.2および「マネージアプリケーション」のテクノロジーが登場して1C機能を簡単に提供できることに注目してくださいブラウザ ただし、これは最初のアプローチの典型的な例であり、次のような利点と欠点があります。



利点は明らかです。

• リアルタイムでのサイト上のカタログの完全な関連性
• 1Cでの新規注文の即時表示
• 注文処理の結果をクライアントに迅速に通知

Webサービステクノロジーは通常、サイトと1Cの間のインターフェイスとして使用されます（クロスプラットフォームであり、システムを統合するための事実上の標準です）。



その後、1Cで一連のメソッドを備えたWebサービスが公開され 、サイトは時々そこを「ノック」し、データを取得または送信します。 すべてが美しいようです。 しかし.... 残念ながら、そのような正確で技術的なアプローチは広く採用されていません。 そして、私たちの意見では、これが理由です：

1）大量使用のためのセットアップの難しさ。

Webサービスを公開するには、Webサーバーを展開し、拡張モジュールのロードを登録し、Webサービス自体を公開する必要があります。 誰かが言う：どのような複雑さ、どんなナンセンスが一般的に正しいだろう。 1Cには、インストールされたWebサーバーにWebサービスを自動的に公開する機能もあります。 しかし...人生は人生です。大衆消費者にとって、プログラマーではない人にとってそれは困難であり、理解できないものです。 そして、問題が始まると、Webサービスが機能しなくなり、外部から見えなくなり、エイリアスが登録されず、ユーザーが開始されず、十分な権限がありません。 -人々が沈殿します。 さらに、企業が十分に大きい場合、IT専門家の関与の必要性は明らかです。

2）サイトの1Cの作業への依存

さまざまな理由により、内部会計システムが機能しない場合があります。ソフトウェアの更新中、機器の交換中、バックアップの復元中などです。 これらの期間中、サイトは1Cに完全に関連付けられているため、正しく動作できません。 もちろん、これらの状況を考慮に入れて、データベースが機能していないという事実を考慮した保護をサイトに実装できますが、これは冗長なコードであり、Webシステムを複雑にする冗長なロジックです。

3）サイトへの1C依存

人気のあるオンラインストアでは、トラフィックが非常に多く、ピーク時の負荷が高く、単位時間あたりの注文が多いことがあります。 商品、価格、在庫のカタログの背後で1Cを絶えずクロールする場合、それはゆっくりと行われます！ Webサービスは便利で技術的ですが、簡単な交換方法とはほど遠いものです。 また、1Cサーバーが適切な機器で実行される場合でも、これは可能です。 サイトからの高いピーク負荷は、一般的にベースを麻痺させる可能性があります。 もちろん、商品のカタログは時々キャッシュして要求することができますが、最初に、アプローチの最初の利点（一定のリアルタイム）が失われ、2番目に最後になりますが、私たちの意見では、最も重要な問題は残っています：心理的...

4）サイトからの潜在的な脅威

1Cはすべての生命が保存される企業の主要な会計システムであることを思い出してください。 1C：貿易管理は通常、会計、人事などと統合されています。 すべてが1つのボトルに入っている複雑な構成があります。 通常、このシステムのセキュリティ問題は最前線に置かれ、多くの場合、非常に簡単に解決されます。原則として、サーバーから「インターネットで」ケーブルを切断します（科学的な方法であれば物理的に）。 ここで、データの記録、受信、更新のためにサイトが常に1Cでクロールすることを通知されるリーダーの代わりに配置します。 また、サイトが1Cに直接クロールされないことはわかっていますが、特定の制限された権限セットを持つWebサービスを通じて、それを受け入れることは心理的に困難です。 どうやって？ ハッキングされ、ウイルスに感染する可能性があるサイトは、1Cにアクセスできますか？ まあ、今、散らばって...！？







したがって、2番目のアプローチを適用しました。

1Cとサイト間のスケジュールされたデータ同期

この概念では、サイトと1Cは独立して動作し、それぞれに独自のデータベースがありますが、確立された期間中に必要な情報は同期されます。



上記の心理的な瞬間を考えると、 サイトは1Cにアクセスできません ！ 次に、すべてが機能するために、1C自体が定期的にサイトにアクセスし、情報を提供または取得する必要があります。



最初のアプローチに対する利点は明らかです。

• サイトは独立して機能し、そのデータは1Cのデータの可用性に依存しません
• 1Cはサイトからのリクエストを受け入れず、追加の負荷は発生しません
• サイトのセキュリティに違反した場合、1Cのセキュリティは侵害されません

現在のアーキテクチャには、最初のアプローチと比較して、データの更新の遅延という1つの欠点しかありません。 たとえば、サイトに加えて、まだ小売している場合、サイトでまだ利用可能な製品はすでに在庫切れになっている可能性があります。 もちろん、衝突の確率は更新間隔に反比例します。 短い更新間隔（数分）と平均的なストアの場合、非常に小さい



しかし、最初に、我々は仮定を受け入れました。それは後に生命によって証明されました。大規模な電子商取引にとって、この欠陥は重大ではありません。 このような状況の可能性は小さく、交換間隔が短くなるにつれて減少します。さらに、多くのオンラインストアは通常、実際の残高で取引せず、訪問者の存在を隠します。 そして、そのような状況がまだ発生した場合、ほとんどの場合、商品は十分に迅速に見つけることができます。



第二に？ そして第二に、結果なしで更新遅延の間隔を十分に小さくすることができるように、いくつかの技術的解決策が使用されました。



繰り返しますが、最大数のケースですぐに使用できる統合を作成する問題を解決しました。 もちろん、これが非常に重要なショップもありますが、結局のところ、多くの車も在庫に満足しておらず、チューニングが必要ですか？！ ）そして、すでにチューニングを許可しています...

輸送といえば...

また、Webサービスについてはどうでしょうか。 結局のところ、1Cの側にない場合、サイトの側にそれらを公開する必要がありますか？ そして、Webサービスでは、よく考えて得点しました。 そして代わりに、 CommerceML標準を使用したファイル交換を使用して、古き良きHTTPプロトコルに従って交換を実装することにしました。



HTTP経由の交換とは、1Cがサイト上のスクリプトにアクセスし、POSTメソッドを使用してデータファイルをそこに転送することを意味します。 これは、特別な設定を行う必要がないため便利です。 80番目のポートは、ほとんどのファイアウォールで開いています。 それを通して、オフィス全体がインターネットを使用し、1Cは同じようにインターネットを見ることが非常に多いです。 サイトのスクリプトは、CMSの箱入り配信に含まれており、他の場所で公開する必要もありません。



また、CommerceMLは、カタログ分類子、商品のグループとプロパティ、商品、注文などの商業情報の交換のために特別に設計されたオープンなXMLベースの標準であるため、優れています。 データ転送は、サイトとバックオフィス間など、異なるシステム間で可能です。 この標準は、作業の開始時にすでに存在し、開発されました。 現在、バージョン2.05がすでに利用可能であり、いくつかの素晴らしい革新が現れています。 もちろん、そのような標準が1C：Enterpriseで定期的にサポートされていたことは非常に喜ばしいことでした。



CommerceMLファイルの例： 製品に関する情報を含むファイル、価格オファーを含むファイル、サイトからの注文に関する情報、およびサイトへの情報を含むファイル。



その結果、統合の次のアーキテクチャが実現しました。







1C：Enterpriseの構造には、データ交換設定が構成されているサイトと共有するための特別なモジュールが含まれています。 企業ネットワークから、リモートサイト（ホストサイトにホストされている）にHTTP経由でアクセスします。 サイトにつながる矢印はリクエストの方向を示し、イニシエーターは常に1Cです。

サイトとの1C交換プロトコル

プロトコルは完全にオープンであり、変更および変更できます。 プロトコルに関する情報は、 1C-Bitrixのドキュメントと1C Webサイトの両方で公開されています 。



したがって、上記のすべての言葉は技術的に見えます：



1 http- http- :

http://<>/bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth

( "\n"):

1. "success";

2. Cookie;

3. Cookie.

:

1 Cookie, "checkauth".







次のステップでは、1Cはさらに交換するためにサイトにいくつかのパラメーターを要求します。



http://<>/bitrix/admin/1c_exchange.php?type=<>&mode=init (: catalog sale, )



:

1. zip=yes/no, zip-.

2. file_limit=<>, <> - . , .







接続が確立され、パラメーターが定義されると、メインのCommerceMLファイル交換が開始されます。 交換モード1Cに応じて：



a）製品命名法のサイトデータへの転送



http://<>/bitrix/admin/1c_exchange.php?type=catalog&mode=file&filename=< >

1C CommerceML 2, POST. "success".







b）サイトの顧客注文からのリクエスト



http://<>/bitrix/admin/1c_exchange.php?type=sale&mode=query



CML 2. 1 :

http://<>/bitrix/admin/1c_exchange.php?type=sale&mode=success







c）以前に受け取った注文の処理結果に関するデータをサイトに転送する



http://<>/bitrix/admin/1c_exchange.php?type=sale&mode=file&filename=< >

, POST. 1- "success". .







リクエスト中にエラーが発生した場合、1C-Bitrixシステムのレスポンスは次のようになります。最初の行に「失敗」という単語があり、次の行にリクエスト処理中に発生したエラーの説明があります。 製品コアまたはsql-requestのレベルで未処理のエラーが発生した場合、この場合、サイトからのhtmlコードが返されます。



繰り返しますが、次の3つの柱に基づいた、このようなシンプルで信頼性の高い交換手順を次に示します。

• HTTP通信
• 交換のイニシエーターは常に1Cです
• オープンフォーマットと交換プロトコル

ちなみに、しばらくして、このプロトコルは他のCMSの開発者によってサポートされ、今日では基本的にサイトとの1C対話の事実上の標準になっています。 このようなタスクはもともと設定されていたため、これは非常に重要です。独占することではなく、取引所を閉鎖することではなく、さらなる開発、取引所の改善、特定の実装への適応の機会を提供することです。 したがって、私たちの意見では、最適なアーキテクチャを選択するという目標は達成されました。



そのトピックはあまりうまくいきませんでした。今日はそれだけです。



記事の後半では、次のことを伝えます。

• 1Cとサイト間のデータ転送の最適化方法
• 大量のデータが転送され、一般的なホスト制限でどのように克服されるか
• 1Cとサイトの両方で特定のタスクの統合を設定するためのインターフェイスは何ですか？
• 交換を変更し、非標準的なことを行う機会はどうですか

続行するには...



敬具、事業開発部長

アルチョム・リヤビンコフ