異なるEコマースエンジン間でのデータの移行

問題

現在、オンラインストアには、機能、機能、コスト、インストール方法が異なる300以上の異なるエンジンがあります。 原則として、これはホスティング（実際にはサイトのインストール）にデプロイされるスクリプトのセットであり、ほとんどの場合はPHP + MySQLです。



最近、いわゆるホスト型ショッピングカートは、電子商取引プラットフォームの市場で大きなニッチを占めています。 つまり、同じShopifyのWebサイトに登録することで、数回クリックするだけで、Shopify自体でホストされている試用版ストアを取得できます。 トライアル期間と限られた機能は、原則として、カードの機能をテストするのに十分です。 さらに、このようなソリューションは、もちろん、独自のホスティングのレンタル、エンジンおよび必要なすべてのPHPモジュールなどのインストールに関連する頭痛の種を取り除きます。彼らが言うように、すべてが既に配備されています。



結果として、異なるプラットフォームはストアデータにアクセスする異なる方法です。 オープンソースカード（「ホストされていない」）がデータベースに直接アクセスできる場合、SaaSソリューションはそのような機会を与えません。 代替オプションは、APIリクエストを介してアクセスできます（プラットフォームでこの方法ですべての必要なデータを取得できる場合は、開発者がこのまたはそのエンティティを操作するすべてのメソッドを追加しない場合があるため非常に便利です）またはファイル（CSV、 XML、txt、dat、xls、およびエンジンに応じたその他の形式）。



後者の方法は、ほぼすべてのプラットフォームでサポートされていますが（それぞれに独自の制限があります）、同じカード間の移行を簡素化します。 しかし、osCommerceをベースにしたストアを1年以上使用しており、MagentoまたはBigCommerceの新しいバージョンに移行する必要がある場合、タスクはさらに複雑になります。



そのような目標を持っている開発者にとって、それを解決する方法は2つあります。

• 自動移行には既製のツールを使用します。
• 前のオプションがすべての要件を満たすことができない場合、独自のソリューションを検索/開発します：少なくとも古いプラットフォームからエクスポートされたファイルの形式を変更して新しいプラットフォームにインポートするモジュールまたは個別のスクリプト（プラットフォームがファイルの操作をサポートしている場合）

もちろん、管理パネルから新しいプラットフォームに手動でデータを入力できますが、製品やユーザーの数が3桁の数字で測定される場合、このオプションはオプションではなくなります:)



したがって、最初の2つのケースを検討します。

カスタム移行

このデータ転送方法はより長くなる可能性があり、自動移行と比較してそのコストも高くなる可能性があります。



なんで？



このタスクに取り組むプログラマーを雇う必要があるため、簡単です。 もちろん、機械ではなく人の仕事のために、あなたはもっと支払う必要があります。 そして、たとえあなた自身が一流のプログラマーであり、必要なスクリプトを非常に書くことができたとしても、時間がかかり、お金であることが知られています。 特にあなたが優秀なプログラマーである場合。



考慮すべきもう1つの要因は、ソリューションの開発にかかる時間です。 そして、あなたのビジネスプロジェクトが十分に緊急である場合、ほぼ確実にあなたは十分な時間を持っていないでしょう。



一方、このアプローチの特徴であるコストと開発時間の増加は、特定の目標と要件への適応という1つの大きな利点によって正当化できます。 ただし、制限がある場合がありますが、それらについては少し後で説明します。



自動化ツールは、限られた数のプラットフォームをサポートする傾向があります。 そのような移行は、長年の使用と数千の移行によって洗練されてきたため、一方では間違いなくプラスになります。 しかし同時に、これはマイナスでもあります。これらのプラットフォームの特定の共通データセットのみをカバーし、ツールにあるような方法で解釈できるためです。 たとえば、さまざまなカードの税の本質は、まったく異なる要素とデータで構成されるまったく異なる方法で構成および使用できます。 したがって、移行はツール内でそのまま行われます。 カスタムツールを使用すると、特定のケース向けに開発されるため、このようなことを最小限に抑えることができます。



カスタムソリューションを可能な限り効果的にするには、使用する必要のあるプラットフォームをより詳細に検討する必要があります。 エンティティを調べて、それらを正しく機能させるために、エンティティ間の関係を決定します。 プラットフォームが異なる場合、プラットフォームの1つが他のプラットフォームにはないエンティティをサポートできることに注意してください。 たとえば、Magentoには製品のバリエーションという概念がありますが、OpenCartにはありません。 あまり頻繁ではありませんが、エンティティが両方のプラットフォームでサポートされていると思われる場合がありますが、それぞれ異なる方法で構築され、同時に完全に異なる目的を持つことができます。



この特定の部分が将来のソリューションの「ボトルネック」になる可能性があるため、データにアクセスする方法には特に注意を払う必要があります。 ショッピングカードがホストされていない場合、つまりデータベース付きのスクリプトセットがインストールされている場合、このデータベースに物理的にアクセスできるため、このデータベースに追加するのと同じ方法で必要なすべてのデータを取得できます。 主なことは、どこにどのような情報があるのか​​、それが何を意味するのか、どのように形成されるのかを理解することです。 さらに、このようなマップでは、商品の画像、商品のダウンロード可能なデータなどのファイルにアクセスできます。



この場合、データ移行スキームは次のようになります。











異なるサーバーに2つのストアがあります。 移行スクリプトはいずれかのサーバーにインストールされ、このサーバーのデータベースへの直接接続が使用されます。 別のストアに接続するには、直接接続を使用できますが、そのためには外部からアクセスを開く必要があります。



サーバーが同じサーバー上にある場合、追加のアクセスは必要ありません。 ストア自体がデータベースへの接続に使用するものと同じものを使用できます。 通常、それらはストアの構成ファイル（たとえば、ストアのルートディレクトリにあるconfig.phpまたはconfiguration.php）にあります。











PHPでデータベースに接続するためのサンプルクラス：

class Db { private $_link = null; private $_triesCount = 10; public function connect($config) { while (!$this->_link) { if (!$this->_triesCount--) { break; } $this->_link = mysql_connect($config['dbHost'], $config['dbUser'], $config['dbPass']); if (!$this->_link) { sleep(5); } } if (!$this->_link) { die(mysql_error($this->_link)); } mysql_select_db($config['dbName'], $this->_link); } public function query($sql) { $query = mysql_query($sql, $this->_link); if (!$query) { die(mysql_error($this->_link)); } return $query; } public function cntRows($query) { return mysql_num_rows($query); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

移行プロセスは、次の手順で構成されます。

1. ソースストアからのデータのプル：データベースから。 API経由; ファイルから。
2. ターゲットストア形式にデータを取り込む：ターゲットストアのテーブルまたはファイル構造に。
3. データをターゲット側に挿入します：データベース内、API経由、ファイル内。

ホスト型ショッピングカードでは、すべてが少し異なります。 ストアは開発者のサーバーにインストールされるため、データベースに直接アクセスすることはできません。また、管理パネルからデータベースを管理する機会しか与えられません。 データを取得するために、ホスト型ショッピングカードの一部の開発者（残念ながら、すべてではない）は、このデータを操作するための一連のメソッドを含む特定のAPIを提供します。











確かに、カードによっては、このセットはかなり意味があり、タスクの要件を満たさない場合があります。 これらは、前述の制限です。 たとえば、Shopifyは、十分に実装され、文書化された方法にもかかわらず、顧客注文の作成を許可していません。 既存の情報のみを表示したり、いずれかのステータスを変更したりできます。 また、Miva MerchantにはAPIを介して作業する機能がありません。 APIのもう1つの機能は、期間ごとのリクエスト数の制限です。 スクリプトまたはプログラムがこの制限を超えると、その後のリクエストが数分間まったく実行されない場合があります。



ほとんどすべてのショッピングカードには、ファイル形式のデータのエクスポート/インポートがあります。 そのようなファイルの情報が移行の成功に十分な場合、データベースへのアクセスは必要ありません。 多くの場合、マップによってエクスポートされるファイルの構造は、データベースの構造よりも直感的であり、APIリクエストへの応答のコンテンツよりも完全です。 データベースへの直接接続がないため、ツールをより柔軟にすることができます。特定のファイル形式に合わせて研ぎ澄まされ、データベースへのアクセス権やAPIリクエスト数の制限などに依存しません。 ショッピングカード間のストレージメディアとしてファイルを使用する場合、通常、独自のスクリプトやプログラムを作成することはできません。 これらのファイルを編集して、必要な形式に変換するだけで十分です。



いくつかのファイル移行スキーム：



1. 1つのファイル形式を別の形式に変換します。











2.ファイルからデータベースへの移行：











3.データベースからファイルへの移行：











このような移行の段階は、前の例とほぼ同じですが、追加の手順がある場合があります。

1. ソースからファイルにデータをエクスポートします。
2. ファイルからデータを引き出します。
3. データをターゲット形式にする：テーブルの構造またはストアのターゲットファイル。
4. ターゲットストアのファイルの生成。
5. 生成されたファイルをターゲットストアにインポートします。

ところで、データベースサーバーへのアクセスを開くオプションが受け入れられない場合は、ファイルの形式でデータベースからデータを取得できます。 phpMyAdminを使用すると、テーブルの内容をCSV、XML、その他のファイルとしてエクスポートできます。



カスタムツールに必要なリソースに関しては、これは転送する必要があるデータの量と、スクリプト自体の実装に依存します。 信頼性を高め、リソース消費を抑えるには、100個のエンティティの配列など、バッチでデータを転送することをお勧めします。



一般に、サーバーの1つで実行されるPHPスクリプトのオプションを検討する場合、次のことを検討する価値があります。

• スクリプトはサーバーに追加の負荷を作成します。これは、同じサーバー上にあるサイトまたはサイトの操作に影響を与える可能性があります。
• スクリプトには一定量のRAMが必要です。これは、スクリプトの実装、特に1回の反復で転送されるデータパケットのサイズに直接依存します。
• スクリプトは、データベースまたはファイルを操作するときにディスクシステムに追加の負荷を作成します。
• データ転送プロセスの期間は、このデータの量に依存し、数分から数時間、場合によっては数日続くこともあります。

カスタムソリューションの作成に使用されるプログラミング言語については、厳密な制限はありません。 主なことは、データベース（必ずしもMySQLではない）への接続、HTTPリクエストの実行、ファイルや画像の操作など、必要な機能を実装できることです。 プラットフォームの大部分はPHPで記述されているため、最もよく使用されるのはまさにそれです。 同じJavaもタスクの解決に適していますが。



ところで、そのようなカスタムツールやスクリプトを作成する会社があります。 特に、TransPacific Software Pvt。 株式会社 osCommerceをMagentoに、X-CartをOpenCartに、Zen CartをOpenCartまたはMagentoに、MagentoにLoaded Commerce（CRE Loaded）を移行するためのソリューションを最大25営業日提供することを提案します。

自動移行

ショッピングカード間でデータを転送するための既製のソリューションには、カードのサービスとアプリケーションの2つのグループがあります。 後者はすべてのカードに対して作成されるわけではなく、より狭い範囲を対象としています。 原則として、対象となるカードのみをサポートします。 このようなアプリケーションは比較的安価で（無料でない場合）、ショッピングカードの1つにインストールされ、カードが機能するホスティングリソースを使用します。



このようなデータ転送の手段はハンドツールに起因する可能性があり、その本質を考えると公平です。 しかし、これらがまだ既成のソリューションであることを考慮すると、私の意見では、これらはこのカテゴリに位置しています。



自動化されたサービスは、さらに多くの種類のショッピングカードをカバーします。 サポートされているオプションのリストには、さまざまなカードのジョイントエンティティの最大数が含まれています。 エンティティが特定のカードに固有である場合、同じプラットフォーム間でデータを転送するときに移行する可能性もあります。



もちろん、カードのカスタムモジュールで生成されたデータ（特定のレポートなど）を転送することはできません。 少なくともサービスの標準機能にはこれが含まれていません。 それでもサービスと必要なカスタムデータを使用することに決めた場合は、サポートチームに追加の作業が可能かどうかをいつでも問い合わせることができます。 もちろん、価格に対して+になります。 自動移行の価格といえば、プロセスへの人的介入が最小限で済むため、通常はカスタム移行の場合よりも低くなります。



一部のサービスでは、SEOデータの移行、製品IDの保存、注文など、移行のための追加オプションが提供されます。 これらのオプションのコストは、移行全体のコストに追加されます。



例として、約50枚のショッピングカードをサポートするCart2Cartサービスを考えます。 商品とそのカテゴリ、メーカー、顧客リストとその注文、税金などのデータを転送できます。また、移行の特定の方向ごとに多くの追加オプションがあります。



移行スキームは次のとおりです。











サイトのデータベースに接続するために、サービスはストアのルートディレクトリに事前インストールされた特別な接続ブリッジを使用します。



すべての移行は AmazonのElastic Cloud（EC2）サーバーで実行されるため、プロセスの高速性が確保され、大量のデータに対処できます。 したがって、すべてのプロセスは専用サーバーで発生します。



一部のショッピングカードでは、ファイルからの移行がサポートされています。

エンティティ間の関係

各ショッピングカードでは、 商品（製品）、顧客（顧客）、注文（注文）の 3つの主要なエンティティを区別できます。 他のすべては何らかの形で主要なものと接続されています。 エンティティを移行する場合、このデータをターゲットストアに正しく復元するために、エンティティ間の関係を考慮することが重要です。



次の図は、主要なエンティティと他のエンティティの関係を示しています。 ショッピングカードによって、リストは異なる場合があります。

製品の本質には、そのようなエンティティが含まれるか、それらに関連する場合があります。

• カテゴリー
• 画像 （画像）;
• レビュー （レビュー）;
• optionsには、 オプション （オプション項目）の値が含まれます 。

ユーザーエンティティはアドレスに関連付けられており、複数のアドレスを含むことができます。











注文エンティティは、次のエンティティに関連付けられています。

• ユーザー （顧客）;
• 請求先住所
• 配送先住所
• 製品
• 合計 （合計）;
• 注文の履歴（履歴）。

ちなみに、 順序では、原則として、ユーザーと製品に関する情報が複製されます。 つまり、注文を行った顧客のIDと注文した製品のIDを保存することに加えて、これらのエンティティに関する基本情報がデータベース内の別のテーブルに複製されます。 これにより、カタログからユーザーアカウントまたは製品が完全に削除された場合でも、完全な注文情報を保存できます。

まとめ

Eコマースプラットフォーム間でのデータ移行のプロセスは、複雑でも単純でも、長時間でも高速でもかまいません。 すべては、選択したパス、ツール、およびリソースに依存します。 業界の急速な発展（アナリストの予測によれば、オフラインストアの3分の1は2017年までに閉鎖される）を考えると、自動ツールは積極的に改善されており、サービスの数が増えているため、データを転送するためのカスタムスクリプトの作成はバックグラウンドに追いやられています。