[閒聊] web與AP的溝通?消失

看板Soft_Job作者時間13年前 (2012/10/30 21:27), 編輯推噓20(20推 0噓 40→)
留言60則, 27人參與, 最新討論串1/3 (看更多)
不太確定標題怎麼下比較好 事情是這樣的 公司做工業電腦的 最近要生產一批新貨 1.訂單產生後 透過 EIP 系統(web)取得這張訂單的 出貨序號及MAC(產量10台就給10組出貨序號/10組MAC) 2.接下來 由軟體工程部寫一支AP程式，寫好安裝在成品機器上 AP主要目的 就是向 EIP 拿MAC，再將MAC燒進成品，並做檢測 他們只提到是在linux環境下寫code. 結果軟體工程跟MIS溝通過程中 就有點雞同鴨講 因為大家都不熟對方的作業 (對方是軟體工程部 我們是MIS) 最後總算硬著頭皮想了解法 -A方案 軟體工程部希望直接從EIP資料庫取得這張訂單的MAC 但我同事認為這樣太危險了..(不希望別部門知道我們DB帳密) 後來討論 -B方案 由軟工透過URL發出給號需求 從web計算並抓取1組序號 組好後再傳送一串url給他，(sn.asp?mac=0003EXXXX) 我是不太懂軟體工程那邊怎麼做事 或者給他一串含參數的網址 他就能get到每一個參數的值嗎?..... (我同事建議的解法 後來又找軟體工程談 也說OK) 然後今天又確認了一次 發現軟體工程師說的是 我們收到他的需求，計算1組序號出來 直接印在網頁上 他再去那個頁面上把序號讀出來... 結果我把結論回報給我同事 他就一直在談網頁UI 接收資料 存檔 轉網頁 這些動作上 他認為直接秀一張頁面給軟體工程部抓資料 沒頭沒尾 甚至很耗資源(?) 我認為反正就是把處理結果印在網頁上 印完再把DB關閉就好... 等發出下一筆需求 網頁再印出下一組序號值.. 生產幾台就loop幾次 我就跟他說 就把這張網頁當成一個媒介 當成是跟軟體工程那隻AP溝通的橋樑 不要想成是網頁功能.. 結果居然回我「阿明明就是網頁啊...」 說真的我有點不知我同事在擔心什麼 他比我資深 而且有待過軟體公司的經驗 基本上觀念會比我嚴謹很多 所以通常我滿尊重他的看法 但針對這件事 真的想不通顧忌點在哪 一開始不想別部門從我們db抓資料 這我能理解 (即使對方已經講明 給他select權限就好 甚至給他一個table抓序號就好) 我同事還是很緊張 就跟我說寧願透過網頁方式傳送結果給他 也不要他來存取 才又討論另一種做法B方案 1.講好是傳網址+參數(讓他接參數值) =>後來改成2 2.軟體工程要求放在*.html上 他從網頁上讀資料 我是覺得還OK 1.2 兩種做法意義上不是差不多嗎? 反正我們(web)都需要先計算下一筆序號是啥 再丟出來不是嗎? 有人可以回答我 是我同事想太多還是我想太少.. 因為感覺應該是不複雜的一件事阿.. -- ※ 發信站: 批踢踢實業坊(ptt.cc)
推
10/30 21:34, , 1F
我猜可能是資料庫有license issue
10/30 21:34, 1F
→
10/30 21:36, , 2F
方案C-存檔後~直接給下載網址 XD 讓軟工自己下載回去分析
10/30 21:36, 2F
其實我不懂的是 http://www.XXXXXXX.asp?MAC=0003EXXXX web可以透過request("MAC")抓到值 但軟體工程師他們使用的技術該怎麼抓值? 因為他們寫的東西都是安裝在機器上的 用來檢查這台機器是否合格.. ※ 編輯: cyr1216 來自: 1.164.119.207 (10/30 21:42)
→
10/30 21:38, , 3F
擔心耗資源大概是怕資料太多~從Server處理成網頁再送給bro
10/30 21:38, 3F
→
10/30 21:39, , 4F
用POST傳SSL加密過後的資料夠安全了吧?
10/30 21:39, 4F
→
10/30 21:40, , 5F
wser會慢?那可能給下載網址會好一點...
10/30 21:40, 5F
→
10/30 21:40, , 6F
重點是有沒有把傳遞和回傳的資料加密 而不是用啥方式傳
10/30 21:40, 6F
→
10/30 21:41, , 7F
沒加密 管你怎樣傳 都有辦法看到內容 而且老實說
10/30 21:41, 7F
→
10/30 21:41, , 8F
都同公司的 只是部門不同 須要考慮啥資安問題?
10/30 21:41, 8F
→
10/30 21:41, , 9F
自己公司駭自己公司???
10/30 21:41, 9F
→
10/30 21:44, , 10F
樓上~他只是純粹不想讓別的部門直接存取資料庫而已吧...
10/30 21:44, 10F
→
10/30 21:45, , 11F
如果request都能發了~那response能收應該不意外...
10/30 21:45, 11F
→
10/30 21:47, , 12F
這個到底有麼危險XD , 開讀不開寫不就好了
10/30 21:47, 12F
→
10/30 21:49, , 13F
你們這種東西會有performance issue的話...一句話
10/30 21:49, 13F
→
10/30 21:49, , 14F
出貨量事有到水果那麼大嗎..-_-
10/30 21:49, 14F
→
10/30 21:53, , 15F
自己公司駭自己公司...就是有這種事發生啊, 故意砍DB看過沒
10/30 21:53, 15F
→
10/30 21:53, , 16F
能保證快離職員工還乖乖的嗎.
10/30 21:53, 16F
不要說快離職的人 就連自己下SQL有時也會手殘忘了加where...XD
→
10/30 21:54, , 17F
耗資源... 那這我真的聽到會笑出來. 8086的server嗎?
10/30 21:54, 17F
→
10/30 22:05, , 18F
管server的有管server的難處，真的爆了半夜被alert叫起來的
10/30 22:05, 18F
→
10/30 22:06, , 19F
不是那些使用server資源的人，而是那些管理server的人。
10/30 22:06, 19F
→
10/30 22:07, , 20F
select 寫壞了確實有可能，最好能經由 dba 審過，至少確定
10/30 22:07, 20F
→
10/30 22:08, , 21F
東西有吃到 index，或是需要調整 index。
10/30 22:08, 21F
→
10/30 22:09, , 22F
最簡單又安全的方法，應該是從DB開一個只能存取
10/30 22:09, 22F
→
10/30 22:10, , 23F
特定資料的帳號吧。
10/30 22:10, 23F
→
10/30 22:11, , 24F
何必多一層Web Data Access還要自己搞 Authentication。
10/30 22:11, 24F
→
10/30 22:30, , 25F
另外你推文的問題，可以從 HTTP Response 的 Header
10/30 22:30, 25F
→
10/30 22:31, , 26F
Location 欄位，取得網址重導後(帶有MAC)的網址。
10/30 22:31, 26F
請問你的意思是 軟體工程師可透給我們給的網址解析到他要的資料嗎? ※ 編輯: cyr1216 來自: 1.164.119.207 (10/30 23:01)
推
10/30 23:15, , 27F
建一個table view再開只能select的帳號給他就好啦不是嗎?
10/30 23:15, 27F
推
10/30 23:32, , 28F
直接印在網頁上就好了，還重新導向幹什麼？ = =
10/30 23:32, 28F
如果軟體工程師作業方便的話 我也是覺得印在網頁上給他抓值就好 原本他是希望從db抓(被拒絕) 不得已才又想出 我們抓值傳給他 這方法 也是希望能早點定案 否則談不攏大家都不用做事也很麻煩
推
10/30 23:33, , 29F
GET接在網頁上面丟過去就好了...
10/30 23:33, 29F
→
10/30 23:36, , 30F
程式也是可以讀網頁內容的..... 很多地方都拿80port來做奇
10/30 23:36, 30F
→
10/30 23:36, , 31F
怪的事啊....
10/30 23:36, 31F
※ 編輯: cyr1216 來自: 1.164.119.207 (10/30 23:45)
→
10/30 23:44, , 32F
拿網頁內容單純很多。不過要改變網址內容，或直接得到
10/30 23:44, 32F
→
10/30 23:45, , 33F
新的網址，就要重導阿。(雖然這種作法非常不直覺)
10/30 23:45, 33F
→
10/30 23:46, , 34F
建議你就直接把MAC放在網頁上吧，也符合REST Sevice。
10/30 23:46, 34F
嗯嗯!! 我會再跟同事講講看 原則上還是希望大家不要做很多道不必要的工 ※ 編輯: cyr1216 來自: 1.164.119.207 (10/30 23:49)
推
10/31 01:20, , 35F
給一個store procedure呢？
10/31 01:20, 35F
推
10/31 06:46, , 36F
不用弄出網頁啊，傳json/xml不就好了...
10/31 06:46, 36F
推
10/31 07:33, , 37F
同樓上，我第一直覺也是這樣，大家避而不談是因為有什麽
10/31 07:33, 37F
→
10/31 07:33, , 38F
缺點嗎?
10/31 07:33, 38F
→
10/31 07:35, , 39F
ap端是java還可以弄個rmi之類的web service
10/31 07:35, 39F
推
10/31 12:48, , 40F
弄一個API就好惹
10/31 12:48, 40F
推
10/31 16:35, , 41F
microsoft也有wcf很好用啊?
10/31 16:35, 41F
推
10/31 17:06, , 42F
web service/xml比純reponse一個序號更搞工吧....
10/31 17:06, 42F
推
10/31 17:23, , 43F
傳個json會難到哪去?
10/31 17:23, 43F
→
10/31 22:12, , 44F
不難啊... 只是還要多一步. 何必?
10/31 22:12, 44F
→
10/31 22:33, , 45F
不在別人基本認知中的東西 就算比較簡單也是麻煩 @@
10/31 22:33, 45F
推
11/01 00:10, , 46F
我比較好奇是不是很多網頁工程師不熟HTTP裏頭傳些什麼?
11/01 00:10, 46F
→
11/01 00:10, , 47F
(就經驗上是這樣沒錯)
11/01 00:10, 47F
→
11/01 00:12, , 48F
App 與內嵌的 Web 溝通可以用 external object 的技巧…
11/01 00:12, 48F
→
11/01 00:13, , 49F
簡單說就是由 ap 在 web 內塞一個 javascript function
11/01 00:13, 49F
→
11/01 00:13, , 50F
web 的流程在處理完後去 call 該 function 設值給 client
11/01 00:13, 50F
推
11/01 00:32, , 51F
現在是在比誰可以更浪費時間嗎? OO?
11/01 00:32, 51F
推
11/01 00:54, , 52F
這有什麼難的，真是搞不懂…
11/01 00:54, 52F
→
11/01 01:05, , 53F
你同事沒搞懂什麼叫 web service 吧。
11/01 01:05, 53F
推
11/01 01:59, , 54F
弄個WebService 給軟工部門Call就搞定拉
11/01 01:59, 54F
推
11/01 02:12, , 55F
這個討論太有趣了, 一件簡單的事, 大家越討論越複雜~~
11/01 02:12, 55F
推
11/01 03:31, , 56F
看來看去 只是在擔心效率問題 跑了才知道有沒有效率問吧
11/01 03:31, 56F
推
11/01 13:23, , 57F
看這一長串..真有點替你們公司擔心XD
11/01 13:23, 57F
推
11/01 20:10, , 58F
你同事是白吃嗎
11/01 20:10, 58F
→
11/01 23:58, , 59F
你同事有什麼祕密在裡面嗎
11/01 23:58, 59F
推
11/07 13:27, , 60F
直接就是想到webservice阿 有什麼問題
11/07 13:27, 60F
‣ 更多 cyr1216 的文章
文章代碼(AID): #1GZzMfW1 (Soft_Job)
‣ 更多 cyr1216 的文章
文章代碼(AID): #1GZzMfW1 (Soft_Job)