Shopify 및 Navision에 대한 답변을 찾고 있습니다. 우리는 현재 webshop 호스트를 Shopify로 전환 할 것을 고려하고 있습니다.shopify navision
ShopSense가 회계 시스템 인 Navison (현재 Microsoft Dynamics NAV)과 직접 협력 할 수 있다는 것이 얼마나 중요한 것입니까? 이것이 가능해야하지만이 통합은 얼마나 포괄적이며 가격이 비싸지 만이 분야에 경험이있는 사람이 있습니까?
도움을 주시면 감사하겠습니다. 감사!
Shopify에 대해 API documentation을 보면 NAV와 Shopify간에 데이터를 동기화하는 것이 매우 간단합니다. NAV에는 Shopify API를 사용할 수있는 기본 방법이 없지만 NAV는 다른 시스템과의 일반화 된 통합을위한 빌딩 블록 만 제공합니다. 따라서 NAV 파트너의 견적을 받아 통합 작성 비용을 결정해야합니다.
비용은 두 시스템간에 동기화해야하는 엔티티 수와 사용중인 NAV 버전에 따라 달라집니다. NAV 2009 R2 (최신 릴리스)에있는 경우 파트너는 NAV 서버에서 실행되는 .NET 코드를 작성하여 Shopify에 직접 전화 할 수 있습니다. 이전 버전을 사용하는 경우 파트너는 대신 COM 또는 CFront을 사용해야합니다. 이는 조금 더 많은 작업입니다.
내 2 센트는 Shopify를 Navision에 통합하려고했을 때 SOAP이 필요하다는 사실에 부딪혔다. SOAP에 대한 경험이 없다면 스스로 행운이라고 생각하십시오. 그것은 우아한 방식으로 인터넷 컴퓨팅을하지 않는 방법에 대한 표현입니다. 독점적 인 엔터프라이즈 시스템에 국한되어 있습니다. Microsoft가 판매하는 것처럼 놀랄 일도 아닙니다. 아무도 그 소프트웨어 똥을 지원하는 것을 성가 시게하지 않을 것입니다.
.Net C# 또는 Java를 사용하고 SOAP 경험이있는 한 Navify에 Shopify를 연결하는 것이 간단한 작업 일 수 있습니다. HTTP를 사용하여 XML 또는 JSON으로 데이터를 전송하는 현대 인터넷에서 작동하는 다른 모든 사람들을 위해 SOAP 로의 전환은 비명을 날려 버릴만한 충분한 이유가되어야합니다. 다시, 단지 2 센트.
ERP는 _Enterprise_ Resource Planning - Enterprise 소프트웨어에서 널리 사용되는 웹 서비스 프로토콜을 사용하는 NAV의 약자입니다. SOAP은 독점 시스템에 국한되지 않습니다. 예를 들어 [Apache Axis2] (http://en.wikipedia.org/wiki/Apache_Axis2)는 오픈 소스 구현입니다. –
알렉스 포인트를 놓쳤습니다. Axis2에 대한 귀하의 언급조차도 오래되고 오래되지 않은 엔터프라이즈에 관한 이야기입니다. SOAP의 모든 예제는 2005, 2006입니다. SOAP을 기반으로하는 인기있는 회사의 최신 API를 보여줍니다. 저의 요점은, SOAP를 통해 NAV에 Shopify를 연결하는 것이 통증을 편안하게하는 사람을위한 운동이라는 것입니다. 가장 현대적인 Ruby SOAP 라이브러리는 2007 년의 삶을 끝냈습니다 ... 저의 오랜 기간 동안 엔터프라이즈 컴퓨팅 역사에 대해 충분히 알려줍니다. EDI처럼 ... 죽을 지 진화하지 않을거야. –
다음 번에 "답변"을 게시하고 싶다면 메모 형식으로 제안하십시오. 댓글은 당신이 목표를 조롱하고 있거나 거기에 도달하는 방법과 같은 포인트에 적합합니다. 더 나은 아직, 당신은 당신 자신을 위해 당신의 2 센트를 유지할 수 있습니다. – Kallja
염두에 두어야 할 한 가지는 NAV 2013입니다. 이 릴리스에는 Odata에 대한 지원이 포함되어있어 JSON이 일반적인 데이터 형식이므로 Shopify 통합을 훨씬 쉽게 할 수 있습니다. 그러나 완전한 서클 판매 거래와 관련된 다양한 세부 사항 모두가 ERP 시스템 (NAV뿐만 아니라)으로의 통합을 보장하는 데 상당한 노력을 기울일 것입니다. 귀하의 필요가 극도로 좁지 않다면 NAV 파트너로부터 비싼 견적을 볼 준비를하십시오.
그것은 경제에서 독점 소프트웨어에 대한 훌륭한 것입니다. 그것은 단순히 이익을 다하는 같은 회사가 제공하는 조리법을 조심스럽게 분배하고 따르는 사람들에게 지불 한 거액의 돈없이 간신히 기능합니다. 그런 아늑한 작은 세상, 결국 최종 소비자에게 거의 도움이되지 않습니다. –
@DavidLazar 진정한 오픈 소스 전도사와 같은 말입니다. 모든 시스템에 투입된 노력 (개발)은 개방형 플랫폼에서 자체 개발에 대해 이야기하고 있는지 아니면 다른 사람과 계약하여 우리에게 힘든 일을하든 관계없이 비즈니스 환경에서 가격표를 가지고 있음을 명심하십시오 . 물론, 독점적 인 플랫폼을 전문으로하는 개발자보다 개방형 플랫폼에서 더 많은 유능한 개발자가 작업 할 수 있습니다. 여전히 일을 끝내는 데 드는 총 비용은 그만큼 높을 것입니다. – Kallja
의견을 게시 할 충분한 점수가 없으므로 답변으로 게시하고 있습니다.
저는 Shopify dev suport의 도움이 필요할 수도 있기 때문에 이런 부정적 코멘트를 게시해야하므로 정말 유감입니다. 그리고 나는 그들을 화나게하고 싶지 않습니다. 이걸 개인적으로 가져 가라.
Shopify가 API로 만든 디자인 결정에 감사하지만 David Lazar와 선원은 Jarko의 요점을 빠뜨린 것 같아요.
필자는 개인적으로 SOAP에 관심이 없다. 가능한 한 JSON과 REST를 사용하고 기술 스택에 대해서는 매우 불가지론하지만 Shopify 제품 API (및 다른 부분)의 한계에 너무 싫증이났다. API)는 언뜻보기에는 절반 정도의보기 좋게 들여다 보면 무거운 물건을 들어 올릴 때까지 사용하기 시작합니다.
거의 모든 다른 비슷한 API를 사용하여 개발자가 하나의 API 호출로 여러 제품을 만들 수있게되었습니다. 실제로이 기능을 제공하지 않은 최초의 API입니다.
변형 및 이미지가 포함 된 단일 제품을 만드는 데있어 Shopify API가 얼마나 느린지를 고려할 때 소수 이상의 제품을 관리하는 데 사용하는 사람이 누구인지 궁금합니다. 예를 들어 통화 당 1 개의 제품 제한으로 인해 스크립트를 통해 API를 통해 모든 제품을 만드는 것을 기다리는 데 2 일의 더 좋은 시간을 보냈습니다.
내 API 라이브러리는 API 요청 제한을 준수하도록 설계되었지만 변형 및 이미지가 포함 된 단일 제품을 만드는 데 11-20 초가 걸리기 때문에 한계에 거의 다가 가지 않습니다. 업로드 할 제품이 약 8000 개 있습니다. 수학 해. API 호출 당 수천 개의 제품을 처리 할 수있는 진정한 엔터프라이즈 수준의 API (AmazonMWS가 완벽한 예입니다)로 작업 한 사람들에게 제품 작성을 기다리는 데 2 일을 기다리는 것은 미친 일이며 신은 당신이 제품이 업로드되면 제품 순서를 변경합니다.
그런 경우 모든 제품 (1 시간 조금 걸립니다)을 삭제하고 다시 업로드 프로세스를 시작하고 2 일을 기다리는 또 다른 8000+ API 호출을해야합니다. 그것은 제가 상상할 수있는 비효율적 인 시스템입니다. 이러한 문제를 해결하기 위해 대량 CSV 업로드를 시도했지만 무엇을 추측합니까? 일괄 업로드는 몇 메가 바이트보다 큰 CSV 파일을 처리 할 수 없으며 향후 API 호출에서 API를 통해 대량 업로드 된 제품을 참조 할 수 없으므로 대량 업로드 한 후 제품 ID를 지정해야합니다. 모든 제품 ID와 변형 ID의 목록을 가져 와서 해당 정보를 데이터베이스에 제공하므로 상인이 설정 한 일종의 parentid 또는 sku 대신 shopify의 내부 ID로 참조 할 수 있습니다.
전체적으로 볼 때 대담한 악몽입니다. 반대로 Amazon의 API를 통해 전체 제품 피드를 업로드하고 처리하는 데 약 한 시간이 걸립니다. 6000 개 이상의 상위 제품에 60,000 개 이상의 하위 변형 및 60,000 개 이상의 이미지가 포함되어 있습니다. 아마존의 API는 여러 가지 이유로 성가시다. (모든 제품 정보를 업로드하기 위해 5 가지 별도의 피드 형식이 필요하며 문서로 인해 어른이 울 수있다.) 적어도 1 시간 이내에 수천 개의 제품을 처리 할 수있는 속도는 일반적으로 빠르다.
Amazon의 API는 SKU와 같은 가맹점 정의 식별자로 대량 가격 및 재고 수량을 업데이트하고 제품 데이터를 업데이트하는 메커니즘도 제공합니다. 즉, Amazon에서 재고없이 수량 및 가격을 업데이트하는 데 약 5 분이 걸립니다. 한 번에 하나씩 참조 할 수 있도록 내부 시스템에있는 제품으로 다시 매핑하는 번거 로움이 없습니다.
새 제품을 만드는 대신 Shopify 제품 API에서 제품을 중복 핸들로 교체 할 수 없다는 사실은 통신 오류로 인해 스크립트가 시간 초과되거나 API가 멈추는 경우 (또는 API가 불가사의하게 몇 시간 동안 404 오류를 반환하기 시작한 오늘과 같이) 나는 여러 번 다시 시작해야합니다. 결국 추적하고 제거하기가 매우 까다롭기 때문에 중복 제품을 얻게됩니다.
이 모두가 Shopify API를 통해 수 백 가지 이상의 제품을 관리해야하는 모든 사람들에게 비참한 경험을 제공합니다. 개발자가이 모든 작업을 뛰어 넘지 않으려 고하는 것이 자신의 잘못이라고 말하면 Shopify 개발자는 게으르거나 개발자가 API를 사용해야하는 방법을 전혀 알지 못한다는 것을 나타냅니다.
아직 2 주간의 통합에 3 주가 걸리지 않았으며 이론적으로는 새로운 사이트를 시작한 지 불과 몇 시간이 지났지 만 지금은 Shopify를 피할 것입니다. 이 프로젝트는 현재 제품 API가 얼마나 많은 제품을 관리하는 번거 로움 때문에 완전히 일주일 이상 지연되었습니다.그리고 사용자가 특정 평판 점수를 얻지 않고도 논평 할 수없는 곳에서 API 질문을 게시하도록 Stackoverflow에 오도록 강요합니다 .... 나는 계속해서 갈 수 있습니다. 할인/프로모션 API가 없거나 관리자가 수동으로 shopify 백엔드로 이동하여 활성화하려는 모든 사용자의 링크를 클릭하지 않고 로그인 할 수있는 API를 통해 사용자를 생성 할 수 없다는 사실에 대해 저를 시작하지 마십시오. .
나는이 API를 사용하여 무언가를 할 수있을 것이라고 생각할 때마다 clusterf $ % *로 밝혀졌습니다. 하지만 REST 원칙을 사용하여 Ruby에서 모두 완료되었으므로이 기능은 멋진 API 여야합니다. 오, 안녕하세요! 한숨. 이 날을 통해 고대 SOAP 기반 API를 가져올 것입니다. 그러나이 프로젝트를 버리고 지금부터 시작하는 것은 너무 늦었습니다. 두려운 한숨.
의견에 감사드립니다. 다른 서비스와 비교하여 정직한 보고서를 남겼다면 다행입니다. Shopify Developer Advocates는 귀하가 제기하는 문제점을 알고 있습니다. 이러한 삶의 질 문제에 관한 보고서를 통해 우리를 대신하여 프로젝트 관리자와 협상하는 데 도움이됩니다. –
답장을 보내 주셔서 감사합니다. 내 의견이 귀가 먹은 귀에 들리지 않았기 때문에 기쁩니다. 좋은 소식은 우리가 마침내 새로운 Shopify 스토어를 어제 출시 할 수 있다는 것입니다. 나쁜 소식은 ... 이제 모든 가격을 업데이트하고 API를 통해 한 번에 한 통화 씩 모든 제품에 대해 3 개의 메타 필드를 만들어야합니다. 와아! (<---- 그것은 울부 짖는 사람의 소리입니다). – minorgod
전화를 병렬 처리하는 [Typhoeus] (https://github.com/typhoeus/typhoeus)와 같은 것을 사용해 보셨습니까? –
Navision과 맞춤 웹샵을 통합했습니다. 얼마나 많은 통합이 필요한지에 달려 있습니다. 그런 다음 통합 방법을 파악할 수 있습니다. –