So your last delta load happened on 10.07.13, today is 16.07.13. I feel there would have been some delta records for sure.
Run this program : RSC1_DIAGNOSIS in SA38 or SE38. If you find any records with NOSEND status, then they will flow to RSA7. If nothing found, then there is genuinely no new delta since 10.07.13.
In RSA3, you need to select the Target system also while running and increase data calls too.
Regards,
Suman
Hi Liesel,
Info:
For data source 0FI_*_6 , delta set for one time activity in a day. if your init was went fine to day, next delta records will come into RSA7 on next day. plese check the note 485958.
As you said 10/7/2013, init load, then after that each day delta loads needs to process.
Coming to issue:
please try to run any another data source at RSA3. if you gets data, thats fine.
if not then there might be an authorisation issue.
Take Ecc team colleaue id and check for full mode at RSA3 with fiscal year selections. with his/her id if you get data then its authorisation issue.
but extrcation was happening thru bw background user id.
please check in that way also.
Thanks
Hi Raman,
thanks for your prompt reply, do you think after we filling setup table it will extract all the DOC_NO from the base table ? does it have any condition which will exlcude certain doc_no? I don;t think it will extract all doc_no base on base table.. I still need to find why the reason , base on your comment it give me some clue , but it still not meet my issues.
I take some another sample here..
Datasource Base Table
2LIS_11_V_SSL VBAP ( EBELN)
DOC_NO ,
60000008 (Coming from rsa3)
30000001 (Not coming),
I check both DOC_NO in VBAP table, and both exits,
https://www.dropbox.com/s/50pzbbteqz3ts64/DOC_NO-Not%20in%20rsa3.XLS
But the 30000001 exits in 2LIS_11_VAITM. The only difference was this doc_no was schedule agreement. Does 2LIS_11_V_SSL will not extracted the schedule agreement doc_no? I did check all the doc_no which under schedule agreement not extracted under 2LIS_11_V_SSL
is that any of SDN note regarding this matter?
Hi there,
I am doing some analysis on standard extractors. Please can you let me know what the key fields are of Extractor PM_TASKLIST_ATTR? And how can I find this for other extractors?
Many thanks
Michelle
Hi Edi,
if possible try copy the same data into Dev environment.
Try debug the extactor at RSA3, select debug check box. its may give some clue. why its not pulling doc no.
Some times there might be chance of extraction logic may exclude as per the logic. for that we need to debug the extractor.
"Does 2LIS_11_V_SSL will not extracted the schedule agreement doc_no? I did check all the doc_no which under schedule agreement not extracted under 2LIS_11_V_SSL"
Might be, its not pulling them. just debug the extrcator you will find the reason.
Thanks
Hello, Amol.
It's interesting idea. Сan you describe more about it?
Regards, Fanil.
To know the data size in MBs , you should contact your BASIS team to check it in DB02 t-code for all your PSA tables. You have to give the PSA table names to them.
Hi gurus,
I am new to BI 7.3, wherein i have succesfully fetched data from info provider to PSA and now wants to update multiple data targets from the DTP created (system is showing 3 data targets under TAB "Data Targets" of info provider but only main data set under which the info provided exists get loaded from PSA while executing DTP.
i came to know that this can be done by executing process chain, wherein i can define steps from whcih multiple data targets will get simultaneously updated from execution of single info provider.
kindly guide to resolve the issue.
Regards,
Hi Shan,
At BI level extrcation only is not the work, there are lot of back end jobs daily may run as per the business needs.
If your basis person, i think you can easily anlyze why this much growth happening on daily with help of db team.
otherwise take DB team help and monitor one day. they can find where/how the data base increasing day by day.
check and implement below options:
1. if possible delete the PSA, change tables with requried apporavls
2. is BW team performing compression?
3. if any used cubes/dso are theren, try delete with help of approvals
4. deletion of SLG1 logs which old 90days
5. reorganising logs
Thanks
thanks for repaly
I am not clear please give me more solution for to solve this issues.
Hi Sudeer,
Some times it causes due to DataSources in the source system were changed.To resolve this you need to replicate the DataSources for the source system that you're extracting out of.
http://scn.sap.com/thread/1418801
May be this thread help you.
Regards,
Bhaskar
Hi experts,
I scheduled the datasource 0HR_PY_1 but it taking lot of time almost 18hours is over still it showing yellow and can any one idea how to solve this issue.
Regards
RK
Hi experts
Thank you very much for your replies.
Regards
RK
HI,
Are you running Full load?
18 hours is too long. Please check the extraction job log in SM37 in ECC.
Do you have sufficient BGDs available in ECC?
How many records have come to BW in infopackage monitor?
I suggest you to cancel the job in ECC and make the "Total technical Status" to red. Please execute the infopackage again after checking the ECC system status with your BASIS.
Regards,
Suman
Hi Ram,
Seems like something went wrong. if you trigger info pack then check job in ecc side.
How to check job:
From BW server go to info pack monitor screen, from header tab, Copy request id.
go to ECC system login, Tx - SM37, Job name: BI<copied request id from bw>
User id: *
Status: Active,cancel and finish
Date Jul 18 2013 to July 20 2013.
Execute it, you will get respective job. select that job and click on job log details icon from tool bar.
You can see the whole data pockets how its processed and how much time its taking or took. whether job was finished or. not.
If you see any error there please share here.
You can check T code SM58(in ecc side, its LUW's may hanged), if you see any red status there, take basis team help.
if its full load. cancel this job and delete request at PSA. re start again.
Ask basis team to keep on monitoring the SM58(ECC side) , if they see any queue, immediately they need to clear.
Thanks
Hi All,
I was able to rectify this error.
The issue was that in RSH1 the 2 hierarchies which were pulled in, 026 and PRDHA of infobject 0MATERIAL were not activated completely. When I tried activating each of them individually it stated that 0HIER_HIEID is active byt the object status is inactive.
Hence I refered SAP Notes and found one.
Note no: 1778181
This note suggests to run the report RSDG_IOBJ_ACTIVATE for the object that shows the error.
Hence I ran the report for 0HIER_HIEID.
The hierarchies were then activated without any error.
Now the Job for the Hierarchies LKLS and LPRH completes successfully and is no more in the yellow warning state.
Thanks to all who responded with your ideas and suggestions.
@Suman : I have not changed the LED settings to green as I thought it might be a change to standard. Anyways thanks for that too.
Regards,
GKR
Thanks for the update. Good to know that your issue is resolved now.
Thank you Ramesh for the update with solution. Please choose your own reply as Correct answer and close the thread. that would be more helpful when others come across the same kind off issue.
Hope you understand.
Thank You
Ok,
I shall do so. Thanks.