以下是以前關於Authority-check的一份總結,現重新編譯並通過,在這裏記錄一下以防遺忘。
1. Authority-check介紹
在ABAP中,我們經常會使用到Authority-check,其中想必遇到最多的就是activity的authority check,如01代表create、02代表change、03代表display。
Authority-check在ABAP中的調用語法是:
AUTHORITY-CHECK OBJECT object |
從這裏可以看出,它的意思就是說:對於權限對象object下面的不同的ID(我們一般稱爲authority fields)進行不同的權限(這裏的權限就是通過f1所指定的,如這裏可以爲01,02,03等等)檢查.
在ABAP中,如果這個object包含多個ID,需要在這裏全部指定出來。這裏,如果不想進行某一個ID的檢查,那麼可以使用field DUMMY進行ommit掉。
另外這個authority-check後的SY-SUBRC返回值的不同也代表着不同的意思,這裏稍微歸總一下:
0 |
權限check成功 |
4 |
用戶無這樣的權限 |
8 |
在寫ABAP authority-check時,指定太多的ID(最多只能有10個) |
12 |
用戶信息中不存在這樣的authority object |
16 |
用戶信息中不存在這樣的profile |
24 |
指定的fild名字與authority-object中ID需要的field不匹配 |
28 |
用戶信息不正確 |
32 |
用戶信息不正確 |
36 |
用戶信息不正確 |
舉一個被經常舉的簡單的例子.
例如,在系統中,目前該用戶具有以下的authority(已經通過profile以及role)。
Authority object: M_EINF_WRK_BERECH1
Authority ID: ACTVT
Fields: 01-03
Authority ID: WERKS
Fields:0001-0003 .
那麼該用戶通過以下的ABAP可以通過權限檢查:
AUTHORITY-CHECK OBJECT ‘M_EINF_WRK’ ID ‘WERKS’ FIELD ‘0002′ ID ‘ACTVT’ FIELD ‘02′. AUTHORITY-CHECK OBJECT ‘M_EINF_WRK’ ID ‘WERKS’ DUMMY ID ‘ACTVT’ FIELD ‘01′: |
而下面的ABAP check則不能通過:
AUTHORITY-CHECK OBJECT ‘M_EINF_WRK’ ID ‘WERKS’ FIELD ‘0005′ ID ‘ACTVT’ FIELD ‘04′. |
另外在標準的SAP中,如tcode的打開、program的執行等,都是有權限check的。可以查閱:
http://help.sap.com/saphelp_nw04/helpdata/en/52/67129f439b11d1896f0000e8322d00/content.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/52/67167f439b11d1896f0000e8322d00/content.htm
2. Authority-check的應用實例
現在我們自己開發authority-check object並應用到ABAP中去。
在這個例程中,我將使用3個authority check object,2個來源於自己開發,一個來源於系統標準的activity的check(這個也是我們經常使用的).同時自己開發的2個object一個帶有field(也就是可以指定它可以具有哪些權限),另一個不需要指定具有哪些權限。
(1)創建Authority Fields需要用的Data element
這裏爲什麼需要data element呢?這個可以通過SU20(Authority fields list)中查看得出,authority field是建立在data element上的。
創建需要指定具有哪些權限的Field:table à data element à Domain
Domain:
另外該domin具有value table:
Data element:
Table:
同時,我們指定該table具有的值:
創建不需要指定具有哪些權限的Field: data element –》 Domain
Domain:
Data element:
(2)創建Authority Fields
這裏爲什麼需要Authority field呢?這是因爲我們最終authority object包含的最多10的authority field。
Tcode: SU20 Authority fields list
這裏list出來了目前所有的authority fields。
點擊create,創建我們自己的authority field:
創建需要指定具有哪些權限的Field:ZAUTH_FD_1
需要指定data element。
這裏指定maintence dialog for authorization values,這裏我指定了前面創建的value table(ZAUTH_1);但是可以發現,這裏還可以使用domain value table以及domain自己的value list等。
同時,現在因爲是新創建,下面的use in authorization objects是空的,等完成後面的步驟後,這裏會List出來所有使用該authorization field的authority object。
創建不需要指定具有哪些權限的Field:ZAUTH_FD_2
步驟同前一個field。只是這裏不指定authorization value.
最後我們可以在SU20中的這個List中找到剛創建的authority fields:
(3)創建Authority Object
因爲在SAP中,所有的authority object都是以authority class組合在一起的。所以,這裏我們先創建屬於我們自己的autority class。
Tcode: SU21 list of object class
點擊create:
點擊save,然後在SU21中的list中就會多了一條剛創建的這個calss。
選中該ZAUT的class,雙擊進入:
可以發現,目前這個class裏還不包含任何的authority object。
點擊create創建authority object:
其中authorization fields就是在第二步所創建的authorization fields(注意,這裏並沒有對zauto_fd_1指定其Permit value).
另外,還添加了一個acivt的系統標準的authority field,並指定它:
然後再進入該authority class,剛創建authority object就存在了。
(4)創建Profile
Tcode: SU01 user management
Enviroment à Maintain Profile
進入:(這裏我們創建simple profile.關於profile可以查閱更多資料)
點擊create work area for profiles:
現在暫時還沒有Profile,點擊create:
進入:
輸入我們剛創建的authority object,同時,在上面的authorizatio裏,輸入一個新的ZAUTHO,然後雙擊創建:
進入:
選中activity點擊Maintain Values..
這裏我們選中所有(也就是我們在上面定義的permitted value)
同理爲下面兩個authorityp fields:都使用from * to *
最後激活該value :
同時激活該Profile。
(5)爲user添加Profile
Tcode: SU01 user management
將剛創建的profile添加給該user.
(6)創建role
Tcode: PFCG Role maintanance
創建一個新的role,點擊create role:
建一個新的role,點擊create role:
在Authorization中指定我們剛創建的profile.
而在user中添加需要指定的user.
(7)指定user的role
Tcode: SU01 user management
將剛創建的role賦給該user.
至此,關於authority-check所需要的對象都已創建完畢。
(8)程序中使用Authority check
測試程序:
*&———————————————————————* *& Report ZTEST_AUTHORITY * *& * *&———————————————————————* *& Using Authority Check * *& * *&———————————————————————* REPORT ZTEST_AUTHORITY no standard page heading . * data data: au_fd_1(2) type c value ‘01′, au_fd_2(20) type c value ‘fd2′, au_fd_3(2) type c value ‘02′. write:/ ‘User Name:’, sy-uname. uline /(120). skip 1. * 1st time: Authority-check:: check all authority-fields. AUTHORITY-CHECK OBJECT ‘ZAU_OBJ’ ID ‘ZAUTH_FD_1′ FIELD au_fd_1 ID ‘ZAUTH_FD_2′ FIELD au_fd_2 ID ‘ACTVT’ FIELD au_fd_3. write:/ ‘1st time: Authority-check:: check all authority-fields:’, 100 sy-subrc. * 2nd time: Authority-check: check only part of authority-fields. AUTHORITY-CHECK OBJECT ‘ZAU_OBJ’ ID ‘ACTVT’ FIELD au_fd_3. write:/ ‘2nd time: Authority-check: check only part of authority-fields:’, 100 sy-subrc. * 3rd time: Authority-check:: igor all authority-fields. AUTHORITY-CHECK OBJECT ‘ZAU_OBJ’ ID ‘ZAUTH_FD_1′ dummy ID ‘ZAUTH_FD_2′ dummy ID ‘ACTVT’ dummy. write:/ ‘3rd time: Authority-check:: igor all authority-fields:’, 100 sy-subrc. * 4th time: Authority-check:: if one authority-field check failed. AUTHORITY-CHECK OBJECT ‘ZAU_OBJ’ ID ‘ZAUTH_FD_1′ FIELD au_fd_1 ID ‘ZAUTH_FD_2′ FIELD au_fd_2 ID ‘ACTVT’ FIELD ‘01′. write:/ ‘4th time: Authority-check:: if one authority-field check failed:’, 100 sy-subrc. * 5th time: Authority-check:: if authority-field name is wrong. AUTHORITY-CHECK OBJECT ‘ZAU_OBJ’ ID ‘ZAUTH_FD_X’ FIELD au_fd_1 ID ‘ZAUTH_FD_2′ FIELD au_fd_2 ID ‘ACTVT’ FIELD ‘03′. write:/ ‘5th time: Authority-check:: if authority-field name is wrong:’, 100 sy-subrc. |
這裏因爲我們上面在創建profile時指定的ZAUTH_FD_1與ZAUTH_FD_2的範圍是* 到*。所以任意的值(當然能與domain中定義的type相匹配)都OK的。而ACTVT則不同,我們只允許其02和03.
如果我們以非EDISON_TC3運行:
而以EDISON_TC運行:
3. Authority-check附加
在我的這個實例中,我雖然爲第一個authority check field指定了value(Domain有value table),但是並沒有像使用標準的activity的authority check field那樣指定permitted value(或value range)。
另外,關於user profile以及role的創建等工作,作爲Developer可以查閱相關資料更深入的學習