以下是以前关于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可以查阅相关资料更深入的学习