on 01-17-2006 6:00 AM
Hello,
I have a problem with the extraction of data in a SL ODS. One of the data requests (of the ODS) has failed and because of that the new data cant get from the ODS to the cube (the ODS have already newer data requests )
In the monitor I get the error messages:
<b>Request REQU_B9H37YZ8NF3EZPV6DPSV77KEH in ODS ZODS_ELE must have QM status green before it
Activation of data records from ODS object ZODS_ELE terminated.</b>
When I look at the OLTP-IDOCS I find 5 idocs in status 64 Idocs ready to be transferred to application and when I look inside I get the message:
<b> IDoc ready to be transferred to application No resources, immed. processing not possible: Too few free dialog work processes.</b>
I also have 13 idocs in the status 51 application document not posted and when I look inside of them I get the message:
<b>IDoc: 0000000002263442 Status: Application document not posted, Error in document: YSL 6000999866 HMPCLNT400</b>
I dont know what to do!!!!
Should I delete the data request and try to load again? Will I lose the data ???
Please Advice.
David
hi David,
take a look oss note 555229
Symptom
IDocs hang in status 64 in the inbox. The message text in the IDoc status record is: (B1999) "NO RESOURCES, IMMED. PROCESSING NOT POSSIBLE: <reason>".
In the BW System: The extraction of data from an OLTP system hangs in the loading monitor and finally gets a timeout.
Other terms
ALE, IDoc, tRFC inbound, status 64
RSINFO, RSRQST, RSSEND
Reason and Prerequisites
The IDocs are received via the tRFC port type and the "Immediate processing" option is selected in the IDoc partner profile. One of the Support Packages described in note 535172 has been imported.
Following the Support Package described in note 535172, the IDoc is processed in a second, parallel process. This decoupling is necessary to be able to guarantee that the transfer only happens exactly once for IDocs. Due to the change, errors occur in scenarios based on a quasi-synchronous communication via IDoc.
Solution
The proposed solution includes source code corrections and a configuration enabled by the source code corrections.
The source code corrections can be imported for this version within a version between the Support Package given in note 535172 and the lowest Support Package given in this note. It is available with the highest Support Package given in this note for the corresponding version. There are 2 configuration variants:
1. Return to the processing in the same dialog process as the IDoc receipt
Maintain the following entry in the TEDEF table using transaction SE16 in every client for which you want to postpone the behavior:
Field EVENTT with value TRFC-IDOC and field ROUTID with value SYNCHRON
Caution: You have thereby restored the original behavior prior to note 535172. It may therefore happen again that IDocs are received and processed repeatedly.
1. Change from dialog to background process
Maintain the following entry in the TEDEF table using transaction SE16 in every client for which you want to postpone the behavior:
Field EVENTT with value TRFC-IDOC and field ROUTID with value BATCHJOB
The IDoc is then processed by the application in a second, parallel process, provided there are enough dialog processes. If no dialog process is currently free, report RBDAPP01 is scheduled for this IDoc and executed as a background process. The job number is logged in the IDoc status record with the status 64. The user under whose identification the IDocs are received must have authorization to release jobs in the S_BTCH_JOB authorization object.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi David,
also note 561880
Symptom
Data extraction in a BW or SEM BW system from an external OLTP System (such as R/3) or an internal (via DataMart) OLTP System hangs with the 'Yellow' status in the load monitor.
After a timeout, the request status finally switches to 'Red'.
Information IDocs with the status '64' are displayed in the 'Detail' tab.
Other terms
IDoc, tRFC, ALE, status 64
Reason and Prerequisites
Status information on load requests is transferred in the form of IDocs.
IDocs are processed in the BW ALE model using tRFC in online work processes (DIA).
IDoc types for BW (RSINFO, RSRQST, RSSEND) are processed immediately.
If no free online work process is available, the IDocs remain and must then be restarted to transfer the request information.With the conversion to asynchronous processing, it can often happen that no DIA is available for tRFC for a short period of time (see note 535172).
The IDoc status 64 can be caused by other factors such as a rollback in the application updating the IDocs. See the relevant notes.
Furthermore, you can also display these IDocs after the solution mentioned below, however, this is only intended as information.
You must therefore analyze the status text.
Solution
We recommend asynchronous processing for Business Warehouse.
To do this, you need the corrections from note 535172 as well as note 555229 or the relevant Support Packages.
The "BATCHJOB" entry in the TEDEF table mentioned in note 555229 is generated automatically in the BW system when you import Support Package 08 for BW 3.0B (Support Package 2 for 3.1 Content).For other releases and Support Package levels, you must manually implement the entry via transaction SE16.
Depending on the Basis Support Package imported, you may also have to implement the source code corrections from note 555229.
The following basic recommendations apply in avoiding bottlenecks in the dialog processing and checking of IDocs for BW:
1. Make sure there is always sufficient DIA, that is, at least 1 DIA more than all other work processes altogether, for example, 8 DIA for a total of 15 work processes (see also note 74141).
TIP: 2 UPD process are sufficient in BW, BW does not need any UP2.
2. Unprocessed Info IDocs should be processed manually within the request in BW;in the 'Detail' tab, you can start each IDoc again by selecting 'Update manually' (right mouse button).
3. Use BD87 to check the system daily (or whenever a problem arises) for IDocs that have not yet been processed and reactivate if necessary.
However, make sure beforehand that these IDocs can actually be assigned to the current status of requests.
TIP: Also check transaction SM58 for problematic tRFC entries.
IMPORTANT: Notes 535172, 555229 and the above recommendations are relevant (unless otherwise specified) both for BW and for SAP source systems.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.