I'm working in a multiple-developer group where we need to create a lot of ReportCaster schedules that send reports to a report library. Each report has a corresponding user access list. We would like to be able to use the same user access list for multiple reports wherever feasible, but ReportCaster always creates a new schedule in the folder of the creator, and within that folder any user access lists created by another developer are not visible. We considered cloning all our schedules under one person's folder, but we found that ReportCaster will not let us create a new user access list under somebody else's folder. Also we can't log in as that user, because we work in a Siteminder environment where there is no login screen - the developer's id/pw are automatically passed from the network to ReportCaster under the covers. Ideally we'd like to have all the schedules and user access lists under one folder, so we don't need to search through multiple folders to find what we're looking for. This could be even more of a problem as developers move out of the group.

Does anybody know a solution to this puzzle to make the ReportCaster environment more manageable?

This message has been edited. Last edited by: Richard the Blackhearted,

Sounds like a job for the API. If you build your own custom interface to ReportCaster, you can use the API to schedule the requests. That way you should be able to bypass siteminder (you are connecting to the server directly) and schedule all the jobs and lists can then be created under a single user id.

We've followed this methodology:

1) All 'production' jobs/schedules are run out of a single RCaster user's library/folder. "His" name is 'rcaster', which shows up nicely when one monitors the server's agents.

2) We defined a UserID in MRE and ReportCaster that is used as the logon ID/Pswd in every production schedule-task. (Production is run by 'rcaster'.) Nobody ever logs into MRE with that ID.

3) IT production control persons log onto ReportCaster as 'rcaster', which gives them access to update old schedules and create new ones. Because report developers don't know the password to 'rcaster' they can't touch production schedules.

4) When developer's have completed their work, they tell production control about the RCaster schedule they used to test-run the report. Production control then logs onto 'rcaster' and uses the Clone facility to copy (install?) the developer's schedule into the 'rcaster' folder. (In older releases 'Clone' is not available and they do a two-window copy-n-paste to duplicate developer's schedule content into 'rcaster's new production schedule.) If the developer has not followed proper naming conventions, the production control guy changes whatever is necessary to make the new schedule fit in with the others.

5) An additional thing we often remove the developer's ability to tinker with installed code by copying the *.fex from the developer's MRE or AppDir 'sandbox' into the application's production AppDir. The Production Control person adjusts the production schedule's Task content accordingly.

This technique also depersonalizes production jobs from a specific person's ReportCaster UserID. As production control people come and go, "Mr. rcaster" is still around running all the jobs.

Chris

dhagen, I've since had some talks with someone else in our company, and he's saying something like what you're suggesting - actually he says the Siteminder installation should have excluded ReportCaster control - we should be forced to log into ReportCaster, with Siteminder confined only to MRE and DevStudio interfaces. I'm going to pursue this with our middleware folks. Thanks for your input.

cburtt, what you're suggesting is similar to what we'd like to implement for our own procedures, except that in our case we're a very small group, and developers double as production control. I keep telling my boss we need a clerk, but all she does is laugh - budget and priorities, you know. If the group got bigger (I can dream, can't I?) we would probably need to have more rigorous production control procedures similar to yours - it's something to keep in mind, cuz who knows?