前段時間公司定製系統在調用SAP RFC接口的時候報錯了,看錯誤消息一時半會兒也不知道是哪裏參數數據錯誤,就想着進到SAP系統裏面對這個接口作遠程Debuger,跟蹤一下參數變量的變化,結果發現根本就沒有這個權限。測試
我記得當初入職的時候是有申請過這個權限的,包括IT總裁及公司老闆在內的都贊成了該申請,到SAP系統管理員那邊的時候也照申請的權限更新了角色,但過了一段時間以後這個權限仍是被收回了。聯繫系統管理員被告知:SAP生產機不能開放Debuger權限,哪怕是公司老闆贊成了也沒用,原則上就是不能開放。3d
他口中的「原則」無非就是SAP生產機畢竟是企業生產真實的數據,權限把控要比較嚴格。若是一個帳號有了Debuger權限,那就等於很大程度擁有了SAP系統不少權限,從審計以及IT管控上來講是不合理的。從他的角度上來講或許是對的,但站在IT業務和開發顧問的角度來看,若是遇到了很是規未知的錯誤,就必須經過Debuger來跟蹤解決,甚至要跟蹤到系統深層次的標準邏輯。那些妄想經過數據複製到測試機來讓問題復現的作法都是愚蠢者的行爲。blog
不只如此,我還問過其餘業務顧問,好比SD模塊的業務顧問,他們的帳號連SD模塊不少權限都不具有(如VA02等),甚至連自開自發的報表權限都沒有。有時候用戶打電話發郵件過來反饋異常,經常讓他們感到難堪,由於權限問題他們看不到這個異常。接口
算起來我混SAP界也是有一些年頭了,一直都是用的sap_all,遇到什麼問題解決歷來不會爲權限煩惱,也不會有人來稽覈我IT帳號的權限,而這麼多年來我也歷來沒有由於權限過大而發生過什麼誤操做。開發
因此開放Debuger權限是必定有的,無論是否是SAP生產機,不然不少問題根本就無法解決。惟一要卡控的是誰能擁有這個權限。通常來講資深的開發顧問以及資歷較深的SAP顧問應該擁有這個權限。這就看企業SAP系統管理員的規劃了,若是隻是偷懶而禁用這個權限,那我只能說像這種把SAP系統當菩薩供着的作法特別不專業和沒水準。變量
文章的最後,再說一句:其實SAP系統是能夠管理到一個帳號能夠用Debuger權限,但不容許修改任何變量的值。如此能夠在必定程度上消除Debuger權限帶來的數據風險,但我相信他們絕對不會。bfc