As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at email@example.com and provide your corporate email address, company, and name.
I've written one WF533 report for RC and the same one accessed by UI front end. Both reports are supposed to be exactly the same output. The RC report just mails a daily snapshot, the UI version allows user to enter their own From and To date, plus a few other options.
I originally felt that RC was different enough to keep all RC reports in one folder separated from the rest of my UI reports(it was new to me two months ago). Now, I'm trying to figure out if I should modify the RC code to make it callable from the UI and RC scheduler. This would eliminate maintenance of two files that do almost the same thing but it would make for some ugly code, and I like clean code.
Has anyone else had this scenario and what is your experience or recommendation?
Thanks in advance for your comments!
Posts: 23 | Location: Daytona Beach, FL | Registered: February 07, 2005
You can read the documentation to see exactly how, but RC allows you to pass parameters to your reports so that they perform properly. In the above example you could pass a parameter that tells you fex to use today's date for both "from" and "to" dates. I hope this is what you were looking for....
You should keep only a single version of a procedure to ensure that any future enhancements are automatically reflected in your RC and UA versions. Like Boogarweed said above, you can run your focexec with any parameters you choose from RC, so there is no need whatever to keep two versions.
Posts: 44 | Location: New York City | Registered: May 23, 2004
We've approached this such that we set -DEFAULT amper variables to the values the Caster requires. For the ad hoc/on-line access, we prompt for the variables and overlay the default values. Works well for us.
Posts: 118 | Location: DC | Registered: May 13, 2005