If you saw my previous blog, you’ll know that I hate
excessive clicking. Well, I have a laundry list of annoyances that I have
chosen to share with you, internet. The next thing on my list is the management
and distribution of scheduled documents.
If you’ve used business objects for a while, you are familiar
with the scheduling system. It’s great; I can set up a document to be sent on a
recurring basis. However, it gets clunky when you need to send the same
document to a lot of people.
You've used this before
For example, you need to send an invoice to a bunch of customers.
This presents two unique challenges to the standard scheduling system.
- The invoice data must be personalized
- The people who will receive this invoice will be
different every month, as customers may join or leave at any time.
You wouldn’t even try this with the standard scheduling system. (Not without 3rd
party add ons, at least) It would be unworkable. You’d have to manually create
a schedule for every customer, set a parameter to filter the data and then
manually update that list every month. The manual intervention would be
enormous.
That’s why we have publications.
Now let’s dig into the specifics. A publication has a few moving parts.
- The report you want to send out. In this case, we’re using a monthly invoice report built in crystal reports
- The list of recipients. This is also a report built in crystal reports
- The publication itself
The Report
You can use any crystal or web intelligence report for this bit. Crystal has a few
more options when it comes to personalization. Specifically, you can use the report’s
grouping for personalization, which means you can run a single report for
all instances and allow the software to split the document up. This is more
efficient on your database. The alternative is to use a report parameter as the
driver for personalization. This works and is logically easier, but it will
mean that every instance generates a unique SQL statement.
The report is an invoice with a parameter for the client’s ID.
The list of recipients
The recipient list is another report. It could be either a web intelligence report
or a crystal report. The source of this report can be anything. (Excel sheets,
databases, your SMTP system, very small rocks, etc)
You’ll probably want to connect it to a dynamic database of recipients. One of the great things
about using a report as the recipient source is that you can put additional
logic to grow and shrink the recipient list. If you want to check that the
client actually has data, put that logic in this report! If you want to only
pull the people who have agreed to receive your newsletter, you can put that
logic in this report! Once set up, you don’t need to go back every month and
maintain that list. A properly set up recipient report will have the logic to
maintain itself.
The chosen ones
The publication
Once you have your moving parts, it’s time to define the publication. Log onto the
BI Launchpad, browse to the folder this document will live in, and select new > publication
Give the publication a name, and then select your source documents. Note, the source
document is only the reports that will be sent out. You’ll add the recipient
list a bit later.
In the previous paragraph, I said “reports”. You can define multiple reports to be
sent out as part of a single publication, and the tool will collate them too.
This is typically used if there is some boilerplate or cover page that needs to
be added to the report. You'll see in the screenshot above that I have added a PDF
document of legal terms
Once you add your report (or reports) you get a lot more options in your
publication. You can choose to send the report to recipients in the BusinessObjects
environment with the ‘Enterprise Recipients’ page, but in this example I am
going to use the dynamic recipients. This is where we choose that other report.
There are three things that the publication wants to know about. It wants:
- a unique ID for each recipient
- the name of the recipient
- the email address of the recipient
Once you choose the document, you’ll map the report fields
to those three requirements.
Now, you can specify your personalization options. In this example, I am using the parameter
method for personalization. It will auto feed the field of your choosing from the recipient report into the source report.
If you are using crystal reports, you can choose to personalize based on a filter.
This requires that the crystal report contain some grouping. When you see “report
field,” you’ll typically choose the report field that your report is grouped on.
On change of the field, it will slice the report. So, if you had a report that
was grouped on customer ID, you’d get a separate report for each customer as
the output. The advantage is that the creation of this report would generally be
a single pass on the database.*
*note:
It’s not always a single pass. This could be due to how you wrote your report,
or because you have an extremely large distribution. If you have this scenario
you can set an advanced option which will burst the report in batches.
Beyond this, the options are not much different than what you see with any regular
schedule, so we won’t go into detail. Any comments? Things I missed? Comment
below
