I would like users to be able to request reports so I am thinking of this process:

1. user requests report
2. our sql DB then writes a record to a table noting the report etc
3. our sql db writes a distribution file to an area on the ib server
4. we have an alert set up to look for new records in the table from number 2
5. we have a schedule on the alert that goes to the distribution file from #3
6. the user gets the report
7. the distribution file is deleted (want a new file for a different user requesting)

So question 1, will this work? I have read about doing an external distribution list and also how to set up the server to delete them when the schedule has run.

If I want the user to be able to just get part of the report (usually using a filter and parameter) do I instead set it up as burst so that the user gets the 'job' they need? And I am a bit confused on the burst mode - the value must be the first 'By' in a column report and second 'by' in a chart - what exactly does this mean? The first sort? or ?

Please note that we are using Business User Edition so we cannot go in directly and access 'code'.

Thank you!

This message has been edited. Last edited by: FP Mod Chuck,

Hi Melanie

Welcome to Focal Point! I think you will find it very valuable for getting help with your WebFOCUS development.

What interface are you using for the user to request a report?

We will be using our sql database - the user will log in and have reports they can request - so then WebFocus can monitor a table for the request.

Hi Melanie

That is a very different way of doing things than I have seen before. Is there a reason why the users just don't log into WebFOCUS BUE and just run the reports they are authorized to use?

These would be external users that we don't want to have access to our BUE.

Hi

I assume that you have an external web based application (outside of the scope of WebFOCUS) which allows the users to "order" the reports and choose parameters(filters)

1. You could consider upgrading your WF license ( to core based for example) and adding an additional WF client in the DMZ (connecting to your main internal WF server) so external users not registered within the BIP could access WF directly via URL or webservices (REST)

2. Another alternative is that your external web application will write to your SQL DB also the parameters/filters the users choose and then have an internal parametrized report caster schedule which will read the SQl Server records/ derive the parameters and send the reports. This is possible by utilizing Report Caster REST API for internal usage within WF. (you could publish and consume report caster jobs, utilizing simple TABLE FILE syntax to pass the parameters).
There also could be licensing implications in this scenario so I would recommend you to contact your local IBI office

Yours

Eran

Melanie

For number 3 if this is the txt file to use as a 'Distribution file' then that is fine. If you are writing a 'Distribution List' to the WebFOCUS repository you will need to use the WebFOCUS RESTFUL Web services API as writing directly to the WebFOCUS repository is not supported as you can easily corrupt it. The same is true for 4 and 5 if you are creating a WebFOCUS Alert and Schedule you will need to use the WF RESTFUL Web Services API to do that.

Hope this helps.

quote:

WebFOCUS RESTFUL Web services API

Thanks for the feedback Chuck - that is beyond my capabilities - we will work on some other method.

Thanks all!

If it's always the same report you could check out bursting in Reportcaster. I think it suits your need.

Make a join to a table where you put in the user, create a distributionlist with user and email (Not sure if with bursting you can have a dynamic list). Then run the schedule regulary or on alert and it will automatically create and send the report to the user.

The first BY in the report is the burst value. This value links to the burst value in your distribution list. Reportcaster will basically slice up the report and send each part to a correspondending reciever in a distributionlist.

If your report looks like this:
company,sales
abc,123
def,456

and your distributionlist like this

burst value, email
abc,user@company.com
def,user@anothercompany.com

then the first row is send to user@company.com and the second to user@anothercompany.com. You could also use wildcards in the distributionlist and [elsesend] in case no match is found.

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

Melanie

I didn't mean to scare you off. But using SQL directly to the repository is a big no no. The RESTful Web Services API is documented and not hard to implement. Here is a link to the documentation. http://infocenter.informationb...om/wf81rel/index.jsp There you will find a section called WebFOCUS RESTFul Web Services. When you open that up there is a link to download it in PDF format.

Thanks Chuck - I didn't want to use sql in the repository - was just wanting access to that 'external distribution list' option - which we don't have in the BUE version.

Frans:

quote:

(Not sure if with bursting you can have a dynamic list)

.

Yes, Buring supports the use of Dynamic Distribution Lists.

Melanie

I just installed BUE and yes you are correct you can only use a distribution list or e-mail addresses. I think you should request distribution file as a new feature.