:: caropepe.com ::

« May 2007 | Main | March 2008 »

October 25, 2007

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

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.

Posted by caropepe at 08:37 PM

ITSM Incident Priority & Priority

ITSM Incident Priority & Priority Weight

In the Incident Management configuration, weights are applied to the impact and urgency values (behind the scenes). When a support staff member selects an impact and urgency of an Incident, the Incident Management application adds the numerical weights together in order to calculate the priority weight, then assigns a descriptive priority (such as "Critical").

You can increment/decrement the Priority Weight to provide a more granular level of prioritization. If increasing or decreasing the Priority Weight causes the weight to cross a priority weight threshold to the next level of priority (say, from High to Critical), the Priority field is updated to reflect the new priority.

The default weight values (Impact + Urgency = Priority) include:

Balancing Impact & Urgency

Using independent weight values for both Impact and Urgency allows the support organization to fine-tune how much relative value is placed on the customer's interpretation vs. the support staff's interpretation the request's importance. For example, if the customer reports something as at a low urgency, but IT recognizes it as having a big impact, weighting the impact values accordingly will ensure the final priority recognizes IT's better ability to determine the scope/impact of the problem.

Slowing Down Support Staff

This is something I thought of while working a couple of test tickets yesterday. Using the numeric spinner to increase & decrease priority actually slows down the support staff's ability to change the priority. It isn't trivial spinning that number 20 times (or whatever it is) in order to increase it to the next priority threshold. This has the effect of dampening the ticket's priority, keeping it from bouncing from one extreme to another (perhaps as SLA's are trying to keep up).

Priority Granularity

Having a priority weight allows the support staff to choose the proper impact and urgency, and then make it "more" of the resulting priority. For example, if the resulting weight of a "High" priority ticket is say, 20, then the support staff can make it a "High" / 23, which would indicate to other staff members that it's more important than a standard "High", but doesn't justify an overall priority of "Urgent".

In conclusion, I don't think it's that big of a deal, really. Once the support team becomes familiar with the default values for Impact & Urgency weights and understands that they drive the priority and priority weight. They should also understand that in order to change the priority you can either increase/decrease the priority weight (making adjustments independent of Impact/Urgency), or change the Impact/Urgency values. It's not hard to do.

Posted by caropepe at 08:36 PM

ARS: Discovery & CMDB

ARS: Discovery & CMDB

There are two primary components of this integration: The BMC Topology Discovery server, and the BMC Atrium CMDB (running on the BMC Remedy Action Request System).

The Topology Discovery server has a number of discovery tasks that scan the defined network segment looking for specific types of devices. Once discovered, these devices, their associated components, and resulting relationships are stored in the Topology Discovery database as a “dataset�.

Multiple discovery tasks can be configured, each looking at different segments, or for different types of devices. Each task can also be scheduled to run automatically, or left to be run manually. There is a single dataset and all discovery tasks populate that dataset.

Once a dataset has been populated with items (a.k.a.; configuration items, or CIs) it can be synchronized with the CMDB. The Topology Discovery synchronization utility is configured with an AR System username/password and uses the ARS API to populate a specific dataset in the CMDB (BMC.TOPOLOGY.IMPORT).

After the BMC.TOPOLOGY.IMPORT dataset is populated with CIs resulting from the discovery, a reconciliation job can be run that merges the temporary topology import dataset with the production dataset (BMC.ASSET).

BEST PRACTICE

As might be expected, the number of configuration items (including their relationships) can easily overwhelm a person(s) designated to manage them. This is particularly true if the degree of discovery detail does not match the degree to which the organization manages devices.

If the organization only manages to the “box� level, swapping out routers, switches, and even servers (per vendor agreements) when a failure occurs, and the discovery tool is configured to the component level (a single server has many components – rack, case, mother board, CPU, memory, hard-drivers, etc. – and discovery can find most of them) there will be a huge amount of unnecessary information stored in the dataset.

What usually happens is both discovery and the CMDB are configured for all devices on all networks (*.*.*.*). It takes 12 hours for the discovery to run, and 4 for the synchronization. Now you’ve got 200K+ items in the CMDB and no idea how to manage them.

This point cannot be understated: Only configure Discovery/CMDB to match the degree of detail that the organization manages devices to.

Posted by caropepe at 08:29 PM