sap basis training - auth

IBM Global Technology Services

携手合作，成就客户 Integrating for Client Succes

s

SAP BASIS TRAININGUser and Authorization

10/10/2006IBM ChinaGuoLei, AMS, [email protected]


© Copyright IBM Corporation 2006

目录

权限概念权限设置



目标

掌握 R3 系统权限的概念掌握系统中权限的设置



目录

权限概念权限设置



权限的概念

SAP AG 1999

Users in the R/3 Environment

Database Server

Da

tab

as

eS

erv

er Operating System

Operating System

Operating System

Ap

pli

ca

tio

nS

erv

er

Pre

se

nt.

Se

rve

r

R/3 User

OS User

DB User

OS User

OS User

Admin. User

Dispatcher

...VD B



权限的概念



SPEX SAP R/3 Project Version 1.0 Authorization Concept

授权就是给个人（或组）一个方式或权力来行使一些特殊的职责

用 SAP 的语言来说… .

它它允许允许或或禁止禁止用户在系统中进行操作用户在系统中进行操作和处理事务和处理事务

权限的概念




SAP SAP 授权概念授权概念SAP SAP 授权概念授权概念

在缺省状态下，所有用户最初是没有执行任何事务的权限的

通过各种授权赋予执行事务的权限一个用户可以执行的事务数量反映出其授权

的大小

权限的概念



SAP AG 1999

User master record User master record

Authorizations assigned?

Objects needing protection

Vendor

Company code Plant

Material

Action

Transaction permitted?

Authorization Concept 1

Profile

Authorizationfor Task A

Authorizationfor Task B

Profile

Action

权限的概念



S A P A G 1 9 9 9

A u th o r iz a t io n C o n c e p t 2

D a ta B a n kD a ta B a n k

U s e r M a s te r R e c o r d P r o f i le (s ) A u t h o r iz a t io n (s ) F ie ld V a lu e s

权限的概念



SAP AG 1999

Authorization Check

SAP GUI

OK?

AuthorityCheck

No

Processing

UserContext

MessageYes

Dynpro

权限的概念




事务基于“角色”进行分组角色是指在业务中事先定义的执行特殊职能的工作

例如，在下面的事务中有两个角色：

存货会计角色存货会计角色

事务 : SM35SM35SE38SE38FF_5FF_5FEBPFEBPF-04F-04

物料管理经理角色物料管理经理角色

事务 : XK05XK05XK04XK04MB53MB53MB24MB24

权限的概念－角色




Mary JonesMary Jones角色 : 会计师会计师

经理经理

John DoeJohn Doe角色 : 会计师会计师

仓库检验员仓库检验员

WO WO 创建者创建者

用户用户 IDs IDs 基于基于业务要求业务要求而被分配给各适合的而被分配给各适合的角色角色

例如 :TCODE1TCODE2TCODE3

TCODE1TCODE2TCODE3

TCODE4TCODE5

TCODE4TCODE5

TCODE6TCODE7TCODE8TCODE9

TCODE6TCODE7TCODE8TCODE9

TCODE1TCODE2TCODE3

TCODE1TCODE2TCODE3

TCODE10TCODE11TCODE12TCODE13TCODE14TCODE15

TCODE10TCODE11TCODE12TCODE13TCODE14TCODE15

用户可以运行他们所属角色中的各种事务代码用户可以运行他们所属角色中的各种事务代码

权限的概念－用户




事务代码怎样分配给角色角色 ?事务代码怎样分配给角色角色 ?

通过分配来实现…

授权对象授权对象授权对象授权对象

权限的概念



SPEX SAP R/3 Project Version 1.0 Authorization Concept 权限的概念－授权对象




授权对象授权对象 == 运行事务的运行事务的权限权限授权对象授权对象 == 运行事务的运行事务的权限权限

没有没有

授权授权

对象对象

没有没有

事务事务

权限权限==

权限的概念－授权对象




进入一个 SAP SAP 事务代码事务代码就好象… .

从一扇门门进入一个房间

授权对象授权对象就是开门的钥匙钥匙授权对象授权对象





即使只缺少一个对象只缺少一个对象，用户都不能够不能够运行事务代码

运行事务代码需要先具备所有的所有的授权对象 ! ( 即整套钥匙 )

授权对象授权对象 11



授权对象授权对象 44授权对象授权对象 55




SAP AG 1999

FinancialAccounting

Authorization

display, change

Customer company code:Authorization A

Customer company code:Authorization B

0001-0009

*

display

Object: Customercompany code

Company Code

Activity

Authorization objectObjectclass

Authorization Objects




例如 : 事务 MIRO MIRO – 发票凭证例如 : 事务 MIRO MIRO – 发票凭证

用户必须具有下列对象才能够运行事务代码… .

这些对象是进入并运行事务代码必需的钥匙钥匙




SPEX SAP R/3 Project Version 1.0 Authorization Concept 权限的概念－对象参数




“ 参数” = 特征“ 参数” = 特征例如 :会计帐目会计帐目 : : 帐目类型的授权有帐目类型的授权有两个两个参数

12

权限的概念－对象参数




有两种类型的参数 :

- 组织数值，例如公司代码帐目类型销售组织

- 约束值，例如行为授权组合购买凭证类型





在这个例子中，有两个对象参数…

对象参数决定了用户在事务代码中操作的特殊 Object parameters determine the specific permissionsspecific permissions a user can perform in a transaction. … 问题 :

This user can perform WWHATHAT ACTIVITIESACTIVITIES to WHICWHIC

H ACCOUNT TYPESH ACCOUNT TYPES?





功能组功能组负责负责补充补充各个角色中授权对象丢失的参数丢失的参数 !!!

重要提示 !!!重要提示 !!!




参数参数参数

授权对象

授权对象

授权对象

授权对象

事务代码事务代码

事务代码事务代码

事务代码事务代码授权对象

角色角色

角色角色角色角色角色角色角色角色

授权级别图表授权级别图表

用户用户是由几个是由几个角色角色组成的组成的角色角色是一系列是一系列事务代码事务代码事务代码事务代码需要一些需要一些授权对象授权对象来运行来运行授权对象授权对象由它的由它的参数参数来定义来定义

用户用户是由几个是由几个角色角色组成的组成的角色角色是一系列是一系列事务代码事务代码事务代码事务代码需要一些需要一些授权对象授权对象来运行来运行授权对象授权对象由它的由它的参数参数来定义来定义

用户用户



目录

权限概念

权限设置



目錄

1. 總述 2. 職能 /Template Role/ 設定的分工 3. 三種不同的常規權限的設定方法 4. 常規以外的權限設定方式 5. 如何快速檢查權限設定的情況



總述

1. 在開始學習之前 2.SAP 權限的架構



在開始學習之前

在開始了解權限前 , 有几點是要大家注意的 1. 權限設定非常重要﹐而且權限的 DEBUG 操作非常繁瑣 , 耗時 , 所以請

大家設定時一定要非常謹慎 , 每次更改都要記錄。 2. 權限設定除非特殊情況﹐不允許在正式環境直接更改﹐請在測試環境修

改好再傳到正式環境。 3.I.T. 不是決定 user 權限的人﹐而是 user 大大小小的 leader﹐所以﹐要

變更權限設定﹐務必要求 user 提供經過簽核的申請表。（當然﹐對 user不合理的權限要求﹐ I.T. 也有責任退回）



SAP 權限的架構

Role template -Description -Menu -Authorizations ……………

Role template -Description -Menu -Authorizations ……………

Authorization profile -Object class -Authorization object -Authorizations ………………..

Authorization profile -Object class -Authorization object -Authorizations ………………..

Assign toAssign toB

ind with

Bind w

ith

Assign to

Assign to

SAP User account -Address -Logon data -Group . . . . . . . . . . . .

SAP User account -Address -Logon data -Group . . . . . . . . . . . .

這是 SAP 權限的架構圖﹐大家也接觸

過。請大家一定要記住

他們的關系。



SAP 權限的架構

名詞解釋（英譯中﹖）﹕ User account﹕就是我們平常說的“帳號”﹐也稱為“ USER ID” 。 Role﹕同類的 USER 使用 SAP 的目的和常用的功能都是類似的﹐例如業

務一定需要用到開 S/O 的權限。當我們把某類 USER 需要的權限都歸到一個集合中﹐這個集合就是“職能” (Role) 。

所謂的“角色”或者“職能”﹐是 sap4.0 才開始有的概念﹐其實就是對user 的需求進行歸類﹐使權限的設定更方便。 ( 面向對象的權限 !!)

分為 single role 和 composite role 兩種﹐后者其實是前者的集合。



SAP 權限的架構

Profile: 真正記錄權限的設定的文件﹐從 sap4.0 開始是與 Role 綁定在一起的。雖然在 sap4.6c 還可以單獨存在﹐但按 sap 的行為推測﹐以后將不能“一個人活着”

Template Role:Role 的模板﹐一般是 single role. 但這個模板具有一個強大的功能﹐能通過更改模板而更改所有應用 (sap 稱為 Derive“ 繼承”）此模板的 Role(sap 稱之為 adjust)



SAP 權限的架構

例外權限﹕這是公司創造的名詞。當一個 USER 除了其職位一般所需的權限外﹐還需要一些特殊的權限﹐我們把這些權限稱之為這個 USER 的例外權限。

例如開工單對生管來說是其職能應有的權限﹐但對倉庫來所就是例外權限。



Role 的命名和分類 Role 的命名規則和分類如下 : 以“ G+” 開頭都是 Template Role( 模板 )﹐都不會直接 assign給 user id 。

- G+ 職能名稱 ﹕全球共同 Template Role- G+ 職能名稱 -1 ﹕ 地區 Template Role

以“ Z+” 開頭都是 User Role, 直接 assign給 user id 。- Z+User ID+ 職能名稱 : 繼承全球共同 Template Role- Z+User ID+ 職能名稱 -1: 繼承地區 Template Role- Z+User ID+Exception : 沒有繼承任何 Role, 例外權限

以“ Y+” 開頭都是 Basis Role, 直接 assign給 user id 。- Y+ 職能名稱 : 全球共同 Basis Role



Role 的命名和分類

附件是一張職能 /Rolename 對照表我們以其中一個職能“ AR 作業人員”做解釋﹕

Microsoft Excel 工作表

A/R 作業人員CO-AR

G+CO-AR

G+CO-AR-1

Y+CO-AR

職能中文名稱職能英文名稱全球共同 Template Role

地區 Template Role全球共同 Basis Role




全球共同 Template Role﹕是指此職能在全球任何一個地區都一致的那部分權限的模板。- 命名特征是以 “ G +” 開頭﹐非“ -1” 結尾。- 例如 “ G + CO – CO ”

地區 Template Role﹕是指此職能根據不同地區而不同的那部分權限的模板。- 命名特征是 “ G+” 開頭 “﹐ -1” 結尾。- 例如 “ G + CO – CO – 1 ”




User Role﹕是指根據每個 user 的具體需求進行設定的權限的 Role.- 命名特征是﹕

“Z+”USER ID 開頭（東莞﹑台灣地區） “W+” USER ID 開頭（吳江地區）

- 例如“ Z+PSC1-ACT01+CO-CO”

全球共同 Basis Role﹕是指此職能關系到整個系統的安全的那部分權限的 Role.

- 命名特征是 “ Y+” 開頭- 例如 “ Y + CO – CO ”



權限設定者分工

一 .以 Role 類型分 1.Template Role 即“ G” 開頭的 2.User Role: 以 Z 開頭的 3.Basis Role: 即以 Y 開頭的




二 .以 USER ID 分從 USER ID 可以區分出這個 ID 所屬的廠別和模組。例如﹕ PSC1-ENG01 這是 PSC1廠的帳號﹐屬于 PP 模組﹐所以這個帳

號申請的權限將由東莞 PP 模組的 I.T.主要負責和監督。




三 . 以所申請的權限歸屬的模組分由于 user 所申請的權限通常涉及多個模組﹐這就需要多個模組的 MIS 共

同合作設定 user 的權限﹐這時先按第二條執行 ,由 ID 所屬模組 I.T. 接受申請﹐并從始至終跟進。然后具體的權限屬于哪個模組就由那個模組的 I.T. 作設定。

但無論如何﹐作為跟進的 I.T. 都是負主要責任的。



權限設定的操作

上面說過﹐權限的大架構由 User ID, Role, Profile 三層組成﹐那么﹐權限的設定自然也會有三層。但由于 sap4.6是 Profile與 Role 是捆綁在一起的﹐所以在建立 Role 的時候﹐ Profile 是會自動創建的（具體見后文）。而 User ID 的建立比較簡單。所以﹐我將主要說明 Role 的部分。



USER ID 的建立

T CODE SU01 ﹕

單擊建立圖標2

輸入要創建的 User ID1



USER ID 的建立

填好這些欄位



USER ID 的建立

設定組別﹐這對 MIS 非常重要﹐ MIS 能否管理此

User ID 就看這里

設定初始密碼

有效期一般不設定



USER ID 的建立

按圖設定（印表機按實際設定）



USER ID 的建立

接著按 save﹐就把USER ID 創建好了

USER ID 創建好了﹐但這時這個 ID 沒有賦予 (Assign) 任何權限﹐是什么都不能做的。 USER 得到這樣的帳號沒有任何意義。

如何 Assign 權限給一個帳號﹖主要就是Assign 一個 Role 給這個帳號了。下面我們看看如何建 Role 和給權限。



Role 的建立

新創建 Role主要有三種方式。 T CODE PFCG﹕ 1.由始至終新建 ;

可以對應所有新建 Role 。主要對應例外權限 Z+USERID+EXCEPTION

2. 繼承 ;主要對應設定 Z+USERID+ 職能名稱

3.復制（ COPY）﹔主要對應設定 Z+USERID+ 職能名稱 -1



Role 的建立—完全新建

我們假設有一個帳號 “ FORTEST”, 他申請了例外權限 VA01和 YF30 。下面我將會一步一步向大家說明操作的步驟和應該注意的地方。看到 PFCG 的畫面了嗎﹖




輸入 Role name

注意選第二項




描述一般與 Role name 一致

記錄此 Role 的創建者記錄此 Role 的最后修改者

把描述填好后﹐按 save 然后點擊 menu 頁簽




建立新目錄修改 TEXT項目下移項目上移刪除項目

手動增加 T code從 SAPMenu 中增加 T code從其他 Role 中 Copy Menu

這些是常用的功能

Menu 頁簽定義的是 USER MENU （個人化菜單）的內容。




請大家按圖所示建立目錄 ﹐第一層是職能﹐這里是EXCEPTION﹐下面分“標准” (Standark) 和 “外挂” (Add On) 兩個目錄。讓菜單保持清晰﹐可以令 User 的個人菜單清楚﹐不混亂。我們 MIS 檢查權限也比較方便。




大家可以對比下面兩個USER 的個人化菜單﹐左邊職能清晰﹐右邊非常混亂﹐同名的目錄大量出現﹐但里面的內容又不盡相同﹐這對依賴路徑執行指令的 user 是很麻煩的。




菜單的殼子有了﹐如何往里面添加內容呢﹖ 比較常見的是﹕從 SAP菜單添加和直接添加 T CODE 。從 SAP菜單添加﹕ 所有標准的 T CODE 和沒有 T CODE 的標準程式都可以用這種方法添加。

好處是可以尋找﹐可以一次添加標准菜單的一個目錄﹐ T code 在標准菜單中的位置也可以顯示出來。缺點是很浪費時間﹐而且外挂的程式無法添加。




直接添加﹕ 所有 T CODE(包括外挂）和沒有 T CODE 的標準程式都可以用這種方法添加。好處是比較快

缺點是必須知道 T code﹐不能帶出路徑。




從 SAP 菜單添加




OBJECT 完全沒有給值OBJECT 只有部分給值OBJECT 已經全部有值

請注意﹕綠燈只是表示全部有值而已﹐但不一定就是我們所需要的值

這時﹐標准 T code 所需要的 Object﹐系統會自動帶出來。




這個 Object 是任何權限設定文件中都應該有的﹐這是給予啟動 T code 的權限﹐如果 T code 沒有出現在這個列表中﹐ user連這個指令的畫面都無法進入




在這里﹐需要向大家介紹一個很重要的概念﹕ Org.level.在權限設定中﹐有許多地方的控制點是一致的﹐ sap 公司為了方便權限的設定﹐把這些地方設計為與全局變數關聯。當改變全局變數時﹐這些地方就可以全部改變過來。

這個全局的變數就是﹕ Org.level




當Org.Level給值后﹐相應的Object

value 的值也變了



Role 的建立—完全新建對 Org.Level 都給值之后﹐會發現相當一部分的 Object value 都已

經給值了﹐但還有一些 Object 是紅燈或者是黃燈﹐這些 Object 是要單獨給值的。




按一下標志﹐就可以輸入值﹐按保存

在這里介紹一下的作用﹐點擊它﹐就相當於給這個 Object 一個 “ *”(star) “*”﹐ 的意義是 All Authorization﹐不卡任何權限。 Object給值后﹐就變成綠色 ﹐不能點擊了。



Role 的建立—完全新建如果是外挂的 T code﹐就只能用“直接添加”的方式加入到菜單中﹐需

要注意的是﹐外挂的 T code的 Object 不會自動帶出來﹐需要自己手工添加。

按 ﹐點擊 Y-AUTH-PRT 前的



Role 的建立—完全新建變為后﹐按屏幕上方的 ﹐插入 Object. 注意﹕外挂的

T code﹐除了前面所說的列表中要有外﹐這里框住的地方要給 T code﹐否則 user 還是不會有權限




都給好值后﹐按保存﹐按“勾”。

然后按激活。退出。




Authorization已經變成綠燈﹐這表示權限的設定已經可用了。

點擊 USER,Assign USER ID 給這個 Role




點擊 USER COMPARE ﹐

再點擊 Complete compare﹐

就完成了 COMPARE 。至此﹐此權限已經 Assign完畢﹐ FORTEST 這個帳號已經具有 VA01 和

YF30 的權限



Role 的建立—繼承

所謂“繼承” , 是指兩個 Role形成這樣的母子關系﹕子 Role 的所有Menu, Authorization（ Org.level 除外 ) 都源于母 Role,并與母 Role保持一致。

母 Role 與子 Role 是 1 對多的。



Role 的建立—繼承下面﹐我們來學習用“繼承”方式建立 Role. 我們假設有一個帳號 “ FORTEST”, 他申請了職能 “ AP立帳員” “﹐ AP立帳員”的 Template Role 是 “ G+CO-AP” 。

我們先來按命名規則 Create 一個新 Role 。




大家注意這個地方﹐建立“繼承”關系就是靠這里了




填入 Template Role,按 Enter.

是否建立繼承關系﹖

回答當然是“ YES” 了﹐否則我們怎樣上課﹖

如果在此前沒有做過存檔﹐系統會詢問是否存檔﹐回答同樣是“ YES”




可以看到﹐菜單已經自動根據 Template Role 生成了 , 點擊

Authorization 頁簽﹐設定權限去。




進入 Profile里面了﹐請注意下面所說的操作﹐如果做錯了﹐可能要拉倒從新開始的喲。

點擊這個按鈕

1. 系統會自動進入Org.level﹐請點擊“ X”, 退出 Org.level 。2. 按“ SAVE” 對 Profile 存檔。




3. 執行菜單Edit 中的 Copy data, 系統會提示這個操作不可反轉。按“勾”繼續 , 執行完畢后我們會看到﹐許多 Object 已經變成綠燈了。




現在可以維護 Org.level 的設定了。進入的方法如上。當 Org.level 每一個欄位都賦值之后﹐應該每一個 Object 都是綠燈﹐如果

還有紅黃燈﹐請通知 I.T. 修正。




當所有權限（其實只是設定 Org.level) 都設定完畢后﹐按激活設定﹐ Assign給 USER ID, 就完成了。




大家是否覺得“繼承”的方法好簡單﹐几下就做完了。其實這種方法思路最復雜了﹐后面的處理還隱藏不少陷阱。

不過現在大家先掌握 Role 的建立方法﹐其它的問題等一下再說。那么﹐我們來看看第三種方法—復制。



Role 的建立—復制

復制其實是一種從思想到操作都很簡單的操作。它的核心就是—……復制 ! 我們來看看如何操作吧。先告訴大家 “﹕ AP立帳員”的 Template Role 還有一個﹐是 “ G+CO-

AP-1”﹐我們就用它來學習。




一開始當然是進入 PFCG 了﹐先把 Template Role 名輸進去﹐然后按 COPY 按鈕




把描述改成與 Role 名一樣

要注意“ -1” 的 Role 的 menu 是空的

這里是空的




紅色框住的都是要填入值的地方﹐最好先填完

Org.level




與其它方式建立的 Role 一樣 , 當所有權限都設定完畢后﹐按激活設定﹐ Assign給 USER ID﹐一個 Role 就設定完成了



Role 的建立—繼承與復制

小結﹕ 非“ -1” 的那種 Template Role ﹐用繼承的方式建立新 Role, 繼承后﹐只需

要填入 Org.level Object﹐ 就全部是綠燈了﹐ 而“ -1” 的那種是用復制的方式﹐還需要在 Object里填入值﹐才能全部綠燈。

這是兩者操作上的最大特點。



Role 的修改

1.Merge 2.新增 /刪除 T Code 3.從其它 Role導入 4.Adjust



Role 的修改

對 Role 的修改最常見的是有 T Code 的新增 /刪除。這種改動﹐一般是從Menu 開始﹐當Menu 改變任何改變﹐系統都會偵測到﹐ Authorization和User 會變成紅燈。

在 Authorization頁簽里有兩個按鈕﹐他們有什么不同呢﹖



Role 的修改我們先點擊 ﹐會出現一個小窗口﹐里面是三個選項﹐他們的意義是

不同的。

第一項﹕刪除此 Role的 Profile 后重建第二項﹕編輯原有的 Profile 第三項﹕讀取原有 Profile并根據 Menu 的變化對 Profile 進行更改



Role 的修改第一項會把 Profile 整個重建﹐并且會把已經被屏蔽掉或刪除的 Object 重新顯示出來﹐極容易造成權限設定錯誤﹐反對使用。

第二項完全保留之前可用的 Profile﹐即使新的權限沒設好﹐還有原有的權限可用。推荐使用。缺點是 Object 的變更需要手動進行。

第三項重新讀取 Role的Menu﹐按菜單的變化變更 Object﹐具有一定的智能﹐但會把已經 Merge的 Item彈開﹐造成設定者的混亂。不反對使用。



Role 的修改

這個按鈕相當與前面所說的第三項。由于已經包含這個選擇﹐而且第三項不是最優選擇﹐所以

我們一般不建議使用它。

總的來說﹐我們認為選的第二項比較穩當﹐保留原有的可用設定。可以看到變化前的 Profile 。詳細細節請繼續看后面的章節。



Role 的修改— Merge

當 Role 所包含的 T Code 經過多次修改后﹐可能產生多個同樣的Object﹐其 Value 可能互相包含。

這時可以通過 Merge （合并）的動作使同一個 Object內 Value相同或者互相包含的 Item 合并起來﹐使權限的條目更清晰




紅框框住的兩個 Object, 是同樣的 Object, 而且其 Value又是第一個包含第二個。




上頁紅框里的兩項被合并了。

選擇菜單 Utilities 里的 Merge



Role 的修改— Merge 的規則

我們來看一個簡單的 Object﹐它只有兩項﹕ Activity 和下面的 Group 。我稱 Acitivity 為“動作”﹐它下面的 Group等項目為“參數”。 Merge 的規則﹕當兩個相同 Object的 Item 的動作或參數完全一致時﹐這

兩個 Item 可以 Merge 。




當一個 Role 經過 Merge后﹐這個 Role的 Object 會比較精簡。但當Menu發生改變后﹐系統會提示菜單已經變化﹐ Authorization和 User 會從綠燈變成紅燈。

現在我來舉一個例子﹐假設新增一個 T Code : FSS0 。




這時﹐如果我們選擇的第二項﹐進入 Profile﹐會發現所有的 Object都和菜單沒有變化前一樣。

到底 FSS0對 Object 的影響有哪一些﹐需要自己的經驗。這里我就不詳細介紹。 ( 如果一點都不知道﹐可以做一個測試用的 Role﹐只含有這一個 T Code﹐看看系統自動為它帶出的 Object 即可 )




如果選擇的第三項﹐進入 Profile﹐我們會發現﹐不少 Object 變成了黃燈。

但如果有經驗的話﹐仔細看看﹐會發現有好几個 Object 其實都是以前Merge過﹐現在給彈開或者刪除過﹐再次帶出 .




對于熟悉的人來說﹐這些多余的 Item 可以刪除就可以了﹐但也要費時間確認。對于不熟悉的人來說﹐就可能無法區分那些 Object 是新增 T Code所需要的﹐哪些是因為不能開放而刪除的。耗費的時間可能更多。

所以﹐我們不推荐這種做法。



Role 的修改—新增和刪除 T Code

新增和刪除 T Code 其實在前面都有提到。在Menu頁簽的操作這里就不再重復了﹐細節請參照《 Role 的新建—完

全新建》在 Authorization頁簽的操作請參考《 Role 的修改》這里只重點提醒一件事。




在每一個有 Menu的 Role里﹐必定有一個叫 S_TCODE的 Object﹐這個Object里記錄的是這個 Role 所有可以執行的 T Code 。當 Menu 變化﹐這里也要相應變化。

但這個 Object永遠是綠燈﹐所以大家一定要記得檢查這里。




經過測試﹕ 在Menu新增 T Code后﹐在進入 Profile 時選擇第二項時﹐系統不會在此

Object自動增加 T Code﹔選擇第三項﹐系統會自動增加 T Code 。在Menu刪除 T Code后﹐無論選擇第二項還是第三項﹐系統都不會自動刪除 T Code 。必須手工刪除﹗﹗

這一點請大家務必注意。



Role 的修改—從其它 Role 導入

當我們要處理的 Role A 與某個 Role B 的設定十分相似﹐可以通過 Insert功能把 Role B的 Object 設定導入到 Role A 中。

請留意﹐實際上是導入Profile 哦﹐所以一般還要去看 Role B 的 Profile Name﹐不是很方便。



Role 的修改—從其它 Role 導入

需要注意的是﹕這樣導入進去的 Object 的設定都跟 Role B 的一樣﹐一定要把其中對 Role A 不適用的部分更正過來。

對 Role B 不熟悉不要亂用這功能哦。

還是那句老話﹕欲速不達﹐不熟的事﹐沒有把握的事一定要謹慎。



Role 的修改— Adjust

Adjust 是專門針對存在繼承關系的母子 Role 的一項功能。在《 Role 的建立》一章﹐我們學習到﹐從子 Role 可以通過 Copy Data從母 Role得到 Object Value 。

現在﹐我們看看從母 Role 傳送 Object Value 到子 Role 的功能 Adjust 。




用 Display 模式進入 Template Role的 Profile﹐選擇菜單上的 Generate derived roles 即可。從操作來看﹐十分簡單。

注﹕不要用 Change 進入 Template Role﹐否則 Adjust 會造成 Template Role本身最后修改日期和最后修改人發生改變﹐對查對權限產生誤會




簡單比較 Copy Data 和 Adjust

從子 Role發出

Copy Data

僅影響執行此功能的子Role﹐其它繼承同一母Role 的子 Role 不受影響

同一 Client 下所有繼承此母 Role 的子 Role均受影

響

從母 Role發出

Adjust



Role 的傳輸

1.產生 Request Num 2.Release 3.Transport



Role 的傳輸—產生 Request Num

在 PFCG 的開始畫面﹐可以看到。由于單個 Role 的傳送比大批量的傳送從操作上來說要簡單而且類似﹐所

以我們重點說大批量傳送的操作。

大批量的傳輸

單個 Role 的傳輸




選擇 Single Role

選擇要傳輸的 Role




確定要傳輸




如果這個 Role 第一次傳輸這里一定要打勾﹐否則傳輸到其它 client 后會沒有

Assign 到 User ID 。但如果不是第一次傳輸請不要打勾﹐因為只要打了勾就要到目標的 Client端去做一次 Compare 的動

作﹐權限才能激活沒有起用




如果要新建一個 Request﹐按

如果現在已經有一個還沒有 Release的可用的 Request Num﹐請在這里輸

入﹐然后打勾




簡要說明傳輸的內容或目的




Request Num產生 , C00K 開頭的都是大陸地區產生的﹐ T00K 開頭的都是台灣地區產生的 .




單個 Role 的傳輸 Request Num產生的過程與打批量的相似﹐只是開始不一樣而已。

單個傳輸直接 Key Role 名字﹐按按鈕﹐其它操作就一樣了



Role 的傳輸— Release

Release 的 T Code SE10﹕

輸入 Request Num的產生者﹐選擇查

看 Modifiable




可以看到﹐其實是有兩個 Request Num

的 , 一個記錄Header﹐一個記錄

Item




先 Release Item的 Num （在下面﹐作為子項的那一個）﹐再 Header的Num

方法是﹕點擊 Item的 Num﹐然后按按鈕﹐會進入另一個畫面﹐按 ﹐會回到原來的畫面﹐然后再 Release Header的 Num 。同樣是點擊Header的 Num﹐然后按 ﹐進入另一畫面后﹐不用存盤﹐按即可



Role 的傳輸—傳送

這一部分是 Basis 的工作。本來是在 Unix 下進行﹐但我們開發了兩支外挂程式。從測試環境到正式環境是 YATP 從測試環境到 QAS是 YATPQA 進行傳送的 Request Num 必須是已經 Release的 Number



Role 的傳輸—傳送

兩者的畫面很象﹐填入 Request Num﹐選擇好目標 Server﹐按就可以了



Role 的傳輸—刪除

如果發現 Role搭錯了一個 Request Num﹐在沒有 Release 前可以補救。同樣是在 SE10, 點擊 Num 后使用就可以了。



Role 的傳輸—刪除

如果已經 Release 就沒有辦法刪除了﹐只能整個 Number 作廢﹐所謂“作廢”其實是不做最后的傳送動作﹐讓這個 Number閑置而已。



Role 的刪除

在 PFCG 中填好 Role 的名字﹐按按鈕﹐確認﹐即可把 Role及其專屬 Profile刪除。



Role 的刪除

請注意﹕如果需要利用傳輸功能在多個環境中刪除 Role﹐一定要按以下順序進行﹕

1.對 Role產生傳輸的 Request Num﹔ 2.刪除本環境的 Role﹔ 3.Release;( 此時本環境中已經沒有這個 Role 了） 4. 傳輸



帳號刪除

帳號（ User ID ）的刪除操作也十分簡單﹐在 SU01中﹐輸入帳號名稱﹐按就可以了



帳號刪除刪除一個帳號后﹐為其專設的 Role （即 Z或W 開頭的）也要刪除（包括

測試和正式環境）﹐減少系統無用的資料﹐也減少不必要的查對。或許有人會認為﹕保留這些 Role﹐雖然占用一點硬盤﹐但如果以后這個

帳號再次起用﹐不就可以不用重設權限嗎﹖ 這個理由咋看起來很有道理。實際上 USER 一旦決定刪除某個帳號﹐在相

當長的時間內都不會再起用（一個帳號的費用不菲﹐決定不會輕易下的）﹐在經過長時間后即使需要再次起用﹐其權限需求也要重新審視﹐與其把其新需求與舊有設定一項一項對比修改﹐還不如重新設定來得方便快捷﹐而且更安全。



Debug/ 查看

有一些工具對權限的問題處理很有幫助 1.SU53 2.SUIM 雖然還有一些其它工具﹐但一般很少用或者不實用﹐這里就不介紹了。



Debug/ 查看— SU53

當一個帳號反映沒有某個應有的權限時﹐我們可以在系統出現沒有權限的信息時﹐馬上輸入“ /NSU53”




上頁紅色框住的就是沒有權限的地方﹐ 而藍色框住的是跟這個帳號已經有的權限。

但是請注意﹕ SU53給出的信息并不詳細﹐大部分情況只能作為一個大方向的參考﹐有時還可能指示不出來問題所在。

但無論如何﹐有一個參考總比沒有好。



Debug/ 查看— SUIM

SUIM 其實就是 Information 系統的一個集合界面。我們最常用的功能是﹕ 已知某個 T Code﹐查找含有這個 T Code的 Role 。




輸入 T Code 后執行﹐就可以得到含有這個 T code的 Role 的列表。請注意﹕其判斷條件是 Role的Menu﹐而不是 Profile



特殊的權限設定 SD 的權限在 SD 模組﹐有一個解 S/O Billing Block 權限的設定﹐它是在 YS08 中設

定



其它知識

1.Object 的狀態 Standard/Manually/Maintained/Changed 2.Object Value VS Org.level



其它知識— Object 的狀態




當我們用第三項進入一個 Profile 的時候﹐我們可以看到每個 Object 的描述前有都有兩個狀態。現在我來給大家解釋一下他們的含義。

右邊的狀態共有兩種﹕ NEW 和 OLD NEW﹕此 Object 有新的 Item或 Value, Profile Save 后會變成 OLD OLD ﹕ 此 Object的 Item 是以前建立的




左邊的狀態有好几種﹕ Standard﹕由系統帶出后沒有經過任何更改 Maintained﹕對系統初次帶出時 Value 為空的 Item 進行過變更或補充 Changed﹕對系統初次帶出時 Value 為非空的 Item 進行過變更



其它知識— Object Value VS Org.level

大家可能對 Object Value與 Org.level 的關系有一些疑問﹐對 Adjust 時子 Role到底那些地方會被母 Role控制變更有點把握不住。

那么下面介紹的東東對大家可能有點幫助 1.Adjust 大原則﹕

Org.level﹕子 Role 有值時﹐ Adjust 時以子 Role 為准﹐子 Role無值時﹐ Adjust 以母 Role 為准

Object.Value﹕一律強制以母 Role 為准




2.Value與 Org.level我們可以發現﹐在 Object里有些 Item的 Value 是與 Org.level相關聯的﹐其值在

沒有手工更改前都是以“ $” 開頭﹐這類值都是變量﹐指向對應的 Org.level 。當 Org.level給值后﹐ Object 就通過這些變量把 Org.level 的值顯示出來﹐但實際上 Object 的值仍然是原來以“ $” 開頭的那個值。




在子 Role中﹐如果這些 Object Value被手工更改﹐在母 Role 沒有做Adjust 之前﹐子 Role的 Object Value 是可以與 Org.level 不一致的﹐實際權限以 Object Value 為准。但一旦母 Role 做了 Adjust﹐子 Role的Object Value 就強制與母 Role 一致。而母 Role 一般對這類 Object Value的處理是保持其變量狀態﹐那么子 Role的 Value 就變會變量狀態（ $XXXX)﹐然后根據子 Role Org.level 的值顯示出新的值。




3. 如果不小心變更了與 Org相連的 Value﹐但又想恢復其變量狀態﹐怎么操作﹖首先﹐簡單地把 Value清空是不行的﹐這樣的操作只是把當前值變為 NULL(空 )﹐第二﹐把其原有的 $ 開頭的值 Key 進去也是不行的﹐主要原因是輸入欄位的長度不夠。

正確操作是﹕把這個 Object 整個刪除﹐然后手工添加這個 Object 。



Q&A

sap basis training - auth

Documents