最近、サイトと1Cの統合に関するいくつかの異なる記事に出会いました。 コメントでは、さまざまなアプローチについての論争がしばしば始まり、私はかつて私に実装できた方法を共有することにしました。 もちろん、以下で説明する方法は普遍性と一意性を主張するものではありませんが、独自のバージョンを作成しようとする人には役立つと思います。
チョッパー、熊手、シャベル
非常に大きな店ではありません（約5000の製品の命名法）。
通常、ファイル1C 8 UT。 この構成は完全にサポートされており、サポートから削除することはできません。
ベースは、従業員の1人が仕事に使用するデスクトップマシンの1つにあります。
最小限の情報（名前、説明、写真、数種類の価格）をアップロードするだけで十分です。
すでに確立されたエコシステムを破壊することも非常に望ましくありません。
サイトには通常の仮想ホスティングが割り当てられます。つまり、その限られたリソースを考慮する必要があります。
アンロードは頻繁に行われない場合があり、3時間に1回で十分です。
その後、価格表のアンロードをxlsに追加する必要が生じました。
プロジェクトの実施のための適度な予算。
「サーバー」として機能するマシンはすでに高速ではなく、1Cベースへの常時接続の存在は状況を悪化させただけです。 しかし、これは顧客に適していました。つまり、別のサーバーを購入して残りの艦隊を再武装するためのお金の山がなかったことを意味します。
予算の制約により、Bitrixとその典型的な統合のオプションはすぐに消えました。 そして、関心はスポーツであり、すべてを独立して実現することでした。 以前は商品のカタログに使用されていたフレームを使用することが決定されました。 フレームワークはCodeIgniterで作成されたため、小さなモジュールを追加することは難しくありませんでした。 解決されました。
始めましょう
最初のことは、情報をアップロードする頻度の問題であり、彼の手はスケジュールされたタスクに手を伸ばしました... 第一に、構成をサポートから削除することは不可能です。これは、構成自体を変更できないことを意味します。第二に、1Cのすべてのコピーは必要な場合にのみ起動されます。 。 はい、「サーバー」の起動時に常に1Cを起動し、常に実行し続けることを顧客に義務付けることができますが、これは顧客に不必要な不便をもたらし、ソリューションが最も便利ではないことを意味します。 残念ながら、今日のスケジュールされたタスクは私たちを助けることができません。 明らかに、特定の時点でアップロード手順を開始するには、サードパーティのアプリケーションの助けが必要になります。 ここで、1Cを使用すると、コマンドラインから自分で実行できること、さらに必要な外部処理をすぐに実行できること、また必要に応じてパラメーターを渡す機会があることを思い出してください。
使用する主なキーは次のとおりです。
" 1" enterprise /F" " /N"" /P"" /Execute" " /C"" /DisableStartupMessages
これで、この設計の立ち上げをスケジュールどおりに構成できます。 Windowsスケジューラー？ 設定、確認...動作します！
しかし、重大な欠陥が1つあります。 スケジューラがスケジュールに従って1Cを起動すると、もちろん、すべてのアプリケーションの上で開かれ、その時点で誰かがコンピューターで作業している場合、最初に気を散らし、次に、それを閉じることができます新しいウィンドウ。 故障しています...どうすればいいですか？ 別のアカウントでローンチに向けて掘り始めます。 Googleのおかげで、別のユーザーの下でバッチを起動できる可能性があることがすぐにわかりました。 新しいWindowsユーザーを作成し、セキュリティポリシーでバッチ起動を許可し、スケジューラーを再構成し、確認します。 すべてが機能しましたが、迷惑なウィンドウは表示されませんでした！ それは、このオプションが私たちに合っていることを意味します...では、データ自体の実際のアンロードに移りましょう。
荷降ろし
もちろん、まず最初にCommerceMLの方向に目を向け始めましたが、ドキュメントを読んだ後、私たちの非常に初歩的な荷降ろしのために、この庭全体をフェンスで囲むことが明らかになりました-長すぎて、予算はゴムではありません。 そこで、別の方法を探します。 テキスト情報をxmlにアップロードし、画像を別のディレクトリにアップロードしないのはなぜですか？ 私たちはそれをやっていると決心しました。 xml-fileのかなり単純な構造を取得します。最初に、グループのレコードが内部に入り、それから命名単位自体になります。
これはグループがどのように見えるかです：
<group> <Code></Code> /*- 1*/ <Name></Name> /* , */ <ParentCode> </ParentCode> /* , */ </group>
そして商品：
<item> <Code></Code> /* - 1 */ <ParentCode> </ParentCode> /* , */ <Name></Name> <Descr></Descr> <Article></Article> <TypePrice> </TypePrice> <Price></Price> <urrency></urrency> <Remains></Remains> <Unit>//</Unit> <Img>img_dae5eacd-7d88-11de-8856-0024213f1c89.jpg</Img> /* 1 */ </item>
トリッキーなリクエストではなく、すべての製品グループと製品に関する情報を取得してから、xml-kuを作成します。 また、別の選択を行って価格表の情報を引き出し、受信した情報をxlsに保存します。
その後、画像のアップロードに進みます。 ホスティングサイトの制限により、ホスティング側での画像処理は最も合理的ではないと思われたため、画像処理+アップロードの作成段階でプレビューを作成することが決定されました。 1Cは確かに収穫機ですが、写真のパックを処理する機能は見つかりませんでした。 しかし、ImageMagickはありますか？ 画像処理に必要なすべての優れたクロスプラットフォームセット...ダウンロード、アンパック...必要な操作を実行するbatnikを記述するだけです。
cd c:\ set thePATH= FOR /R "%thePATH%" %%a IN (*.jpg) DO ImageMagick-6.7.0-10\convert.exe %%a -resize x^> -quality 70 %%a FOR /R "%thePATH%" %%a IN (*.jpg) DO ImageMagick-6.7.0-10\convert.exe %%a -resize x^> -gravity center -extent x -quality 70 %thePATH%mini\%%~nxa
このbat'nikを処理から開始し、結果を受け取ります。
すべての情報がアップロードされますが、残っているのは慎重にzipにパックし、ftp経由でサーバーにアップロードすることです。1Cは通常のツールでうまくいきます。
一見、すべてですが、...すべての命名法を毎回、すべての写真で引き出し、すべての巨像をサーバーにアップロードしますか？ いいえ、この写真は心の弱い人向けではありません...そして、どうすればいいですか？ フラグを作成し、どの命名単位が変更されたかをマークしますか？ いいえ、構成を編集することはできません...しかし、交換計画はありますか？ 誰がそれらを使用することを禁じましたか？ 誰も！ 交換計画を作成し、カスタマイズします。 次に、アップロードを変更します。アップロード中に交換に関して新しいメッセージを作成し、最後のメッセージ以降に変更されたユニットのみをアップロードします...
サーバー側
ここではさらに透明です。 スクリプトの起動をクラウンにハングアップします。 スクリプトで、目的のディレクトリを調べ、マスクを使用して目的のアーカイブを探します。 ある場合は、XMLを解凍して解析し、データベースに情報を書き込みます。 内部にある写真は別のアーカイブです。既存の写真があるディレクトリのすぐ上に解凍します。 そのような画像が既に存在する場合は、新しい画像に書き換えます。 xlsファイルは、目的のディレクトリに置き換えられてコピーされます。 私たちは、彼らがそのような更新を行ったデータベースに情報を書き込み、それからそのような番号を使用して、一時ファイルをクリーンアップします。 それだけです
失敗からのStr
情報のアップロード、画像処理、アーカイブ、リモートFTPへのアップロード中にエラーが発生した場合、更新の一部が失われる可能性があり、その結果、サイトと1Cデータベースの情報が同期しなくなります。 以下に、ストローを敷く必要がある主要な鋭角コーナーについて説明します。
1.では、たとえば、FTPアップロード時に接続が切断された場合はどうなりますか？
交換計画にメッセージを既に記録している場合、1Cはこれらの変更を正常にアップロードし、新しい変更を収集したと考えていますが、それらはサイトに到達していません。 そうです。FTP経由でのファイルのアップロードを含む、アップロードのすべての段階が正常に完了した後にのみ、交換計画への書き込みを完了します。 また、アップロードプロセス中に例外が発生した場合、交換計画でのメッセージの記録を中断し、エラーログにエラーを書き込みます。
2.サーバー上のスクリプトがアンロードされたアーカイブの処理を開始したらどうなりますか？
最初に1つの名前（export.zip_など）を付け、最後にのみ名前を変更して、サーバー上でスクリプトが検索する名前を付けます。
3.サーバーがクラッシュし、スクリプトがアーカイブを処理する時間がない場合、1Cはそれを新しいアーカイブで上書きしますか？
いいえ、このため、各アーカイブには、名前に交換計画のメッセージ番号が含まれています（たとえば、export_1.zip）。 サーバー上のスクリプトは、複数のアーカイブを検出すると、それらを番号の昇順で処理します。
4.そして、ログはオーバーフローしませんか？
なぜなら アンロード中に、各アクションの結果に関する情報がログに詳細に書き込まれると、ログは非常に急速に成長するため、アンロードするたびにサイズを制御し、必要に応じて古いものを削除することを忘れないでください。
5.そして、1Cにアンロードする時間がなく、この時点で新しいアンロードのプロセスが開始された場合はどうなりますか？
スケジューラー設定で、前のタスクが完了していない場合に新しいタスクが実行されないように構成します。
PS
そのため、このような簡単な方法で、かなり短期間、サイトへのアイテム/価格/残高のアンロードが実装されました。 もちろん、このオプションには多くの欠点があり、唯一の真の栄冠であるとは言えませんが、同時にお客様のエコシステムによって設定された制限に完全に適合することができました。 この設計はすべて弱いマシンで動作し、1Cの常時実行コピーを必要とせず、最も一般的な仮想ホスティングで動作し、従業員の注意をそらすことはなく、最も重要なことは、1Cを簡単に維持できることです。 寝具は十分であり、幸運にも、ほぼ1年間、システムへの介入は必要ありませんでした。