ARS: Reporting using Mid-Tier and CR 10/CRXI/BOXI on Seperate Server (Windows)

10.25.2007 · Posted in BMC Remedy

SEATTLE — Since ARS Mid-Tier 6.3 more BMC Remedy AR System implementations than ever are using web browsers as the client of choice. This version was completely redesigned from earlier efforts and closed the gap in speed and functionality that’s long existed between the AR User tool and the Mid-Tier.

While users enjoy the ease of accessing ARS via the web, configuring the Mid-Tier to run Crystal Reports is a bit more complicated.

When the “fat” client (AR User) is installed on your Windows workstation, most people also install the Business Objects Crystal Reports Windows report viewer (it’s the default). This makes it simple for AR User to run a report — it already has a connection to the AR System server API so it’s just a matter of grabbing the .rpt template definition file from the Report form, running the ARS query, and handing the results to the Crystal viewer for display.

Architecturally speaking, using a web browser as your client makes this much harder. The browser has no practical [0] way of knowing anything about the AR System, available API’s, or what other software is installed on your workstation (if any). The Mid-Tier handles all translation between the HTML your browser understands [1] and the AR System’s API.

But what about the reports? This is where the Business Objects/Crystal Reports web viewer comes in. The web viewer is included whenever you install BusinessObjects Enterprise or Crystal Reports Server on a web server and is used to format and display reports over the web. Think of it as the web server’s version of the Windows Crystal Reports viewer installed with AR User.

The AR System Mid-Tier simply needs access to the web viewer. Everything else is managed by the AR System [2].

If you have report administrators and developers in your organization be patient explaining how this all works, especially if they are used to hosting all reports on their system. They’ll want to manage users, groups, permissions, control who uploads report template definitions (.rpt), and decide what databases your users can access. They need to be made very clear that the AR System handles all of this (be nice — you may be asking them to install some software on their system…).

Configuring the ARS Mid-Tier to access the web viewer depends on what version of Business Object’s software you’re running. Crystal Reports 10 is different than Crystal Reports XI, and they’re both different than Business Objects XI [3]. With all versions the report server running the web viewer uses the ARS ODBC driver to make the connection back to the ARS server and query for results. In the sections below I’ll describe each environment and note any oddities.

Crystal Reports 10 – A URL-based Approach

The URL-based approach is exactly what it sounds like. When you request a report a new browser window is opened with a URL pointing to the web viewer configured in the ARS Report Type form. Hopefully everything (including the report template file) will be where it needs to be (and has the proper permissions) and the web viewer displays the report.

Usually, the record in the Report Type form for “Crystal” includes the $CRTLOC$ parameter for Mid-Tier’s Crystal Enterprise 10 Location report server host name, and the $RPTLOC$ parameter for Mid-Tier’s Reporting Working Directory. There are additional parameters for login information and the query string (among other things)[4].

In the mean time, the Reporting Working Directory is shared and made accessible to the report server across the network. From the report server’s perspective, the Mid-Tier’s shared directory is mapped as a local drive (which may require specific permissions) and made accessible to it’s web server as a virtual directory (so the web viewer can access it).

CR 10 Key Points:

  • ARS ODBC driver installed on report server.
  • Mid-tier caches the report template locally in its Reporting Working Directory.
  • The Reporting Working Directory must be shared across the network.
  • The report server’s web server maps a virtual directory to the Mid-Tier’s Reporting Working Directory.
  • Report template file never actually is stored on the report server.
  • Web viewer gets all run-time information via parameters contained in the URL.

[DIAGRAM: URL-based Reporting using ARS Mid-Tier & CR10]

Crystal Reports Server XI – An Unmanaged Java-based Approach

The single biggest difference between CR 10 and CRXI (and BOXI) is how the Mid-Tier and the Central Management Server (CMS) communicate with each other. Rather than saving the report template locally and sending the CMS a URL telling it where it’s at and what to do with it, the Java-based approach provides direct communication between the Mid-Tier and CMS [5].

Specifically, the Mid-Tier communicates with another bit of BMC Remedy software installed on the report server called the “ARWebReportViewer”. This software acts as the go-between for the Mid-Tier and the CMS. It receives the report template, credential information, and query information all in one big package from the Mid-Tier. Then it saves the report template locally to the Reporting Working Directory (on the report server), and hands the rest over to the CMS for processing. Much neater (and faster).

With CRXI the CMS simply processes all the pieces and invokes the web viewer. There is no provision for local caching of this information on the report server (it’s not published to the CMS), so you can’t access or manipulate it in other ways (like scheduling the report to run overnight, etc.) This is why CRXI is called an “unmanaged” solution.

CRXI Key points:

  • ARWebReportViewer and ARS ODBC installed on CRXI report server.
  • Report Working Directory located on report server (no network share required).
  • Mid-Tier hands off credentials & query to ARWebReportViewer.
  • ARWebReportViewer hands off to CMS (for display only).
  • Web viewer generates & displays report.
  • Report is discarded.

[DIAGRAM: Java-based Reporting using ARS Mid-Tier & CRXI]

BusinessObjects XI – A Managed Java-based Approach

Everything is the same as CRXI, except:

Before a report is displayed it is first published (cached) to a folder of CMS where it remains available for further manipulation making it a “managed” solution. This why during ARWebReportViewer BOXI configuration you specify a CMS Machine Name and CMS Machine Connection Details (CMS folder name – usually “ARReports” – and CMS user credentials) and CRXI configuration does not.

BOXI Key Points:

  • ARWebReportViewer and ARS ODBC installed on BOXI server.
  • Report Working Directory located on report server (no network share required).
  • Mid-Tier hands off credentials & query to ARWebReportViewer
  • ARWebReportViewer hands off to CMS (for publishing & display)
  • Web viewer generates & displays report.
  • Report remains available for further management by BOXI (including scheduling).

[DIAGRAM: Java-based Reporting using ARS Mid-Tier & BOXI]

Common Troubleshooting

  • Make sure your Reporting Working Directory is properly configured. If it’s not set to the default (say, you have a separate directory for each AR System server running reports), you may have to configure the URL specified in the Report Type form.
  • Using the “Properties” context menu of your browser (right-click anywhere on the page) allows you to view the URL of the page you’re viewing, even if it isn’t enabled by default.
  • Permissions are important – Your web server will be running as a particular service account. Make
    sure this account has permissions to wherever the report templates are stashed.

Final Thoughts

Configuring the AR System for web reporting is actually pretty straightforward, especially once you understand the architecture.

Common problems include not specifying the proper Reporting Working Directory and having the proper permissions setup. You can view the properties and look at the URL in the browser.

[0] Of course tools like ActiveX let a browser interact with the workstation and it’s underlying OS, but they are proprietary in nature and are not used in the BMC Remedy environment.

[1] I’m using HTML here in the generic sense, meaning browser-readable content. The ARS Mid-Tier uses a servlet engine (New Atlanta or Tomcat) to render Java server pages (.jsp).

[2] For “unmanaged” installations, anyway. Even with “managed” installations additional involvement is optional. BTW, I often find myself having a simliar conversation with database administrators. They don’t typically “get” that the AR System manages itself and insist on medling.

[3] Dont’ get me started on the confusion caused by Business Objects and their silly naming conventions.

[4] Is there a handy reference to all of the keywords available in this URL? NOTE: Technically you can configure other report types for different report formats. For example, you could created a report type of CrystalPDF and specify the Adobe PDF format as the output of the report. In theory this should work, but in earlier versions of the Mid-Tier something deep inside was hard-coded to only accept “Crystal” as the report type. You mileage may vary.

[5] The Java-based approach uses Java API’s. It is not a pure Java solution.

Comments are closed