on 10-03-2008 3:18 PM
Hi, I have a Data Load Process where the start routine is dependent on DSO data that was just previously activated. For some reason it looks like the the time before the load and the time after the DSO activation are close by just seconds.
The Data Load Routine will drop records if the activated DSO data is not available and this seems like what I am witnessing. I thought there was a way to configure the chain or job to wait until the previous is completely done. or did that go away with 7.0...
Is there a way to make sure the loading process doesn't start until the previous DSO activation is completed and the data is available?
Thanks!
Follow on processes dependent on activation do not have to wait for anyperiod of time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey, why don't you do this. In your process chain, between the ODS activation and the new load, add an 'AND' process. You can add an ADN even in a straight flow.
Right Click on the AND and add a time delay, like 60 sc OR 120 sec
This will make sure the Activation is completely executed before the next load.
Uday-Ram Chamarthy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi thanks for following up. Here's what I have.
Step 1. Load DSO A
Step 2. Activate DSO A
Step 3. Load DSO B (has Start Routine)
This DSO Load has a start routine dependent on the data being available in DSO A. Step 2.
I'm missing data in my DSO B. It seems like a few times the start routine may have dropped records, because the DSO B Start Routine Load requires a matching records in DSO A which I'm surmising may not have been available yet?
Would it be wise to put the delay after the activation and before the load?
Thanks for your advice!
Hey, that sort of inconsistency didn't happen to me yet. but, adding a time delay doesn't hurt either.
Meanwhile, you can do some investigation yourself. ake the start and end times of each processes within the chains and go to SM 37 and do the same. Here, carefully look at the end time of the ODS activation job (SM37 number) and start time in the Load Process (both SM 37 and RSPC) and compare.
Uday-Ram Chamarthy
You should be able to rely on the sequencing in the process chains. I've not had any problems on in the 9 months since we upgraded from 3.5 to 7.0 (SP15).
Is this a DTP load? I'd check OSS Notes. I noticed this these from SP19/20, but there could be more -
Note 1180301 - P19:PC:Data activated too early in DSO;RSM1 110
Note 1248575 - 70SP20: A subsequent process starts prematurely
Hi,
Interuppt concept :
If a process chain is only processed either in part or in its entirity if more than one start condition is filled, you use this process type to specify the additional conditions.
The chain is started when the condition of the start process is filled. However, the interrupt process will interupt the processing of the chain (as long as its status is "active") up until the point at which the condition of the interrupt process is filled. Should the start process condition be filled again before the interupt process condition is filled, the chain will start again and will only run up until the point of interruption. As soon as the interrupt process condition is filled, the system continues the last run of the chain only. The earlier runs remain unchanged.
The interrupt process schedules an additional background job that starts based on the relevant condition. Therefore the interrupt process is not really active during the interrupt phase; it does not use any resources during this time.
If the interrupt processes are filled before the start process condition, the chain starts as soon as the start condition is filled; the interrupt process no longer interupts the chain because its condition has already been filled. If the interrupt process condition is is filled again before the start condition of the chain is filled, this does not influence the chain. It is not stopped by the interrupt process..
so basically your interrupt will wait for an event like ex:..YABAP_YGTRFCEVENTRAISE_0035 ... so you can raise that event eother by some job or some program..bUt for you i think adding the waiting timw will be better option ..
hope i cleared you ..
Regards,
Shikha
Hi Kenneth,
If you have any dependency loads, you have to maintain same dependency in process chain.
please provide some more details.
Hope it Helps
Srini
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
87 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.