I want to use a FileWatcher text file to run multiple reports on the 4th business day of every month. What I’m not sure about is that because these reports all have to run on the same day, I want them to use the same txt file to run using FileWatcher instead of creating a new file for each report, so instead of deleting the txt file after just one report running, I want it deleted after the batch of reports have been completed.
What you need to do is schedule the report to run “daily” AND when the filewatcher file is there. Then when the file exists, ALL the reports will be submitted. Just have 1 of them delete the filewatcher file and you should be good to go. The whole batch will be submitted before the the file is removed.
If you are on V6, you have the choice of whether the file is deleted before or after the report is run.
I’ve had the occasional problem with the file being zapped and the batch not going off as planned when one of the jobs was allowed to delete the file. Also, we often have multiple jobs running and slightly different times for load purposes that all look for one file. What I do to get around both issues is schedule an additional job to run at 11:00PM or whenever that does nothing but delete the trigger file. That has been very reliable.
This is what we have been doing but “what if” the batch didn’t get loaded and therefore that later filewatcher report that deletes the file never ran. Instead this unrun report will run the next day when that batch is successful and delete the file preventing the other reports from running.
Is there anyway to limit how long the filewatch looks for the file? I’m thinking no.
Another thing to be aware of here - if you need the reports to run at a specific time.
After the first successful run, if the reports are set to look for the Filewatcher file daily, it doesn’t matter what time you have scheduled the reports to run - they will run immediatley the file is placed there.
We had problems with this when we needed to run reports out of office hours, after a data load into the database completed.
Our ‘fix’ was to generate a dummy report that runs at the time required, and creates a text file - the Filewatcher file required to trigger the others.
It really is a pain when you can’t schedule your reports to run on set calendar schedules!
That seems like alot of effort. Why not just have your scheduler that runs the data load simply copy a file to the file watcher location after the last data file is loaded?
I did something similar by having the original trigger file kick off the first report, then having that report create the trigger for the second report, and so on.
It forces the reports to run sequentially, which while it wasn’t an actual requirement didn’t hurt anything. You could, of course, have a situation where this is not possible (time constraints, etc.), but it might be something worth looking into.
My reports ended up something like this:
Mainframe job sends original trigger file (trig1)
First report waits for trig1, writes out trig 2, and deletes trig1 at completion
Second report waits for trig2, writes out trig 3, and deletes trig2 …
.
.
.
Last job doesn’t write out another tirgger, but does send an email that the run is complete
This is probably too late, but I set a series of jobs up yesterday…
We use a tool called autosys to schedule events, in my case I run a script after the loading of data into our data warehouse.
To make sure all my reports ran, and that sequence did not mess up the completion of further reports, I simply had my script create one file for each report - I call them flag1 - flag20.txt They get deleted as each report runs.
I had considered chaining the reports; but if one failed, or if one ran before the other completed (eg, an error forcing a retry), I could see some number of the reports not being refreshed. This seemed a simple way to handle my reports, and I can add more by updating my script to create more flag.txt files.
I know this post is old, but I have this requirement also that needs to kick off jobs on BCA tied to a mainframe job ending. As I see it,
I can’t afford to have them run all at once (too many jobs for BCA at once and will error out) if tied to one file watch as suggested, but I also don’t need to have them run in any particular order. In fact, stream lining them to run one at a time, as suggested with previous job creating output file that subsequent job looks for to start, would take much longer and might jeporadize the completion of the batch of 50 jobs in one system running in a weekend.
Any suggestions on how to batch them so the first job in the stream kicks off tied to completion of a mainframe job and the 50 jobs run, but not all at once and not in any particular order?
I’m not a BCA configuration expert, but won’t the 50 jobs just wait their turn? I would think the configuration would limit how many jobs can run simultaneously. If 50 scheduled at once kills your BCA server(s), then to me you run that risk now (other users), not just because of your batch, right?
Alternatively, you could procedurally group your 50 jobs into five groups of ten, and have the five groups scheduled to start say, 15 minutes apart.
You are correct in that they wouldn’t all kick off at once but they’d kick off at their scheduled time and when the file is present (both conditions must be true). I was thinking they’d all kick off at once if there were BCA problems and the jobs didn’t run when they were supposed to, but we’d suspend the jobs and run manually if that were the case. We would just need to have the first job look for the file and then each subsequent job spaced out over time so more then a certain number of jobs (based upon server capacity) don’t kick off at once. They could be batched as you suggested.
Thanks Dwayne!!
This can all be control in the settings for your BCA. You can set the Max number of jobs running. Have them all scheduled for the same time looking for the filewatcher. Then have your Max number of jobs set to whatever your server can handle. Then that many jobs will run at a time. So if Max was set to 5. Five reports would start processing as soon as filewatcher was present. Then every time one finsishing another one will begin until all jobs are processed.
this is a bit off this thread topic but would anyone happen to know if its possible to set the filewatcher default setting to not delete the filewatcher file? I was wondering if we could set that via the value of the registry key (File Watcher) found in \My Computer\HKEY_CURRENT_USER\Software\Business Objects\BusinessObjects\5.0<user> User Prefs\busobj\BCS. I cannot find this key in 6.x and would also like to know if this is possible for Full Client 6.x and if so how?
(BOB member since 2004-01-05)
(BOB member since 2002-06-25)
(BOB member since 2002-06-17)
(BOB member since 2002-08-29)