Summary
Symptom
For the planned execution of a service session at SAP, you want to provide SAP with statistical data on the use of the R/3 System. For this purpose you want to use the Service Data Control Center
(Transaction SDCC)
Operating instructions for SDCC are available in the attached document.
For questions regarding SDCCN please refer to note 763561.
Typical problems with SDCC are described below.
RFC Download, EarlyWatch, GoingLive Check, Service, EarlyWatch Alert,
SDCC, Data Collection, Data Transfer, Solution Manager
While using the Service Data Control Center (SDCC) for preparation of a pending EarlyWatch, GoingLive check session, or similar, you have encountered problems
************************************************************************
Do not import any transport files containing SDCC into systems with R/3 Releases 6* and higher, and/or systems where ST-PI has already been implemented.
************************************************************************
Below you will find a list of answers to question which are often raised in connection with the Service Data Control Center.
- 1. Q: Which version of the Service Data Control Center should I use, SDCC or SDCCN?
A: SDCCN is the newer version, this should be activated, especially in SAP Solution Manager systems where SDCCN controls the data collections for NON-ABAP satellite systems.
You can find information about SDCCN in SAP Note 763561. SDCC should only be used if it is not possible to activate SDCCN. SAP Note 792941 explains which formats have been used to deliver the Service Data Control Center for the different basis releases.
- 2. Basic use of SDCC
Q: How does one download a session with SDCC?
A: To use SDCC successfully it is important that the preparations described in note 91488 have been executed. the newest version of SDCC.
a) Call Transaction SDCC. You may be prompted with two pop-ups which ask if you would like to run a Service Preparation Check and/or if you would like to schedule the Automatic Session Manager (see below).
SERVICE PREPARATION CHECK:
This will take you to RTCCTOOL; a tool which lists which notes may yet have to be implemented to obtain the best possible data collection (see note 69455). Skipping this step by hitting the 'No' button means that you can perform a download, but you can not be sure that all necessary notes have been implemented. You may find errors in the data collection message log which could have been avoided.
ASM: This functionality should be scheduled as follows:
AUTOMATIC SESSION MANAGER (ASM)
The easiest method to use SDCC for service data collection and transfer is to use the Automatic Session Manager (ASM). The ASM is a periodic background job which you can trigger as follows:
I. Call Transaction SDCC.
II. In the menu, select 'Autom. Sess. Manager' -> Controls.
III. Enter the start date and time. Please choose a time when the load on the system is low. Please avoid times when other jobs start (i.e choose 00:17:47 rather than 00:00:00). Enter also the ASM period.
Please run the ASM daily.
IV. Select the pushbutton 'Schedule the ASM'.
Use of the ASM is strongly recommended.
EARLYWATCH ALERT SERVICE.
The ASM should be active for this service to be supported sufficiently. Please refer to note 91488 and note 207223 for further details on Earlywatch Alert.
a) A list display containing the session you would like to perform should appear after the first run of the ASM. If the session is not there, use 'Maintenance -> Refresh -> Session overview' to load it. If it still doesn't appear, check below for possible error sources. (questions 2 ff.).
b) If the session you plan to prepare has overall status 'green' it means that either the ASM or a member of the SAP Service Delivery Team have already completed the download for this session. If the status is not 'green' proceed by selecting the session in the list.
c) Then click on the button ' Download'. In the pop-up that appears you can choose to either schedule the download immediately, or at a time of your choice. This should only be necessary if the ASM is not set up.
d) If you have chosen to do the download immediately, a little red and white propeller icon appears while the download is running. You can follow it's progress in the main SDCC message log (Information -> Display message log ) or the session message log (double click on the relevant 'paper' icon at the right hand side of the session overview).
e) After the download is complete, the propeller icon disappears and is replaced (after a screen refresh) by a status light for data collection, data transfer and overall status. Mostly the transfer status is 'green'.The data collection status is occasionally yellow or red. This does not mean that data collection on customer systems has failed altogether (see below for details). In most cases the majority of data has been collected and may well be sufficient to perform a session.
- 3. SERVICE DEFINITION REFRESH
A regular service definition refresh from SAPNET R/3 Frontend (formerly OSS) is recommended for systems on basis release 4.x with ST-PI, and systems on basis release 6.x. You can refresh the service definitions by calling 'SDCC -> Maintenance -> Refresh -> Service Definitions'.You should check in the main message log if this was done successfully.
Systems on basis release 4.x without ST-PI MUST not refresh the Service Definitions from SAPNET R/3 Frontend after April 2004, as this will cause a shortdump.
Note 713674 must be implemented to prevent or repair this.
Also systems on basis release 3.x MUST not refresh the Service Definitions from SAPNET R/3 Frontend after April 2004, as this will cause a shortdump.SDCC then probably can not be used anymore.
Note 712757 must be implemented to prevent or repair this.
Whenever in the following text a service definition refresh is recommended please check the above text for the appropriate action.
- 4. Session data have not arrived in the Solution Manager system
Q: I have downloaded data from the satellite system without apparent errors, yet no download can be found in the Solution Manager.
A: Please ensure that you are using the current version of SDCC, at least version 2.3 (see note 91488). Please ensure also that the destination which connects the satellite system to the Solution Manager system is set up according to the instructions in the Solution Manager Installation Guide. Please ensure also that the user in this destination has been given the necessary authorisations (see the Installation Guide as well as note 546283).
- 5. Q: I have collected data for a session, but when I drill down in the download in the Service Data Viewer I get the error message No logical functional names found for current select'.
Has data been collected?
A: The Service Data Viewer in certain releases (see below) can not display download data if the server name contains an '_' (underscore). Please check the SDCC message log for this session. If there is no error message regarding the function module, the data was collected. In this case there should be no problem for the system were the session is performed. Another option is to rename the server, and collect data again when enough data has been accumulated under the new server name.
ST-PI 003D_4* , Support package 30 (610) and 20 (620 ) will contain the new Service Data Viewer 2.0, where this problem has been resolved.
The problem can occur in Release 4.X Solution Tools Plug-In (Version A, B and C), Release 610 (Basis Support Package 23-29), Release 620 (Basis Support Package 8-19)
- 6. During a data collection an error message or a warning for a particular
function module appears in the SDCC session log.
Q: Where can I find more information about this?
A: For more information about problems with function modules please refer to note 781680.
- 7. Q: You try to use SDCC but fail with a shortdump CONNE_ILLEGAL_TRANSPORT_VERS.
A: Systems on Basis Release 3.x and systems on Basis Release 4.x without ST-PI MUST NOT refresh their Service Definitions from SAPNET R/3 Frontend ( formerly OSS) anymore. If they do, the above shortdump occurs, SDCC can not be used anymore.
Systems on Basis Release 3.x :
Please advise the customer to implement note 712757
Systems on Basis Release 4.x without ST-PI
Please advise the customer to implement note 713674
- 8. Shortdump CONNE_IMPORT_WRONG_COMP_LENG (Error when attempting to IMPORT object "BDL_TABLE" )
Q: Either when trying to do a Service Definition Refresh (Maintenance -> Refresh -> Servive Definitions), when calling Transaction SDCC, or at the start of each ASM run I get a short dump.
A: Please get the newest version of SDCC implemented, at least version 2.3. The service definitions should be maintained as described in Question 2 of this note, (SERVICE DEFINITION REFRESH)
- 9. Faulty initialization of SDCC for R/3 release 4.6D
Q: When I run SDCC on a 4.6D system I get error messages like "RFC dest. CSD : does not exist" and plenty of type 'D' messages in the SDCC Message Log.
A: Please implement the newest version of SDCC, at least version 2.3.
- 10. "No valid service" in SDCC Message Log
Q: "No valid service" appears in SDCC Message Log during report BDLCOLL. Data collections fails because of this error.
A: It is likely that the service definition tables are not filled. Please ensure that the newest version of SDCC is implemented, at least version 2.3. The service definitions should be maintained as described in Question 2 of this note, (SERVICE DEFINITION REFRESH)
- 11. No authorization to perform a 'Service Definition Refresh' (R/3 >=4.6B)
Q: When I try to use 'Maintenance ->Refresh -> Service Definitions' I am prompted with the message ' You do not have customizing permission', and the refresh is not carried out.
A: Please note that Service Definitions may only be refreshed on systems with basis release 4.x with ST-PI, and basis release 6.x. For all other systems please switch off the service definition refreshes as described in notes 712757 or 713674, as appropriate.
For systems where service definition refreshes are allowed please ensure that your user has the profile 'S_SDCC_ADMIN'. Alternatively use transaction SE38 and call report BDLTRA (/BDL/TRA if SDCC has been implemented by ST-PI, see note 91488).
- 12. Error in RFC destination of SDCC (CSD_PETER) - 4.6B customers only
Q: How can I fix the faulty RFC destination?
A: Please implement the newest SDCC version, at least version 2.3. Before changing the SDCC version, please fix the destination as described in note 209203.
- 13. Problems with systems on Basis Rel 3.0D
Q: On this system calling SDCC results in syntax errors being displayed.
A: Please implement SDCC version 2.3, and maintain the Service definitions as described in note 712757.
- 14. No authorization to call SDCC (R/3 release >= 4.6B)
Q: How can I get the missing authorization to call SDCC?
A: If your user contains the profile SAP_ALL, you should have no problems. If you do not have SAP_ALL, please add S_SDCC_ADMIN into the profile list for your user.
- 15. Q: ASM schedules several SASM_
one session. The jobs interrupt each other, in the SDCC message log you find the error > collect/transfer jobs for session already active
A: The background job AUTO_SESSION_MANAGER carries out multiple scheduling of sessions. The job does not query the complete time window asking whether a SASM_*_COLL_TRANS job already exists.
Please refer to the solution in note 624427.
- 16. RFC breakdown just after the ASM has started
Q: In the SDCC message log the entry " Maximale Anzahl von CPIC-Clients erreiched " oder " Maximum number of CPIC-clients reached " appears. How can this be fixed?
A: There can be several reasons for this:
a) If it happens during the run of the Automatic Session Manager: The default starting time for the ASM was 22:00:00 for SDCC up to version 2.0. So, if the starting time is not changed before the ASM is started, it will attempt a Service Definition Refresh through an RFC call to OSS every day shortly after 22:00. If too many customers attempt such a call at the same time, there can be an overload on OSS. To avoid this, please delete the next ASM job, using 'Autom. Sess. Manager -> Controls (leads you to sm37), and reschedule it at another time. Please choose a time when there is little load on the system.
NOTE: Service definitions should be only be refreshed from OSS where appropriate, as described in Question 2 of this note, (SERVICE DEFINITION REFRESH)
b) Otherwise, the logon group for the RFC destination SAPOSS may not be used properly. To force the system to use it, go into 'SDCC->Maintenance->Customizing->General' and
- if the input box for 'Logon group' is empty, fill in 'EWA'.
- if the input box for 'Logon group' already contains 'EWA', and the box for 'RFC destination' contains SAPOSS, replace SAPOSS with SAPNET_RFC.
- 17. RFC destination SAPOSS works, it's copy SAPNET_RFC does not work
Q: I get connection errors in SM59 RFC destination SAPNET_RFC. Therefore data transfer to SAP or service definition refreshes fail.
A: Please note that only systems on basis release 4.x with ST-PI and systems on basis release 3.x may refresh service definitions from SAPNET R/3 Frontend (OSS). For all other systems please check Question 2 of this note, (SERVICE DEFINITION REFRESH)
SAPNET_RFC is a copy of SAPOSS which uses load balancing through logon group EWA. It is created automatically by SDCC. If, however, SAPOSS is changed ( for example, if the 'Message Server' string there is changed, or because the entries 'Technical parameters' in transaction OSS1 were updated) it is necessary to adjust SAPNET_RFC. You can do this by simply deleting SAPNET_RFC. A fresh copy of SAPOSS will be created when SDCC tries to connect to SAP. If this does not work, and you get an error of type "hostname ... unknown/CPI-C error CM_PRODUCT_SPECIFIC_ERROR" you should refer to note 316221 for advice.
- 18. Submitting the data collection or transfer background job fails
Q: When going through the standard procedure of collecting or transmitting data, an error message 'error during JOB_CLOSE, see SYSLOG' appears, and no job is submitted.
A: Both the collection of session data and its transfer to the SAP Service System are done through class C background work processes. Usually the customer system looks for any free background work process on any server and starts the collections and/or transfer jobs there. Problems can occur when:
- the 'Background server' parameter in 'Maintenance -> Remote Environment -> Default destinations' is not empty but set to a server that doesn't exist anymore, contains no background work processes, whose background work processes have been removed, or whose background work processes do not permit class C background jobs.
- on the entire system all background work processes are in use.
- the user under which the background work process is scheduled does not have authorization to do so (the user EARLYWATCH can have this problem). If the background work processes you tried to start (Session -> Display -> Coll./trans. jobs) are in status 'SCHEDULED' and you try to release them, you'll get an error message.
- 19. Run of AUTO_SESSION_MANAGER failed ( in R/3 rel 4.*)
Q: During run of ASM following error message is shown in job log
(SM37):
"Variant &0000000000000 does not exist"
A: Go to transaction sm37, select job AUTO_SESSION_MANAGER. Select the next future job ( there should be only one). Go into change mode (Job -> Change). Then press button 'Steps'. Select program name (BDLATRUN or /BDL/ATRUN with ST-PI) and go to Change mode. Change field entry "Parameters" from &0000000000000 to 'Space' and save. Subsequent ASM jobs should be executed without the paramater, and run through.
- 20. Oracle error 1039 and/or 942 appear in the SYSLOG during execution of a SDCC download
Q: While the SDCC report BDLCOLL is running Oracle error 1039 and/or 942 appears in the SYSLOG (Datenbankfehler 1039, Datenbankfehler 942). What should be done?
A: These errors occur when the function module SQL_CACHE_ANALYSIS_READ is called. This module calls a kernel C routine which make EXPLAINs on SQL statements. The kernel routine returns the error codes.
This SYSLOG entry causes no disruption for the Service. It also causes no short-dumps. Therefore it can be ignored. PLease see also note 200463.
.
- 21. Data collection gets stuck
Q: What should I do when a data collection is going on for a long time (hours), or simply stops without the 'Data collection completed' entry in the SDCC Message Log?
A: Data collection can take very long when, for example, the system consists of many servers, or the system performance is poor. However, it is possible that some of the function modules called by SDCC lead to errors, very long loop times etc. These errors can occur in a variety of circumstances which need to be examined on a case by case basis. They often indicate some general problems in the system, or in some of the function modules called. If they are not contained in the scenarios outlined below you should seek specialist advice by opening a message in component SV-SMG-SDD.
a)SDCC batch jobs fails. Typically the SYSLOG (SM21) contains an error message of type
"F61 K TemSe input/output to unopened file".
In SM37 (SDCC -> Session -> Display -> Coll./trans.) I get the error "Error occurred when reading job log JOBLGX...X" when I try to look at the job log.
Please refer to Note 21661. Further information is, if required, in Note 48400. If the problem is a full file system, please refer to Note 16513.
b) If the system has R/3 release 3.0D have a look in transaction ST22. Look for short dumps 'CALL_FUNCTION_PARM_MISSING' for the user who is running SDCC. If the error analysis shows that the error occured while calling function 'DDIF_NAMETAB_GET', parameter "X031L_TAB", the situation is as follows:
The version of the DDIC function module 'DDIF_NAMETAB_GET' is not up to date. For old R/3 releases in function 'DDIF_NAMETAB_GET' (it is used to get DDIC information) the 'optional' flag is not set for tables parameter "X031L_TAB".
Solution: Set the tables parameter "X031L_TAB" of function 'DDIF_NAMETAB_GET' optional and generate the function. After that you can run transaction SDCC as normal.
c) For AS400 systems data collection stops, and in the SYSLOG (SM21) an entry appears "DB error -901 at DEL access to ...".
Solution: A DB patch is required. The customer should seek specialist AS400 advice through a message in component BC-DB-DB4.
- 22. RFC destination not found in SDCC
Q: When trying to transfer data in SDCC the following messages appear.
- No data transfer possible: destination info not found
- No RFC destination found: transfer not possible
in the SDCC Message Log and the data are not transferred.
A: Please check if the RFC destination has been accepted by SDCC.
Highlight the session, then do 'Maintenance -> Remote Environment -> Custom target dest.' If no target destination is implemented, you can do it in this screen for this single session.
If you need a general solution for future sessions please do 'Maintenance-> Remote environment -> Default target destination'. Here you have to change the current destinations to any different destination and save. After this you have to reimplement the original destination once again. Please check again if the RFC destination has now been accepted ( check as described above). If this does not work, please open a message in component SV-SMG-SDD.
- 23. RFC errors
Q: I tried to refresh the 'Service definitions' and/or the 'Session overview' but I am prompted with errors 'Session update via RFC failed' (SD-140) and/or 'Service definition update via RFC failed' (SD-141).
or
Data collection was successful, but data transfer failed (RFC problems)
NOTE: Service definitions should be only be refreshed from OSS where appropriate, as described in Question 2 of this note, (SERVICE DEFINITION REFRESH)
A: Ideally the system should have a working RFC connection from each of its servers to the SAP Service System. You can check whether this is the case by using Transaction SM59 -> R/3 destinations, then choosing SAPOSS and doing 'Test -> Authorisation'. From SDCC version 1.7 on, a tool for checking RFC destination SAPOSS is available through Information -> Service prep. check -> Status of RFC dest. (from outside SDCC it can be called through Transaction SE38 -> BDLPING(or /BDL/PING,if SDCC was implemented with ST-PI))
A list with SAP instances is displayed, and for each instance it is
shown whether
a) there are background work processes on the instance (key functions of SDCC run as background jobs!)
b) whether the RFC connections to SAPOSS/SAPNET_RFC are working.
(Please note that this only checks if a 'ping ' can be exchanged, not the authorization of the user sending it. Please check Question 29 for information on how to maintain the destinations.)
What you need is an instance where both these requirements are rated 'green'; the server assigned to that instance can be used by SDCC.
Case 1: Some servers have functional SAPOSS RFC destinations
If a working SAPOSS RFC destination exists in one server (but not in others) and this server contains background work processes, this server can be explicity set in 'Maintenance -> Customizing -> General' under 'Background server' for use by SDCC. This makes sure that the SDCC core data collection and transfer processes can run and that the 'Session Overview Refresh' that is triggered by the ASM is working.
In terms of doing a Service Definition Refresh, or a Session Overview Refresh (which run on dialog work processes), you have to switch to a usable server with Transaction SM51.
NOTE: Service definitions should be only be refreshed from OSS where appropriate, as described in Question 2 of this note, (SERVICE DEFINITION REFRESH)
If a working RFC destination exists in one server but this server does not contain background work processes, you can call report BDLSEND (/BDL/SEND where SDCC is implemented by ST-PI) with SE38 on the functional server and transmit data manually. In the input screen for BDLSEND (or /BDL/SEND...) you usually only need to fill the fields SESSNR (with .Sess. num..), MANDANT (with the .Ext..) and DEST (with the RFC Destination in 'Maintenance -> Customizing -> General'). However, this should only be done as an exception! For the normal use of the Earlywatch Alert a sufficient number of background work processes should be set up.
Case 2: No server has a functional SAPOSS RFC destination
If the system has no working SAPOSS RFC destination it can have a number of reasons (see Note 33135, Appendix A):
I. Error ' service sapdp99 unknown' or 'error opening an RFC connection'occurs
The services file may not be maintained correctly.
(i) Add the entry sapdp99 3299/tcp in the 'services' file of the customer system which is usually UNIX: /etc/service , NT:
This method should be preferred to option ii).
(ii) Alternatively you can change from 'sapdp99' to '3299' directly in SAPOSS.
After this you can proceed as in case 1.
II. If there is a saprouter or firewall problem (route permission denied)
The file saprouttab is not correct, refer to note 30289. If all efforts fail, please open a message (component BC-MID-RFC).
- 24. Dedicated background server can't be set in SDCC
Q: After entering the dedicated background server in SDCC -> Maintenance-> Remote Environment -> Default Target Destinations, and leaving the window with the OK Button the server name is automatically changed into capital letters. This makes processing of the download in the background impossible. In some cases warnings in SDCC log appear : "ASM: SASM_Z0000000xx_COLL_TRANS failed". The reason for this warning is that the job SASM_Z0000000xx_COLL_TRANS is scheduled without a start date and time due to the badly implemented background server.
What can be done?
A: Please implement the latest SDCC version, at least SDCC 2.3 (see note91488). If the problem persists, please open a message in component SV-SMG-SDD.
- 25. Getting kicked out of SDCC immediately after calling it
Q: After calling SDCC a pop up shows up : " YOU ARE NOT AUTHORIZED TO LOG ON TO TARGET SYSTEM" or "KEINE BERECHTIGUNG ZUR ANMELDUNG AM ZIELSYSTEM" before throwing me out. What should I do?
A: The RFC destinations SAPOSS or SAPNET_RFC are not properly maintained, most likely because the user or password are not maintained correctly.You will find information about how to maintain these destinations correctly in the next question.
- 26. SAPOSS, SAPNET_RFC, SAPNET_RTCC are not properly maintained
Q: These destinations look unusual in SM59; is there a template I can check them against?
A: SAPOSS is configured automatically on the basis of data in OSS1.
If SAPOSS isn´t working, please make sure that the entries for 'Technical settings' in OSS1 are correct. Refer to Notes 33135 and 30289 for more information on OSS1. To ensure SAPOSS is maintained with 'load distribution' set to 'yes', please follow note 766505.
SAPNET_RFC and SAPNET_RTCC are copies of SAPOSS. They get created automatically when the tools SDCC (SAPNET_RFC) and RTCCTOOL ( SAPNET_RTCC) connect to OSS the first time. They get created with 'Loadbalancing' switched on. This makes the entry in the field 'Target Host' appear very short - please note that the full string as described below can only be maintained if 'Loadbalancing' is set to 'No'.
Please note that after an update of SAPOSS via TA OSS1 the client may change to 000 - please update this manually to 001.
Also, after an update of SAPOSS via TA OSS1 SAPNET_RFC and SAPNET_RTCC do NOT get updated automatically. The easiest way to ensure they are updated correctly is to delete both destinations, and then start a connection to OSS from the tools ( SAPNET_RFC: SDCC -> Maintenance -> Refresh -> Service Overview. SAPNET_RTCC: SE38 -> RTCCTOOL)
Often ( but not always - systems with 2 saprouters can be different) the parameters of a working SAPOSS or SAPNET_RFC destination (where Load balancing is set to 'No' ) are set up like this:
- Target host: /H/X1/S/sapdp99/H/X2/S/sapdp99/H/oss001
with
X1 = customer saprouter IP address
X2 = IP address of sapservX
possible entries for sapservX:
sapserv1 (194.117.106.129) Internet VPN connection
sapserv2 (194.39.131.34) Internet SNC connection
sapserv3 (147.204.2.5) for customers connected to Germany.
sapserv4 (204.79.199.2) for customers in Americas.
sapserv5 (194.39.138.2) for customers connected to Japan.
sapserv6 (194.39.139.16) for Australia and New Zealand customers.
sapserv7 (194.39.134.35) for Asia customers.
SAPOSS and SAPNET_RFC
- System number = 01
- Client = 001
- User = OSS_RFC
- Password = CPIC
SAPNET_RTCC
- Client = 001
- User = ST14_RTCC
- Password gets set automatically when the destination is created. In case of problems with the password please delete SAPNET_RTCC and recreate it.
- 27. Data transfer job aborts with a short dump TSV_NEW_PAGE_ALLOC_FAILED
Q: When I collect and transfer data for a download the SDCC message log shows that data collection is ok, but ends with 'Data transfer started'. Additionally a short dump TSV_NEW_PAGE_ALLOC_FAILED is created ( see ST22) and the transfer job is aborted.
A: In table BDLCUST (/BDL/CUST where SDCC has been implemented via ST-PI) the entry for SENDSTYL has to be changed from SINGLE_RFC to MULTIPLE_RFC. You can do this in SE38, with report BDLSETUP (/BDL/SETUP where SDCC has been implemented by ST-PI), using KEY : SENDSTYL and VALUE: MULTIPLE_RFC. Then delete the data collection from the download viewer and redo the complete download. For more details, especially regarding ADDON data see note 312834.
- 28. RFC related errors
Q1: While collecting data the message log shows the following error:
-
- BDL_GET_DDIC_INFO exception 2 wrong_function_parameter
A: On systems with more than one server each server should have the same entry in the 'services' file for the message server. Change the entry 'sapms
UNIX: /etc/service ,
NT:
Q2: ST22 shows ABAP runtime errors ´RFC_NO_AUTHORITY´ for the user that executed SDCC. User ´...´ has no RFC authorization for function group
´BDL...´.
A: The user authorizations have to be adjusted accordingly.
- 29. Transport errors ( ONLY relevant if SDCC was implemented by note 560630 - NEVER if it was implemented with ST-PI)
Q: Implementing transport SAPKVSDB* ended with RC8, and the following message: BDLFUVER2 table class is 'L'. Entries must not be replaced.
A: Please re-implement the transport with unconditional mode u168. Please be careful NEVER to implement any transport containing SDCC into a system where ST-PI has already been implemented, or in a system with R/3 release 6*.
- 30. For security or infrastructure reasons the system does not exchange RFC calls with the outside world.
Q: The system cannot use RFC to communicate with the SAP Service System. As a result
- the session overview cannot be loaded into the system, so that the session list remains empty
- collected data can't be transferred
- a Service Definition Refresh can't be performed
Is there a way out of this?
A: Yes. The data can be sent to sapservX, the Service Engineer performing the session then creates an IT/IBC message to get the data transferred to the system he performs the session in. Please note that the Service Engineer will have to give you the session number as it is
defined at SAP.
a) Call Session -> Create -> Internal Session. A window appears.
In the field 'Session number' any number (that has not been used before) can be typed in.
In the field #Session type# the relevant session type has to be selected. Then push the green check icon at the bottom of the window.
b) The newly created session should now appear in the session overview.
c) Highlight that session.
d) Click on the 'Download' button. A window appears. In this window de-select(!) the 'Transfer ...' field and click on the 'Start task(s) immediately' button.
e) Now watch the Message Log with Information -> Display Message Log until the 'Data collection completed' entry comes up.
f) Once this is done, please do the following:
Highlight the session, then do:
'Session -> Process -> Export data to file'
A window comes up.
At the bottom of it you see two pairs of session numbers. On the left side is the imaginary number the you made up; on the right hand side the session number as it is defined for this session at SAP must be entered.
For the 'Destination extension' use '000' (three zeros) and click the green check icon. At the bottom of the screen and in the message log a file path will appear. This file path indicates the location of the file that contains the session data.
g) Now the file has to be transported to the SAP system:
Please contact the Service Engineer performing the session. He will provide a link ( via SAPMats) to which you can upload the file.The process will then be continued internally; the Service Engineer can use note 588128 for information on how to continue the process.
Please note that from this point on it takes 24 hrs to get the data into the correct system at SAP, so the process must be started in good time before the session.
Please note also that this method is not primarily meant for customers with 'bad' lines. In case of such a line, please try to solve the problem first by reducing the RFC packet size using 'Maintenance ->
Customizing -> General -> Block size for one RFC'
i) Concerning the Service Definition Refresh:
Please follow note 727998, which explains how to completely replace the service definitions for all possible combinations, with the relevant transport.
Header Data
| Release Status: | Released for Customer |
| Released on: | 07.07.2008 15:56:03 |
| Master Language: | English |
| Priority: | Recommendations/additional info |
| Category: | Special development |
| Primary Component: | SV-SMG-SDD Service Data Download |
Affected Releases
Release-Independent
Related Notes
Attributes
|
Attachments
|
No comments:
Post a Comment