SMWMQUEUES - what does status "ready" mean

Question

SMWMQUEUES lists all outbound queues by name in CRM. All my queues are in status NOSEND . They currently can not conntrans so I am wondering if this is some indication that their site is not correctly identified. Does anyone know why all the othere queues are in status NOSEND and this one is READY ?
Many thanks MM

Answer 1

Please have a look  at the note below and <b>reward points if it helps</b>
Basically, if the initial load is not successful, you should analyze queues and restart them if required. It makes sense to restart the initial load of an individual object if the analysis did not result in problems. Always log on to the CRM/EBP server in English to see the error texts. For notes on the delta data supply from the R/3 Backend system into the CRM server and the other way round, see the attached notes.
Error Detection - Tool Monitoring in the Middleware Menu:
a) Transaction R3AM1: Initial load monitor: After a successful initial load, all traffic lights should be "green".
b) Transaction SMWP: 'Middleware Portal':Under 'Runtime Information' -> 'Adapter Status Information' -> 'Initial Load Status', you can investigate the inbound and outbound queues and branch to the qRFC transactions from there. Below, the error analyses with access via the CRM Middleware Portal are described.
c) Transaction SMW01: Analysis of errors in the BDoc flow, in particular CRM/EBP application Customizing errors during the initial load into the CRM Server.
d) Transaction SMWT: Middleware trace with trace environment 'I':Display of additional information for each data block transferred.
Analysis
1. Ensure that the highest available plug-in (PI) Support Package plus Core Support Package is installed in the R/3 back-end system. The same applies to the CRM/EBP Server.
2. Transaction SM30:In the R/3 Back-end System, the correct RFC destination must be entered in table CRMRFCPAR for CONSUMER CRM. For this, see the documentation on the CRM Adapter Framework.
3. Transaction SM59:Test RFC connection - 'Remote login' from CRM/EBP to R/3 Back end and vice versa.
4. Transaction SMOEAC (Administration Console): Check the sites for R/3 systems. Have the RFC destinations been entered correctly and do the additional attributes exist? For this, see the documentation on the CRM Adapter Framework.
5. Transaction SMWP:Menu item 'Runtime information' -> 'Adapter Status Information' -> 'Initial Load Status':The subitems for the monitoring of the different inbound and outbound queues must each be evaluated in a similar way:
              Double-click a queue entry to display the status of a queue (for example, READY, RUNNING, SYSFAIL). If you double-click again, you can see the cause of the error from the status text in the case of an error (SYSFAIL). Note: In case of temporary errors, it often helps to restart the queue (F6).
              In general, a short dump occurs for status SYSFAIL. For the outbound queues, this short dump exists in the target system and not in the system in which the queue is. For inbound queues, the short dump exists in the same system as the inbound queue. For the initial data transfer between CRM and CDB or CRM and XML/ALE sites, the source and the target system are the same.
a) Menu option 'Load from OLTP systems:Start outbound queues in the CRM server':Status SYSFAIL in these outbound queues displays that a program termination occurred during the selection or the sending of data from an R/3 source system.If the program termination occurs in programs SAPLCRM0, SAPLCXML, SAPLCXMP, SAPLCTRK, SAPLCRMD, SAPLCGEN, SAPLCGNR, SAPLCFIL, SAPLCRMR, SAPLCRMS, SAPLCRMC and if you cannot solve the problem with the help of this note, send a customer message to component CRM-MW-ADP.In all other cases, choose the corresponding application component.
b) Menu item 'Load from CRM: Start outbound queues in the CRM server': Status SYSFAIL displays that a program termination occurred during the selection of data from the CRM for the CDB or a different site (for example, XML). Apart from that, the same applies as under the previous point.
c) Menu item 'Outbound queues in OLTP-R/3 System(s)':In general, these queues are only temporary because they are converted into inbound queues on the CRM Server. Consequently, they only exist if network errors, incorrect RFC connection parameters or database problems occur on the CRM server. If a restart of the queue is not successful, a short dump has occurred on the receiving side, the cause of which you must first correct. If the status of the queue is 'NOSENDS', the sending of data was blocked by mistake. This should never be set during live operation. To solve the problem, ensure that the HOLD_DATA field is initial in the CRMRFCPAR table. You can use Transaction SM30 to check or change this. In this transaction, it is the entry for the 'Save data' text. You must trigger existing queues with the status 'NOSENDS' manually. Afterwards, the processing of the outbound queue will occur automatically again.
d) Menu item 'Inbound queues on CRM server': In these queues, you find the data from the initial data transfer from an R/3 System. A SYSFAIL is by far the most frequent item in these queues. The reasons for this can be manifold. Program terminations in the CRM application due to missing or incorrect Customizing are the most frequent reason. To see detailed information on the errors which occurred, call Transaction SMW01 for the corresponding BDoc type. This is also required if there is no queue with errors that you can use to determine and analyze errors in any type of data transport. Short dumps may also occur due to real program errors. In this case, there is a corresponding short dump on the same system. If the error occurs in the SAPLSMOUTIL, SAPLSMO0 or SAPLSMOXML programs and if you cannot correct the error yourself, create a message for component CRM-MW-ADP. In all other cases, create a message for the corresponding component.
A possible error text in the inbound queue is "Error in Mapping (Details: Transaction SMW01)" (SMOF078). To correct this error, proceed as follows: Analyze and correct the error which is displayed in Transaction SMW01 at the error segments. You can find the correct BDoc message with the aid of the date and the time of the entry in the queue as well as with the BDoc status which is 'F05'. After you have corrected this problem, restart the inbound queue in order to process the entry. You can request help for correcting the error displayed in Transaction SMW01 in the corresponding application component.
e) Menu item 'Inbound queue on CRM server from CRM': These queues contain the data from the initial data transfer from the CRM Server to the CDB or other linked sites (for example, XML). For the error analysis, the same applies as for the previous menu item.
6. Logical system maintained in the CRM/EBP Server and in the R/3 Back end?
7. Transaction SMW01: Incorrect settings in the CRM/EBP application.In the selection screen, restrict the relevant period and, if required, the BDoc type.In the result of the selection, select the incorrect message and choose 'Display errors/error segments'.Here, you find notes on CRM/EBP application Customizing problems.
8. Transaction ST22: Short dumps on OLTP CRM/EBP Server
9. Transaction SE80:Syntax check for generated functions in development class $SAP_MSAGEN, for example function group /1CRMG0/PRDCT_OBJECT for product master. If a function group has syntax errors, it is often useful to regenerate it by using Transaction SMOGGEN.
Typical error messages and their solution:
Error 1654, for example for table space PSAPBTABI: Solution: add SAPDBA to the table space.
Timeout in R/3 back-end system during the initial download: Solution:See Note 162956
General performance problems during the initial download:See Note 350176
Inbound queue (SMQ2) on the CRM/EBP Server has status 'READY', but it is not processed. Solution:Restart the queue and check the registration of R3A, CRI in Transaction SMQR
The outbound queue in the R/3 Back-end System has status 'SYSFAIL', the detailed message is: Solution:shut down the CRM/EBP Server and restart it.If other SYSFAIL messages occur, restart the queue and analyze the short dumps.
RSQL error 13 when accessing table SMOTCURR:you should convert the data exchange between the R/3 Back end and the CRM Server to the XML format (see Note 333008).Then delete the inbound queue (in SMQ2, for example, R3AI_DNL_CUST_CURREN) and restart the object.
The number of data records between an R/3 Back-end table or a CRM table and the corresponding CRM CDB table do not match. Solution:Check the following:
Was the initial load completed successfully?
Are filters set for the object?
Note:Filters that are defined in the CRM Server must be defined in the form in which the data is stored in the source system in the database. For example, the filter for date 20010215 corresponds to a filter for February 15, 2001 (format YYYYMMDD).Make sure that the filter criteria are entered with leading digits, for example 10-digit customer numbers, 18-digit material numbers with leading zeros.
Are there error messages in Transaction SMW01 indicating rejections by the CRM server application?
Is the table a child table and are the excessive records orphaned child records that are not selected as well?
Should this delta data only be in the Customizing tables after the compare?
After you start the initial load using Transaction R3AS, the started object remains in status WAIT in Transaction R3AM1, and the initial download is not started. This is not an error.
The following causes are possible:
Too many objects already have status RUNNING or too many requests have been started or too many DIMa instances have been started and not completed. The number of running initial loads plus the number of running requests is the total number of all running initial-like processes. Therefore, this object must wait for the initial load or request of a different object to be completed. After an object is completed, a different object in status 'WAIT' is started automatically. If the initial load/request of the other objects is not completed, you can use this note to analyze why these are not completed and trigger their processing. You can change the maximum number of parallel initial loads using the MAX_PARALLEL_PROCESSES parameter in the SMOFPARSFA table. The standard value in the 'Param. Value' field is 5.
The object has a parent object whose initial load was not completed successfully. You can see from flag 'P' in Transaction R3AM1 whether an object has a parent object. You can see from table SMOFOBJPAR which objects these are.
No entry exists in one of the queues, but the status in R3AM1 remains 'Running':
This is probably because after the data selection in the source system, no reply was sent to the CRM system. If this is the case for one adapter object but not for others, contact the respective application component, which can analyze why the source system does not send a reply and correct the problem.
If this system response occurs for all adapter objects, create a message for component CRM-MW-ADP.
During the start of the initial load, the system displays the message "No initial load if COMPARE is active" or "No Initial Load if data distribution is active. Use Synchron. Load" (SMOF162):
In this case, start a synchronization load for the respective Adapter Object.