Cisco Developer Community

There is quite a bit of interest in different techniques for using multiple AW/HDS servers with a single CUIC instance, for a number of reasons.

One reason people typically want to use multiple AW/HDS servers is to spread the load from a CUIC instance to multiple data sources. I've already blogged in the past about how you can set this up using the host file on the CUIC Web server to point different CUIC servers to different data sources.

I recently received another question regarding whether it's possible to point a single CUIC server to multiple AW/HDS servers for failover purposes. While this isn't natively supported, there are a couple of ways you can do this.

The first, most obvious way, is to set up multiple data sources and then create another set of reports which point to the alternate data source. This has the advantage of being simple, and requires no intervention from administrators, but it requires the users to know which report to launch.

Another option is to change the datasource to point to another server when it goes down. This will let users continue to run the same reports, but requires an admin to go in and update the data source when one goes down. The admin has to keep the security information handy or remember it, which can also be a problem. You'll also have to set the data source back to original settings once the AW/HDS is back up.

The third option is to use a host file as in the post I linked to above. You can set up an alias on the Web server, even if you're using the same AW/HDS for all CUIC Web servers. Then you can use that alias to redirect traffic to and from that data source as needed.

Now, there are two ways to redirect traffic. One, you could go in and edit the host file on the CUIC Web servers to point to the backup data source. This requires editing and saving the host file, which is a pretty simple operation. Again, you'll have to change it back once the original data source is back online.

Another option is to point that alias to a load balancer which automatically keeps track of which AW/HDS to send traffic to. That is, instead of pointing CUIC directly to the AW/HDS, you can point it to a load balancer which directs CUIC to the correct AW/HDS. This has the advantage of being completely automatic, which is probably what people would like to do. Keep in mind that I have never set this up myself, but I see no technical reason why this should not work. If you do try it, please contact me at @ciscojason on Twitter.

CUIC 7.5.3 was recently released, and is now available for download from CCO at http://tinyurl.com/n6auuo

This is a maintenance release and includes several new features not in 7.5.2, and many improvements. Here are some of the highlights:

• Improved performance - You will notice significant performance improvements from 7.5.2, particularly when running reports with many simultaneous users
• Improved grouped grid - The grouped grid is now the only grid available, the ungrouped grid is no more. (Your reports, however, will be automatically ported to the grouped grid.) The grouped grid now supports dynamic sorting, and will also preserve the sort order for saved reports. You can also sort the groups themselves as well as the data within the groups.
• Improved Excel export - Excel export now exports the grid exactly as it appears on the screen by working much more tightly with Excel itself. This includes exporting formula fields, groupings, and footers (even group footers!) The only caveat is that in order to export to Excel users must now have Excel installed. (However, if you don't have Excel installed you can download the free Excel viewer from Microsoft which works as well.

Aside from these big-ticket items there are a ton of bug fixes and the release is the most stable and scalable release yet.

The team has been working hard on this one and we think it's a fantastic release, please check it out and let us know what you think!

With the release of CUIC 7.5.3, there is one grid, the grid that was previously known as the "grouped grid". Since it now supports dynamic sorting it is now the only grid available.

One of the nice things about this grid is that much of its appearance can be customized by modifying the CSS (cascading style sheet) file that dictates its appearance. This is an undocumented technique, but should be fairly straightforward for anyone with a bit of HTML experience.

This CSS file can be found in the <CUIC root>/Stylesheets/ directory, and is called "StaticGroup.css". You can open this file in a text editor such as Notepad or Wordpad.

While a discussion of CSS is beyond the scope of this article, let's take a simple example, hiding the user and filter information at the bottom of the report.

After opening the StaticGroup.css file you can hide the footer information by deleting the existing style information for the .dateUserSummary and .filterSummary classes, and replace them with a style that hides those elements:



That's it! Other elements can be changed as well, play with it and make it your own. Make sure that you don't change the class names or the styles won't apply at all.

Note that any changes made to this file will be applied across the entire system, so you can't modify these and only apply the effect to a single report. If you change this file you will need to keep a backup as well, because subsequent releases and/or patches of CUIC will overwrite your modifications.

For more CUIC tips and tricks you should follow me on Twitter here.

I've just published a fairly comprehensive list of ways to improve performance of CUIC 7.5.x on the Developer Community at http://bit.ly/85kB.

There are a few items that I've covered in blog posts before, but a ton of new content as well. The document covers the following topics:

• Server considerations
• Configuration options
• Database maintenance
• Data source load balancing
• Report Design
• Data caching
• Dashboard design
• Value list refresh
• Scheduled reports

This whitepaper covers a lot of ground on various internal CUIC technical issues that are little-understood, so even if you've just wondered about what's about on under the hood it may be worth a read.

You'll need a developer services contract to see this whitepaper, but otherwise it's available now for your reading pleasure.

Want to show off your Web 2.0 mojo? Here's a fun way to share reports with your Twitter contacts.

First, find the report you want in the Report Manager, right-click it, and click on the Report Info context menu item.



The Report Info dialog is very handy, it gives you all the information you need to access a report without using the CUIC menus. Here, we want the "Interactive Grid Permalink":



Just copy this URL and paste it into a browser to test it. You should get right to the report. Not that you may need to tweak the URL if your server name isn't configured properly or is blank, for example you might have to add http://<SERVERNAME>/<permalink> to the front of the URL given to you here.

Once you have the permalink, it's time to shorten it to fit into Twitter's 140 character limit, as it's pretty long. Go to bit.ly or tinyurl.com and plug the permalink in:



You'll get back a nice short URL that you can use in a tweet:



You can take this shortened URL and paste it into a Tweet, where you can share your wonderful report with your colleagues:



A couple things to note about this. The permalink used here will default to whatever display you have set up as the report's default display. If you've defaulted to grid and chart then the grid and chart will show up when you follow this link, and if you have the default display set to XSLT then the XSLT display will be shown.

The default filters for the report will be used, so make sure that you're ok with everyone seeing the report exactly as you see it.

Also note that only people who have access to the report will be able to follow the link in your tweet, everyone else will get a message saying that they don't have access to the report. They also have to be inside your firewall unless your CUIC installation is exposed to the Internet. Regardless, the user will probably need to log in before they can see the report, unless they're already logged into the network.

Have fun!

As always, if you'd like to learn about more tips and tricks you should follow me on Twitter here.

When you write a custom report, it's always a good idea to use the SQL NOLOCK hint to improve performance and reduce the chance of deadlocks.

By default, when a query is sent to SQL Server (i.e. the AW/HDS), a read lock must be acquired before the data can be read. This means that the data cannot be changed while the record(s) is being read for the query. Sounds like a good thing, but this can create conflicts when multiple queries are trying to access the same data at the same time, which results in performance degradation.

The fix is easy, however, and it is to simply add a NOLOCK hint to your query, simply by adding the text "(NOLOCK)" after any table names in your query, like this:

SELECT field1, field2 FROM table1 (NOLOCK) left join table2 (NOLOCK) on table1.field3 = table2.field3

That's it! If you use this your reports will be more reliable, and they will run faster! You should also use these hints in your stored procedures and anonymous block reports.

Note that this doesn't apply to any reports you're writing against an Informix data source, CUIC automatically sets this hint at the connection level for Informix.

For more tips and tricks you should follow me on Twitter here

In some very specific instances, you may want CUIC Web servers to share a database but query different AW/HDS servers, to split load. At first glance this doesn't seem possible as the AW/HDS that is queried is defined by a data source, which is stored in the CUIC database. However, there is a workaround which I'll show you in this post.

Let's say you have two Web servers, Server A and Server B. You want Server A to query against HDS 1 (IP address 192.168.0.1) and you want Server B to query against HDS 2 (IP address 192.168.0.2). However, you want to use the same data source for all reports so that you don't have to keep a duplicate copy of each report pointing to a separate data source.

The trick is that when you set up the data source, you don't use an actual HDS machine name or IP address in the "Server" field. You will supply a bogus "alias" name, which we can then redirect using the Windows host file.

Let's call our alias "HDSREDIRECT". You would plug "HDSREDIRECT" into your data source configuration as the server name. Obviously that will not work right away, there's one more step. You'll have to edit the host file on each of the Web server, typically located in C:\Windows\System32\drivers\etc, the filename is simply "hosts".

In order to make the "HDSREDIRECT" alias work, and split the traffic between the two AW/HDS servers, you would add this line to Server A (which, remember, you want to query HDS 1):

192.168.0.1 HDSREDIRECT

And you would add this line to the hosts file on Server B (which we want to query HDS 2):

192.168.0.2 HDSREDIRECT

Note that the name of the alias is the same on both servers, but the IP address is different.

And that's it! Because the Web server issues the request to the AW/HDS, it will use the hosts file to determine which IP address to query. Just make sure that your security configuration matches up on the two AW/HDS servers and you should be good to go!

Most people don't realize just how extensible CUIS is. You can do a lot with it, however, if you know what you're doing.

For example, most people don't realize that you can build a completely custom display using custom-built XSLT files. It's true! You can give CUIS your own stylesheets, and then tell the report to use that stylesheet instead of the default displays.

If you're not familiar with XSLT, it allows you to take raw XML data and transform it into something useful, like an HTML page for the Web. It's a template for data, and people have done some very innovative things with this including building reports that print packing slips, implementing custom Javascript data displays, and so on. You could also transform CUIS data to another XML format for input into another system.

To make an XSLT available just put it in the CuisWeb\UserFiles\XSLT directory. The XML schema isn't documented anywhere but it's pretty simple, I would recommend using the XSLT files already in that directory as an example.

CUIS passes the report data in XML format to the XSLT, does the transformation, and displays the result.

Only thing to keep in mind is that you won't get support on XSLT's, it's considered completely custom work. You really have to be a technical person with knowledge of XML and XSLT to do cool things with this.

Another thing that people don't realize is that you can get report data directly as XML from CUIC!

Another one that I'm surprised people haven't figured out is that you can create your own stylesheets to give CUIS 7.5 a custom look. If you know CSS, you can create a new CSS file, put it in the CuisWeb\UserFiles\CSS directory. Again, this isn't documented, you'll have to use the existing CSS files as guides and modify them to suite your purpose.

One interesting thing to try is embedding CUIC inside of other applications! Using report permalinks, you can call, filter, and display a report just by calling a URL. Just right-click a report in the report manager, click on Report Info, and there's the URL down there. Embed CUIS reports inside of your own applications!

And you knew that you could embed Web pages in a dashboard, right? You can create a dashboard item that displays a URL. Some customers use this as a simple bookmarking system, by putting their internal systems in different dashboards so they can flip between them and see the relevant reports next to them.

Hope this post sparks some innovative ideas on how to use CUIC 7.5!

To talk about CUIC more, you should follow me on Twitter here