Shopify と Navision に関する回答を探しています。現在のウェブショップ ホストを Shopify に切り替えることを検討しています。
ただし、重要なことの 1 つは、Shopify を当社の会計システムである Navison (現在の Microsoft Dynamics NAV) と直接連携させることができるということです。これは可能であるに違いありませんが、この統合はどの程度包括的で (そして費用がかかりますか)、この分野での経験はありますか?
どんな助けでも大歓迎です。ありがとう！
コメントを投稿するのに十分なポイントがないので、これを回答として投稿しています。
このような否定的なコメントを投稿しなければならないことを本当に残念に思います。特に、Shopify dev suportの助けが必要になる可能性があり、本当に彼らを怒らせたくないので、彼らがこれを個人的に受け取らないことを願っています。
ShopifyがAPIを使用して行った設計上の決定のいくつかは評価できますが、David Lazarと乗組員は、Jarkoの主張を見逃しているか、気にしないようです。
私は個人的にSOAPについてあまり気にすることができず、可能な限りすべてにJSONとRESTを使用し、テクノロジースタックに関してはかなり不可知論者ですが、Shopify製品API（およびAPIの他の部分）の制限にもうんざりしています。これは、重い物を持ち上げるために使用しようとするまで、一見、中途半端に見えます。
私が使用した他のすべての同様のAPIを使用すると、開発者は1回のAPI呼び出しで複数の製品を作成できます。実際、これは、その機能を提供しなかった、これまでに使用しなければならなかった最初のAPIです。
Shopify APIがバリアントと画像を含む単一の製品を作成するのがどれほど遅いかを考えると、少数の製品を管理するためにShopifyAPIを使用している人がいるのは不思議です。たとえば、呼び出しごとに1つの製品が制限されているため、スクリプトがAPIを介してすべての製品の作成を完了するのを待つために2日間の大部分を費やしました。
私のAPIライブラリはAPIリクエストの制限を尊重するように設計されていますが、バリエーションと画像を含む単一の製品を作成するのに11〜20秒かかるため、制限に近づくことさえありません。アップロードする商品は約8000個あります。計算する。API呼び出しごとに数千の製品を処理できる真のエンタープライズレベルのAPIを使用することに慣れている人にとって（AmazonMWSは完璧な例です）、製品の作成が完了するまで2日間待つのはおかしなことであり、神はあなたが単純なことをする必要があることを禁じていますアップロードされたら、製品を再注文します。
その場合、さらに8000回以上のAPI呼び出しを行って、すべての製品を削除し（1時間強かかります）、アップロードプロセスを最初からやり直して、2日間待ちます。それは私が想像できるほど非効率的なシステムです。これらの問題を回避するためにCSVの一括アップロードを試みましたが、どうでしょうか。一括アップロードでは数メガバイトを超えるCSVファイルを処理できず、今後のAPI呼び出しでAPIを介して一括アップロードされた製品を参照するには、shopify製品IDを指定する必要があります。つまり、一括アップロード後に、次のことを行う必要があります。すべての製品IDとバリアントIDのリストをプルダウンし、その情報をデータベースにフィードして、マーチャントが設定したある種の親IDやSKUではなく、shopifyの内部IDでそれらを参照できるようにします。
全体として、対処するのは完全な悪夢です。対照的に、AmazonのAPIを介して完全な商品フィードをアップロードして処理するのに約1時間かかります。これには、60,000以上の子バリアントと60,000以上の画像を持つ6000以上の親商品が含まれます。AmazonのAPIはさまざまな理由で煩わしいです（すべての製品情報をアップロードするには5つの別々のフィード形式が必要であり、それらのドキュメントは成長した人を泣かせる可能性があります）が、少なくとも一般的に高速で、1時間以内に数千の製品を処理できます。
AmazonのAPIは、価格と在庫数量を一括更新し、SKUなどの販売者定義の識別子によって商品データを更新するメカニズムも提供します。つまり、Amazonが在庫全体の数量と価格を面倒なく更新するのに約5分かかります。一度に1つずつ参照できるようにするために、IDを内部システムの製品にマッピングし直します。
また、Shopify製品APIに、新しいハンドルを作成する代わりに重複するハンドルで製品を置き換えるように指示する方法がないという事実は、スクリプトがタイムアウトしたり、通信エラーのためにAPIがチョークしたりした場合（または今日のようにAPIは不思議なことに数時間で404エラーを返し始めました）、何度も再起動する必要があり、重複した製品を取得することになり、追跡して排除するのが非常に困難になります。
これらすべてが一緒になって、ShopifyAPIを介して数百を超える製品を管理する必要がある人にとっては悲惨な体験になります。これらすべてのフープを飛び越えたくないのは彼ら自身の責任であると開発者に伝えることは、Shopify開発者が怠惰であるか、開発者がAPIを使用する方法にまったく触れていないことを示しています。
2週間の統合にまだ3週間もかからず、理論的には新しいサイトの立ち上げからわずか数時間で、この時点でShopifyを捨てることになります。このプロジェクトは、製品APIが多数の製品の管理を非常に面倒にしているため、完全に1週間以上遅れています。そして、ユーザーにStackoverflowにアクセスして、特定のレピュテーションスコアがないとコメントすらできないAPIの質問を投稿するように強制します。割引/プロモーションAPIがないことや、管理者が手動でShopifyバックエンドにアクセスしてアクティブ化するすべてのユーザーのリンクをクリックしなくてもログインできるAPIを介してユーザーを作成できないことについても始めないでください。
このAPIで何かを成し遂げることができると思うたびに、それはclusterf $％*！であることがわかります。しかしねえ、それはすべてRESTの原則を使用してRubyで行われるので、素晴らしいAPIでなければなりません...おやおや！はぁ。私はこれについていつでも古代のSOAPベースのAPIを使用しますが、このプロジェクトを捨てて今からやり直すには遅すぎます。ダブルため息。
ShopifyのAPI ドキュメントを見ると、NAV と Shopify の間でデータを同期するのは非常に簡単なようです。NAV には、Shopify API を操作する組み込みの方法はありません。代わりに、NAV は、他のシステムとの一般化された統合のためのビルディング ブロックのみを提供します。そのため、NAV パートナーから見積もりを取得して、統合を作成するためのコストを決定する必要があります。
コストは、2 つのシステム間で同期する必要があるエンティティの数と、使用している NAV のバージョンによって異なります。NAV 2009 R2 (最新リリース) を使用している場合、パートナーは NAV サーバーで実行される.NETコードを記述して Shopify を直接呼び出すことができます。以前のバージョンを使用している場合、パートナーは代わりにCOMまたはCFrontを使用する必要があり、これは少し手間がかかります。
私の 2 セントは、Shopify を Navision に統合しようとしたときに、SOAP が必要であるという事実に遭遇したことです。SOAP の経験がない場合は、幸運だと考えてください。これは、インターネット コンピューティングをエレガントな方法で行わない方法の表現です。マイクロソフトが販売しているように、それはプロプライエタリなエンタープライズ システムに限定されており、当然のことです。他の誰もそのソフトウェアのうんちをサポートすることを気にしません。
.Net C# または Java で苦労し、SOAP の経験がある限り、Shopify を Navision に橋渡しすることはおそらく簡単な作業です。XML または JSON としてデータを転送するために HTTP を使用して最新のインターネットで作業している他の人にとっては、SOAP への移行は悲鳴を上げるのに十分な理由になるはずです。繰り返しますが、私の 2 セントです。