shopify navision

Question

我正在尋找關於Shopify和Navision的答案。 我們正在考慮將我們當前的網店主機改為Shopify。

但是，重要的是，我們可以讓Shopify直接使用我們的會計系統--Navison（現在是Microsoft Dynamics NAV）。 這必須是可能的，但這種整合有多全面（和昂貴），你們中誰都有這方面的經驗嗎？

任何幫助將非常感激。 謝謝！

Answer 1

由於我沒有足夠的積分發表評論，我將其作為答案發布。

我真的很遺憾不得不發布這樣的負面評論，特別是因為我可能需要Shopify dev支持的幫助，我真的不想小便，所以希望他們不會這樣做。

我可以欣賞Shopify通過其API進行的一些設計決策，但David Lazar和工作人員似乎缺少Jarko的觀點，或者只是不在意。

我個人可能不太關心SOAP，我盡可能地使用JSON和REST來處理所有事情，並且在技術堆棧方面我非常不可知，但我也對Shopify產品API（以及API的其他部分）的局限性感到反感，乍一看，在你開始嘗試使用它進行任何繁重的工作之前，乍看起來都不錯。

實際上，我使用過的所有其他類似的API都允許開發人員使用單個API調用創建多個產品，實際上這是我曾經使用過的第一個沒有提供該功能的API。

考慮到Shopify API在創建具有變體和圖像的單一產品方面的速度有多慢，所以根本不會有任何人使用它來管理多種產品。 例如，由於每個呼叫限制1個產品，我花了2天的大部分時間等待我的腳本通過API完成所有產品的創建。

我的API庫旨在尊重API請求限制，但我們甚至都沒有接近極限，因為創建具有變體和圖像的單個產品需要11到20秒。 我有大約8000個產品要上傳。 算一算。 對於過去使用真正的企業級API的人來說，每個API調用可以處理數千個產品（AmazonMWS就是一個完美的例子），等待2天產品完成創建只是瘋了，上帝禁止你需要做一些簡單的事情在上傳產品后對其進行重新排序。

在這種情況下，您可以再次進行8000+ api調用以刪除所有產品（需要一個多小時），然后重新開始上傳過程並等待2天。 這就像我想象的那樣效率低下。 我嘗試過批量CSV上傳來解決這些問題，但你猜怎么着？ 批量上傳無法處理大於幾兆字節的CSV文件，並且在未來的API調用中通過API引用批量上傳的產品，您必須指定shopify產品ID，這意味着批量上傳后，您必須下拉所有產品ID和變量ID的列表，並將該信息提供給您的數據庫，以便您可以通過shopify的內部ID而不是商家設置的某種parentid或sku來引用它們。

總而言之，這是一個徹頭徹尾的噩夢。 相比之下，我需要大約一個小時的時間才能通過亞馬遜的API上傳和處理完整的產品Feed，其中包括擁有60,000多個兒童版本和60,000多張圖片的6000多種母版產品。 亞馬遜的API因各種原因而煩人（需要5種不同的Feed格式才能上傳所有產品信息，而且他們的文檔可能會讓成年人哭泣），但至少它通常很快，能夠在一小時內處理數千種產品。

亞馬遜的API還提供批量更新價格和庫存數量以及通過商家定義的標識符（如SKU）更新產品數據的機制，這意味着亞馬遜需要大約5分鍾來更新我的整個庫存的數量和價格，而不會有任何麻煩將id映射回我們內部系統中的產品只是為了能夠一次引用它們1。

此外，沒有辦法告訴Shopify產品API用​​重復的句柄替換產品而不是創建新的產品，這意味着如果我的腳本超時或由於通信錯誤導致API窒息（或者就像今天的API神秘地開始返回404錯誤幾個小時）並且我必須多次重啟，我最終得到重復的產品，然后非常難以追蹤和消除。

所有這些共同為那些必須通過Shopify api管理超過幾百種產品的人帶來了悲慘的體驗。 告訴開發人員，不想跳過所有這些環節是他們自己的錯，這表明Shopify開發人員要么懶惰，要么完全不了解開發人員如何使用API​​。

如果我已經進入為期2周的整合已經有3個星期了，理論上距離推出一個新網站還有幾個小時的時間我就會放棄Shopify。 由於產品API管理大量產品的繁瑣程度，這個項目現在已經過了一個多星期了。 並迫使用戶來Stackoverflow發布API問題，他們甚至無法評論而沒有一定的聲譽評分....我可以繼續下去。 甚至沒有讓我開始關於缺少折扣/促銷API，或無法通過API創建用戶，無需管理員手動進入shopify后端並為每個要激活的用戶單擊鏈接。

每次我認為我能用這個API完成一些事情就會發現它是一個clusterf $％*！。 但是，嘿，它必須是一個很棒的API，因為它都是使用REST原則在Ruby中完成的......哦，好！ 嘆。 我會在任何一天采用一種古老的基於SOAP的api，但現在放棄這個項目並重新開始為時已晚。 雙重嘆息。

Answer 2

要記住的一件事是NAV 2013即將來臨。 此版本包括支持的OData ，這將有可能使得Shopify整合實質上更容易，因為JSON將是通用的數據格式。 但是，全圈銷售交易中涉及的所有細節都確保了這種與ERP系統（不僅僅是NAV）的集成將是一項重大的工作。 除非您的需求非常狹窄，否則請准備好從您的NAV合作伙伴那里看到一些昂貴的報價。

Answer 3

查看Shopify的API文檔 ，看起來在NAV和Shopify之間同步數據非常簡單。 在NAV中，沒有內置的方法可以使用Shopify API，而NAV只提供與其他系統進行通用集成的構建塊。 因此，您需要從NAV合作伙伴處獲得報價，以確定他們編寫集成的成本。

成本取決於您需要在兩個系統之間同步的實體數量，以及您正在使用的NAV版本。 如果您使用的是NAV 2009 R2（最新版本），合作伙伴可以編寫在NAV服務器中運行的.NET代碼，直接調用Shopify。 如果您使用的是早期版本，則合作伙伴需要使用COM或CFront ，這是一項更多的工作。

Answer 4

我的2美分是當我嘗試將Shopify集成到Navision時，我遇到了它需要SOAP的事實。 如果您沒有使用SOAP的經驗，請認為自己很幸運。 它表達了如何不以優雅的方式進行互聯網計算。 它僅限於專有的企業系統，毫無疑問，就像微軟銷售的那樣。 沒有人會打擾支持那個軟件便便。

只要您使用.Net C＃或Java並且具有SOAP經驗，將Shopify橋接到Navision可能是一項簡單的任務。 對於使用HTTP將數據作為XML或JSON傳輸的現代互聯網的任何其他人來說，過渡到SOAP應該足以讓人們尖叫起來。 再說一次，我的2美分。