Project

<Client Logo> Version:- 1.0

Document History: Versio Date n 1.0 19.04.2012 Author Sonal Kumar. Comment Handle IDOC of Status 64

Page 1

Project

<Client Logo> Version:- 1.0

Table of Contents
PURPOSE.................................................................................................................................3 SYSTEM DESCRIPTION..............................................................................................................3 SAP NOTE/ OTHER REFERENCES...............................................................................................3 DESCRIPTION OF THE ISSUE/ERROR.........................................................................................3 SOLUTION/FIX FOR THE ERROR................................................................................................3 ADDITIONAL INFORMATION (IF ANY).........................................................................................7

Page 2

Project

<Client Logo> Version:- 1.0

Purpose
To know about Idoc error 64.

System Description
SAP Kernel Version SAP Product OS (Including Version) DB (Including Version) SAP XI

SAP Note/ Other References

SAP Notes Other References 1055679 555229 74141 535172

Description of the issue/error

When Idocs are getting failed in the system wirh Error Status:64.We need to take the below action.

Solution/Fix for the Error

1. Go to Transaction BD87 2. Select the IDoc that needs to be transferred 3. Procedure the IDoc manually. IDocs retain status 64, but should be actioned immediately: Check 1: Reason and Prerequisites: The problem can have various technical causes. One possibility is a temporary lack of resources; another reason is that released locks are not available in time on other servers.

Page 3

Project

<Client Logo> Version:- 1.0

These two issues can only be solved by not procedureing the IDocs at runtime. Depending on the technical cause, you can write a second status 64 (immediate Procedureing is not possible), in some cases, however, even this is not possible. Note 555229 describe a method that allows you to start immediate procedureing if resources are scarce. However, you cannot use this method to eliminate the other technical issues. This means that there still may be IDocs left in status 64. If a large number of IDocs hangs (due to insufficient resources) over a short period of time, you may also disturb the background Procedureing if you start a background job for each IDoc. Solution This note delivers a report that is specifically designed to select the hanging IDocs for virtually synchronous Procedures, and transfer them one by one to report RBDAPP01 for Procedureing. (*** Source: 734576 IDocs retain status 64, but should be Procedureed immediately) Check 2: tRFC or qRFC calls are not Procedureed qRFC or tRFC calls are not Procedureed because the profile parameters are configured incorrectly. Five different symptoms can occur: 1. In the case of qRFC calls, the outbound queues (transaction SMQ1) are in the READY status and the QOUT scheduler (SMQS) is in the WAITING status. In addition, you can see the reports SAPLQOWK and SAPLSPBT looping in transaction SM50. 2. In the case of qRFC calls, the inbound queues (transaction SMQ2) are in the READY status and the QIN Scheduler (SMQR) is in the WAITING status. 3. tRFC calls are in the 'Transaction recorded' status. Comment: The 'Transaction recorded' status may also be displayed if the relevant RFC destination is deregistered in transaction SMQS (see SAP Note 484753). 4. In the case of qRFC calls, the outbound queues (transaction SMQ1) have the READY status and the relevant RFC destination is deregistered in transaction SMQS (Type 'U'). Register the RFC destination, and refer to Note 484753. 5. In transaction SM58, the tRFC LUWs have the 'Transaction recorded' status, and the function module involved is RSAR_TRFC_DATA_RECEIVED. For more information, see Note 784414.

Page 4

Project

<Client Logo> Version:- 1.0

6. In transaction SM58, the tRFC LUWs are in the 'Transaction recorded' status and the column "Cln" does not include any clients. For more information, see Note 804548. 7. The field ARFCRESERV is empty in the table ARFCSSTATE. If this field does not contain any value, the outbound scheduler (SMQS) does not Procedure the t/qRFC LUWs. Until now, the problem was observed in MaxDB and the solution is described in Note 737241. Other terms WAITING, READY, 'Transaction recorded', "rdisp/rfc_min_wait_dia_wp","Minimum Number of Free WPs", CUA, Central User Administration Reason and Prerequisites The qRFC or tRFC calls cannot be Procedureed because the profile parameters are configured incorrectly. The Qout scheduler or Qin scheduler does not receive any resources to send the calls. Comment: The "WAITING" status in transaction SMQS or SMQR indicates that the problem is due to: o A shortage of resources or o Waiting for the completion of requests in the target system. Solution Determine the number of dialog work Procedurees that are available for Procedureing tRFC/qRFC. As of qRFC Version 6.20.045 with supplement 7: Call transaction SMQS or SMQR and choose the menu option -> "Goto" -> "QRFC Resources". In earlier qRFC versions, execute the report RSTRFCDR. A '0' in the right-hand column ('DIA-WPs for tRFC/qRFC') indicates that there is a resource problem for tRFC/qRFC communication. In this case, check the configuration of your system: 1. The qRFC or tRFC requires at least 4 free dialog work Procedurees on an application server. 2. The following rule MUST be followed: - a = (current number of DIA work Procedurees) minus (minimum number of free work Procedurees)- b = (current number of DIA work Procedurees) multiplied by (maximum number of work Procedurees used/100)

Page 5

Project

<Client Logo> Version:- 1.0

Comment: You can refer to transaction RZ12 for the values of the profile parameters 'Minimum Number of Free WPs' and 'Max. Number of WPs Used' for each application server. - The minimal values of (a, b) must be greater than or equal to 4. o Defining the profile parameters in RZ12: 'Minimum Number of Free WPs' (rdisp/rfc_min_wait_dia_wp): The parameter 'rdisp/rfc_min_wait_dia_wp' indicates how many dialog work Procedurees cannot be blocked using RFC. This means that if 'rdisp/wp_no_dia' minus 'rdisp/rfc_min_wait_dia_wp' dialog work Procedurees are currently acting as RFC servers, no Further RFCs are distributed by the dispatcher. Only the dialog work Procedurees that are acting as RFC servers are counted, and not high-priority requests (such as using a number from the number range buffer) or requests from the SAPGUI. 'Max. Number of WPs Used' (rdisp/rfc_max_own_used_wp): The parameter determines the quota of dialog work Procedurees that an (RFC) user can use at the same time. The value is specified as a percentage of the configured dialog work Procedurees. 3. A resource bottleneck may arise due to parallel Procedureing of tRFC requests, which are used (among other things) in Central User Administration (CUA). To avoid this situation, reduce the number of child systems to be supplied in parallel as described in Notes 399271 and 557610, and reduce the number of parallel requests for each RFC destination using the "max-conn" parameter in transaction SMQS. Refer to Note 400330 for this purpose. 4. The profile parameter "rdisp/rfc_use_quotas" must NEVER be set to zero. 5. Note 142419 describes in detail the reasons for a resource bottleneck. 6. Comment: The number of dialog Procedurees must be greater than or equal to the total number of update and background Procedurees for each application server and must be configured across all operation mode switches. 7. Set the profile parameter rdisp/max_arq to the value of the profile parameter rdisp/max_comm_entries as described in Note 311930. You can reset the profile parameters dynamically in transaction RZ12.

Page 6

Project

<Client Logo> Version:- 1.0

During a restart, these parameters are overwritten by the instance profile. Therefore, you must also adjust the parameters in the instance profile. For information about additional profile parameter settings in transaction RZ12, see Note 74141. (Source: 527481 tRFC or qRFC calls are not Procedureed) 00127771 2008 Please note that high volume and all non-critical IDocs should be Procedureed in the background using RBDAPP01. I would advise that for all non-critical IDocs you Procedure these in the background. With report RBDAPP01 you can specify additional selection parameters so that this report executes IDocs of a particular type, for a particular destination etc. This report can be used to both Procedure IDocs which are set to foreground Procedureing but are stuck in status 64 and also to Procedure IDocs in the background. I have attached Note 527481 for your review also. This note statesthat the qRFC or tRFC needs at least 4 free dialog work Procedurees on an application server. 561880 Requests hang because IDocs are not Procedureed: Check 535172, 555229 notes in both source and target systems.

Additional Information (If Any)

Notes to be applied: 1055679 IDoc-tRFC inbound with immediate Procedureing may not work 555229 IDocs hang in status 64 for tRFC with immediate (Report RBDAPP01 to be scheduled) 74141 Resource Management for tRFC and aRFC

Page 7