webmehtods 使用JCO和sapidoc3配置SAP Adapter.关于JCO用户应该使用什么权限的账号使人头痛,找了好久,最后发现在SAP Note 460089里有详细的介绍。摘抄如下:
Symptom
In the RFC communication between an external program and an SAP system, you want to use a user who only has authorizations in the SAP system that are absolutely necessary. Depending on the technology that your program uses for communication, the release of the attached R/3 or SAP system and the type of the calls that you want to execute, the SAP user set in the external program requires different authorizations.
For the sake of clarity, these authorizations are summarized in this note.
Other Terms
RFC, RFC SDK, NW RFC SDK, JCo, SAP Java Connector, .NET Connector, Business Connector, authorization, authorization objects
Reason and Prerequisites
External programs can essentially use the following technologies for RFC communication:
- 1. RFC SDK (C/C++)
- 2. NW RFC SDK (C/C++)
- 3. Java Connector (Java)
- 4. .NET Connector (C#)
- 5. Business Connector (XML,HTTP,FTP or SMTP interface )
Most of these components provide a repository service, which dynamically reads the interface definition of a remote-enabled function module (abbreviated as RFM) from the ABAP Data Dictionary. This service in turn calls several function modules in the ABAP application server internally. For this reason it requires specific authorizations in function groups.
Solution
Firstly some general comments:
- You can use the auth/rfc_authority_check=0 profile parameter to deactivate the authorization check in the RFC. This is set by default in all R/3 releases up to and including Release 3.1l. To protect the system against unauthorized RFC accesses, you should check that this parameter is set to at least 1.
- In Releases 3.1I to 4.6D there were some bugs at the beginning in the RFC authorization check. Ensure that your R/3 kernel has at least the patch level referred to in Note 93254.
- Some application function modules and BAPIs perform an internal check again for a “business” authorization object. In this case the user, who wants to execute the RFC call, must also have authorization for this “application authorization object” as well as the “technical” authorizations described in the following section.
- If the module that you called wants to execute a transaction code, the user also requires the S_TCODE authorization object (with the relevant transaction codes). If you start a report within the module, the user also requires the S_PROGRAM authorization object (with the relevant program groups).
- In general it is sufficient if the user is of the “CPIC” type (R/3 Release 3.1I to 4.6B) or “communication” (as of R/3 Release 4.6C). The user must only be of the “dialog” type if you want to debug function module calls from the external program in the ABAP debugger. For the additional authorizations required to carry out the debugging, please see Notes 905364, 668256 and 668252.
Some standard scenarios are described in the following section. For the scenarios in which a dynamic repository is used, the assumption is made that two different types of users are used: A dedicated user, who is responsible for repository accesses, and the application users, who execute the actual RFMs of the application. This is advisable for security reasons. If you only want to use one user in the external program, simply assign the user the union of both authorizations.
The authorization profile of the user must contain the S_RFC authorization object, whereby the fields are filled as follows:
ACTVT: 16
RFC_TYPE: FUGR
RFC_NAME: The list of the function groups executed below.
In the following list X is the name of the function group for which you want to call function modules.
1. Call a function module directly
(for example, via the RFC library or via NW RFC SDK/JCo/NCo with static repository)
Application user:
R/3 release | Function groups |
---|---|
3.1I | SYST, X |
as of 4.0A | SYST, SYSU, X |
2. Call a function module directly using tRFC or qRFC
(for example, via the RFC library or via NW RFC SDK/JCo/NCo with static repository)
Application user:
R/3 release | Function groups |
---|---|
3.1I | SYST, ARFC, ERFC, X |
as of 4.0A | SYST, SYSU, ARFC, ERFC, X |
3. Call a function module using the dynamic repositories
(For example, using NW RFC SDK, JCo, .NET Connector or Business Connector)
Application user:
R/3 release | Function groups |
---|---|
3.1I | SYST, X |
as of 4.0A | SYST, SYSU, X |
Repository user:
R/3 release | Function groups |
---|---|
3.1I | SYST, RFC1, SUNI |
4.0A to 4.5B | SYST, RFC1, SYSU, SUNI, SDIF |
4.6A to 4.6C | SYST, RFC1, SYSU, SDIF |
as of 4.6D | SYST, RFC1, SYSU, SDIFRUNTIME |
4. Call a tRFCs or qRFCs using the dynamic repositories
(For example, using NW RFC SDK, JCo, .NET Connector or Business Connector)
Application user:
R/3 release | Function groups |
---|---|
3.1I | SYST, ARFC, ERFC, X |
as of 4.0A | SYST, SYSU, ARFC, ERFC, X |
Repository user: as in the previous point
5. Send and receive IDocs
(For example, with the SAP Java IDoc Library or the Business Connector)
Application user (for sending IDocs):
R/3 release | Function groups |
---|---|
3.1I | SYST, ARFC, ERFC, BD11 |
as of 4.0A | SYST, SYSU, ARFC, ERFC, EDIN |
In addition, the user still requires the B_ALE_RECV authorization object, whereby the EDI_MESTYP field is filled with the list of the message types of the IDocs to be processed.
Repository user:
R/3 release | Function groups |
---|---|
3.1I | SYST, RFC1, SUNI, EDI6, EDI8, EDIF |
4.0A – 4.5B | SYST, RFC1, SYSU, SUNI, SDIF, EDIMEXT, EDI6 |
4.6A – 4.6C | SYST, RFC1, SYSU, SDIF, EDIMEXT, EDI6 |
as of 4.6D | SYST, RFC1, SYSU, SDIFRUNTIME, EDIMEXT, EDI6 |
The user also requires the S_IDOCDEFT authorization object, for example, using the “S_IDCDFT_DIS” authorization.
Note: If in the SAP System the auth/rfc_authority_check profile parameter has a value larger than “2”, all users also require the authorization for the SRFC function group.
Authorization check as of SAP Release 7.10
As of Release 7.10 you can execute the RFC authorization check on individual function modules, instead of on entire function groups. You can also use the procedure described above, but if you want to refine the authorization check even further, fill the fields of the S_RFC authorization obect as follows:
ACTVT: 16
RFC_TYPE: FUNC
RFC_NAME: The list of the function modules executed below.
In the following section Y is the name of the function module that you want to call.
1. Call a function module directly
Application user: RFCPING, SYSTEM_RESET_RFC_SERVER, Y
2. Call a function module directly using tRFC or qRFC
Application user: RFCPING, SYSTEM_RESET_RFC_SERVER, API_CHECK_TID, API_CREATE_TID, API_CLEAR_TID, ARFC_DEST_SHIP, ARFC_DEST_CONFIRM, Y
3.Call a function module using the dynamic repositories
Application user: RFCPING, SYSTEM_RESET_RFC_SERVER, Y
Repository user: RFCPING, SYSTEM_RESET_RFC_SERVER, RFC_GET_FUNCTION_INTERFACE, DDIF_FIELDINFO_GET
4. Call a tRFCs or qRFCs using the dynamic repositories
Application user: RFCPING, SYSTEM_RESET_RFC_SERVER, API_CHECK_TID, API_CREATE_TID, API_CLEAR_TID, ARFC_DEST_SHIP, ARFC_DEST_CONFIRM, Y
Repository user: as in the previous point
5. Send and receive IDocs
Application user (for sending IDocs): RFCPING, SYSTEM_RESET_RFC_SERVER, API_CHECK_TID, API_CREATE_TID, API_CLEAR_TID, ARFC_DEST_SHIP, ARFC_DEST_CONFIRM, IDOC_INBOUND_ASYNCHRONOUS
In addition, the user still requires the B_ALE_RECV authorization object, whereby the EDI_MESTYP field is filled with the list of the message types of the IDocs to be processed.
Repository user: RFCPING, SYSTEM_RESET_RFC_SERVER, RFC_GET_FUNCTION_INTERFACE, DDIF_FIELDINFO_GET, IDOCTYPE_READ_COMPLETE, EDI_AGREE_OUT_MESSTYPE_READ
The user also requires the S_IDOCDEFT authorization object, for example, using the “S_IDCDFT_DIS” authorization.
Reduction of the roundtrips when using the dynamic repositories
As of SAP System Release 7.00, you can use the procedure described in Note 1456826 to reduce the roundtrips required for the dynamic repository between the external connector and the SAP system. If you want to do this, the repository user that is used also requires the authorization for the following function group: RFC_METADATA
If the alternative authorization check at function module level is to be used, then the repository user requires the authorization for the following function modules instead: RFC_METADATA_GET, RFC_METADATA_GET_TIMESTAMP
Header Data
Released On | 11.01.2011 14:15:15 | ||||
Release Status | Released for Customer | ||||
Component | BC-MID-RFC RFC | ||||
Other Components |
|
||||
Priority | Recommendations / Additional Info | ||||
Category | Installation information |
Validity
This document is not restricted to a software component or software component version
References
This document refers to:
SAP Notes
1853904 | RFC authorizations for Java Connector | |
1820917 | Unable to cast object of type ‘System.InvalidCastException’ | |
1553144 | Authorization error during inserting query | |
1168772 | Minimum authorization profile for JRA | |
20534 | Authorization check – a short introduction |
今天的文章sap用户权限管理_sap物料被用户锁定怎么解除「建议收藏」分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:http://bianchenghao.cn/66104.html