![]() ![]() ![]() Note that the processing of qRFC never locks a queue. On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ1 or programs). We therefore recommend a waiting time of at least 30 minutes before you reactivate the queue. Note that activating a queue in status RUNNING may cause a LUW to be executed several times if this LUW is still being processed in the target system at that time. If this is the case, you can activate this queue again. If a queue in this status hangs for more than 30 minutes, this may mean that the work process responsible for sending this LUW has been terminated. The first LUW in this queue is currently being processed. There can however be the data status where a queue was locked manually or by a program using transaction SMQ1/SMQ2 and can then only be unlocked The queue is ready for transferring and processing. During the qRFC call, the application determines at the same time that the current LUW is not sent immediately. NOSEND is used to debug the execution of an LUW via transaction SMQ1. Under no circumstances should this NOSEND status be reset using transaction SMQ1 and the queue activated. This LUW is only deleted from the queue once this application confirms collection (collective confirmation possible). Even if a LUW has been read by the corresponding application (BW, CRM), this NOSEND status does not change. NOSEND queues are only used internally at SAP for communication between components BW or CRM with Mobile Clients. LUWs of this queue are not sent but retrieved by a special application. Processing of this queue is locked temporarily because the LUW data is being modified. The qRFC Manager will automatically delete the LUW already executed and send the next LUW. ![]() You can reactivate this queue without any problems. In contrast to status RUNNING, this current LUW has definitely been executed successfully. ![]() The system waits for a qRFC-internal confirmation from the target system before processing further LUWs. The first LUW of this queue has been processed. In this case, qRFC simulates a communication error with the text "Command to tRFC/qRFC: Execute LUW once again." If this error occurs very often, you must contact the corresponding application. Status CPICERR may also exist in the following cases although no communication error occurred: A qRFC application finds out that a LUW cannot be processed any further due to a temporary error in the application and therefore calls the RESTART_OF_BACKGROUNDTASK function module to prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in accordance with the specification in transaction SM59. A batch job is scheduled for the resend depending on the definition in transaction SM59 for the destination used. For more information on this error, see the syslog (SM21), the trace files dev_rd or dev_rfc*. When you double-click on this status, the system displays an error text. To solve the problem, you need to inform the relevant application here.ĭuring transmission or processing of the first LUW in the target system, a network or communication error occurred. Information from the affected application is required to solve the problem. Is there a way to prevent this from happening? In case of an error (when validating the ERP delivery) in EWM qRFC processing, I would like to remove the faulty record from the queue, return the error message to the ERP and mark the ERP delivery as not distributed or distribution error.During LUW execution the application has diagnosed a temporary problem and has prompted the qRFC Manager in the sending system via a specific qRFC call to schedule a batch job for a repetition based on the definition in transaction SM59.ĭuring the LUW execution, the application has found a serious error and prompted the qRFC Manager via a specific qRFC call to cancel processing of this LUW. However, if for whatever reason the validation API is not called, the ERP could still send erroneous deliveries to EWM that would get stuck in the SMQ2 queue. If the API rejects the delivery, then the distribution should be prevented. The obvious option is to implement a BADI in the ERP before distributing the delivery that would call a EWM validation API. I want to prevent this from happening because if the issue needs to be solved in the ERP side, the error shouldn't stay in EWM. In that case the error stays in EWM SMQ2 queue. Sometimes the ERP deliveries are not properly validated and don't fulfill the requirements to be distributed to EWM, but they are still sent. A BAPI is called that creates a delivery replica in EWM. The setup is standard and works via a distribution model in the ERP BD64 transaction. In my landscape, the ERP system is creating deliveries in EWM via qRFC. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |