speedup report distribution

sdk development
1

As of now we have an addin on our servers that gets executed whenever a report runs on a BCA. The addin refreshes the report, then gets a list of recipients for the report. Then for each recipient: the addin saves the report under a temp file name, then opens that temp file and applies filters to each tab of the report for that recipeant. Works great for 98% of our reports.

Problem:
For large reports with large distributions, the time it takes to open the temp file and apply a complex filter for each tab can be very long. ie. 3-4 minutes per tab. Report has 3 tabs. So 12 minutes per recipient times 300 recipients.

Looking for some high level ideas on how to speed this process up. Looked in processing a pdf. That looks ugly at best. Also, looked into threading application. Any Ideas.

cparsons :us: (BOB member since 2004-02-20)

2

So the “one” report has data for all recipients, and a report-level filter limits it for each recipient? Hmmm, so all 300 have all the data in them. I can see how a large report would be slow. But then again, you already knew that :rotf: .

Is the recipient ID the same as the BusObj user ID? Or can it possibly be derived? If so you could add a condition to the data provider that limits the data based on user ID, and use the “Refresh with profile of each recipient” (something like that) option to generate the reports. Yes, it would run the report 300 times, but each one would be smaller. The cumulative time might actually be shorter.

Just a thought.

Dwayne Hoffpauir :us: (BOB member since 2002-09-19)

3

That might be a solution if every recipient was a BO user. But unfornuatly they are not. We mostly burst on things such as Branch_Nbr.

cparsons :us: (BOB member since 2004-02-20)

4

So, your current process is:

Refresh
Get List of Recipients
For Each Recipient
    Save
    Open
    Filter
    Save again
Next Recipient

Here’s an alternative:

Refresh
Get List of Recipients
For Each Recipient
    Filter
    Save
Next Recipient

By avoiding the open and second save, it’s got to be faster.

Here is another idea. Tweak the report so that the data provider prompts for recipient. Let’s say the prompt is “Enter Recipient”:

Get List of Recipients
For Each Recipient
    Fill in Prompt
    Refresh
    Save
Next Recipient

Yes it means refreshing 300 times, but each should be quick and the resulting file sizes would be MUCH smaller I would think. Another benefit is that the report can serve double duty and prompt when run interactively.

Dwayne Hoffpauir :us: (BOB member since 2002-09-19)

5 

Get recipient list
Refresh current.rep
For each recipient
    save as temp.rep
    filter tabs
    remove any tabs recipient does not recieve
    save as pdf
    email pdf
    make current.rep active document
next

The remove tab section is the only thing that would prevent us from using your first suggestion. I am going to try refreshing per recipient as you suggest. If it refreshes in anything under 12 minutes, I guess it is an improvement. Looks like we might have to cut some content out of the report.

cparsons :us: (BOB member since 2004-02-20)

6

If it wasn’t for the deleting tabs, it should be possible to create one large .pdf file and getting hold of some shareware to split it up.

I found the filter and export on each value method quite slow, we now export entire documents as text and use VB programs to split it up. Some reports were taking almost 24 hours to filter can now be done in a fraction of the time.

Would your customers accept several files, one for each tab?

chrishogben (BOB member since 2003-06-26)

7

One of the big pushes to create our own distribution system was to get all the tabs of a file on one pdf with bookmarks.

cparsons :us: (BOB member since 2004-02-20)

8

Is this something that could be run on a number of PCs overnight? If you can split the job over a few machines you might be able to shorten the overall duration.

Or course, this would generate work to keep everything organised, so you’ve probably got another development project…

chrishogben (BOB member since 2003-06-26)