Question:
Ok...
My problem isn't as dire as I once thought. Here is what has transpired.
While the delta init load does fail, all records are processed correctly and accounted for. It seems the reason for failure, is that the Idoc sent is bigger than BW can handle... hence "39065 records are sent from R/3 and only 13020 are received"... at least this is what the Extraction message is, and Transfer message for some of the failed IDoc's is:
"sent, not arrived; IDoc ready for dispatch (ALE service)" But when I check the source, there is no IDoc waiting. Huh??
What ends up happening is that the data packages all end up processing successfully (the good news), but I have to manually change the status message from red to green in order for the data to post to the cube, and finish the delta initialization(the bad news). This isn't a show stopper, as we're a small shop but this shouldn't be happening.
Has anyone run into this before? I need to be pointed in the right direction here, to insure that my two systems are communicating properly. This has got to be some simple communication config thing; I just don't know where to look.
Were running 3.0b lvl23 and 4.5b lvl29
Thanks in advance for your help.
Z
Answer:
Did you check the status tab and see what it says before messing around with the QM status? It may have said the the process is still running or somethign, otherwise it would show error messages at the bottom.
Check the settings on the table (in either system, R/3 or BW) ROIDOCPRMS. If there are no entries, the system uses default values fo 20 Kb for packet size, 1 processor for the job and frequency of 10 (# of Idocs per packet)
If, however, there is a failure, there would a blue left pointing arrow at the bottom of the status tab, which will allow you to jump to the source system and process the idoc (TRFC) or LUW (logical unit of work).
_________________
Keep smiling
Answer:
Hey, first off thanks for the response!
Yeah, I did check the status tab and I let the job run over night which eventually kicked out and turned red, I then went through the whole step by step analysis wizard, but to no avail... the text is as follows:
***********************************
Non-updated Idocs found in Source System
Diagnosis
IDocs were found in the ALE inbox for Source System that are not updated.
Processing is overdue.
Error correction:
Attempt to process the IDocs manually. You can process the IDocs manually using the Wizard or by selecting the IDocs with incorrect status and processing them manually.
*************************************
Now when I select the problematic IDocs, and select update manually, I'm told that "This IDoc is already updated and cannot be updated again"
Now I do see the left pointing blue arrow that takes you to the tRFC log in the source... and when I use the inputted selection criteria (display period, username, etc.) I don't find any errors... odd huh?
I did check ROIDOCPRMS in both the source and BW and it looks like the defaults are being used, as there are no entries in those tables.
I’m confused because the errors lead me to believe that these IDoc's didn't make it across at all, thus my initial fear of missing data. However, when I looked at all the processed data packets... and after a bit of addition... I'm pretty sure that all the data made it across as the number of processed packets equals the number of sent records. I’m at a loss as to why, after all the packets processed, the load was waiting for something (perhaps a return code or something??) that says "hey I'm done sending IDocs and everything was sent successfully"
Any thoughts???
Thanks again
Z
Answer:
Hi Z
I am experiencing a similar issue here on my system (seems to occur more when extracting from CRM than extracting from R/3 though).
In the monitor, I get two types of red requests:
- May have gootten all records e.g. 126 of 126 records
- Got no record e.g. 0 of 2000 records.
My Basis team is saying that it could be resource contention as I may be running to many jobs at the same time?
I was wondering if you obtained any resolution on this issue or opened an OSS note with SAP.
Thanks for sharing.
C
Answer:
We've posted an OSS request but have yet to hear back... will keep you posted
Z.
Answer:
So for what ever reason the status IDoc 2 is not being sent in a timely fashion, i.e. it is never leaves status 30 in the source. So the BW job times out eventually, and fails. By periodically running program RSEOUT00 in the source we're able to clear out the status IDOC's. We set up a variant for BW with the following info:
IDoc type: RSINFO
Port of Reciever: A000000018
Partner number of recipient: "name of BW box" ours is BWDEV
Logical message type: RSINFO
We schedule a job to run every hour with this variant and works like a charm!