Can I ask if anyone else out there finds this a pain.

The assumption is that if a rcaster job does not produce a report then it has errored.

There's lots of jobs that perform updates that don't produce a report. However I get a message in my inbox in the morning saying there's an error - so I switch the notify flag to never as a convenience - so if the job actually does go wrong then its not known about.

What is needed is an extra status of notify on no report (this can be the default for backwards compatibility) as distinct from on error.

Do others feel the same? If so I will raise a request for a new feature in 8.1 or thereabouts!

This message has been edited. Last edited by: Kerry,

I support it. It would be better to be able to define several tyes of errors and to be able to distinguess in sending that report to differt levels in the organization.
Technical problems should be send to tecnical people and others to a developer or to the people that need to get the report ("sorry no report today...")

It is a bit of an annoyance, of course we get it on fex that mostly create files and then the message shows the file layout. So torn, it would be nice to have the option to turn of the 'no report' error.

AMEN!!!
To add one more issue along that line - if you run a report that is burst and one of the burst sections happens to have no data(e.g. new policies by underwriter - if underwriter was out of town for the week and had no new policies) you get an error message as well saying "no report for burst value X" even though the report worked fine. It isn't really an error, there was just no data for that value.

Agree we are looking for the same NFR you are suggesting.

Thanks to all for advice and Darin for mentioning the case of burst output.

This would be my first NFR - does anyone have a URL. I think I need to check somebody has not done this already.

Wording would be something like.

Reportcaster needs additional notification thresholds.

Users could set notification threshholds which would apply whether the report was burst or not.

1. Always (even when the report has been sent to all potential recipients)
2. Not all recipients on distribution list were sent a report.
3. No report was produced for anyone.
4. There was an error executing the report
5. Never

The current settings would be translated to the new:

On error - 2. Not all recipients on distribution list were sent a report.

Always - 1. Always
Never - 5. Never

Burst distribution would trigger all threshholds. Non burst would trigger all except 2.

Has anyone got any suggestions to add to this - I usually miss something off

This message has been edited. Last edited by: hammo1j,

Does anyone know if ReportCaster is still a 3rd party tool...or does IBI have control now...

3rd party ??? Never heard that one, just two different development areas and code enforcement is not always 100% the same.

There are way to handel both of the items addressed here so far.

1. have a -INCLUDE at the end of you focexec that does not produce a report, that reads the famous car file and print only 1 line and send it to the local ftp server on the box into a temp folder that gets cleaned up every night or on reboot. This way RC will produce a report but who cares where it goes call you care about is the local file being created.

2. on jobs where the bursted receiver does not get a report. change report caster to use a dynamic list. Have a focexec that create the list with the bursted values and receivers email address. This way who ever does not due a report will not be on the distribution list.

However, I do agree with everyone that having a setting for report caster that can be overriden by each job would be great.

Hope this helps.

good idea Texas, with a couple logistical problems. Also becomes a bit of a management issue when you're sending a single burst value to multiple users (yeah, MacGuyver would work here) or email addresses are not maintained somewhere - apart from having to run ANOTHER procedure to get the list (against a million row table). There should be a simpler way to avoid an error message for "no output."

I requested this as a NFR last year (case 21882033). At that time there was a note that we were the 4th customer requesting this.

Someone has pointed out that the case where a burst value was contained within a report with no corresponding distribution value might be considered an error.

This does not fit in with the threshhold scale and would be catered for as a separate flag.

"Notify when no distributee for burst value."

Another event that needs to be catered for:

Task error:User termination via KILL_RPC flag.

KILL_RPC should not always be an error.

Does anyone know the link to the NFR page?

John,

NFRs are raised just like any other case with the exception that the first three chars of the subject should be "NFR".

Don't raise too many!! lol

T

Release 764 (currently scheduled for late Oct 2007) and Rel 718 (currently scheduled for Nov 2007) will contain a new feature to respond to the many NFRs for the ability to categorize the condition of there being no report to distribute for a full report or a specific burst value. This is a new ReportCaster Server configuration variable named: Default Processing for No Report to Distribute
The default is set to ERROR (as this is the default behavior) and can be changed to WARNING.
When set to WARNING the log report will contain a message (in orange text) to advise of the condition and error notification is not distributed.
Phase 2 of this enhancement will be in the next major NF Release (currently referred to as Rel 7.7 targeted for 2008) to add a scheduling option that will display the default value and the user can set the value within each schedule. So some schedules can classify having no report to distribute as an ERROR while others can be WARNINGs.
There is also another new ReportCaster configuration variable in Rel 764 and 718 related to report distribution for when the ReportCaster Distribution Server receives a FOC message back from the WF Server the scheduled job ran against. The new configuration variable is:
FOC Message Numbers to be Processed as Warnings
This feature allows you to specify which FOC message numbers that are returned with a report are to be handled as WARNINGs and the Distribution Server should distribute the report.
This feature also has a Phase 2 implementation planned for Rel 7.7 for the per schedule option.
I hope these features provide the flexibility that you need.
Please do keep submitting new feature requests. You can submit your requests related to the new features I have outlined by opening a case with Technical Support and reference these two projects.
Project 82617 Configuration Variable for Notify When No Report to Distribute
Project No: 82616 Report Distribution When FOC Messages Received

Thanks Susan for that very informative update.
I would like a 3rd setting of NO Warning at all if you are creating something that would never have anything to distribute...but guess this will work

That's a big YES from me as well.

a great step forward, but for me, not as useful until it can be handled on a per schedule basis - some reports I want any error message, other reports I want to ignore "No report for burst value" or "No report to distribute". Sounds like that's in the works--

Well, I need a bit more functional definition of what you would like the NONE option for the config variable 'Default Processing for No Report to Distribute
' to do differently than the WARNING option.
Keep in mind the ReportCaster Log information is a history of the schedule job execution. It should include information as to whether there is or isn't a report to distribute as this is information to confirm the schedule job's processing. The request This is important because ReportCaster interacts with services that deliver the report, such as email, which can have its own issues at times.
So.. with my product mgr hat on...the only difference between the 'WARNING'and 'NONE' options would be the message in the log report would not indicate the message is a WARNING and hence the color of the message would be gray (not orange). Remember also that WARNING does NOT distribute the ERROR notification which has been the focus of the NFRs and discussion.

ReportCaster Log file shows message in red color: "Unable to retrieve data for the distribution list". I've changed "Default Processing for No Report to Distribute" from Error to Warning and restarted Distribution server. It worked for few days (I didn't see those error messages in Log file for few days). Now messages coming again. I didn't make any changes to WebFocus & ReportCaster settings.

This message has been edited. Last edited by: Seva,