cancel
Showing results for 
Search instead for 
Did you mean: 

Scheduling sender file channel w.r.t to another file channel

PS23
Participant
0 Kudos

Hi

scenario is multiple idoc to single file scenario, wherein using collect idoc@R3 and RSEout00 sends chunks of idocs to PI, (i.e each chunk can have 80,100 etc idocs in it )

Now as per requirement i need to merge chunks in PI which i m doing using 2-ICO, first ICO handles (idoc-file)appends idoc chunks to one file another adds timestamp and pushes it to desired location.

But problem is how will second ICO sender file channel will get to know that all files are appended and hence we can pull. AvailabilityTime Plannig on first sender channel not feasible as the interface runs on adhoc basis i.e it can be run anytime in a day.

Can anyone suggest if any workaround so that sender channel pulls exactly after all files are appended.

*chunks arrives in delay of 2-3 minutes and max to 15/40minutes

Thanks

Accepted Solutions (0)

Answers (3)

Answers (3)

PS23
Participant
0 Kudos

Hi All

Thanks Anupam for your amrt advice which really worked.

As there was no particular time for the interface to run instaed was to run once a day hence the 23:59 was the time when final channel was scheduled and assuming all the run wud hav happend by then.

iaki_vila
Active Contributor
0 Kudos

Hi,

You are using an ECC to send the IDOCs. My suggestion is to control the sender channel of the second scenario externally:

The idea is to start the second scenario from the sender (if you have a dual PI system you could do it in the PI system). From ABAP is easy to do the wait time, also if the file is deposited on a shared NFS between ECC and PI you could check in the ABAP how many time the file hast not been acceded to throw the second scenario.

Regards.

PS23
Participant
0 Kudos

Thanks Vila,

Indeed it is a nice feature and hav never used before, though m still exploring the ste-by-step guide to have a look, but had few doubts w.r.t feasibility to my scenario.

I need to use this for my 1st ICO receiver and second ICO sender as well. As sender has to start processing only after receiver file channel in 1st ICO has finished appending all the files in single.And number of chunks processed by file receiver can be more than 30 and and each of size (can be 2mb) and delay in arrival of chunk in PI cud be max (45mins) min 3min.

At r3 end collect idocs is used, and rseout00 is used to send the generated idocs in chunks/bundles.

And this is absolutely dependent of the size of idocs generated that hw many idocs chunks and how many idocs in each chunks are created.

*PI7.4 single stack is being used

I am unable to align it with my scenario.Can u suggest.

Thanks

iaki_vila
Active Contributor
0 Kudos

Hi,

As you have different idoc's in time you can´t use "Msecs to Wait before modification Check" because you never can assure if any idoc is lacking to be processed. Then, when you know all the idocs are processed?, and more important where is this information available?. From my point of view, i think your ECC system can know when all the idocs needed have being processed. To suppose a period of time can be a risk in my opinion, if one day one idoc has a fail and this is not processed in PI correctly?. I think the control from ECC can be an idea, may be with NW BPM as well. On the other hand we can think in java proxy on PI or to deploy an own java development, in my opinion a bad idea for further PI updates; to create an own module adapter to control the situation, i am not a friend to own module for this specific requirements.

May be another SCN member had a better idea, i think this is a interesting thread and all we can learn something

Regards.

PS23
Participant
0 Kudos

Thanks so much for ur options,

Controlling from R3 has a problem as when RSEout00 is run and even idocs appears processed in R3, the delay time is observed in PI after that. After Rseout00 is triggered the idocs arrival is observed with the delay of 30--45 min max sometimes..queue processing is EO.

iaki_vila
Active Contributor
0 Kudos

Hi,

Only a idea, if you set two receivers in your first scenario?, the second receiver, for example a RFC (from the sender ECC) that store in a Z table the IDOC xxxxx stored. May be Ockham's Razor says that this idea is a bit complex. You have Anupam suggestion as well, with Anupam suggestion the only problem that i see is how you can control that all needed IDOCs has been sent from the ECC, i am not a fan of the time delay, because there is always a possibility to pass that time, however you know better the business situation and to value if this possibility will never happen.

Regards.

nitindeshpande
Active Contributor
0 Kudos

Hello,


You can use "Msecs to Wait before modification Check" to make sure you are picking the file which is completely written.

This ensures that it picks only those file which are not modified for the time provided by you in the above mentioned parameter.

You can use this in your sender channel of 2nd ICO.

Regards,

Nitin

PS23
Participant
0 Kudos

Thanks Nitin,

Yes but will msec a solution when idoc chunks can arrive in delay of say 20--30minutes.

Lets say 1st chunk arrived at 10 am second chunk@ 10.25am in PI. Keeping that amount of time in msec feasible?

Rgds

anupam_ghosh2
Active Contributor
0 Kudos

Hi SAP PI,

                    You have to decide a time interval after which file should be read by second sender channel.  Target directory of first ICO (dir A) should be different than source directory of second ICO (dirB).  Write a script which moves appended files from dirA to dirB after every 40 mins(say). It is possible that the script moves a file before it is completely written. Thus the script must check last modification time of the file being copied and compare to present time of the server. If there is some difference in timings then only it copies else it waits for a minute and checks again. Sender channel in second ICO picks up the file from dirB.

Regards

Anupam

PS23
Participant
0 Kudos

HI Anupam,

Thanks for suggestion

Size of the file and and duration each chunk takes to reach PI is uncertain, Could be 20min for each bundle or less and then how may such bundles not sure. Last execution in PI i observed was 994MB file arrived distributed in 34 bundles. As there is no filtering and size reduction done at R3 end hence file with large number of segments arrive.

As the idea of script suggested , this , correct me if m wrong, cud b used wth deploying single channel which runs in append mode and at the end we concatenate with timestamp and checking modification check as u advised. I need to check its behavior w.r.t to last modification time idea mentioned.

Thanks,