Hi all,

Some of our users do not want to receive an email from the Report Caster if the report is empty. We currently handle this by checking &LINES in the report. If &LINES is zero, we jump to -EXIT.

However, to stop the Report Caster sending us an 'Empty Report' error notification, we have to change the job to ‘Never’ send out a notification. This is not ideal as the report may crash due to a genuine error and we won't find out!

Therefore is there another way, to not send a report if empty and to also be told if the report has a problem?

Cheers

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

Here's a couple of things. You should NOT schedule jobs in RC that have a -EXIT. This causes problems with RC when encountered because the process stops prematurely not allowing RC to finish what it needs to do.

There is a parameter called &&KILL_RPC that you can include to cancel further RC processing.

-SET &&KILL_RPC = IF &LINES EQ 0 THEN 'Y' ELSE 'N';

If at any time the value of the parameter is set to 'Y' then RC immediately stops. no emails, no reports. A log record is written out and that's it. However, you may also want to test &FOCERRNUM to make sure that the problem was truly zero records and not a report crash.

Darin,

Do you know what that approach does if you are bursting on several E-mail addresses and some get reports on a day...and some do not?

&LINES wouldn't be zero in that case, I don't think.

If bursting gives records for some but not all users, that means that &LINES does have a non-zero value. The bursting is done AFTER the report finishes, based on the results. So processing will continue as usual. Only if there is no data at all to be distributed Darin's approach will kick in.

it does not test per burst value - only for the total report. IBI has been messing around in the latest version to allow for some different notifications based on whether or not a specific burst value contains data rather than sending an error message. This was always an annoyance to me because in many of my jobs, all burst values don't always have a report (in fact, they almost never do) so I almost always get an error report, when there really was no error except "there was no data for burst value xx " I can't remember what the latest functionality was but they didn't change it in previous versions and I'm not on the latest. Might be able to find it by searching techsupport case notes or the forum.

We just recently had this start happening for one of our reports and I haven't had time to play around and see how to fix. Thanks for the info.

I have a scheduled job that has several tasks perform on the same dataset. I don't mind sending one empty report to the users but not all. Is there a way to do it?

Hua

Not exactly sure what you mean, but you can probably use the same method described above. After each task, test &LINES and add 1 to a &&counter if it's empty. After the last task is performed, test the &&counter to see if ALL reports were empty then set &&KILL_RPC='Y'. If each task in the job is executed on its own thread (agent), you might have to -WRITE and -READ to a file to get this to work as the &&var may not be perpetuated through completion of all the tasks.

Darin,

Sorry, I should've give you more detail the first time. Say I have 4 separate tasks/threads/agents/fexes(how ever you call them) scheduled in the same job. One fex produces the summary and rest are various detail reports. I like to stop the job once the summary is empty and email ONE empty report to the users.

Hi Darin,

Thanks, what you suggests sounds perfect....however I can't get it to work?!

Test fex:

TABLE FILE CAR
PRINT *
WHERE COUNTRY EQ '&COUNTRY';
ON TABLE HOLD AS TEST
END
-RUN

-SET &&KILL_RPC = IF &LINES EQ 0 THEN 'Y' ELSE 'N';

TABLE FILE TEST
PRINT *
END
-RUN

I run a Report Caster where &COUNTRY is set to 'ITALY' and I get a report containing 5 lines.

I then change this to 'XXX' and I still get an email error notification stating empty report, which is what I am trying to avoid (Report Caster set to only report on error):

quote:

BTP1010 Starting worker thread
BTP1020 Starting task: Task 1
BTP1020 Task type: EDA RPC
BTP1020 Procedure name: dev/car
BTP1020 Connecting to server EDASERVE with execution id iadmindev
BTP1020 Executing focexec.
BTP1020 No report to create.
BTP1020 WARNING. YOU REQUESTED PRINT * OR COUNT * FOR A MULTIPATH FILE
BTP1020 Task finished.
BTP1010 No report to distribute.

Any thoughts?

Mark

By using the &&KILL_RPC you are in fact forcing an error. So RC sends you the error report.
What we do is use outlook to filter this kind of error reports and delete it without reading.
(the system reads the line "no report to distribute")

Hua

How about starting your own question?
It's a bit confusing when people interrupt with posting more or less new issues in other people cases.

We do want to answer your question of course.

I apologize for cutting in the line. Hua

quote:

Originally posted by FrankDutch:
Mark

By using the &&KILL_RPC you are in fact forcing an error. So RC sends you the error report.
What we do is use outlook to filter this kind of error reports and delete it without reading.
(the system reads the line "no report to distribute")

Hi Frank,

Yep I guess that is one way of dealing with it, however from reading Darin's post it sounds like we should be able to avoid the email being sent out at all?

If this isn't the case I think we will have to go with the Outlook method, however I think this could be a nice thing for the IBI guys to look at and perhaps add to a future release?

Cheers

Sorry - I seem to have created a little bit of confusion. The determination to set the &&KILL_RPC flag must be executed as a pre-processing procedure (with an ON TABLE HOLD). This determines whether or not the scheduled task(s) should run. Once the schedule tasks begin to execute, they will all run until completed. The use of this flag is documented in the RC Administration Manual (mine are 7.1.3 and it's in appendix C) I don't know where it is in other versions. Pre-processing procedures are also discussed in the same manual.
Sorry if there was a mis-direction there.
My suggestion would be to run your first report (using a parameter to determine whether it is pre processing or not to branch around the HOLD), and set &&KILL_RPC is no records are found. Might be a little overhead, so you'll have to determine if the solution causes another problem.

Mark

Yes, it is possible to suppress the error messages, but then you will never get an error message also not if there is an other reason the process did not work.

It's a matter of settings in this special RC process. (some check settings)

quote:

"no report to distribute"

If you have a corporate spam filter on your mail server block it there.

What about : SET EMPTYREPORT = ON. Or, -IF &RECORDS EQ 0 THEN GOTO NoDataToShow ; Where NoDataToShow contains a -HTMLFORM BEGIN / END or a DEFINE / TABLE FILE request which produces a No Data To Show message?

Just some good thoughts that worked for my at previous locations...
-Doug

Nice idea Doug, but what was the question?

quote:

How to not distribute Report Caster if report is empty

your suggestion creates a report that informs the receivers of the report that there is no data.
Nice to know, but if you just do not want a report if there is no data ???

It's like receiving an empty envelop!!!

Good point... Oh, the question... And a alternative solution...

Actually, the client will get what they request. However, what about 'Positive Reporting'? Would the recipient, who did not get their report, think that they did not get it because there was no report to deliver or was it due to a system error and they did not get their report which could be critical. Perhaps Mark66 should go back to the client and present this scenario.

IMHO... - Doug

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

In Release 7.6.4 a new setting was added to the ReportCaster Configuration Tool labeled 'Default Processing for No Report to Distribute'. This value of this setting is 'Error' by default. This means that a No Report to Distribute condition is an error and triggers error notification. If you change this setting to Warning then a No Report to Distribute condition is considered a warning and does not trigger error notification. This is a global setting whose value affects all schedules.

Thanks Gerry that's nice to know, I suppose you use 7.6.x...

If you update your signature it's easier to know who is using what....

Gerry's suggestions worked for me for few days. Now I'm getting emails and Log file shows in red color "Unable to retrieve data for the distribution list". I didn't change any settings in WebFocus & ReportCaster. Any ideas why it stopped working?

How and where is your distribution list organized.

My distribution list comes as a result of WebFocus procedure. This procedure retrieves data from SQL 2005 and it is scheduled to run every 1 minute. If there are records returned by procedure then it will send report by email (another procedure called to generate report) to users. If there are no records returned by procedure then there is no email to users and I don't want to get email notifications about error (no data should not be considered as error). However, I do see message "Unable to retrieve data for the distribution list" in the ReportCaster Log file and I receive emails about error every 1 minute despite I selected "Warning" in "Default Processing for No Report to Distribute" setting. The simplified procedure for distribution list below:

 ENGINE SQLMSS SET VARCHAR OFF 
SET SQLENGINE=SQLMSS
ENGINE SQLMSS SET DEFAULT_CONNECTION 811DEV 
SQL SQLMSS PREPARE SQLOUT FOR
SELECT DISTINCT APAN8, EAEMAL FROM F085520W, F01151 WHERE APAN8=EAAN8 AND EAAN8 IN
  (SELECT DISTINCT APAN8 FROM F085520W WHERE APESIGN<>'' AND
  DATEDIFF(MI, CRPDTA.sJulianToNormalDate(APUPMJ) + ' ' +
  CRPDTA.formatMilitaryToStandardTime(APUPMT), GETDATE()) < 2)
END
 
DEFINE FILE SQLOUT
  APAN8/I8 = APAN8;
END
 
TABLE FILE SQLOUT
  PRINT
    APAN8
    EAEMAL
  ON TABLE HOLD AS HFILE
END
-RUN
 
-* Procedure for bursting (see page 3-23 in ReportCaster manual).
SET ASNAMES=ON
TABLE FILE HFILE
PRINT APAN8 AS 'VALUE'
      EAEMAL AS 'DEST';
  ON TABLE PCHOLD
END

But as far as I know this only creates your XML mail address list.

I had some problems with this lately and I changed this to...

....
DEFINE FILE SQLOUT
  VALUE/I8 = APAN8;
  DEST/A25=EAEMAL;
END

TABLE FILE SQLOUT
  PRINT
     VALUE
     DEST
ON TABLE PCHOLD
END

But is it necessary to do this every minute?

Yes, this procedure creates only email adress list. Another procedure creates reports which are sent to those email addresses. I had no problems with this code in WF 7.1.6 and it works in 7.6.4, except errors sent to me when no records returned by procedure (only in 7.6.4). It is necessary to do this (run procedure which creates email address list) every minute according to functional requirements.

quote:

Originally posted by Seva:
Gerry's suggestions worked for me for few days. Now I'm getting emails and Log file shows in red color "Unable to retrieve data for the distribution list". I didn't change any settings in WebFocus & ReportCaster. Any ideas why it stopped working?

Seva,

In your case it hasn't stopped working. You are getting messages because "Unable to retrieve data for the distribution list" is an error not a warning. Without the distribution list the report can not be distributed.

This is a very different scenario than "No Report to distribute". Check your edaprint.log for any errors on the fex that produces the distribution list.

Cheers

Stu

I suspected that message "Unable to retrieve data for the distribution list" may be different from message "No Report to distribute". In my case it is not clear what is the difference between these messages because procedure open_enroll_address.fex runs every 1 minute and usually there is no report to distribute every 1 minute. Which is fine, but why do I get errors "Unable to retrieve data for the distribution list" in Log file and by email? However, if the records exist (when employee submits Open Enrollment info, record with time stamp is inserted into database) then reports are distributed fine.
The interesting thing is that after I changed setting for "Default Processing for No Report to Distribute" from "Error" to "Warning", I did not see errors "Unable to retrieve data for the distribution list" in Log file and I did not receive emails with these errors for few days. After few days I'm getting the same errors in Log file and emails. I did not touch any WebFocus or ReportCaster settings during these few days.