1C-BitrixからBASHへの標準的な交換：増分アップロードスクリプトの詳細な分析

1CシステムとBitrix管理システム上のサイト間で製品カタログの同期を確保するために、1CからBitrixへの特定のパラメーターを持つHTTP GETおよびPOSTリクエストの転送に基づいて、CommerceML形式のBitrix XMLファイル交換プロトコルの標準が使用され、ステータスを含む標準応答を受信します実装の結果を示す操作。



このシリーズの最初の記事では 、1Cまたは別のシステムまたはプログラムで生成されたXMLファイルを取得し、標準プロトコルを使用してBitrixに転送する別のスクリプトを使用する可能性を実証します。



この記事では、スクリプトの各行に詳細なコメントを付けます。 これにより、ニーズへの変更が簡単になります。



このスクリプトはBASHで記述されており、1C-Bitrixが1Cからカタログ製品を転送し、Bitrix管理システムに基づいて構築されたサイトから注文をダウンロードするために提供するのと同じ標準を通じて異なる交換を提供するいくつかのスクリプトの1つです。



次はコメント付きのスクリプトのテキストです。 排他的なコードを含むスクリプトの簡単なビューは、 前の記事で説明されており、bitrexchangeプロジェクトのgithubで入手できます。

スクリプトとローカルファイルの設定

空または破損したファイルが送信されるのを防ぎ、エラーが発生した場合のデータ破損を防ぐために、スクリプトを終了します。

set -e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在の完全なパスを変数に保存しながら、これは現在のディレクトリへの非常に興味深い移動です

 cd $(dirname $0) cdir=$(pwd)"/"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常、1Cはファイルをネットワーク上のサーバー上の共有フォルダーにアップロードします。これは事前にマウントします。 しかし、それはあなたのためのローカルディレクトリであり、ネットワーク上であなたによって共有されます

 remote_dir="/mnt/localwinserver_fs/import/webdata/"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

xmlファイルがパックされるzipファイルの名前。 代わりに、一時的な名前のみを使用できます。 ただし、このようなハードコードされたファイル名は、以前に転送されたファイルのコピーを保存するために使用されます。 それは非常に便利です。いつ、どの製品がどの日に登場し、どの価格で表示されたかなどを確認できます。

 zip_fname="catalogue.zip"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

転送するファイルの名前。 これらのファイルは1Cによって形成され、通常はそのような名前を持っていますが、他にもあるかもしれません！ それをチェックアウトする必要があります！ ファイルはスペース付きでリストされます。

 xml_files="import0_1.xml offers0_1.xml"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラーメッセージが送信される管理者のメール。

 email1="admin@yourinternetshop.com"; email2="alert@yourinternetshop.com";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在の時刻を決定します。

 ctime=$(date +%Y-%m-%d-%H%M)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルの確認と準備

このスクリプトは、多くの種類のダウンロードすべての特殊なケースです。 現在実行中のカタログをアンロードすることに加えて、別のスクリプトがある他の交換があります。 ただし、このアンロードのフレームワーク内-カタログのアンロード、2つのタイプが定義されています。いわゆる増分アンロード、つまり変更のアンロードと完全なアンロードです。 形式では、1つのパラメーターのみが互いに異なります：属性の値

-それはtrueまたはfalseです。 XMLファイルの内容について言えば、インクリメンタルアンロードには完全な製品セットを含めることもできますが、違いは異なります。Bitrixが完全なアンロードを受け取ると、既存の商品カタログ全体を完全に消去し、再び充填します。 商品の画像もすべて失われるため、完全なアップロードには必ずすべての画像が含まれますが、増分アンロードには含まれない場合があります。 もちろん、作成したバインディングをサイトのデータベースに保持することが重要な場合は、既存のディレクトリを削除しないことをお勧めします。 一般に、何らかの方法で、使用するアンロードのタイプと定義する大きな違いがあります。 したがって、1Cを決して信頼しないで、このアンロードが実際に増分であることを確認してください。さらに、両方のファイルをチェックインします。 同時に、これらのファイルがまったく存在すること、および2つのファイルがあることを確認します。 たとえば、何らかの理由で1Cが製品範囲のみをアンロードする場合があり、ボールが落下してファイルがまったくアップロードされないことがあります。 したがって、問題が発生した場合は、そのことを自分で通知して終了します。

 chan=$(grep -e "=\"true" ${remote_dir}*.xml | wc -l) if test "$chan" != "2"; then echo "Error: XMLs are not in 'changes only' mode or file(s) are missing" mail -s " " -a "From: bitrexchange <${email1}>" $email1,$email2 <<< "     ." exit 1 else echo "OK: Format of XMLs are 'changes only'" fi
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作業自体を開始します。ファイルをパックし、以前のファイルのアーカイブを現在の日付にします。 このコマンドは、すべてのxmlファイルをディレクトリにパックすることに注意してください。

 if [ -f $zip_fname ]; then mv $zip_fname "${zip_fname}.${ctime}"; fi /usr/bin/zip -9j "$zip_fname" ${remote_dir}*.xml
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HTTPリクエスト設定

HTTPリクエストのヘッダーを設定します。 実際、これは、第一に、完全にオプションであり、第二に、ユーザーエージェントなど、独自の一部を設定できます。これにより、受信側のApacheログでこれらのリクエストをキャッチできます。

 headers="--header=\"User-Agent: 1C+Enterprise/8.2\" --header=\"Accept-Encoding: deflate\""
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ログインがロードされるユーザーのユーザー名とパスワード。 これは通常1c_importまたはimportです。 このユーザー名とパスワードは、Bitrixコントロールパネルで設定されます！ テストには、管理者アカウントadminを使用できます。

 login="import" password="yourpasswordonbitrix"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトを煩雑にしないために、すべてのリクエストのベースURLを個別の変数に入れます。 これは通常、 ドメイン/ bitrix / admin / 1c_exchange.phpです

 baseurl="http://yourinternetshop.com/bitrix/admin/1c_exchange.php"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際の交換

文書は非常に（！）表面的であり、プロトコルの使用方法は1C構成とは異なるため、使用される交換方法は実験的に検証および確認され、いくつかの作業プロジェクトで変更なしで機能し、大量使用の可能性を確認します。



交換プロトコルによれば、いくつかのタイプのリクエストが順番に送信されます。 リクエストのタイプは、ベースURLに追加されたパラメーターによって決まります。このパラメーターは、既にベースURLとして設定しています。 URLの2つの変数は、リクエストのタイプを指定します。 最初のタイプは、販売またはカタログのいずれかです。 少なくとも最初のリクエストでこれを変更し、常にカタログを使用することができます。 2番目は、変数モードで交換の段階を決定するため、私たちにとってより重要です。



最初のリクエスト、モード= checkauth

2番目の要求、mode = init

3番目の要求、mode = file + POST zip file。

後続のリクエスト、モード=インポート

最初のリクエスト

HTTP認証を使用してログインします！ 通常、このメソッドはbitrixに含まれていますが、含まれていない場合はサーバー設定を確認してください。 私の知る限り、bitrixでこのメソッドを有効または無効にする設定はありませんが、多くの方法でプログラムで認証をオフにすることができます。 いわゆる「プロアクティブな防御」も干渉する可能性があります。ログインできない場合は、テスト中は無効にしてみてください。

 ret_line=$( wget $headers --user=${login} --password=${password} --auth-no-challenge -O - -q "${baseurl}?type=sale&mode=checkauth" ) read -a ret_ar <<< $ret_line
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロトコルによると、ログインが成功した場合、BitrixはHTTP応答の本文に3行の形式で応答を返します。



最初は文字列の成功です

2番目はセッション変数で、通常はPHPSESSIDです

第三-セッション値、文字列。



susseccを受信した場合は、セッション変数とその値を保存して、将来使用できるようにします。保存しない場合は、スクリプトを終了します。 この時点でエラーが発生した場合、何らかの方法で保存および表示できるHTMLページを取得できます。ほとんどの場合、ログインが必要であるというメッセージが表示されます。 この段階-ほとんどの場合-ユーザーのユーザー名とパスワードを確認し、まず、このユーザー名とパスワードの下でBitrixコントロールパネルに移動します。

 if [ ${ret_ar[0]} != "success" ]; then echo "Login error\r\n"; exit -1; fi sessvar=${ret_ar[1]} sessid=${ret_ar[2]} echo sessid=$sessid
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2回目のリクエスト

2番目の要求はInitです。 このリクエストを受信すると、ディレクトリ/ upload / 1c_catalog /は完全にクリアされます（！）前のダウンロードからのデータが必要な場合は注意してください。 たとえば、商品の写真を転送することが重要です。 1Cバージョン8.3は発見されたため、何らかの理由でこの要求は送信されず、すぐにファイル要求に進みます。 この段階でエラーが発生する可能性があります。これについては付録で説明します。エラーの可能性を参照してください（1）。

 ret=$(wget $headers --header="Cookie: ${sessvar}=${sessid}" -O - -q "${baseurl}?type=catalog&mode=init"); echo $ret
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3番目のリクエスト

3番目の要求では、POST要求とともにzipファイルを転送する必要があります。 mode = fileである必要がありますが、ファイル名-パラメータファイル名-私が理解するように、リクエストにはどこにも表示されず、送信されたデータがファイルとして保存される名前のみを設定するため（ファイルはPOSTリクエストであるため、実際にはHTTPのコンテキストでは、これはファイルではなく、単なるデータの一部にすぎません）。



このステップでは、upload / 1c_catalogディレクトリーに、解凍されたimport.zipファイルがあります。 興味深いことに、それ以上の追加リクエストは必要ありません。 最初のインポート要求があるとすぐに、自身を解凍します。

 ret=$(wget $headers --post-file ${zip_fname} --header="Cookie: ${sessvar}=${sessid}" -O - -q "${baseurl}?type=catalog&mode=file&filename=import.zip"); echo $ret
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インポートリクエスト

さらに、1C-Bitrix交換プロトコルによれば、成功文字列が受信されるまで、mode = fileでリクエストを送信する必要があります。 実際、成功ではないことを確認する必要がありますが、各リクエストに進捗応答があり、もしあれば、インポートを続行できます。何か他のものが来た場合、何らかの理由でインポートが終了しました。たぶん成功。 文書化されていない多くのポイントの1つは、そのようなリクエストサイクルを展開されたファイルごとに繰り返す必要があり、zipファイルの名前は他の場所で指定する必要がないことです。 付録のエラー（2）も参照してください。

 for fname in $xml_files; do st="progress"; while [ "$st" = "progress" ]; do ret=$(wget $headers --header="Cookie: ${sessvar}=${sessid}" -O - -q "${baseurl}?type=catalog&mode=import&filename=${fname}"); st=$( <<< "$ret" head -n1 | cut -c1-8); echo "$ret" | iconv -f cp1251 -t utf-8 done done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このサイクルの後、最後のメッセージ=成功であることを確認する必要があります。そうでない場合は、再度自分自身に通知します。 これは、このスクリプトのフレームワーク内で、または他の方法（ログの確認など）で実行できます。

最後のリクエスト

ドキュメントによると、最後の要求はtype = successである必要があり、1Cはこの要求を送信しますが、このスクリプトはこれを不要にします。

アプリケーション：

考えられるエラー（1）

2番目の要求では、エラー「失敗」がスローされます。 コンポーネントは、エラーとともに「失敗」という単語を返し、その後にエラーの説明が続きます。 しかし、どうやら、要求時に言語を判別できないため、エラーを詳細に記述せずに失敗を返すだけです。 何らかの種類のデフォルト言語が必要ですが。 おそらくその理由は他の何かかもしれませんが、事実は失敗が与えられ、それがすべてだということです。 エラーの原因を特定できません。 いつものように、コードに忍び込むことで解決します。

 COption::GetOptionString("sale", "secure_1c_exchange", "N") == "Y"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードでこのパラメーターの検証を直接無効にできます。Nに設定できます。

設定-ツール-PHPコマンドライン。

 COption::SetOptionString("catalog", "DEFAULT_SKIP_SOURCE_CHECK", "Y" ); COption::SetOptionString("sale", "secure_1c_exchange", "N" );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

考えられるエラー（2）

非自明な間違い：各段階で2行が表示されます。1行目は進行状況で、2行目は何が行われているかの説明です。 ですから、間違いなくプログレスブロックが必要です。 YYYYYアイテムのXXXXを処理しました。



-ここでは、「非常に多くの要素の非常に多くを処理します」-これはインポートです。 そうでない場合、インポートは行われません。 そのような場合は、特定の構成でした。



1C-BitrixからBASHへの標準交換： 一連の出版物の最初の記事 。