20150905-工作-近期工作狀況+實作出EAI RQ/RS定義檔

回憶照~(20130824-第一次越野精實團)~~

因2015/08/29阿寬告知，七星山主峰柱子被人為破壞！真是該死的王八蛋！~
紀念那時越野團一同上山的回憶。

==========================================================

來寫寫近期的工作狀況，
目前都過得非常的"精實"，而這樣的記錄，先來記記「較有成就感」的一段開發~~

==========================================================
這「較有成就感」的是：EAI電文範例程式。

而這一連串的過程就LOG下來。

8/26(三)預計明天要提供給Benson一版EAI電文處理的範例
這時的電文RQ/RS的處理，是我當下認為「很有架構」的Class處理。

就是針對VN029，我將RS接收到後，依該支的RS定義檔，在VN029.cs下描述它要序列化給Web的Json格式。

在星二，發Mail給George /HJ 後，他們說，不是這樣寫 (!?)
因而安排了 星期三 下午在公司討論

在激烈的討論後，發現，真的就這樣使用，到時partner在每支開發時，會用的很"複雜"，
要更簡單的透過「XML」定義去處理！！

當天晚上&隔天早上，就思考&將這樣架構的XML及使用方式訂出來！
星期四下午就與Benson他們報告！

這是訂出來的呼叫方式：


這是訂出來的TradeDefine.xml  (這是Final版，即星四報告完後，後來RQ參數的填入/RS的訊息處理都有再調過)



這是VN029_Define.xml各電文所訂出來的長像 (MAC/RQ/RS)



星期四，在與他們報告結束，這一份XML設計，應是可以滿足這電文的需求，

再來就是「實作」的部份了！！

===================================================
星期五搞了一天，非常專注的去實作它，(印象中做好 RQ/RS Message這一段)
而那RS的處理比我想像中的複雜。

而它複雜的地方在於：
EAI的XML層級 與 產出的JSON 層級，是可以變化的！可以達到 平鋪 或是 轉為多階層。

這就是那時在思考這邏輯的「筆記」~



分三段處理：
將EAI Node 資料 放至 Dictionary 裡。
而當處理好EAI Node 那一筆的最後一個節點時 (即 最深層的最後一個節點)
就要開始填好「Dic」及開始「轉JSON」格式。

在填好「Dic」這部份，透過 MapKey 及Params的變化，可以去取得對應Map的資訊。
(這部份也做的頗有意思的)

而填好「Dic」後，再來的「轉JSON」，竟比我想像中的難處理！！

難的地方是：我要透過 JSON物件 Dictionary 去表示它的JSON層級關系。
(也就是筆記下面的Logic思考)

它的層級關系是：Dictionary();
若它是單一節點，則object 是 string 型別。
若它是多筆子層(Detail)，則object是 List 型別！！

這可以搞超久，才整理出這樣的觀念！！

這一搞就是搞到星期五的一點半 @@~~~~~

(隔天，到新竹幫雨柔搬家)


而星期日，因為這段處理有BUG (沒辦法動態變化JSON的層級：比如變為：AA/BB/Detail)。

所以，星期日又在改這超挑戰的Logic。

=========================================

星期一，已將這機制實作出來，Partner他們不需用假資料，可以直接去打電文。


「寫程式，最有趣的地方在於邏輯」

這是我趕這功能的心得，

從訂定規格到將它實作出來。
這種開發心情，非常的充實。


而其實最初沒有辦法想到 這麼「簡潔」的使用方式，
實在是與自已的「視野」有關。

看的層面不夠廣。


而這兩個禮拜，腦子裡也都塞滿了這些實作邏輯，導至我失眠很嚴重。
本來就不好睡了，腦子想更多更難入睡。


總之，仍算是「值得」的經驗。


(THE END)