I have a need to schedule reports based on report requests that get created in a report request application that stores these requests in a SQL server database. Each report request has an associated type and frequency.

The design that I have in mind for the WebFocus side goes like this:

a) Create one WebFocus procedure per type and frequesny of report.

b) Schedule this procedure based on the frequency.

c) Have this procedure read only the report requests that correspond to the type of report and frequency that it is built for.

d)Have this procedure create the reports and store to an MRE domain.

Here is where I think I have a problem!! If there are 3 report requests of a certain kind and frequency then the three reports that get created need to be stored as three different files (say PDF) in the MRE domain. I don't suppose the design idea stated above will achieve that!

Is there a better approach?

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

Let the front end generate the report filename (including, say, date + a sequence number); reference that in the front end's confirm message; and store it as part of the request record for use by the fex.

This message has been edited. Last edited by: j.gross,

The best way would be have it run multiple times for each request of that kind. In other words, the ability to schedule reports dynamically based on the request type, frequency and parameters. How would one do that?

Suppose it's freq is daily, at midnight;

Schedule a series of tasks to conditionally run the request at one-minute intervals (e.g., 00:00 00:01 00:02 ... 00:20). Each would run one pending request, if found, immediately marking it off in the database. Once the all pending requests have been marked off, the remainder of the scheduled series of tasks will find the cubbard is bare, and silently terminate.

If you'd like, the successive tasks could pass a distinguishing value which becomes part of the filename.

Save yourself the trouble. If you already have an application that creates and stores the requests, push the scheduling of the request back to that application.

dhagen, assuming that I add that functionality to the report request applcation, how would I trigger a WebFocus report from it?

Also, I can see this would require quite a bit of development effort. I am tending to lean towards J.G.s suggestion for that reason.

I can schedule this fex to run every couple of minutes and maintain a foc file to tell me which request got processed the last time to be able to pick the next one.

We have a couple of reports that run this way out of necessity. But we have to closely monitor/clean out the report caster logs as they fill up quickly when it is logging every couple of minutes.

I did a similar one few years ago. The solution is as follows.

1. let the front end application create a record with the fex name, parameters, ferquency with processed='N'

2. write a fex which wil read from this table (1) the record that matches the datetime (<=)

3. Schedule the fex in 2 to run every minute.

4. Update the record picked in 2 with processed= 'Y'

I am posting again on this topic after a long time.

I implemented this solution (per Bhanu's suggestion with a slight difference) as follows:

1. Stored report requests entered by users in a SQL Server database table.

2. Wrote a fex which reads the first request from the table that satisfies the selection criteria based on status and datestamp on it. (status 0 [new request] or 1 with date in last period [processed last reporting period with error] or 2 with date in last period [processed successfully in last period] )

3. Scheduled the fex in 2 to run every minute.

The fex (see below) has statements to
a) Update the database record picked in 2 with status = 1 and the datestamp (using a stored procedure)
b) Execute the fex that creates the compund report
c) Update the database record with status = 2 and datestamp (using stored procedure)



ENGINE SQLMSS SET DEFAULT_CONNECTION CONN1
SQL SQLMSS PREPARE SQLOUT FOR
-* Get all the merchant deck requests
select .......
;
END
TABLE FILE SQLOUT
PRINT *
ON TABLE HOLD AS TEMPFILE FORMAT ALPHA
END
-RUN
-SET &&RECCOUNT = 0;
-*
-READ TEMPFILE NOCLOSE &REQID.A10. &RPTID.I11. &&RPTNAME.A150. &RPTLEVEL.A5. &RPTLVLID.A10V. &DUMMY.I11.
-IF &IORETURN NE 0 THEN GOTO EXITPROC;
-*
-*
-SET &REQID=TRUNCATE(&REQID);
-SET &RLVLID = SUBSTR(17, &RPTLVLID, 7, 17, 10, 'A10');
-SET &OUT_FILE= &&MDECKFOLDER || 'output\' || &REQID || '.pdf';
FILEDEF RPT DISK &OUT_FILE
-*
-* Get the options for this report
-*=================================
EX GetOptions RPTID='&RPTID', REQID='&REQID'
-RUN
-* Get the list of stores to include
-*=================================
EX GetStors RPTLEVEL='&RPTLEVEL', RPTLVLID='&RLVLID', REQID='&REQID'
-RUN
-*=================================
-* Set the status for this request to indicate that it is being run
EX setstartstatus REQID=&REQID, TODAY=&TODAY
-RUN
-*=================================
-* Now run the report
EX m_deck GRPRTMNTH='&GRPRTMNTH', GRPRTYR='&GRPRTYR', MNTHNAME='&MNTHNAME', REQID=&REQID, RPTLEVEL='&RPTLEVEL', RPTLVLID='&RLVLID'
-RUN
-*=================================
-* Set the status for this request to indicate that it is completed
EX setendstatus REQID=&REQID, TODAY=&TODAY
-RUN
-*
-*=================================
-* Now rename the fiel to the right name format
-SET &DOSCMD='MoVe '| &OUT_FILE | ' "' |&&MDECKFOLDER|| 'output\'|| &&RPTNAME || '-' || &REQID ||'-'||&GRPRTMNTH || &GRPRTYR ||'.pdf"';
-*TYPE &DOSCMD
-DOS &DOSCMD
-RUN
-EXITPROC


The issues I am facing are
a) The fex seems to take longer to execute when compared to the time it takes when I execute it by hand (The reports on an average take 15 to 20 seconds when run by hand. There are some that take a minute or over).
b) Whenever a new instance of the fex is spawned (on the next minute) by the Reportcaster before the previous instance has terminated, the new instance seems to get hung up because the database table has been locked by the previous instance. I confirmed this by trying to open the table in the SQL Server Management Stodio. How do I unlock the table soon after the stored procedure(s) has run?

I had expected the 500 requests to get processed in less than 1000 minutes (or 16 hours), assuming an average processing time of two minutes per report, but it goes on for a much much longer time.

Any help in resolving these two issues would be much appreciated.

Your Stored Procs should have NOLOCK coded within:

  
/*********************
* Setup environment *
*********************/
SET NOCOUNT ON 
set @cmd = N'SELECT sum (isnull(c.acc_paid_amount,0)) AS ''acc_paid_amount'',
                    b.transportation_mode_type,
                    a.customer_key
               FROM Impact.dbo.branch a WITH(NOLOCK)
         INNER JOIN Impact.dbo.freight_bill b WITH(NOLOCK)
                 ON a.branch_key = b.branch_key
         INNER JOIN Impact.dbo.fb_acc_charges c WITH(NOLOCK)
                 ON b.freight_bill_key = c.freight_bill_key
		 INNER JOIN IMPACT.dbo.carrier d WITH(NOLOCK)
                 ON b.carrier_key = d.carrier_key
              WHERE a.customer_key = @CustKey
                AND b.' + @datetype + ' between @fromdate and @todate  
                AND b.freight_bill_status_code in ( ''A'',''D'',''P'')
                AND c.acc_charge_type = ''FUE'' 
				AND a.status = ''Active''
				AND d.Status = ''A''
           GROUP BY a.customer_key, b.transportation_mode_type
            HAVING ( sum(isnull(c.acc_paid_amount,0)) > 0)'

set @parm = N'@custkey integer, @fromdate datetime, @todate datetime'

exec master.dbo.sp_executesql @cmd, 
                              @parm, 
                              @custkey=@custkey, @fromdate=@fromdate, @todate=@todate 

Tom

Tom,

The stored procedures contain just an update statement for that report request.

Is there a way to handle the transaction (begin before calling the SP and commit after it is done executing the SP) using SQL passthru?

Yes,

You can Update/Insert/Delete via a Stored Proc, passing parrameters.

My example is passing a column name and 3 data values; the same can apply for your Update.

I would move the update to the very end of the process, then, after the Update:

UNLOCK TABLES;

HTH

Tom

Thanks Tom! I followed the SQL Passthru that updates the table with another that COMMITs the transaction using

SQL SQLMSS COMMIT WORK;
END


Works like a charm now.