Seting parameter auth/rfc_authority_check = 2 or 9
SAP R/3 Rel 4.7
We have auth/rfc_authority_check currently set to 1 (the default).
Can anyone provide an example or a justification case for setting the value to 2 or 9?
Has anyone made the changes in a live system? What was the impact and what scope of regression testing needed to be performed?
I understand the risk of the SRFC FUGR functions exposing some system info to a unauthorised user with the value set as 1 but I'm struggling with the business case for making the changes.
Assistance appreciated.
Alan
> Has anyone made the changes in a live system?
Yes, several times. But not always.
> What was the impact and what scope of regression testing needed to be performed?
Not much if you know what you are doing and why you are doing it. It helps a lot if your interfaces are well documented and managed.
> ... but I'm struggling with the business case for making the changes.
The correct value is "1" (hence the default) unless you have special requirements or special scenarios (config).
If you do not understand those special scenarios (i.e. do not use them), then rather leave it alone and concentrate on restricting the S_RFC names and the use-cases of the interfaces.
Cheers,
Julius
Similar Messages
-
External RFC logon not possible when auth/rfc_authority_check is set to 9
Hello,
we have to logon via RFC to an ECC6 system where auth/rfc_authority_check is set to "9" but SAP gives 'RFCAPI_RFC_SYS_EXCEPTION:RFC_ERROR_SYSTEM_FAILURE' error. If this parameter is set to "1" then logon is ok. I checked Saphelp and Sapnotes but the documentation for this parameter is a little bit unclear. I tried to change authorizations but without success. Does anyone have experience with this topic?
Many thanks in advance for your help!
TamáHello Julius,
thanks for your answer and sorry for the long delay.
We have only one instance so I think load balancing cannot be a problem.
I'd to set authorizations for SRFC but it didn't help. I try to include it here:
Manually Authorization Check for RFC Access
Activity Execute
Name of RFC to be protected *
Type of RFC object to be prote Function group
And another version:
Manually Authorization Check for RFC Access
Activity Execute
+Name of RFC to be protected RFCPING, RFC_SYSTEM_INFO, SYSTEM_RESET_RFC_SERVER
Type of RFC object to be prote Function group
The shortdump created when I try to logon is confusing, because it says that password is incorrect but this is not true. And it says that RFC is sent with invalid user "SAPCPIC".
I do not really familiar with the RFC authorization concept maybe this caused the problem.
Many thanks in advance if you can help me!
Regards
Tamá -
Turning on auth/rfc_authority_check 0
I want to change the value of auth/rfc_authority_check to 1 in a legacy SAP system, but this will cause RFC calls to my system to hit numerous authorisation errors.
How can I determine the authorisation required for the various authorisation function groups for RFC calls into my system, before change this parameter to 1. Is there any information repository that I can tap on for RFC historical informations.> Has anyone made the changes in a live system?
Yes, several times. But not always.
> What was the impact and what scope of regression testing needed to be performed?
Not much if you know what you are doing and why you are doing it. It helps a lot if your interfaces are well documented and managed.
> ... but I'm struggling with the business case for making the changes.
The correct value is "1" (hence the default) unless you have special requirements or special scenarios (config).
If you do not understand those special scenarios (i.e. do not use them), then rather leave it alone and concentrate on restricting the S_RFC names and the use-cases of the interfaces.
Cheers,
Julius -
Error in connecting SAP r\3 6.4 to BW 7.0
hello.
try to create source system to R/3 system.
after window log in as administration appear window with RFC connection
when I try to test authorization it show error. logon is failed. but this user in BW created and Password is correct
what have I do to save that RFC connection correctly?
thank you for any advise.
BTW read B84: BW Connectivity and
link: http://help.sap.com/saphelp_nw04/helpdata/en/80/1a61e5e07211d2acb80000e829fbfe/frameset.htm
may be I understand something wrong..in source system run tran sm59.
open my rfc destination.
try to check authorization. and its show error: incorrect login or password (try again).
user have all rights (sap_all and S_BI-WHM_RFC)
login and password correct.
what's wrong with rfc?
profile parameter auth/rfc_authority_check is set to 1.
is any solution to connect sap r/3 6.4 and sp bw 7.0? -
Regading getting data to and forth between 2 programs through SUBMIT
Hi All,
I have a issue regarding fetching internal table data from one program to another.
Actually I have <b>Main Program</b> from that through SUBMIT statement i am calling another program and executing it for every 100 records - Actually this program is having BAPI running in it, By result i will get an internal table data. Now i want to get that internal table data back into my MAIN Program so that i can use it for next process.
<b>EXPORT & IMPORT statements are working from MAIN Program to Other Program.</b>
<b>EXPORT & IMPORT statements are not working from Other Program[SUBMIT'ed Program] to MAIN Program.</b>
So can anybody tell me how can i get that data in other program into MAIN Program[Back].
Thanks in advance.
Thanks & Regards,
Rayeez.When you submit the program is then running in parallel with the program which submitted it. There is no mechism that you are using to stop the calling program and wait for the submitted program to finish and bring back some data. Most likly program 1 ends before program 2 is finished updating the material master. You can do this kind of thing with Function modules. You would put your call to the submitted program inside of a function module, then call that function module saying STARTING IN NEW TASK, then you can wait for it to be done and get the results using the RECIEVING statement.
Here is the F1 Help.
+
CALL FUNCTION
Variant 2
CALL FUNCTION func ...STARTING NEW TASK task name.
Additions:
1. ... DESTINATION dest
2. ... DESTINATION IN GROUP group name
3. ... DESTINATION IN GROUP DEFAULT
4. ... PERFORMING form ON END OF TASK
5. ... EXPORTING p1 = f1 ... pn = fn
6. ... TABLES p1 = itab1 ... pn = itabn
7. ... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
Starts the function module func asynchronously ina new session. In contrast to normal function module calls, the callingprogram resumes processing as soon as the function module is started inthe target system. It does not wait until the function module hasfinished. Through CALL SCREEN,the called function module can, for example, display a screen and thusinteract with the user.
Notes
This variant applies only from R/3 Release 3.0, so boththe client system and the server system must have Release 3.0 orhigher.
With this variant, the called function module must also be flagged inthe Function Builder as externally callable, even if it is executedlocally (without the addition DESTINATION).
There can be no function call to the destination 'BACK' in thecalled function module (for more information about the destination 'BACK', see CALLFUNCTION func DESTINATION dest).
This variant does not support the execution of externalprograms accessible via the destination of the TCP/IP type asasynchronous calls (see the Transaction Tools ¨Administration, Administration ¨ Network ¨ RFC destinations formaintaining destinations).
You cannot display screens (screens or lists asamodal windows in RFC communication using SAP Router.
From Release 4.0, you can check the load of each RFC destination moreclosely (in the RFC destination maintenance for an R/3 connection, choose Destination -> ARFC options). This checks whetherthe target host has sufficient resources before the function module isexecuted. If the target host is overloaded, the system delays executingthe function module. The algorithm for calculating the load on thetarget host is the same one used in an asynchronous RFC call using the DESTINATION IN GROUP addition. Note that this option can only beused with target hosts running Release 3.1H or higher. Note also thatit is the default setting.
In principle, parallelization makes sense whenever applicationservers have the necessary resources. In this case, the applicationservers must be configured with at least 3 dialog work processes.
A program that is run in the background and uses RFC parallelizationrequires at least 1 dialog work process per application server becausedialog processes use parallel execution.
If the instance profile parameter 'auth/rfc_authority_check'is set (to 1), the system automatically performs an RFC authorizationcheck. The authorization check refers to the relevant function groupfor the function module to be called. If no authorization is found, aruntime error occurs. You can check the authorization in advance withthe function module AUTHORITY_CHECK_RFC. If the communication takes place in the same system with thesame user context (same client and user ID), there is no authorizationcheck. For further information, refer to the RFCAuthorization Concept.
When you are using asynchronous RFC to implement parallel windows,all these windows are closed if the caller session is the only sessionand terminates.
ABAP_ADDITION_1&
... DESTINATION dest
Effect
Executes the function module externally as a RemoteFunction Call (RFC); dest can be a literal or a variable.The R/3 System where the function module is executed depends on thespecified destination. Externally callable function modules must beflagged as such in the Function Builder (of the target system).
Note
If the destination is not explicitly specified, the systemuses the default destination 'NONE'.
Note
If, during a RemoteFunction Call, an error occurs in the target system, detailsof the error message are passed bac to the calling system in thefollowing system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1,SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields areinitialized before every RFC. If a short dump or a type X messageoccurs, the short text of the dump is transferred to the caller, andthe contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.
In RFC-enabled function modules, no ABAP statements are allowed thatwould end the RFC connection (for example, LEAVE, SUBMIT or the ANDRETURN addition).
Note
Note that a database commit occurs at eachRemote Function Call (RFC). Consequently, you may not use RemoteFunction Calls between pairs of statements that open and close adatabase cursor (such as SELECT ... ENDSELECT).
Addition 2
... DESTINATION IN GROUP group name
Addition 3
... DESTINATION IN GROUP DEFAULT
Effect
You use this addition to perform parallel execution offunction modules (asynchronous calls) on a predefined group of R/3System application servers.
You use addition 2 (DESTINATION IN GROUP group name) toperform parallel execution of function modules on a predefined group ofapplication servers. To maintain the RFC groups, choose Tools ¨ Administration ¨ Administration ¨ Network ¨ RFCdestinations ¨ RFC ¨ RFC groups. The application programmer isresponsible for the availability of RFC groups in the productionsystem.
You use addition 3 (DESTINATION IN GROUP DEFAULT) to performparallel execution of function modules (asynchronous calls) on all currently available R/3 System application servers. However,instead of this variant, you are recommended to use an RFC group withappropriate resources for parallel processing of asynchronous calls (atleast for performance reasons). Please note that the additionDESTINATION IN GROUP ' ' has the same effect as the additionDESTINATION IN GROUP DEFAULT.
When you first call a function module with these additions, thesystem initializes the specified RFC group (provided no explicitinitialization has already been performed).
To obtain current information about resources (that is, the number ofresources available to process function modules), you can alsoinitialize the RFC group explicitly in the program via the functionmodule SPBT_INITIALIZE. You must perform this actionbefore the first function module call.
In both cases, the system first determines the number of currentlyavailable resources (work processes) on the available applicationservers (either a group of servers or all servers). By checking thecurrent system load of each application server, the system determineshow many work processes are available to execute asynchronous calls.
After determining the available resources, the asynchronous call isexecuted at one of the destinations. If no resources are available atthat particular time, the system executes the exception routine RESOURCE_FAILURE (see the addition EXCEPTIONS). In thecase of an asynchronous function module call, this exception must be handled by the application program (see example).
Parallel processing cannot take place if any of the resourcethresholds are exceeded.
Notes
In order to be taken into consideration for RFC parallelprocessing, an application server must have at least 3 freedialog processes.
The system triggers the exception RESOURCE_FAILURE only forasynchronous RFCs with the additions DESTINATION IN GROUP groupname and DESTINATION IN GROUP DEFAULT.
At present, only one RFC group per program environment issupported for parallel execution of asynchronous calls. Using both theadditions DESTINATION IN GROUP group name and DESTINATION INGROUP DEFAULT in a program is thus not allowed.
To find out which destination was automatically selected, call thefunction module SPBT_GET_PP_DESTINATION immediately after thefunction module call with the two additions. This returns the selectedRFC destination.
If you want to delete an application server from the list of theconfigured RFC group at runtime (for example, when the applicationserver is not accessible for technical reasons), use the functionmodule SPBT_DO_NOT_USE_SERVER.
Addition 4
... PERFORMING form ON END OF TASK
While the parameters for receiving results (i.e. IMPORTING andTABLES parameters) are specified directly as additions in thecase of "conventional" function modules (see variant 2), these arelogged in the FORM routine form when making anasynchronous call (see RECEIVE).
Notes
If a function module returns no result, and you are notinterested in error messages that arise when executing the functionmodule, this addition (... PERFORMING form ON END OF TASK) canbe omitted.
If you want to handle the error messages that arise when executingthe asynchronous function module call, you must use thisaddition. Also, when receiving the results in the FORM routine(see RECEIVE), you must reactaccordingly to the system exceptions SYSTEM_FAILURE andCOMMUNICATION_FAILURE.
With asynchronous RFC, the task name uniquely identifies theasynchronous connection and thus the context called.
If several asynchronous function modules are executed consecutivelyto the same destination, you must assign a different task name to each.
A calling program that starts an asynchronous RFC with PERFORMINGform ON END OF TASK cannot switch roll areas or change to aninternal session. This is because the asynchronous function module callreply cannot be passed on to the relevant program. You can perform aroll area switch with SUBMIT or CALL TRANSACTION.
If a calling program makes asynchronous calls, finishes, and thenexpects responses, these responses cannot be delivered.
To wait for the reply to a started asynchronous function module, usethe WAIT command with the additionPERFORMING form ON END OF TASK. Here, WAIT must be in thesame program context (session).
Note that the execution of the asynchronous calls involves a changeof roll area. This means that the FORM routines for receivingthe external calls can be processed while you are making furtherexternal calls. This means that the developer must ensure thatthe FORM routines can be executed at any time. You cannotmake any assumptions about the processing sequence.
Addition 5
... EXPORTING p1 = f1 ... pn = fn
Effect
EXPORTING passes values of fields and fieldstrings from the calling program to the function module. In thefunction module, the formal parameters are defined as importparameters.
Addition 6
... TABLES p1 = itab1 ... pn = itabn
Effect
TABLES passes the contents of internal tables.
Addition 7
... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
While any exceptions arising in the called functionmodule are handled by the second addition (in the FORM routine),this addition can handle two special system exceptions, as withfunction module calls with the addition DESTINATION:
SYSTEM_FAILURE
is triggered, if a system crash occurs on the receiving side.
COMMUNICATION_FAILURE
is triggered if there is a connection or communication problem.
In both cases, you can get a description of the error with theoptional addition
... MESSAGE msg
Note
In principle, you should always react to these twosystem exceptions, whether you are making an asynchronous functionmodule call or receiving results.
Examples
Asynchronous call to a transaction and display in a separate session.
DATA: MSG_TEXT(80) TYPE C. "Message text
Asynchronous call to Transaction SM59 -->
Create a new session
CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'
DESTINATION 'NONE'
EXPORTING
TCODE = 'SM59'
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT
SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT.
IF SY-SUBRC NE 0.
WRITE: MSG_TEXT.
ELSE.
WRITE: 'O.K.'.
ENDIF.
Using RFC groups to parallelize function module calls (RFC parallelprocessing)
TYPES: BEGIN OF TASKLIST_TYPE,
TASKNAME(4) TYPE C, "Task administration
RFCDEST LIKE RFCSI-RFCDEST
END OF TASKLIST_TYPE.
DATA: INFO LIKE RFCSI, C, "Message text
JOBS TYPE I VALUE 10, "Number of parallel jobs
SND_JOBS TYPE I VALUE 1, "Sent jobs
RCV_JOBS TYPE I VALUE 1, "Received replies
EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs
TASKNAME(4) TYPE N VALUE '0001', "Task name administration
TASKLIST TYPE TABLE OF TASKLIST_TYPE,
WA_TASKLIST TYPE TASKLIST_TYPE.
DO.
CALL FUNCTION 'RFC_SYSTEM_INFO'
STARTING NEW TASK TASKNAME DESTINATION IN GROUP DEFAULT
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2
RESOURCE_FAILURE = 3.
CASE SY-SUBRC.
WHEN 0.
Administration of asynchronous tasks
WA_TASKLIST-TASKNAME = TASKNAME.
CLEAR WA_TASKLIST-RFCDEST.
APPEND WA_TASKLIST TO TASKLIST.
WRITE: / 'Started task: ', WA_TASKLIST-TASKNAME COLOR 2.
TASKNAME = TASKNAME + 1.
SND_JOBS = SND_JOBS + 1.
JOBS = JOBS - 1. "Number of existing jobs
IF JOBS = 0.
EXIT. "Job processing finished
ENDIF.
WHEN 1 OR 2.
Handling of communication and system failure
WHEN 3. "No resources available at present
Receive reply to asynchronous RFC calls
IF EXCP_FLAG = SPACE.
EXCP_FLAG = 'X'.
First attempt for RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.01' SECONDS.
ELSE.
Second attempt for RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.1' SECONDS.
ENDIF.
IF SY-SUBRC = 0.
CLEAR EXCP_FLAG. "Reset flag
ELSE. "No replies
"Endless loop handling
ENDIF.
ENDCASE.
ENDDO.
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST INTO WA_TASKLIST.
WRITE:/ 'Received task:', WA_TASKLIST-TASKNAME COLOR 1,
30 'Destination: ', WA_TASKLIST-RFCDEST COLOR 1.
ENDLOOP
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2.
RCV_JOBS = RCV_JOBS + 1. "Receiving data
IF SY-SUBRC NE 0.
Handling of communication and system failure
ELSE.
READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME
INTO WA_TASKLIST
IF SY-SUBRC = 0. "Register data
WA_TASKLIST-RFCDEST = INFO_RFCDEST.
MODIFY TASKLIST INDEX SY-TABIX FROM WA_TASKLIST.
ENDIF.
ENDIF.
ENDFORM
Note
If you encounter problems, refer toTypical RFC problems and theirsolutions.
Note
Runtime errors:
Note
Runtime errors:
CALL_FUNCTION_NO_RECEIVER:
Data received for an unknown CPI-C connection.
CALL_FUNCTION_DEST_TYPE:
Destination type not allowed.
CALL_FUNCTION_NO_DEST:
Specified destination does not exist.
CALL_FUNCTION_NO_LB_DEST:
Specified destination (in load distribution mode) does not exist.
CALL_FUNCTION_TABINFO:
Data error (info internal table) in a Remote Function Call.
CALL_BACK_ENTRY_NOT_FOUND:
The called function module is not released for use in RFC.
CALL_FUNCTION_FIELD_NOT_FOUND:
The function parameter that you passed is not recognized on therecipient side.
RFC_NO_AUTHORITY:
The user does not have RFC authorization.
CALL_FUNCTION_SINGLE_LOGIN_REJ:
No authorization to log on as a trusted system. The error codeshave the following meanings:
0) Valid security key but wrong logon data 1) Calling system is not a trusted system, or security key is invalid 2) User either does not have RFC authorization (authorization object S_RFCACL), or logged on as one of the protected users 'DDIC' or 'SAP*' 3) Timestamp of the logon data is invalid
CALL_FUNCTION_DESTINATION_NO_T:
Missing communication type (I for internal connection, 3 for R/3) in anasynchronous RFC
CALL_FUNCTION_NOT_REMOTE:
The function module called is not flagged as "RFC supported"
CALL_FUNCTION_REMOTE_ERROR:
An error occurred during the Remote Function Call. This has been loggedin the target system.
CALL_FUNCTION_SIGNON_INCOMPL:
The logon data for the user is incomplete.
CALL_FUNCTION_SIGNON_INTRUDER:
You cannot log onto a target system using an internal call.
CALL_FUNCTION_SIGNON_INVALID:
External RFC without a valid user name.
CALL_FUNCTION_SIGNON_REJECTED:
Attempt to log onto a target system without a valid user name. Theerror code can have the following meanings:
1) Wrong password or invalid user ID
2) User locked
3) Too many logon attempts
4) Error in authorization buffer (internal error)
5) No external user check
6) Invalid user type
7) Validity period of user has expired
CALL_FUNCTION_SYSCALL_ONLY:
RFC without a valid user name only allowed when calling system functionmodules. For the meaning of the error codes, refer toCALL_FUNCTION_SINGLE_LOGIN_REJ.
CALL_FUNCTION_TABLE_NO_MEMORY:
No memory available for a table to be imported
CALL_FUNCTION_TASK_IN_USE:
Asynchronous RFC only: Task name already in use.
CALL_FUNCTION_TASK_YET_OPEN:
Asynchronous RFC only: The specified task is already open.
CALL_FUNCTION_SNC_ERROR:
Error reading the SNC information for the destination.
CALL_RPERF_SLOGIN_READ_ERROR:
No valid trusted system entry for the calling system.
CALL_RPERF_SLOGIN_AUTH_ERROR:
No trusted authorization for the RFC caller and trusted system.
+
Regards,
Rich Heilman -
How to check if the user has only the display authority of a message
hi,
How to check if the user has only the display authority of a message but does not have the change authority for a certain message?
Best regards,hi blake
though i am an application consultant and for authorisation u need to have help of BASIS person if u r not the one but still i can guide u regarding the same,
Basically Authorization Management
Use
You can use the following authorization objects to control the authorizations for maintaining business partner data:
Authorization objects for the Business Partner:
 B_BUPA_GRP
 B_BUPA_ATT
 B_BUPA_FDG
 B_BUPA_RLT
Authorization objects for relationships:
 B_BUPR_BZT
 B_BUPR_FDG
In addition, you can assign an authorization group to a business partner in the dialog. The authorization group controls which users may maintain data for this business partner.
You can also define authorizations for fields and field groups using the Business Data Toolset (BDT). Depending on the settings you have made, the system carries out the relevant authorization checks.
In the dialog in the SAP GUI, you can display an overview of the authorizations assigned to you by pressing the button Settings.
For more information on authorization management, see the Implementation Guide (IMG) of the Business Partner, as well as in the Developers Handbook for the BDT under Authorizations.
IntegrationAuthorization management for the Business Partner forms part of the SAP authorization concept.
Prerequisites
You have made the necessary settings in Customizing of the Business Partner under Basic Settings--> -Address Management.
Moving over
AS ABAP Authorization Concept
The ABAP authorization concept protects transactions, programs, and services in SAP systems from unauthorized access. On the basis of the authorization concept, the administrator assigns authorizations to the users that determine which actions a user can execute in the SAP system, after he or she has logged on to the system and authenticated himself or herself.
To access business objects or execute SAP transactions, a user requires corresponding authorizations, as business objects or transactions are protected by authorization objects. The authorizations represent instances of generic authorization objects and are defined depending on the activity and responsibilities of the employee. The authorizations are combined in an authorization profile that is associated with a role. The user administrators then assign the corresponding roles using the user master record, so that the user can use the appropriate transactions for his or her tasks.
Authorization Checks
To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:
Starting SAP transactions (authorization object S_TCODE)
Starting reports (authorization object S_PROGRAM)
Calling RFC function modules (authorization object S_RFC)
Table maintenance with generic tools (S_TABU_DIS)
Checking at Program Level with AUTHORITY-CHECK
Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source code of the program, to check whether users have the appropriate authorization and whether these authorizations are suitably defined; that is, whether the user administrator has assigned the values required for the fields by the programmer. In this way, you can also protect transactions that are called indirectly by other programs.
AUTHORITY-CHECK searches profiles specified in the user master record to see whether the user has authorization for the authorization object specified in the AUTHORITY-CHECK. If one of the authorizations found matches the required values, the check is successful.
Starting SAP Transactions
When a user starts a transaction, the system performs the following checks:
The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.
The system then checks whether the user has authorization to start the transaction.
The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.
 The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.
 If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).
If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.
The check is not performed in the following cases:
You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.
This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.
 You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.
 So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to Y (using transaction RZ10).
All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.
Starting Report Classes
You can perform additional authorization checks by assigning reports to authorization classes (using report RSCSAUTH). You can, for example, assign all PA* reports to an authorization class for PA (such as PAxxx). If a user wants to start a PA report, he or she requires the appropriate authorization to execute reports in this class.
We do not deliver any predefined report classes. You must decide yourself which reports you want to protect in this way. You can also enter the authorization classes for reports with the maintenance functions for report trees. This method provides a hierarchical approach for assigning authorizations for reports. You can, for example, assign an authorization class to a report node, meaning that all reports at this node automatically belong to this class. This means that you have a more transparent overview of the authorization classes to which the various reports are transported.
You must consider the following:
After you have assigned reports to authorization classes or have changed assignments, you may have to adjust objects in your authorization concept (such as roles (activity groups), profiles, or user master records).
There are certain system reports that you cannot assign to any authorization class. These include:
RSRZLLG0
STARTMEN (as of SAP R/3 4.0)
Reports that are called using SUBMIT in a customer exit at logon (such as SUSR0001, ZXUSRU01).
Authorization assignments for reports are overwritten during an upgrade. After an upgrade, you must therefore restore your customer-specific report authorizations.
Calling RFC Function Modules
When RFC function modules are called by an RFC client program or another system, an authorization check is performed for the authorization object S_RFC in the called system. This check uses the name of the function group to which the function module belongs. You can deactivate this check with parameter auth/rfc_authority_check.
Checking Assignment of Authorization Groups to Tables
You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.
You can assign a table to authorization group Z000. (Use transaction SM30 for table TDDAT) A user that wants to access this table must have authorization object S_TABU_DIS in his or her profile with the value Z000 in the field DICBERCLS (authorization group for ABAP Dictionary objects).
please See also:
SAP Notes 7642, 20534, 23342, 33154, and 67766
guess this info will help you,there is one graphic which actually explain the hierarchy of authorisation,i will find some time out to let u know more info about the authorisation
but if u sit with ur BASIS guy then u can learn lot of things in PFCG
i guess u r a basis guy,then its not a problem
best regards
ashish -
Hi,
Call Function 'FM' starting new task task-name
Exporting
What does this statement does.Hi
chk this out
CALL FUNCTION STARTING NEW TASK
Variant 2
CALL FUNCTION func ...STARTING NEW TASK task name.
Extras:
1. ... DESTINATION dest
2. ... DESTINATION IN GROUP group name
3. ... DESTINATION IN GROUP DEFAULT
4. ... PERFORMING form ON END OF TASK
5. ... EXPORTING p1 = f1 ... pn = fn
6. ... TABLES p1 = itab1 ... pn = itabn
7. ... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
Starts the function module func asynchronously in a new session. In contrast to normal function module calls, the calling program resumes processing as soon as the function module is started in the target system. It does not wait until the function module has finished. Using CALL SCREEN, the called function module can, for example, display a screen and thus interact with the user. Note that taskname must be a valid string of at least 2 characters, preferably fewer than 8 characters. You cannot use either ' ' or SPACE as tasknames.
Notes
Note that under certain circumstances, an RFC may cause a database commit. For this reason, do not insert an RFC between two OpenSQL statements that open and close a database cursor (such as SELECT...ENDSELECT).
This variant applies only from R/3 Release 3.0, so both the client system and the server system must have Release 3.0 at least.
With this variant, the called function module must also be flagged in the Function Builder as externally callable, even if it is executed locally (without the addition Destination).
There can be no function call to the destination 'BACK' in the called function module (for more information about the destination 'BACK', see CALL FUNCTION func DESTINATION dest).
This variant does not allow you to execute external programs that you access from a TCP/IP-type detination asynchronously. (See the Transaction Tools -> Administration, Administration -> Network -> RFC destinations for maintaining destinations).
Neither does this variant allow you to display images such as lists or screens in a separate window during RFC communication using a SAProuter.
From Release 4.0 onwards, you can carry out a new, stricter system load check on RFC destinations. (In RFC destination maintenance of an R/3 connection, choose Destination -> ARFC-Optionen). Before the function module is executed, the system checks that the destination has sufficient resources available. If not, the system delays execution of the function module for a given period of time. The algorithm used to determine the system load on the target machine is the same as that used for an asynchronous RFC with the DESTINATION IN GROUP addition. Note that this option is only available for target systems from Release 3.1H onwards. This procedure is active as default.
In principle, parallel processing makes sense whenever application servers have the necessary resources. In this case, the application servers must be configured with at least 3 dialog work processes.
A program that is run in the background and uses RFC parallel processing requires at least 1 dialog work process per application server (because parallel processing takes place in a dialog work process).
If the instance profile parameter 'auth/rfc_authority_check' is set to 1, the system automatically performs an RFC authorization check. The authorization check refers to the relevant function group for the function module to be called. If no authorization is found, a runtime error occurs. You can check the authorization in advance with the function module AUTHORITY_CHECK_RFC. If the RFC communication takes places in one system and in the same user context (that is, the same client and User ID) the system does not perform an RFC authority check. For more information, see: RFC Authorization Concept.
When you are using asynchronous RFC to implement parallel windows, all these windows are closed if the caller session is the only session and terminates.
Note that asynchronous tasks that have been started are not necessarily closed when the calling program ends.
See also RFC Logons to the Target System (Remote Logon).
Addition 1
... DESTINATION dest
Effect
Executes the function module externally as a Remote Function Call (RFC); dest can be a literal or a variable. The R/3 System where the function module is executed depends on the specified destination. Externally callable function modules must be flagged as such in the Function Builder (of the target system).
Note
If the destination is not explicitly specified, the system uses the default destination 'NONE'.
Note
If, during a Remote Function Call, an error occurs in the target system, details of the error message are passed back to the calling system in the following system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields are initialized before every RFC. If a short dump or a type X message occurs, the short text of the dump is transferred to the caller, and the contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.
In RFC-enabled function modules, no ABAP statements are allowed that would end the RFC connection (for example, either LEAVE or SUBMIT without the AND RETURN addition).
Note
Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you cannot use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).
Addition 2
... DESTINATION IN GROUP group name
Addition 3
... DESTINATION IN GROUP DEFAULT
Effect
You use this addition to perform parallel execution of function modules (asynchronous calls) on a predefined group of R/3 System application servers.
You use addition 2 (DESTINATION IN GROUP group name) to perform parallel execution of function modules on a predefined group of application servers. To maintain the RFC groups, choose Tools -> Administration -> Administration ->Network -> RFC destinations -> RFC -> RFC groups. The application programmer is responsible for the availability of RFC groups in the production system. In this case the group name variable must be of the type RZLLITAB-CLASSNAME
You use addition 3 (DESTINATION IN GROUP DEFAULT) to perform parallel execution of function modules (asynchronous calls) on all currently available R/3 System application servers. However, instead of this variant, you are recommended to use an RFC group with appropriate resources for parallel processing of asynchronous calls (at least for performance reasons). Please note that the addition DESTINATION IN GROUP ' ' has the same effect as the addition DESTINATION IN GROUP DEFAULT.
When you first call a function module with these additions, the system initializes the specified RFC group (unless the group has already been explicitly identified).
To obtain current information about resources (that is, the resources available to process function modules), you can also initialize the RFC group explicitly in the program using the function module SPBT_INITIALIZE. You must perform this action before the first function module call.
In both cases, the system first ascertains the currently available resources (work processes) on the available application servers (either a group of servers or all servers). By checking the current system load of each application server, the system determines how many work processes are available to execute asynchronous calls.
After ascertaining the available resources, the asynchronous call is executed to one of the
destinations. If no resources are available at that particular time, the system executes the
exception routine RESOURCE_FAILURE (see the addition EXCEPTIONS). In the case of
an asynchronous function module call, this exception must be handled by the application
program (see example).
No resources are made available by the system if resource availability limits are exceeded:
Notes
To be taken into consideration for RFC parallel processing, an application server must have at least 3 free dialog processes.
The system triggers the exception RESOURCE_FAILURE only for asynchronous RFCs with the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT.
At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT in a program is thus not allowed.
To find out which destination was automatically selected, call the function module SPBT_GET_PP_DESTINATION immediately after the function module call with the two additions. This returns the selected RFC destination.
If you want to delete an application server from the list of the configured RFC group at runtime (for example, when the application server is not accessible for technical reasons), use the function module SPBT_DO_NOT_USE_SERVER.
Addition 4
... PERFORMING form ON END OF TASK
While the parameters for receiving results (that is IMPORTING and TABLES parameters) are specified directly as additions in the case of "conventional" function modules (see variant 2), these are logged in the FORM routine form when making an asynchronous call (see RECEIVE).
Notes
If a function module returns no result, and you are not interested in error messages that arise when executing the function module, this addition (... PERFORMING form ON END OF TASK) can be omitted.
If you want to handle the error messages that arise when executing the asynchronous function module call, you must use this addition. Also, when receiving the results in the FORM routine (see RECEIVE), you must react accordingly to the system exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE.
With asynchronous RFC, the task name uniquely identifies the asynchronous connection and thus the context called.
If several asynchronous function modules are executed consecutively to the same destination, you must assign a different task name to each.
A calling program that starts an asynchronous RFC with the PERFORMING form ON END OF TASK addition cannot switch roll areas or change to an internal mode. This is because the asynchronous function module call reply cannot be passed on to the relevant program. You can perform a roll area switch with SUBMIT or CALL TRANSACTION.
If a calling program makes asynchronous calls, finishes, and then expects responses, it cannot receive these responses.
To wait for the reply to a started asynchronous function module, use the WAIT command with the addition PERFORMING form ON END OF TASK. Here, WAIT must be in the same program context (mode).
Note that executing asynchronous calls is subject to a roll area change.That is, subroutines performed to receive asynchronous calls can take place while other asynchronous calls are being made. Thus as a developer you must ensure that subroutines can be executed at any time. You must not make assumptions about the implicit processing sequence.
Addition 5
... EXPORTING p1 = f1 ... pn = fn
Effect
Passes values of fields and field strings from the calling program to the function module. In the function module, the formal parameters are defined as import parameters.
Addition 6
... TABLES p1 = itab1 ... pn = itabn
Effect
Passes references to internal tables.
Addition 7
... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
While any exceptions arising in the called function module are handled by the second
addition (see the FORM subroutine RETURN_INFO), this addition can handle two special
system exceptions, (as with function module calls with the DESTINATION addition):
SYSTEM_FAILURE
is triggered, if a system crash occurs on the receiving side.
COMMUNICATION_FAILURE
is triggered if there is a connection or communication problem.
In both cases, you can get a description of the error with the optional ... MESSAGE messaddition
Note
In principle, you should always react to these two system exceptions, whether you are making an asynchronous function module call or receiving results.
Examples
Calling a transaction in a seperate session.
DATA: MSG_TEXT(80) TYPE C. "Message text
Asynchronous call to Transaction SM59 -->
Create a new session
CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'
DESTINATION 'NONE'
EXPORTING
TCODE = 'SM59'
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT
SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT.
IF SY-SUBRC NE 0.
WRITE: MSG_TEXT.
ELSE.
WRITE: 'O.K.'.
ENDIF.
Using RFC groups to parallelize function module calls(RFC parallel processing)
TYPES: BEGIN OF TASKLIST_TYPE,
TASKNAME(4) TYPE C, "Verwaltung der Tasks
RFCDEST LIKE RFCSI-RFCDEST,
END OF TASKLIST_TYPE.
DATA: INFO LIKE RFCSI, C, "Message text
JOBS TYPE I VALUE 10, "Number of parallel jobs
SND_JOBS TYPE I VALUE 1, "Sent jobs
RCV_JOBS TYPE I VALUE 1, "Received replies
EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs
TASKNAME(4) TYPE N VALUE '0001', "Task name administration
TASKLIST TYPE TABLE OF TASKLIST_TYPE,
WA_TASKLIST TYPE TASKLIST_TYPE.
DO.
CALL FUNCTION 'RFC_SYSTEM_INFO'
STARTING NEW TASK TASKNAME DESTINATION IN GROUP DEFAULT
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2
RESOURCE_FAILURE = 3.
CASE SY-SUBRC.
WHEN 0.
Administration of asynchronous tasks
WA_TASKLIST-TASKNAME = TASKNAME.
CLEAR WA_TASKLIST-RFCDEST.
APPEND WA_TASKLIST TO TASKLIST.
WRITE: / 'Started Task: ', WA_TASKLIST-TASKNAME COLOR 2.
TASKNAME = TASKNAME + 1.
SND_JOBS = SND_JOBS + 1.
JOBS = JOBS - 1. "Number of existing jobs
IF JOBS = 0.
EXIT. "Job processing finished
ENDIF.
WHEN 1 OR 2.
Handling of communication and system failure
WHEN 3. "No resources available at present
Receive reply to asynchronous RFC calls
IF EXCP_FLAG = SPACE.
EXCP_FLAG = 'X'.
First attempt for RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.01' SECONDS.
ELSE.
Second attempt for RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.1' SECONDS.
ENDIF.
IF SY-SUBRC = 0.
CLEAR EXCP_FLAG. "Reset flag
ELSE. "No replies
"Endless loop handling
ENDIF.
ENDCASE.
ENDDO.
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST INTO WA_TASKLIST.
WRITE:/ 'Received Task:', WA_TASKLIST-TASKNAME COLOR 1,
30 'Destination: ', WA_TASKLIST-RFCDEST COLOR 1.
ENDLOOP.
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2.
RCV_JOBS = RCV_JOBS + 1. "Receiving data
IF SY-SUBRC NE 0.
Handling communication and system failure
ELSE.
READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME
INTO WA_TASKLIST.
IF SY-SUBRC = 0. "Daten registrieren
WA_TASKLIST-RFCDEST = INFO-RFCDEST.
MODIFY TASKLIST INDEX SY-TABIX FROM WA_TASKLIST.
ENDIF.
ENDIF.
ENDFORM.
plz reward if useful -
SFLIGHT is NOT defined for the current logical database.
I have just started learning ABAP and bought an ABAP Objects book by Horst Keller. I have installed 4.6d mini sap and SAP GUI 6.4 on win XP Prof. I executed S_FLIGHT_MODEL_DATA_GENERATOR to load DB tables.
(1). When I tried to check a sample program, I get an error message SFLIGHT is not defined for the current logical database.
Here is the partial code:
REPORT zbcb01f1 .
TABLES: sflight, sbook.
DATA: BEGIN OF sr OCCURS 100,
carrid LIKE sbook-carrid,
connid LIKE sbook-connid,
fldate LIKE sbook-fldate,
bookid LIKE sbook-bookid,
order_date LIKE sbook-order_date,
loccuram LIKE sbook-loccuram,
END OF sr.
GET sflight. <---- Error is pointed here
(2). I am also not getting Graphical Screen Painter when selecting Layout for a screen. Instead, I am getting alphanumeric editor.
Someone please help me.
Raizak.Hi Raizak,
the easiest way is to go to service.sap.com/notes and enter the note number. For this time I've copied the 2 notes below.
Best regards,
Christian
Symptom
The Graphical Layout Editor of the Screen Painter either does not start or terminates.Error message 37527 is displayed in the session in which the call was made (Graphical Layout Editor not available.
Additional key words
() EUNOTE, EUSCREENPAINTER, 37 527
Cause and prerequisites
This note comprises all the common causes for error message 37527 and provides you with information on how to systematically trouble shoot the problem.
1. Windows32 or UNIX/motif?
As of Release 4.6B there is only the program version for 32bit Windows (NT, 95, 98, 2000 ff.).Up to Release 4.6A there was also a version for UNIX/Motif.All of the more current notes (with the exception of Note 45490) refer only to the Windows version.
2. Termination at the start or during use?
The following diagnostic steps refer to the causes of the errors which prevent the Graphical Layout Editor from starting. However, there are also known error causes, which result in the program terminating when the application is being used and which also produce the 37527 error message. This affects -
Rel.4.6C/D: Termination when attempting to read texts in the logon language -> Note 375494
Crash after transferring program and dictionary fields. Termination after transferring program and dictionary fields -> Note 189245
Release 3.1I: Termination after inputting field text -> Note 113318
3. Is the SAPGUI installation correct?
The Graphical Layout Editor is automatically installed during the standard installation of the SAPGUI.If you chose a non-standard installation, then you should have explicitely selected its installation (component "Development Tools - Graphical Screen Painter").
The program executable is called gneux.exe.During the SAPGUI installation it is placed in the same directory as the SAPGUI programms (for example, front.exe) (usually C:\Program Files\SAPpc\sapgui). The following belong to the program:
- An additonal executable gnetx.exe (RFC starter program)
- the DLL eumfcdll.dll
- various eusp* data files (that is, the names all begin with eusp.)
You can check the completeness of the program installation by starting the program gneux.exe locally in the SAPGUI directory (for example, by double-clicking on the program name in the Explorer window).The Layout Editor is displayed with German texts and an empty drawing area for the pseudo screen EUSPDYND 0000.
If the installation is not complete, an error dialog box provides information regarding the cause of the error, for example, sometimes the DLL eumfcdll.dll is missing after reinstalling the SAPGUI. For example, the eumfcdll.dll DLL was sometimes missing after the SAPGUI was reinstalled.
4. System link defined and okay?
The Graphical Layout Editor is a separate program which is started by the Screen Painter Transaction (SE51) on the Frontend machine.
Up to Release 3.0F, the programs communicated with each other via the graphics log of the SAPGUIs (gmux).The definition of the environment variable SAPGRAPH may be the cause for the program not being being found where it is.
As of Release 3.1 G, the programs use a separate RFC link which is set up in addition to the SAPGUI's RFC link.Missing or incorrect definitions of the RFC destination EU_SCRP_WN32 or problems with the creation of the RFC link are the most frequent causes for error message 37527 being displayed.Below you can find the correct settings for the RFC destination EU_SCRP_WN32 (under "Solution").Note 101971 lists all the possible causes for problems with the RFC link set-up. Attention:The Graphical Layout Editor may not be operated through a firewall (for example between the SAP and the customer system) because this does not allow an additional RFC connection in addition to the SAPGUI.
Solution
ad 1 UNIX/Motif
Note 45490 describes possible errors resulting from an incorrect program installation under UNIX/Motif (up to Release 4.6A).
ad 2 Termination when using
The above-mentioned notes may contain options for solving individual problems.However, you usually have to replace the program with an corrected version.You can do this either by downloading a patch from sapservX or by installing a more current SAPGUI.The patch is mentioned in the respective note.
ad 3 Installation
You either need to reinstall the SAPGUI or manually copy the missing file into the SAPGUI directory.In both cases you should make sure beforehand that a Graphical Layout Editor is no longer running.To do this you can either remove all processes gneux.exe from the process list by using a tool such as Task Manager (on WindowsNT) or exit the Graphical Layout Editor from the Screen Painter Transaction menu via Edit -> Cancel Graphical Screen Painter). Attention:For each session or system an individial Layout Editor process may exist so that, if need be, several processes should be cancelled.
ad 4 System link
Up to Release 3.0F:you can either delete the environment variable SAPGRAPH or copy all the files of the Graphical Layout Editor into the directory which is specified by SAPGRAPH.
As of Release 3.1G:you can use Transaction SM59 to check the RFC destination EU_SCRP_WN32 (expand the TCP/IP connections, select destination EU_SCRP_WN32).If the destination is missing, then you should create it with the following settings:
- Connection type "T" (start of an external program via ...)
- Activation type "Start"
- Start on "Front-end workstation"
- Front-end workstation program "gnetx.exe" (caution! NOT gneux.exe)
- Description (optional) "Graph. Screen Painter (Windows32)
Start Program gneux.exe using the gnetx.exe starter program."
If you want to start the program from a different directory than the SAPGUI standard directory, then replace the default value under Frontend work station by the complete path name for program gnetx.exe.Transaction SM59 also allows you to check the RFC connection via the pushbutton "Test connection").In this case the system attempts to localize and start the program gnetx.exe.If there are errors, a message is displayed regarding the possible causes (for example, gateway problem, timeout problem or the like).Note 101971 provides a detailed explanation of the problems involved with an RFC connection set-up.As the Graphical Screen Painter requires a functional RFC connection as of Release 3.1G, contact the System Administrator or create an message on the topic Middleware (BC-MID-RFC) if you encounter RFC problems.
If the program gnetx.exe can be found and started, the banner dialog box with logo, release data and version number is displayed briefly.As the Layout Editor itself is not started, the error cause must be in the installation of the Layout Editor program gneux.exe if the connection test was successful.
Release 4.5A to 4.6B: Use with Releases <3.1G>.
The Graphical Layout Editor is downward-compatible as regards the system connection, that is, an RFC-based Layout Editor for example from Release 4.6C can also be used on a non-RFC-based Screen Painter, for example of Release 3.0F.However, the releases mentioned above have a program error which causes a crash due to memory violation in the start phase of the program.Note 197328 describes the solution by installation of the corrected program version.
Important: Trace file dev_euspNNN!
If none of the diagnosis steps leads to the cause of the error and to the solution of the problem via the corresponding note, then you should add the contents of the trace files dev_euspNNN (NNN = process number) to the message for SAP, if possible.You can find this file in the current directory of the SAP System, for example under Windows NT in C:\Winnt\Profiles\<user>\SAPworkdir.If several such trace files can be found there, make sure that you use the file which matches the termination time with respect to date and time of creation.In most cases the ERROR message in the last lines of this trace file provides an important note on the cause of the error.
Source code corrections
Symptom
The graphic layout editor of the Screen Painter cannot be started (RFC version).
Other terms
() EUNOTE, EUSCREENPAINTER
Reason and Prerequisites
This is generally caused by the fact that the RFC connection between the frontend graphics layout editor and the calling screen painter program at the backend cannot be set up.
Possibility 1: Route permission denied
In the trace file dev_eusp<Process Id> of the graphics layout editor you find the entry "ERROR in RFCMgr_accept: not accepted", and in the RFC trace file dev_rfc.trc you have an entry of the form "ERROR route permission denied (<Front-Id> to <BackId>,<Service>)".
If there is a firewall between frontend computer and application
server, you need to decide whether the port for the RFC of the graphical layout editor can be released here (see Solution 1 below).
In case no firewall exists between the frontend computer and the application server, in its route permission table, the SAProuter contains either no entry for the frontend computer, on which the graphics layout editor is started, or the entry says that the link is saved by a password.Since the connection is denied, the graphics editor processes exits again, and the screen painter switches to the alphanumeric layout editor.
Possibility 2: Service 'sapgw<ServiceId>' unknown
In the trace file dev_eusp<ProzessId> of the graphics layout editor you have the entry "ERROR in RFCMgr_accept: not accepted", and in the RFC trace file dev_rfc.trc you have an entry of the form "ERROR service 'sapgw<ServiceId>' unknown".
The service sapgw<ServiceId> (for example, sapgw00) is not known on one of the computers participating in the RFC communication because the corresponding entry is missing in its service file. The affected computer can be the frontend computer or the gateway computer.
Possibility 3: The system parameter gw/cpic_timeout value is too low
This system parameter determines how many seconds the gateway is waiting for the RFC connection to be set up.In case of a high network load, the default value of 20 seconds is too small with the result that the connection cannot be created on time.Here the graphics layout editor process also exits with the trace file entry "ERROR in RFCMgr_accept: not accepted".
Possibility 4: System parameter abap/no_sapgui_rfc set
The profile parameter abap/no_sapgui_rfc of the system is set (that is, it has a value not equal to space or 0).This prevents the program of the graphics layout editor from being started with RFC at the frontend.
Possibility 5: Unnecessary authorization check
The error message "No RFC authorization for user xxxxxx" is generated although the check of the RFC authorization was deactivated by profile parameter auth/rfc_authority_check (value = space or 0). The problem is caused by a program error, that ignores the value of the profile parameter let during the call of the RFC authorization check (see Note 93254). This error can occur as of Release 4.5.
Solution
ad 1) If a Firewall is installed between frontend computer and the application server, you need to decide whether the port for the RFC link of the graphical layout editor shall be released in the firewall. This is port 33nn, where nn is the 2-digit system number of the SAP application server. As of Release 3.1G, the graphical layout editor needs an RFC link for communication with the application server in addition to the already existing linkof the SAP GUIs. Such a second link is not allowed by the firewall in general because it would contradict the security concept (password protection, logging of the connection).
If no firewall exists, you should check whether the frontend computer can be added to the route permission table or whether the password option can be removed from out of the available entry.
For details refer to chapter 4.4 of the attached Note 30289.
ad 2) Include service sapgw<ServiceId> in the service file.
Refer to Note 52959 for details.
ad 3) Increase value for system parameter gw/cpic_timeout. 60 seconds should be sufficent as a timeout limit.
ad 4) Set the system parameter abap/no_sapgui_rfc to space or 0
Start the application server so that the new parameter value comes into effect.
ad 5) Import the Support Package specified in the attachment for the release in question or implement the advance correction in the source code as described in the attached correction instructions.
As a workaround, assign RFC authorizations as described in Note 93254. -
Hi Gurus,
I am soon going to start testing on an SAP upgrade project. Whats the best way to get myself prepared for the same? I am currently studying the client's Buiness processes, however there are just too many docs and these are getting me confused. Also I am concerned that all this time studying the docs is not wasted. If you have been in a similar situation before, please let me know how do you go about it. testing will be Functional + integration.hi dave,
pls see the below matter i think it gives you a solution.
SAP R/3
Security Upgrades
1. overview
The purpose of this document is to provide additional information that could be helpful with SAP Security upgrades, especially pertaining to 4.6C.
This document is not aimed at replacing the SAP Authorizations Made Easy guidebooks procedures, but rather to complement these based on lessons learnt from previous upgrade projects.
It is focused mainly on upgrades from 3.1x to 4.6x and covers the following:
· Evaluation of the Security Upgrade approaches;
· Gotchas to watch out for with SAPs SU25 utility;
· Transactions and authorizations that require special attention; and
· Helpful reports, transactions, hints and tables to know.
It is highly recommended that you review the chapter on upgrades in the Authorizations Made Easy guide before attempting the security upgrade.
See OSS note 39267 for information on obtaining the Guide, or visit SAPLabs website at: http://wwwtech.saplabs.com/guidebooks/
2. Security upgrade objectives, Process and approaches
2.1. Objectives
There are a couple of objectives for having to upgrade the SAP Security infrastructure:
· Converting manual profiles created via SU02 to activity groups, as SAP recommends the use of Profile Generator (PFCG) for the maintenance of profiles;
· Adding new transactions representing additional functionality to the applicable activity groups;
· Adding the replacement transactions that aim at substituting obsolete or old-version transactions, including the new Enjoy transactions;
· Adjusting the new authorization objects that SAP added for the new release; and
· Ensuring that all existing reports, transactions and authorizations still function as expected in the new release of SAP.
2.2. Overview of the Security upgrade process
Once the Development system has been upgraded to 4.6, the security team will need to perform the following steps as part of the Security Upgrade:
· Convert Report Trees to Area Menus;
· Review users (via SU01) to check for any new or changed fields on the user masters;
· Convert manual profiles created via SU02 to Activity Groups (See Approaches below);
· Compare SU24 customer settings to new SAP default settings (SU25 steps 2A-2C);
· Determine which new / replacement transactions have to be added to which activity groups (SU25 step 2D);
· Transport the newly-filled tables USOBT_C and USOBX_C that contain the SU24 settings youve made (SU25 step 3); and
· Remove user assignments to the manual profiles.
2.3. Approaches to convert manual profiles to Activity Groups:
2.3.1. Approach #1: SAPs standard utility SU25
SAP provides an utility for converting Manual Profiles to Activity Groups and to identify the new and replacement transactions that need to be added to each activity group.
You can access this utility by typing SU25 in the command box.
If you do decide to use SU25 Step 6 to convert the Manual profiles to activity groups, you will need to watch out for the following gotchas:
Naming convention (T_500yyyyy_previous name)
All activity groups created before SU25 is run, are renamed to T_500yyyyy_previous name.
See OSS note 156196 for additional information and procedures to rename the activity groups back to their original names using program ZPRGN_COPY_T_RY_ARGS. Carefully review information regarding the loss of links between profiles and user master records.
Transaction Ranges
Ranges of transactions are not always added correctly to the newly-created activity groups. Some of the transactions in the middle of the range are occasionally left off. E.g. you have a transaction range of VA01 VA04 for a specific manual profile. After SU25 conversion, the new Activity Group only contains VA01 and VA04. Transactions VA02 and VA03 were not added.
It is important that a complete download of table UST12 is done prior to running SU25. Once SU25 has been run, a new download of UST12 can be done to identify which transactions have been dropped off.
The missing transaction codes will need to be added manually to the relevant activity group via PFCG.
Missed new transactions
The output of one of the steps in SU25 is a list of the new replacement transactions (e.g. Enjoy transactions) that need to be added per activity group. E.g. transaction ME21N replaces ME21. The list will identify each activity group that has ME21 where ME21N needs to be added to.
In some cases SU25 does not identify all new transactions to be added.
2.3.2. Approach #2: Manual reconstruction of Profiles as Roles (Activity Groups)
An alternative approach to SU25 is to manually create an activity group for each manual profile that was created via SU02.
The advantage of this approach is that you wont have any missing transactions that were dropped off with the SU25 conversion.
3. Items requiring special attention
3.1. Authorizations
Several new authorization objects have been added with release 4.6. Care should be taken when adjusting authorizations carefully review all new defaults that were brought in. These are indicated by a Yellow or Red traffic light in PFCG.
It is highly recommended that you first check the previous settings where new defaults were brought in, before just accepting the new defaults. You can either use the existing 3.1x Production system or the UST12 and/or USOBT_C tables as reference.
3.2. * in S_TCODE
Its recommended that all activity groups containing an * in authorization object s_tcode are recreated via PFCG by selecting only those transactions required for that role. Also, if you did previously add transactions to an activity group by manipulating the s_tcode authorization entries, it is recommended that the transactions are pertinently selected/added on the Menu tab. The object s_tcode should be returned to its Standard status.
3.3. Report Trees
Report Trees need to be converted to Area Menus using transaction RTTREE_MIGRATION..
3.4. ABAP Query reports
Reports created by ABAP Query need to be added either to the activity group (Menu tab) or to an Area menu to ensure an authorization check on s_tcode level.
3.5. S_RFC
The use of an authorization object for Remote Function Calls (RFC) was introduced to provide authorization checks for BAPI calls, etc. Authorization object s_rfc provides access based on the Function Group (each RFC belongs to a Function Group). Due to the potential prevalent use of RFCs within the R/3 system, SAP has provided the ability to change the checks for this object via parameter auth/rfc_authority_check. It is possible to deactivate the checking of this object completely. However it is recommended to rather set the values as required, which makes testing even more important!
3.6. Custom tables and views
Custom views and tables that are customarily maintained via SM30, SM31,etc. will need to be added to an authorization group. This can be done via transaction SE54 or SUCU or by maintaining table TDDAT via SM31.
3.7. User menus versus SAP menu
A decision needs to be made once the first system has been upgrade to 4.6x as to whether the user menus or the SAP menu, or both are to be used.
Most users find the new user menus confusing and unfamiliar due to duplication of transactions, etc. (if a user has more than one activity group and the same transaction appears in several, the transaction will appear multiple times). The majority of upgrades from my experience have opted to use a modified copy of the SAP menu by adding their own area menus (converted report trees).
3.8. Re-linking of user master records to profiles
If you do not maintain the user masters in the same client as the activity groups, you will need to establish a strategy for re-linking the users in the QA and Productive environments when transporting the activity groups as part of the upgrade cutover. This might also be necessary depending on whether you decided to rename the Activity groups per OSS note 156196.
Remember to thoroughly test and document all procedures and CATT scripts prior to the Production cutover.
3.9. Dual-maintenance
With most current upgrades, the upgrade process will be tested on a separate environment set aside from the existing landscape. In a lot of cases a dual-landscape will be implemented where the existing landscape is complemented with an additional 4.6x test client(s). The new 4.6x clients usually become part of the permanent landscape once the Production system has been cut over and all changes are then sourced from these new Development and/or QA systems.
It is imperative that all interim security-related changes are applied to both sets of systems to ensure that the new 4.6x development source system is current with all changes that were made as part of Production support in the old version landscape. If not, you will have changes that were taken to Production when it was still on the older release, but are now missing after the switch is made to the 4.6x systems.
It is thus advisable to keep changes during the upgrade project to a minimum.
3.10. Transport of activity groups
Changes to activity groups are not automatically recorded in 4.6x. When an activity group needs to be transported, it needs to be explicitly assigned to a change request via PFCG.
SAP recommends that you first complete all the changes to an activity group, before you assign it to a transport request. Once youve assigned the activity group to a request, do not make any further changes to it.
You can also do a mass transport of activity groups via PFCG > Environment > Mass Transport.
If you want to transport the deletion of an activity group, you first have to assign the activity group to a transport request before performing the deletion via PFCG.
3.11. Client copies
The profiles used for creating client copies have been changed, especially profile SAP_USER from 4.5 onwards. Activity groups are seen as customizing and the SAP_USER profile copies both user masters and activity groups.
Its recommended that the client copy profiles are carefully reviewed before the copy is performed.
See OSS note 24853 for additional information on client copies.
3.12. SU24
Changes to check indicators that were made via SU24 might have to be redone as part of the upgrade. Ensure that any resulting transport requests are noted and included in the detailed cutover plan.
Check indicator changes done via SU24 will need to be applied for any new and replacement transactions.
3.13. Composite Activity Groups
Composite activity groups can be built in release 4.6x using individual activity groups. A composite activity group does not contain any authorizations, but is merely a collection of individual activity groups.
3.14. Central User Administration
Central User Administration (CUA) simplifies user administration, allowing security administrators to maintain users in a single central client only. The user masters are then distributed to other clients using ALE. It is recommended that CUA is implemented post-upgrade and once the systems have been stabilized. Carefully review OSS notes and the impact on the existing landscape, client copy procedures, etc. prior to implementing CUA. It is recommended that the upgrade is kept as simple as possible there are going to be plenty of opportunities to test your problem-solving skills without complicating the setup with new utilities!
See Authorizations Made Easy guide for information on setting up CUA.
See OSS notes 333441 and 159885 for additional information.
4. additional tips
4.1. OSS and Release Notes
Review all security-related OSS and Release notes related to upgrades and to the release youll be upgrading to, prior to the upgrade. Its useful to review these before you define your workplan, in case you have to cater for any unforeseen issues or changes.
4.2. Workplan
Given the amount of work and number of steps involved in the security upgrade, it is recommended that a detailed Workplan is defined at the startup of the upgrade project. Key milestones from the security workplan should be integrated and tracked as part of the overall Upgrade Plan.
Clear ownership of activities, including conversion of Report Trees, needs to be established. This function is often perform by the Development team.
4.3. Standards and Procedures
Naming conventions and standard procedures should be established before the manual profiles are reconstructed as activity groups. Each team member should know how the new activity groups should be named to ensure consistency. Other standard practices for the construction of the activity groups should include:
· Transactions are added via the Menu tab and not by manipulating s_tcode.
· Ideally, no end users should have access to SE38, SA38, SE16 nor SE17.
Remember to keep Internal Audit involved where decisions need to be made regarding the segregation of job functions or changes to current authorizations are requested or brought in with new authorization objects / defaults.
4.4. Testing
4.4.1. Resources for testing
Enough resources should be allocated to the security upgrade process as each activity group and profile will require work to some degree or the other. It is important that key users and functional resources are involved in testing the activity groups and that this effort is catered for in the Upgrade Project plan. Clear ownership of each activity group should be established not only for testing purposes, but also for ongoing support and approval of changes. Ideally, the ownership and approval of changes should reside with different resources (i.e. the person requesting the addition of a transaction or authorization should not be the same person responsible for approving the request).
4.4.2. Test Plan
The security team should also establish testing objectives (whether each transaction being used in Production should be tested, whether each activity group should be tested with a representative ID, etc.).
A detailed test plan should then be established based on the approach, to ensure each person responsible for testing knows what s/he should be testing, what the objective(s) of the test is and how to report the status of each test. Both positive (user can do his/her job functions) and negative (user cant perform any unauthorized functions) testing should be performed.
The Reverse Business Engineering (RBE) tool is very useful in identifying which transactions are actually being using in Production. This can assist with focusing on which transactions to test.
The importance of testing all used transactions individually and as part of role-testing cannot be stressed enough. TEST,TEST,TEST!
Every menu option, button, icon and available functions for all critical transactions need to be checked and tested. There are some instances where icons are grayed out or dont even appear for certain users, due to limited authorizations. The only way these type of issues can be identified, is through thorough testing.
4.5. Issue Management (tracking and resolution)
Due to the number of users potentially impacted by issues / changes to a single activity group, a perception can quickly be created that the security upgrade was unsuccessful or the cause of many post GoLive issues.
It is therefore recommended that an issues log is established to track and ensure resolution of issues. The log should ideally also contain a description of the resolution, to aid with similar problems on other activity groups.
This log will be helpful during the entire upgrade process, especially where more than one resource is working the same set of activity groups, so set it up at the beginning of upgrade project! You can also use this for a lessons learnt document for the next upgrade.
4.6. Status reporting
The security upgrade forms an integral part of the overall upgrade given the sensitivity and frustration security issues could cause. It is important that key milestones for the security upgrade are tracked and reported on to ensure a smooth and on-time cutover.
4.7. Detailed cutover plan
The detailed cutover plan differs from the overall security workplan, in that the detailed plan outlines the exact steps to be taken during each systems upgrade itself. This should include:
· Transport request numbers,
· Download of security tables prior to the upgrade, especially UST12, USOBT_C and USOBX_C,
· A backup and restore plan, (e.g. temporary group of activity groups for critical functions),
· The relinking of user master records, with details on any CATT scripts, etc. that might be used,
· User comparison, etc.
The security team needs to ensure that enough time is allocated for each action item and that this time is built into the overall cutover plan. The project manager is usually expected to give an indication to end users and key stakeholders as to when the Productive system will be unavailable during its cutover to the new release. This downtime should thus incorporate time required to perform user master comparisons, unlocking of IDs and all other action items.
4.8. Project team access
The SAP_NEW profile can temporarily be assigned to project team members to provide interim access to the new authorization objects. This provides the security team the opportunity to convert and adjust the IS teams activity groups. It also eliminates frustration on the functional teams side when configuring and testing new transactions, etc.
4.9. Training and new functionality
Some support team members (e.g. Help Desk members responsible for reset of user passwords, etc.) might require training and/or documentation on the changed screens of SU01, etc.
It is recommended that a basic Navigation & Settings training module is created for all SAP users and should cover the use of Favorites, etc.
The security team should also review Profile Generator in detail, as several new functions have been added (e.g. download/upload of activity groups, etc.). Remember to review all the different icons, menu options and settings on the authorizations tab, etc.
Lastly, if your company / project does use HR as related to security (activity groups and users assigned to positions / jobs), ensure that you become acquainted with the new enjoy transactions, e.g. PPOMW.
4.10. SU53
A new function with SU53 is the ability to display another users SU53 results. (Click on the other user button and enter the persons SAP ID).
4.11. Post Go-live
Remember to establish a support roster, including after hours for critical batch processes, to ensure security-related issues are resolved in a timely fashion.
Dumps should be checked regularly (Objects s_rfc and s_c_funct like making appearances in dumps) for any authorizations-related issues. Transaction ST22 can be used to review dumps for that day and the previous day.
Avoid transporting activity groups at peak times, as the generation of activity groups can cause momentarily loss of authorizations. Its recommended that a roster for activity group transport and mass user comparison be reviewed with the project manager prior to the upgrade. Exceptions should be handled on an individual basis and the potential impact identified, based on number and type of users, batch jobs in progress, etc.
And, dont forget to keep on tracking all issues and documenting the resolutions for future reference.
5. helpful reports, transactions and tables
5.1. Reports and Programs
· RTTREE_MIGRATION: Conversion of Report Trees to Area Menus
· PFCG_TIME_DEPENDENCY: user master comparison (background)
· RSUSR* reports (use SE38 and do a possible-values list for RSUSR* to see all available security reports), including:
v RSUSR002 display users according to complex search criteria
v RSUSR010 Transactions that can be executed by users, with Profile or Authorization
v RSUSR070 Activity groups by complex search criteria
v RSUSR100 Changes made to user masters
v RSUSR101 Changes made to Profiles
v RSUSR102 Changes made to Authorizations
v RSUSR200 Users according to logon date and password change, locked users.
5.2. Transactions
· SUIM : various handy reports
· SU10 : Mass user changes
· PFCG: Profile Generator
· PFUD: User master comparison
· SU01: User master maintenance
· ST01: System trace
· ST22: ABAP dumps
· SUCU / SE54: Maintain authorization groups for tables / views
· PPOMW: Enjoy transaction to maintain the HR organizational plan
· PO10: Expert maintenance of Organizational Units and related relationships
· PO13: Expert maintenance of Positions and related relationships
· STAT: System statistics, including which tcodes are being used by which users
5.3. Tables
Table
Use
UST12
Authorizations and Tcodes per Profile
UST04
Assignment of users to Profiles
AGR_USERS
Assignment of roles to users
USOBT_C
Authorizations associated with a transaction
USR02
Last logon date, locked IDs
AGR_TCODES
Assignment of roles to Tcodes (4.6 tcodes)
USH02
Change history for users (e.g. who last changed users via SU01)
USH04
Display history of who made changes to which User Ids
USR40
Non-permitted passwords
i am also providing the url of sap upgrade guide. pls check it out ok.
www.thespot4sap.com/upgrade_guide_v2.pdf
reward me points if it helps you
thanks
karthik -
Auth/object_disabling_active parameter
Hi,
can somebody tell me details about this parameter?
What is the recommended value for this and why?
What is the impact of different values for this ?
Thanks,
Chittacheck the details from transaction RZ11
Parameter : auth/object_disabling_active
Short description : Value 'N' prohibits disabling of auth. objects
Parameter description :
Authorization objects can be deactivated with the transaction
AUTH_SWITCH_OBJECTS, if this parameter is set to "Y" or is not set.
If it is set to "N", it cannot be deactivated.
Work area : Auth
Unit :
Default : Y
Who is permitted to make changes: The customer
Limitations for operating systems: None
Limitations for database systems: None
Other parameters affected or dependent: None
Valid entries, formats, areas : Y, N
Regards
Raja -
Creating a Perl script for SAP sytem profile parameter
Hi,
I need to create a perl script for all th eprofile parameter to check as a security directive ,so that whenever the system is started it checks for this profile parameter.
As per my company sap directive ,these are the profile parameter i need to set.
Can anyone let me know how to write the scripts.
login/min_password_lng Minimum password length for user password 320 Min.
8
login/password_expiration_t
ime
Number of days between forced password change. 0 Max.
35
login/fails_to_session_end Number of invalid logon attempts allowed before the
SAP GUI is disconnected.
3 Max.
3
login/fails_to_user_lock Number of invalid logon attempts before the user id is
automatically locked by the system.
12 Max.
6
rdisp/gui_auto_logout Time, in seconds, that SAPGUI is automatically disconnected
because of in-activity.
0 60-
7200
21
auth/test_mode Jump into report RSUSR400 at every authority check N N22
auth/system_access_check_
off
Switch off automatic authority check for special ABAP
commands
0 0
auth/no_check_in_some_ca
ses
Special authorization checks turned off by customer.
Enabling of Profile Generator
N/Y23 Y
login/ext_security Security access controlled by external software. N N24
auth/rfc_authority_check Permission for remote function calls from within ABAP
programs
0 1
login/failed_user_auto_unlo
ck
Enable system function for automatic unlock of users
at midnight. (0 = locks remain)
0 0
login/
no_automatic_user_sapstar
(as of 3.1h)
login/no_automatic_user_sa
p* (prior to 3.1h)
Disable ability to logon as SAP* with PASS as password
when SAP* deleted.
0 125,26
auth/tcodes_not_checked TCode checking for SU53 & SU56 analysis disabled (empty
"SU5
3
Regards,
Chetan.Here's a simple perl script that should help you get what it is you're looking for - you can add all the parameters you want to search for, I just took a few of them:
#!/usr/bin/perl -w
use strict;
use sapnwrfc;
SAPNW::Rfc->load_config;
my $rfc = SAPNW::Rfc->rfc_connect;
my @parms = ( "login/min_password_lng",
"login/password_expiration_time",
"login/fails_to_session_end",
"login/fails_to_user_lock" );
for my $x (0 .. $#parms) {
my $rcc = $rfc->function_lookup("SXPG_PROFILE_PARAMETER_GET");
my $slr = $rcc->create_function_call;
$slr->PARAMETER_NAME($parms[$x]);
$slr->invoke;
print "Value for $parms[$x] is: ".$slr->PARAMETER_VALUE."\n";
$rfc->disconnect();
And running it, you'll get:
[dhull@397 scripts]$ ./read-profile.pl
Value for login/min_password_lng is: 7
Value for login/password_expiration_time is: 90
Value for login/fails_to_session_end is: 3
Value for login/fails_to_user_lock is: 6
[dhull@397 scripts]$
If you need to get your perl environment read to make RFC calls to your SAP system, check my series of blogs on how to do so here:
https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/u/251752730
Cheers,
David. -
Transport control program tp could not be started
Hi,
While importing a request to Quality Server , transport terminates with an error "Transport control program tp could not be started" RFC error.
Function TMS_TP_IMPORT
Message TP_CALL_FAILED
Tp output says "This is tp version 340.16.37 (release 640)
Warning: Parameter DBLIBPATH is no longer used.
Warning: Parameter DBSWPATH is no longer used."
340.16.37.kernel release 640,patch number 193.
RSTPTEST was successful .
Changed auth/rfc_authority_check to value '0' in the profile and restarted.
user id provided in RFC connection is TMSADM and the user is
having "S_RFC" authorization object.
This error started after putting the oracle patchset 9.2.0.8.
SAP version 4.7, Oracle 9.2.0.8, on AIX 5.2
It will be appreciable if any one can help me out in this issue.
Regards,
Saji KumarHi,
provide result for
tcode - stms_import -> import queue -> check -> transport tool
also execute RSTPTEST report on QAS,
RFC error indicate problem in RFC connection , check it using SM59
regards,
kaushal -
RFC error when sending logon data
Hi;
We cannot configure the STMS of our development system. When we try to
configure it, system gives an error message: Errors during distribution
of tp configuration; TMS Alert Viewers tells us
RFC_COMMUNICATION_FAILURE: RFC communications error with
system/destination TMSADM-FKT.DOMAIN_FKT RFC error when sending logon
data and READ_PROFILE_FAILED:File
erptest\sapmnt\trans\bin\TPPARAM
could not be opened for reading (No such file or directory).
Is there any advise for solution?
Best regards
Noyan
PS: Please find the profiles below:
START:
#.* Start profile START_DVEBMGS00_erptest *
#.* Version = 000006 *
#.* Generated by user = BASIS *
#.* Generated on = 30.12.2010 , 15:40:55 *
generated by R3SETUP
SAPSYSTEMNAME = FKT
INSTANCE_NAME = DVEBMGS00
SAPSYSTEM = 00
SAPGLOBALHOST = erptest
DIR_PROFILE = D:\usr\sap\FKT\SYS\profile
start database
#_DB = strdbs.cmd
#Start_Program_02 = immediate $(DIR_EXECUTABLE)\$(_DB) FKT
start message server
#_MS = msg_server.exe
Start_Program_03 = local $(DIR_EXECUTABLE)\$(_MS) pf=$(DIR_PROFILE)\FKT_DVEBMGS00_erptest
Start IGS
Start_Program_05 = local $(DIR_EXECUTABLE)$(DIR_SEP)igswd$(FT_EXE) -mode=profile pf=$(DIR_PROFILE)$(DIR_SEP)FKT_DVEBMGS00_erptest
start application server
#_DW = disp+work.exe
#Start_Program_04 = local $(DIR_EXECUTABLE)\$(_DW) pf=$(DIR_PROFILE)\FKT_DVEBMGS
General parameters for starting the system
#parameter created by: BASIS 24.12.2007 23:53:27
#SAPSYSTEM = 00
#parameter created by: BASIS 24.12.2007 23:53:27
#SAPSYSTEMNAME = FKT
#parameter created by: BASIS 24.12.2007 23:53:27
#INSTANCE_NAME = DVEBMGS00
#parameter created by: BASIS 24.12.2007 23:53:27
DIR_PROFILE = D:\usr\sap\FKT\SYS\profile
#parameter created by: BASIS 24.12.2007 23:53:27
#SAPGLOBALHOST = erptest
Start database
#parameter created by: BASIS 24.12.2007 23:53:27
_DB = strdbs.cmd
#parameter created by: BASIS 24.12.2007 23:53:27
Start_Program_01 = immediate $(DIR_EXECUTABLE)\$(_DB) $(SAPSYSTEMNAME)
Start message server
#parameter created by: BASIS 24.12.2007 23:53:27
MS = msgserver.exe
#parameter created by: BASIS 24.12.2007 23:53:27
Start_Program_02 = local $(DIR_EXECUTABLE)\$(_MS) pf=$(DIR_PROFILE)\FKT_DVEBMGS00_erptest
Start applications server
#parameter created by: BASIS 24.12.2007 23:53:27
_DW = disp+work.exe
#parameter created by: BASIS 24.12.2007 23:53:27
Start_Program_03 = local $(DIR_EXECUTABLE)\$(_DW) pf=$(DIR_PROFILE)\FKT_DVEBMGS00_erptest
DEFAULT:
SAPDBHOST = ERPTEST
dbms/type = mss
dbs/mss/server = ERPTEST
dbs/mss/dbname = FKT
dbs/mss/schema = fkt
SAPSYSTEMNAME = FKT
SAPGLOBALHOST = erptest
SAPFQDN = tr.delta.is
SAPLOCALHOSTFULL = $(SAPLOCALHOST).$(SAPFQDN)
SAPDBHOST = erptest
SAPTRANSHOST = erptest
DIR_TRANS =
$(SAPTRANSHOST)\sapmnt\trans
#DIR_TRANS = D:\usr\sap\trans
DIR_PROFILE = D:\usr\sap\FKT\SYS\profile
SAP Message Server for ABAP
rdisp/mshost = erptest
rdisp/sna_gateway = erptest
rdisp/sna_gw_service = sapgw00
rdisp/vbname = erptest_FKT_00
rdisp/enqname = erptest_FKT_00
rdisp/btcname = erptest_FKT_00
rdisp/msserv = sapmsFKT
rdisp/msserv_internal = 3900
rdisp/bufrefmode = sendoff,exeauto
login/system_client = 200
#GUVENLIK PARAMETRELERI
login/password_expiration_time = 90
login/min_password_lng = 6
#parameter created by: BASIS 25.03.2004 08:41:25
rdisp/gui_auto_logout = 10800
#parameter created by: BASIS 25.03.2004 08:37:47
#old_value: 3 changed: BASIS 25.03.2004 08:42:38
login/fails_to_user_lock = 6
#validasyon geregi, g#venligi artirma ama#i - check active but no check for SRF
#parameter created by: BASIS 16.06.2007 17:35:41
#old_value: 2
#changed: BASIS 14.05.2008 15:24:55
auth/rfc_authority_check = 1
#otomatik unlocki iptal eder
#parameter created by: BASIS 10.11.2006 17:47:15
login/failed_user_auto_unlock = 0
#AUDIT PARAMETRELER?
#old_value: changed: BASIS 20.04.2005 17:13:37
rsau/max_diskspace/per_day = 1996800000
#old_value: 1000000000 changed: BASIS 20.04.2005 17:17:01
#old_value: 0 changed: BASIS 20.04.2005 17:19:12
rsau/max_diskspace/local = 2048000000
#old_value: 2000000000 changed: BASIS 28.03.2005 23:17:11
#old_value: 2 changed: BASIS 29.03.2005 12:09:14
#old_value: 0 changed: BASIS 20.04.2005 17:13:37
rsau/max_diskspace/per_file = 665600000
rsau/enable = 1
rsau/local/file = D:\usr\sap\FKT\DVEBMGS00\log\++++++++######..AUD
rsau/selection_slots = 12
#rec/client = ALL
DIR_AUDIT = D:\usr\sap\FKT\DVEBMGS00\log
FN_AUDIT = ++++++++######..AUD
#DIL PARAMETRELERI
#Turkish codepage settings
abap/import_char_conversion = 0
install/codepage/db/non_transp = 1610
install/codepage/db/transp = 1610
zcsa/installed_languages = DET
#zcsa/system_language = E
zcsa/system_language = T
zcsa/second_language = E
install/codepage/appl_server = 1610
#OS dependent
abap/locale_ctype = Turkish_turkey.28599
#DIR_PUT = D:\usr\sap\FKQ\upg\abap
*** UPGRADE EXTENSIONS (RELEASE "701") ***
#rdisp/msserv_internal = 3900
#system/type = ABAP
INSTANCE:
SAPSYSTEMNAME = FKT
SAPGLOBALHOST = erptest
SAPSYSTEM = 00
INSTANCE_NAME = DVEBMGS00
DIR_CT_RUN = $(DIR_EXE_ROOT)\$(OS_UNICODE)\NTAMD64
DIR_EXECUTABLE = $(DIR_INSTANCE)\exe
icm/server_port_0 = PROT=HTTP,PORT=80$$
SAP Message Server parameters are set in the DEFAULT.PFL
ms/server_port_0 = PROT=HTTP,PORT=81$$
#rdisp/wp_no_dia = 10
#rdisp/wp_no_btc = 3
#rdisp/wp_no_enq = 1
#rdisp/wp_no_vb = 1
#rdisp/wp_no_vb2 = 1
#disp/wp_no_spo = 1
rdisp/wp_no_dia = 12
rdisp/wp_no_vb = 3
rdisp/wp_no_vb2 = 0
rdisp/wp_no_enq = 1
rdisp/wp_no_btc = 3
rdisp/wp_no_spo = 1
#PERFORMANS PARAMETRELERI
#parameter created by: SAP* 08.08.2001 10:30:18
abap/fieldexit = yes
#parameter created by: ALPER 13.10.2000 18:24:16
install/collate/active = 1
rdisp/max_wprun_time = 25000
MEMORY_NO_MORE_PAGING dump nedeniyle
#parameter created by: BASIS 27.12.2006 17:00:22
rdisp/PG_MAXFS = 262144
abap/heap_area_nondia = 2000000000
rdisp/PG_SHM = 16384
rdisp/ROLL_SHM = 32768
#'STORAGE_PARAMETERS_WRONG_SET' or 'TSV_TNEW_PAGE_ALLOC_FAILED'
#Note 552209 - Maximum memory utilization for processes on NT/Win2000
#parameter created by: BASIS 30.10.2007 10:57:24
#abap/heap_area_nondia = 50000
#parameter created by: BASIS 30.10.2007 10:58:54
#rdisp/PG_SHM = 0
#parameter created by: BASIS 30.10.2007 10:58:27
#rdisp/ROLL_SHM = 625
#EWA report 12.2007
#parameter created by: BASIS 03.01.2008 19:49:57
dbs/mss/stats_on = 1
#EWA report 12.2007
#parameter created by: BASIS 03.01.2008 19:49:33
dbs/oledb/stats_on = 1
#EWA report 12.2007
#parameter created by: BASIS 03.01.2008 19:48:23
dbs/oledb/add_procs = 8
#EWA report 12.2007
#parameter created by: BASIS 03.01.2008 19:47:29
rsdb/esm/max_objects = 2000
#EWA report 12.2007
#parameter created by: BASIS 03.01.2008 19:47:03
rsdb/otr/buffersize_kb = 4096
#EWA report 12.2007
#parameter created by: BASIS 03.01.2008 19:46:21
rsdb/esm/buffersize_kb = 4096
Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:18:14
ztta/parameter_area = 16000
Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:16:43
enque/table_size = 10000
Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:16:20
gw/max_sys = 2000
#Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:16:01
gw/max_overflow_size = 25000000
#Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:15:19
rdisp/max_comm_entries = 2000
Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:14:48
rdisp/tm_max_no = 2000
Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:14:20
gw/max_conn = 2000
Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:13:42
rdisp/max_arq = 2000
#Eyl#l 2006 EWA raporu
#parameter created by: BASIS 24.11.2006 13:12:57
ztta/roll_area = 3500000
#parameter created by: BASIS 18.05.2005 09:20:25
#old_value: 90 changed: BASIS 18.05.2005 09:22:25
rdisp/max_hold_time = 300
#parameter created by: BASIS 20.08.2003 12:10:20
#old_value: 6144
#changed: BASIS 03.01.2008 19:42:10
rsdb/obj/buffersize = 20000
#parameter created by: BASIS 20.08.2003 12:09:48
#old_value: 6000
#changed: BASIS 03.01.2008 19:42:59
rsdb/obj/max_objects = 20000
note 103747
#parameter created by: BASIS 08.07.2003 20:42:11
#old_value: 250000
#changed: BASIS 30.10.2007 10:56:17
#abap/buffersize = 100000
#changed: BASIS 03.01.2008 19:40:36
#abap/buffersize = 300000
#by: BASIS 12.06.2008
abap/buffersize = 400000
note 103747
#parameter created by: BASIS 08.07.2003 20:41:32
#zcsa/presentation_buffer_area = 20000000
#64 bite gectikten sonra by: BASIS 10.06.2008
zcsa/presentation_buffer_area = 30000768
note 103747
#parameter created by: BASIS 08.07.2003 20:40:55
rsdb/ntab/ftabsize = 30000
note 103747
#parameter created by: BASIS 08.07.2003 20:40:12
rtbb/max_tables = 500
note 103747
#parameter created by: BASIS 08.07.2003 20:39:15
#old_value: 20000
#changed: BASIS 03.01.2008 19:41:29
#rtbb/buffer_length = 30000
#64 bite gectikten sonra by: BASIS 10.06.2008
rtbb/buffer_length = 50000
note 103747
#parameter created by: BASIS 08.07.2003 20:38:26
zcsa/db_max_buftab = 10000
note 103747
#parameter created by: BASIS 08.07.2003 20:37:37
#zcsa/table_buffer_area = 50000000
#64 bite gectikten sonra by: BASIS 10.06.2008
#zcsa/table_buffer_area = 89000000
by: BASIS 12.06.08
zcsa/table_buffer_area = 99000000
note 103747
#parameter created by: BASIS 08.07.2003 20:36:54
sap/bufdir_entries = 10000
note 103747
#parameter created by: BASIS 08.07.2003 20:36:12
rsdb/cua/buffersize = 8000
#note 103747
#parameter created by: BASIS 08.07.2003 20:34:46
#old_value: 5000 changed: BASIS 08.07.2003 20:35:39
rsdb/ntab/sntabsize = 5500
#parameter created by: BASIS 08.07.2003 20:33:56
#note 103747
#old_value: 10607 changed: BASIS 08.07.2003 20:34:58
#old_value: 10000 changed: BASIS 08.07.2003 20:35:39
rsdb/ntab/irbdsize = 11000
#note 103747
#parameter created by: BASIS 08.07.2003 20:32:18
rsdb/ntab/entrycount = 40000
#old_value: 2076 changed: BASIS 28.06.2005 19:36:21
#old_value: 5735 changed: BASIS 28.06.2005 19:40:01
PHYS_MEMSIZE = 4096
#64 bite gectikten sonra by: BASIS 10.06.2008
abap/heaplimit = 40894464
abap/heap_area_total = 2000683008
ztta/roll_extension = 2000683008
em/blocksize_KB = 4096
*** UPGRADE EXTENSIONS (RELEASE "701") ***
#rdisp/elem_per_queue = 2000
#auth/auth_number_in_userbuffer = 9000
#snc/enable = 0Hi Srikishan;
You are right. The problem was releated with secstore. I found a SAP note ( Note 1532825 - Deleting SECSTORE entries during system export/system copy). I created the program which ise mentioned in the note and than run it. After that everything seems ok now.
Thanks for your help and interest
Best regards
Noyan -
New version of sapyto - SAP Penetration Testing Framework
Hello list,
I'm glad to let you know that a new version of sapyto, the SAP Penetration Testing Framework, is available.
You can download it by accessing the following link: http://www.cybsec.com/EN/research/sapyto.php
News in this version:
This version is mainly a complete re-design of sapyto's core and architecture to support future releases. Some of the new features now available are:
. Target configuration is now based on "connectors", which represent different ways to communicate with SAP services and components. This makes the
framework extensible to handle new types of connections to SAP platforms.
. Plugins are now divided in three categories:
. Discovery: Try to discover new targets from the configured/already-discovered ones.
. Audit: Perform some kind of vulnerability check over configured targets.
. Exploit: Are used as proofs of concept for discovered vulnerabilities.
. Exploit plugins now generate shells and/or sapytoAgent objects.
. New plugins!: User account bruteforcing, client enumeration, SAProuter assessment, and more...
. Plugin-developer interface drastically simplified and improved.
. New command switches to allow the configuration of targets/scripts/output independently.
. Installation process and general documentation improved.
. Many (many) bugs fixed. :P
Enjoy!
Cheers,
MarianoHi Mariano,
Thanks for the update.
We implemented secinfo restrictions 5 years ago, but used a rather complicated approach. We did some tests today (the "local" setting works okay so far) and will continue tomorrow.
We now use the HOST and USER-HOST set to "local" and let the application security deal with who-can-do-what and this works quite well; though we have encountered some external 3rd party server programs in some cases. It seems to be popular amongst the business folks and some of the products use the gateway monitor to comunicate with the SAP system to find out when it has completed processing.
I think this is a design error, but they of course think otherwise
What was interesting to note, was that we locked ourselves out of an unprotected system. We changed the gw/monitor from 2 to 1 in a test. This worked. But then the gwmon cannot be used to change it back to 2! To we tried RZ11, and experienced the same. So we changed it to 0 in a test, and then 1 was blocked as well. This appears to be implemented in the kernel, as even hobbling the application coding does not help. The parameter is only dynamic when decreasing the value and increasing the security.
We had to restart the whole system for the instance profile to take effect again. Rather noisy and a few developers could take an additional 10 minute coffee break as a result
We are testing this on 3 different releases with different config:
- 4.6C (46D)
- 6.40
- 7.00
The different config relates to:
- gw/sec_info
- gw/monitor
- auth/rfc_authority_check
Our intention behind this is to improve baseline security and harden some special systems further.
Cheers,
Julius -
We did a test in our sandbox erp system setting auth/rfc_authority_check=1.
No many users are missing specific rfc_names - SYST, etc.
I am curious how others use this parameter. Can I use an asterick *? IS that bad?
Seems everytime I add a specific rfc_name another pops up.Yes, you can do it that way. You will get to learn the system well...
Like in this case, SFW_COMMON is used for BC sets the Switch Framework. So see who is using SFW1 to SWF5 transactions (should be very few...) but there is also mention of parallel processing in some of the fucntions so chances are good that you will find it being an internally used remote call (within the same SID) so you do not need to give this access at your current config.
If you see an RFC failing, then please check ST22 as well to see whether it really dumped. It might also "just" be a config dependent "try" to see whether there is a connection, and if not then it proceeds locally.
I am sorry, but there is no easy medication for this tricky topic, but it will settle down after a few days and you have done it once or twice.
Cheers,
Julius
Edited by: Julius Bussche on Dec 23, 2009 3:56 PM
Switch Framework corrected.
Maybe you are looking for
-
I have 2 Ipod nanos, can i use the same apple id for both of them
I have 2 ipod nanos, 1 for my wife and mine. Can I use the same Apple ID for both so we can share the same music.
-
Can't Duplex print from Acrobat Pro 9.3.2 to Epson Artisan 800
I can not duplex Print from Acrobat Pro 9.3.2 to an Epson Artisan 800. I an running it from a MacBook Pro with OSX 10.6.3 I called Epson support and they could not help me. However they suggested that I try using Adobe Reader. Well that works OK if I
-
What devices do apple offer to transfer from my ios 7 iphone to my windows 8 computer
What does apple offer to transfer from my iphone to my windows 8 computer
-
I am trying to run query 0FIGL_VC1_Q0002 and it is giving me an error message: <i>Hierarchy INT 0000000 is not available for InfoObject Fincl Statement item(BRAIN 037)</i> I read through the "How to ..." paper that saids this report uses the hierarch
-
Diagnostics Agent installation - which SID for the systems in your landscap
Hi, I have a question in regads to installing the Diagnostics Agent on the systems in your landscape: ie. I want to install the Diagnostics Agent on all systems, and SAP suggests the system ID "DAA" as standard sid. From my experience there are no er