我正在寻找有关 Shopify 和 Navision 的答案。我们正在考虑将我们当前的网店主机切换到 Shopify。
然而——一件重要的事情是，我们可以让 Shopify 直接与我们的会计系统——Navison（现在的 Microsoft Dynamics NAV）一起工作。这一定是可能的，但是这种集成有多全面（和昂贵），你们中有没有人在这个领域有任何经验？
任何帮助将非常感激。谢谢！
问问题
3343 次
4 回答
6
Since I don't have enough points to post a comment I'm posting this as an answer.
I'm really sorry to have to post such a negative comment like this, especially since I may need help from Shopify dev suport at some point and I really don't want to piss them off, so hopefully they won't take this personally.
I can appreciate some of the design decisions Shopify has made with its APIs, but David Lazar and crew seem to be missing Jarko's point or just don't care.
I personally could care less about SOAP, I use JSON and REST for everything whenever possible and am pretty agnostic when it comes to technology stacks, but I too am disgusted by the limitations of the Shopify product API (and other parts of the API), which, at first glance looks half way decent until you start trying to use it for any heavy lifting.
Virtually every other similar API I've worked with allows devs to create multiple products with a single API call, in fact this is the first API I've ever had to use that didn't offer that ability.
Considering how slow the Shopify API is at creating a single product with variants and images, it's a wonder there's anyone at all using it to manage more than a handful of products. For example, I spent the better part of 2 days waiting for my script to finish creating all our products via the API due to the 1 products per call limitation.
My API library is designed to respect the API request limits, but we never even get close to the limits because it takes between 11 and 20 seconds to create a single product with variants and images. I have roughly 8000 products to upload. Do the math. For people used to working with true enterprise level APIs that can handle thousands of products per API call (AmazonMWS is a perfect example), waiting 2 days for products to finish being created is just crazy, and god forbid you need to do something as simple as reorder the products once they are uploaded.
In that case you get to make another 8000+ api calls to delete all the products (which takes a little over an hour) and then start the upload process all over again and wait 2 days. That's about as inefficient a system as I can imagine. I've tried doing bulk CSV uploads to work around these problems, but guess what? The bulk upload can't handle a CSV file bigger than a couple of megabytes and to reference bulk-uploaded products via the API in future API calls you have to specify a shopify product ID which means that after bulk uploading them, you then have to pull down a list of all the product ids and variant ids and feed that info into your database so you can then reference them by shopify's internal ids instead of some kind of parentid or sku set by the merchant.
All in all, it's a total nightmare to deal with. By contrast it takes about an hour for me to upload and process a full product feed via Amazon's API, including 6000+ parent products with 60,000+ child variants and 60,000+ images. Amazon's API is annoying for different reasons (it takes 5 separate feed formats to upload all the product info and their documentation could make a grown man cry), but at least it's generally fast and capable of processing thousands of products in under an hour.
Amazon’s API also provides mechanisms for bulk updating prices and inventory quantities and updating product data by a merchant-defined identifier such as an SKU which means that it takes about 5 minutes for Amazon to update quantities and prices for my entire inventory without any of the hassles of mapping ids back to products in our internal systems just to be able to reference them 1 at a time.
Also, the fact that there's no way to tell the Shopify product API to replace a product with a duplicate handle instead of creating a new one means that if my script times out or the API chokes due to a communication error (or like today when the API mysteriously began return 404 errors for several hours) and I have to restart multiple times, I end up getting duplicate products which are then very annoyingly difficult to track down and eliminate.
All of this together makes for a miserable experience for anyone who has to manage more than a few hundred products via the Shopify api. Telling developers that it's their own fault for not wanting to jump through all these hoops indicates that Shopify devs are either lazy or just totally out of touch with how developers need to use the API.
Were I not already 3 weeks into my 2-week integration and theoretically just hours away from launching a new site I would be ditching Shopify at this point. This project is now more than a week overdue entirely because of how cumbersome the product API makes managing large numbers of products. And forcing users to come to Stackoverflow to post API questions where they can't even comment without having a certain reputation score....I could go on and on. Don't even get me started about the lack of a discount/promotion api, or the inability to create users via the API that can log in without an admin manually going to the shopify backend and clicking a link for every user they want to activate.
Every time I think I'm going to be able to get something done with this API it turns out the be a clusterf$%*!. But hey, it MUST be an awesome API because it's all done in Ruby using REST principles...oh goody! Sigh. I'll take an ancient SOAP based api over this any day, but it's too late for me to ditch this project and start over now. Double sigh.
于 2012-08-13T23:42:56.743 回答
1
查看 Shopify的API 文档，在 NAV 和 Shopify 之间同步数据似乎非常简单。在 NAV 中，没有内置的方式来使用 Shopify API，相反，NAV 仅提供与其他系统进行通用集成的构建块。因此，您需要从 NAV 合作伙伴处获得报价，以确定他们编写集成的成本。
成本取决于您需要在两个系统之间同步多少实体，以及您使用的是哪个版本的 NAV。如果您使用的是 NAV 2009 R2（最新版本），合作伙伴可以编写运行在 NAV 服务器中的.NET代码来直接调用 Shopify。如果您使用的是较早版本，则合作伙伴将需要使用COM或CFront，这需要更多的工作。
于 2012-06-22T11:18:50.067 回答
-3
My 2 cents is that when I tried to integrate Shopify to Navision I ran into the fact that it requires SOAP. If you have no experience with SOAP, consider yourself lucky. It is an expression in how not to do Internet Computing in an elegant fashion. It is confined to proprietary Enterprise systems, no surprise there, like Microsoft sells. No one else would bother supporting that software poo.
As long as you toil with .Net C# or Java and have experience with SOAP, bridging Shopify to Navision is likely a simple task. For anyone else that works with the modern Internet using HTTP to transfer data as XML or JSON, the transition to SOAP should be reason enough to run away screaming. Again, just my 2 cents.
于 2012-06-22T16:30:54.657 回答