Printing (or not printing) Crystal Reports with SAP BusinessObjects BI 4.1

I recently wrapped up a BI 4.1 upgrade project that was 80% Crystal Reports and 20% Web Intelligence. The SAP BusinessObjects Enterprise XI 3.1 system was older than the tenure of the team that supported it, so some of its tribal knowledge had been lost. One of the things that we overlooked was printing requirements. Very few Crystal Reports were actually scheduled to print; however, many of Crystal Reports had printers defined.

While the challenges were few and easily managed, here are some lessons learned that I’ll be applying to my next BI 4.1 upgrade project.

Printer cartridges for printing

Install Printer Drivers as Part of BI4 Prerequisites

Either immediately before or immediately after BI 4.1 installation but before you begin using the Upgrade Management Tool, take a few moments to install the most common printer drivers in use in your organization. At a minimum, take a walk around your work area and install printer drivers for those models. And choose one of those nearby printers to be the default printer for each node in your SAP BusinessObjects cluster.

Missing printer drivers can significantly increase migration time of Crystal Reports via the Upgrade Management Tool (SAP KB 1701318) requiring the timeout to be increased (SAP KB 1804414). We didn’t realize the reason for needing a much higher timeout was the lack of printer drivers. We had already migrated the content and moved onto testing, only to learn that scheduled Crystal Reports with defined printers would have a job status of running but never complete. Which leads to the next best practice.

Install Crystal Reports 2013 On the Job Server

In our development environment, we installed Crystal Reports 2013 on the node containing the Adaptive Job Server. Depending on which development tools you’re using, you may also want to install the SAP BusinessObjects Client Tools (Web Intelligence Rich Client, et. al.), Crystal Reports for Enterprise, and Dashboards, as they can be helpful when troubleshooting. In most cases, running a Crystal Report in the client yields much more actionable troubleshooting information then the brief error from the Adaptive Job Server.

And with printer drivers in particular, Crystal Reports 2013 offered to install them automatically.

Do You Trust This Printer?

While I wouldn’t criticize somebody for installing the clients on a production node, we never identified an issue that required it. Plus, being stingy with client installs means fewer things to patch later.

Remove Unneeded Printer Specifications from Crystal Reports

If your Crystal Report doesn’t have a schedule to print requirement, you’re better off not specifying a printer.

  • A printer specification can slow the overall performance of a Crystal Report (see SAP KB 1197593 and 1205023).
  • A printer specification can prevent an InfoView (or BI Launch Pad) user from printing a Crystal Report to the default desktop printer (SAP KB 1202786).
  • Unfortunately, there’s no way to make “no printer” the default (see SAP KB 1220244).

To remove the printer specification, simply choose File -> Page Setup from the Crystal Reports 2013 menu and check the “No Printer” box (shown unchecked). This action should be on your checklist prior to publishing a Crystal Report to the BI platform. Or something to verify before promoting the Crystal Report to a higher environment with Promotion Management.

Crystal Reports No Printer

Make Sure Printed Reports Still Deliver Value

We discovered that one of our printed Crystal Reports was no longer in use. In fact, the defined printer was nowhere to be found. SAP BusinessObjects Enterprise XI 3.1 would run the job anyway with a result of “success”. But BI 4.1 ran the same job with a result of “failed” because the printer was missing and therefore did not send a response.

Consult with users to see if they’d rather receive a printed report on a shared file system or via email. Or simply run the reports on-demand from the BI Launch Pad when necessary. Keep track of any print jobs that you halt in a spreadsheet with its average number of pages and printing frequency. When your upgrade is complete, you can compute the annual cost savings of making the BI 4.1 system more “green” than the one it replaced.

Don’t know who “owns” a printed report? I won’t tell anyone if you simply stop delivering the report after BI 4.1 cutover and see if anyone calls to complain.

Influence SAP to Bring Feature Parity to Web Intelligence

Desktop Intelligence also had the ability to schedule to a printer but this feature is still lacking in the latest versions of Web Intelligence (see related article, All the Desktop Intelligence That’s Fit to Print). The idea is “under review” by SAP but has languished in the SAP Idea Place for nearly four years. Nobody should be forced into porting an existing Desktop Intelligence or Web Intelligence document to Crystal Reports simply because they have a printing requirement.

If you haven’t yet voted, please lend your support to the idea (see SAP Idea Place, Schedule Web Intelligence documents to a printer).

Are there other Crystal Reports best practices you followed for your SAP BusinessObjects BI 4 upgrade? Please share them in the comments?

Dallas Marks

Dallas Marks

I am an analytics and cloud architect, author, and trainer. An AWS certified blogger, SAP Mentor Alumni and co-author of the SAP Press book SAP BusinessObjects Web Intelligence: The Comprehensive Guide, I prefer piano keyboards over computer keyboards when not blogging or tweeting.

8 thoughts on “Printing (or not printing) Crystal Reports with SAP BusinessObjects BI 4.1

  1. Dallas,

    Great post! I’ve been arguing the question on whether or not to install clients on the server for years. My argument to support it has been that in the event one has to go to SAP for a product defect they will want to isolate the server from the network. Therefore you need a small set of the tools there to support troubleshooting. Then I give them a stern talking to that these tools are not being installed there for use in development. Yeah it increases the time to apply patches but better than the risk of updating a production server during a support call. Crystal Reports is the main client that woke me up to this a while back. It’s not for the faint of heart when migrating from earlier versions. Lots of things to consider beneath the service. Not hard necessarily, just unexpected.

    Oh the dreaded printer driver issues! I take a slightly different school of thought and recommend setting their reports to have no printer before saving to the server. However, the drivers still need to be installed to support reports that already have defined printers (and don’t forget sub reports). But over time the reports get cleaned up and set to no printer. You can still schedule to a printer of need be although that is ripe with its own set of legal issues depending on who you are working with at the time.

    A couple other things with Crystal you may consider:

    When dealing with a SAP backend, be sure to have the Basis team update the transports and if supporting older reports using Infosets or direct queries you may need to configure SNC based SSO not just STS for BW BICS.

    Finally, even though you installed all your database drivers needed to support the report you may actually need to touch individual reports and update the datasource. Oh and don’t forget those sub reports and old school business views (supporting LOVs) that may be hiding embedded inside of the reports you migrated.

    1. Chris,

      Thanks for writing and sharing additional tips with my readers. We also had to “touch individual reports and update the datasource” but I wasn’t able to find a pattern as to which reports needed more love than others.


  2. Other “Printing (or not printing) Crystal Reports with SAP BusinessObjects BI 4.1” Tips…

    1.) Pre-Install and Configure Database Drivers on the 64-bit Windows Server OS in BOTH the 32-Bit and 64-bit formats. CR-2013 services use the 32-bit drivers to direct-connect to the DB. CR-for-Enterprise-4.0 services use the 64-bit drivers to (semi) direct-connect to the DB.

    2.) Use and Enforce a STANDARD “Preference” setting for Crystal Viewer and Print-Controls. Try to avoid any of the ActiveX Plug-ins in large Corporate environments, because (A) ActiveX controls are Internet Explorer specific – and not all end-user workstation have IE as the default browser, and (B) ActiveX download & plug-in install are often BLOCKED by Corporate IT policy for Internet Explorer end-users.

    NOTE : This isn’t always easy to achieve, as there is a known issue with PDF-One-Click Printing of CR-for-Enterprise-4.0 in the LaunchPad of SAP BO-BI 4.1 (SP2) platform.

    3.) Anything that goes to a PRINTER should have the following TEXT on the design of EVERY-page :
    – Data-Date/Time
    – RunBy UserName
    – Privacy/HIPPA/Security “STATUS”

    In the Corporate-world this will SAVE you a Ton of Headaches when people are “fighting” over numbers in a meeting, and help to CYA when somebody leaves a PRINTED copy of a Patient-Report on a Subway.

    1. Mark,

      Thanks for sharing these great tips. For my latest customer, most people received a PDF or Excel in their email so I didn’t have to (so far) deal with the print controls. I’ve certainly been bitten by the whole 32-bit vs 64-bit thing- see my related article, SAP BusinessObjects BI 4 is (Mostly) 64-bit. I’ll try to not leave any patient data on the subway.


  3. I agree with Chris that “Yes” installing the CR clients (CR4E & CR-2013) locally on each Node is sometimes needed to help debug an issue.

    However, downside (other than longer patch-cycle) is that SAP “officially” says that installing the Clients on the SAME server as the BI-Platform is “not recommended”, even though they will ask you to do it when trying to debug a problem….

    SAP note: 2014953 – “Installation of server and client components of
    BI 4.x on the same physical machine.”

    Which kinda makes me crazy, but that’s often my Default-setting when dealing with SAP Support.

    1. Kills me too, on hand best practice is don’t do it, on the other can we connect from your server. Will have to mention it to a few people out at d-Code this year.

  4. Not a printing related comment but just want to add to the last few client install comments. Yeah, in the “good old days” it was always best practice to install the clients on the server – it was invaluable for troubleshooting. But as colleages of mine back at SAP have found, the 4.x client installs have been known to interfere with the BI platform components – especially CR for Enterprise due to problems with java pieces tripping over one another. I’m not happy about this java-centric development approach if it means clients shouldn’t be installed to the server but that’s why they have that server/cient separation recommendation. I hope that changes in the future as there is a lot of good troubleshooting that can be done with everything on one machine – they’ve stepped backwards on this one.

Comments are closed.

%d bloggers like this: