開發背景

在使用銷幫幫的時候錯誤的將簽訂時間和開始時間弄錯了，造成開始時間是正確的簽訂時間，簽訂時間是正確的開始時間。在2020年前需要把錯誤資料處理掉。

解決方案

方案一：可以通過匯入匯出功能，把資料匯出來，然後更新欄位後重新匯入進去。

缺點：由於有同名的人員，銷幫幫的匯入不能正確處理同名的人員資訊，所以該方案否決。

方案二：通過銷幫幫API更新資料，通過諮詢銷幫幫的相關技術負責人，確定更新時，不需要拿到所有的資料，更新那個欄位就修改那個欄位即可，類似於SQL:

Update Table Set Field1=Value1 where ID=1 的格式。感覺可行

中間遇到的問題：通過介面API測試時，發現如果修改了欄位後，會重新走審批流程。確定這是API的錯誤，銷幫幫會修改該問題。

由於時間緊張，而銷幫幫的問題修復需要時間，所以暫時把簽訂、開始時間從審批中去掉解決該問題。 確定方案可行

方案三：通過模擬修改資料，可以通過抓包模擬正常操作進行資料修改

缺點：1、需要知道所有的欄位，然後更新的時候也要更新所有的欄位。不能實現類似Update Table Set Field=Value Where ID=1 格式的修改

2、 需要實現查詢、資料分析、然後更新 抓包比APi複雜。不採用該方法。

開發邏輯

通過【合同訂單列表介面】抓取合同的列表資訊

        在抓取合同列表資訊時發現的問題

1、 隱藏的欄位是不顯示的，雖然這些欄位在審批時會用到，但是依然不顯示。

2、 技術問題：由於資料是Json格式的，不想寫個固定的類，然後NewtonSoft去轉換，採用了dynamic 型別，只要找到自己要的幾個欄位即可。

3、 為了試試技術能力，還特意想吧Json的所有的欄位都採集下來，然後整理成一張SQL表，方便查詢所有的資料。Json的dynamic後只有JArray/JObject/JValue/JProperty 4中型別，根據4種類型遍歷 然後整理成 Key=Value型別的資料儲存到一張表裡即可。根據需要列轉行即可。

4、 為了確定資料處理過，準備一張表儲存已經處理過的資料，保證不重複處理。

5、 為了省事，還專門準備了Dapper進行資料庫處理，在處理過程中發現Dapper對資料庫的批量入庫並不友好。自己又寫了個SQLBulkCopy 來進行批量入庫，開始的時候10條/秒的速度入庫，後來讀完即可完成入庫。總共468083條資料，好慶幸寫了SQLBulkCopy 否則不知道採集一次到什麼時候了。

軟體使用教程

習慣了VS開發各種工具，所以還是使用C#+SQLServer開發

以前作爬蟲留下的習慣，所有的方法只完成一個功能，資料通過佇列進行中轉，比如採集只需要把資料採集下來，然後分析的另起執行緒進行分析，資料分析完後，有專門的執行緒進行儲存入庫，有專門的佇列儲存執行日誌，專門的執行緒顯示日誌。

1、 採集合同列表資訊

首先點選按鈕開始，按照分頁採集合同列表資訊，如下圖。等待提示全部採集完成後，開始分析資料

2、 資料分析

通過SQL初始化合同資訊基本資訊，ID，編號，通過【更新到資料庫】按鈕整理需要的欄位到合同表中。

在銷幫幫欄位名稱、資料庫欄位名稱中輸入需要轉換的欄位名稱，選擇欄位型別，如果是字串，直接複製；如果是時間型別，則轉換為標準的年-月-日 時:分:秒格式的資料；如果是列舉型別，則根據列舉值獲取列舉描述資訊。

3、 資料分析後，會把需要把資料都整理到合同表中

4、 資料處理更新到銷幫幫

資料處理可以分為批量資料處理、單條資料處理。根據已經採集到資料庫的資訊進行批量的銷幫幫資料更新，更新後在對應的表中儲存已修改狀態，防止重複修改。並在銷幫幫新增系統備註欄位標識：已經處理 2步驗證 防止重複修改。

為了快熟處理特定條目的資料，可以通過【更新時間到銷幫幫】按鈕單條修改合同資訊，在上面的文字框輸入合同編號，然後點選下方的【更新時間到銷幫幫】按鈕更新單條合同資訊。

總結

通過這次小工具的開發，感覺還是沒有準備好各種基礎工具類，包括ORM標準類，日誌處理標準類、Http採集標準類等。

唯一有點挑戰的也就是系統標準化、列舉匹配、遞迴函式處理。

這次的Json處理，感覺NOSQL越來越近了，很多東西都不能通過關係型資料庫關聯起來了。如果非要關聯起來會非常的麻煩，比如這次的合同表就有合同基本資訊、模版資訊、負責人、協同人、附件等資訊整個而成。如果整理成關係型資料庫最少得4張表。

各有優劣吧

&n