為什麼基於 CSV 文件的集成比基於 API 的集成更好

已發表: 2018-11-07

商家經常需要將大量數據（例如產品目錄、訂單或客戶數據）從一個系統移動到另一個系統以進行處理或組織。問題是一個系統如何構建和接受數據可能與目標系統不同。那麼，您如何在系統之間傳輸和共享數據（除了手動輸入）？

許多依賴於使用 CSV（逗號分隔值）文件在系統之間導出和導入其數據的文本文件的集成。 CSV 是一種通用文件類型，許多系統都支持並且商家可以輕鬆管理。雖然文件集成通常是一種集成選項，但它也有其局限性。在您評估這種數據集成方法時，本文會考慮為什麼通過 CSV 文件進行基於文件的集成比基於 API 的集成更好。

什麼是平面文件集成？

基於文件的集成是指您的源數據和/或目標數據必須在文件（如 CSV 文件）中表示。一些系統需要它作為 API 或直接數據庫連接的替代方案。基於文件的集成允許數據在不同的數據庫或操作系統之間傳遞，而不必直接連接到它們。

雖然基於文件的集成可以包括不同的文件類型（例如 XML、JSON），但本文特別關注 CSV 文件集成。 CSV 文件中只能包含一個文件，但有時基於文件的集成需要您組合來自多個文件的元素。它們被稱為“扁平化”文件，其中在多行中定義了一條記錄。

CSV 用於存儲表格數據。這意味著它們可以從將數據存儲在表格中的程序（如 Microsoft Excel 或其他電子表格軟件）中導入和導出，以成為可讀格式。需要注意的是，CSV 不能包含公式或 Excel 工作表提供的任何格式設置功能。如果您將 Excel 文檔另存為 CSV，則所有多餘的內容都將被刪除。

由於各種原因，商家幾十年來一直成功地使用 CSV 文件集成在系統之間移動數據。然而，在過去的 10 到 15 年中，API 已經成為兩個系統相互通信或集成的一種更“現代”的方式。有什麼不同？

API 集成與 CSV 集成方法

API（應用程序接口）是一組代碼，允許兩個軟件程序相互通信。軟件的 API 為開發人員編寫從另一個系統或應用程序請求服務的程序提供了一種標準的、可預測的方式。

REST (REpresentational State Transfer) API 接受對 GET、PUT、POST 或 DELETE 數據的 HTTP 請求。 REST 代表了大多數現代 Web 服務開發中使用的一種架構風格和通信方法。因此，它通常用於構建允許用戶與雲服務連接和交互的 API。

SOAP（簡單對象訪問協議）是另一種用於開發 API 的協議。它在新 API 中不如 REST 常見，但完成基本相同的事情。

API 集成讓您可以通過 API 在兩個系統之間解釋和轉換數據，從而連接兩個系統。它支持數據流，例如從 ERP 中的已知 API 端點“獲取產品”和“PUT 產品”到電子商務平台中的已知 API 端點。

雖然 API 集成是一種更現代的方法，但對於希望集成其係統的商家而言，它並不總是正確的解決方案（或可能）。下面深入探討了為什麼基於文件的集成比 API 集成更好。

為什麼基於文件的集成比 API 集成更好

在某些情況下，CSV 集成可能對您的業務最有意義。請參閱下面這種系統集成方法的一些主要優點。

無需 API 即可保持和連接系統

並非所有軟件系統都具有可用於集成的 API。對於較舊的“遺留”軟件來說通常是這種情況，但對於像 Salesforce Commerce Cloud (Demandware) 電子商務平台這樣的現代系統來說也是如此。必須在不使用 API 的情況下與這些系統集成，這意味著您最好的選擇可能是基於文件的集成。

大多數係統至少通過手動導入過程接受 CSV，無論軟件的年齡如何。有些（同樣，如 Salesforce Commerce Cloud）提供通過指向 SFTP 服務器自動導入 CSV 的能力。

值得注意的是，許多商家將使用這種集成方法，而不是承擔有時成本高昂的項目來升級或替換這些無 API 系統。

非專有

CSV 文件不屬於任何特定軟件供應商。創建和共享 CSV 是處理數據的通用方式。這使它們易於在人和系統之間進行交互和共享。您可以利用 Excel 或其他電子表格軟件創建 CSV，大多數人都習慣以這種方式處理它們。無論您使用哪種特定軟件，能夠導入和導出 CSV 文件並不是該軟件或品牌獨有的。

更容易創建文件

由於 CSV 是純文本文件，因此 Web 開發人員或團隊的其他成員可以更輕鬆地以電子表格的形式創建、查看和驗證數據。您所需要的只是頂部的標題行和隨後的數據行。您將能夠根據需要操縱數據來組織它。然後很容易在不同的系統之間共享這些數據。

數據之間沒有層次關係，除非您使用多個 CSV 文件人為地表示該層次結構。如果您需要這樣做，它確實會使基於 CSV 的集成更加複雜。

商家可能創建的 CSV 文件的常見示例是定價表、客戶列表、產品數據、訂單數據以及在其電子商務和 ERP 或 POS 系統之間共享的折扣。

多源之間的標准通信

CSV 文件也是一種標準的數據通信方式，這使它們成為從多個來源或系統收集和編譯數據的絕佳工具。雖然數據的格式（哪些列的順序）可能會有所不同，但 CSV 是一種成熟的、幾乎普遍支持的文件類型。

例如，您可能會從少數不同的供應商那裡收集產品目錄。無論他們使用什麼系統來掌握他們的產品數據，他們都應該能夠導出他們所有產品數據的 CSV。然後，您可以獲取此 CSV 文件並將其導入您的系統。您無需擔心直接集成到他們的系統中。由於安全或其他問題，您甚至可能沒有直接的 API 集成選項。

基於文件的集成的局限性

您應該考慮這種集成方法的缺點，尤其是在將此方法與基於 API 的集成等替代方法進行比較時。

安全責任

當自動化 CSV 文件傳輸時，您實際上是在服務器上放置一個文件，然後由另一個系統拾取該文件。誰在維護服務器？在整個過程中，您如何確保數據安全？

基於文件的集成要求商家以不同的方式考慮安全性。雖然您希望您的數據在整個傳輸過程中都是安全的，但您也不能讓訪問變得太困難。否則，將很難與其他業務系統進行通信。您有責任找到這種平衡並確保所有人（僅此而已）可以根據需要訪問這些文件。

批量同步

在集成系統時，大多數商家都希望在系統之間實時或即時同步他們的數據。

這對於具有快速變化的庫存可用性的電子商務項目或必須在兩天內發貨的訂單等數據尤其重要。在線下訂單後，您希望減少所有銷售渠道的庫存數量並開始處理訂單。這種同步的延遲，即使是小至 30 分鐘，也可能在限時搶購或節假日等銷售高峰期造成超賣。它們還可能會減慢訂單履行速度，導致您錯過保證的交貨日期。您的客戶將承擔後果。

默認情況下，大多數 CSV 文件集成無法立即同步。這是因為當其他一些系統不斷地從 CSV 讀取新行時，實際上不可能不斷地向 CSV 寫入新行。您必須將一堆行寫入文件，刪除要拾取的文件，然後啟動一個新文件。

這意味著無論您啟動新文件的規則是“行數”還是“時間段”，在此過程中都會存在某種延遲。

以另一種方式考慮 CSV 文件集成：您不會像電子郵件一樣按需交付郵件。一天一次，您可能會收到一批信件，並且您也將它們作為一批發送出去。

處理複雜的數據結構

雖然 CSV 的平面文件結構可能是一個優勢，但也可能是它的缺點。按照設計，CSV 數據既不是分層的也不是面向對象的，這意味著它們具有普遍存在的結構。對於某些商家來說，當您有多個相互關聯的數據層時，這是一個問題。考慮一下您需要如何表示具有多個訂單項的訂單或具有多種尺寸或顏色的產品。

您最終將創建多個 CSV 文件來嘗試表示數據之間的這種關係。嘗試管理和組織大量數據可能具有挑戰性。

驗證數據

系統集成的一個關鍵步驟是驗證您正在傳輸的數據。您不想將不准確或錯誤的數據發送到另一個系統，尤其是因為它可能導致“無效”錯誤。通過 CSV 文件集成，數據驗證對用戶來說是一個手動過程。

當您處理包含數百行數據的多個 CSV 時，驗證變得難以管理。您將不能僅僅“目測”一切看起來都很好發送。相反，如果錯誤，用戶將依靠用 Excel 編寫的公式或宏來突出顯示單元格。然後，您需要手動修復任何錯誤。在查看大量數據時，此過程既耗時又出錯。

在某些情況下，加載 CSV 數據的系統可能會在導入的 CSV 上提供數據驗證，但這也有缺點。這些特性的存在性和魯棒性在平台間並不一致。而且，他們通常在失敗時無法很好地管理導入事務。這可能意味著如果 100,000 行中有一行不正確，則整個導入可能會失敗。

從數據傳輸期間的錯誤中恢復

CSV 文件集成依賴於在服務器上刪除和拾取文件。在整個過程中，可能會出現很多問題，例如文件損壞或服務器或文件系統關閉。通常也不會檢查無效字符、缺少數據描述或其他文件內容問題。當您發送有這些問題的文件時會發生什麼？你打算如何修復它？

管理用於數據處理的計算資源

根據編寫代碼以集成您的系統的方式，基於文件的集成可能需要大量 CPU 和 RAM 來跨多個文件讀取大型數據集。

字符編碼問題

每個系統都有自己的默認字符編碼，例如 UTF-8。在共享文本文件（如 CSV）時，商家必須考慮到文件需要使用相同的編碼字符。否則，您的 CSV 文件之一可能會被拒絕，或者數據可能會出現錯誤，因為系統無法正確讀取您的字符。例如，目標系統可能無法讀取亞洲語言的專用撇號或字符。

了解有關 CSV 集成的更多信息

在整合他們的系統時，商家可以選擇。對於許多人來說，通過 CSV 進行基於文件的集成可能是正確的選擇。但是，這種集成方法並非沒有您應該考慮的缺點。

如果您有興趣了解有關如何通過基於文件的集成實現業務自動化的更多信息，請了解有關 nChannel 文件傳輸解決方案的更多信息，該解決方案旨在直接解決本文檔中描述的所有挑戰。