Quick ‘n’ Dirty Dogear Backup

A little bit of a deviation from our usual WebSphere content here, but: if you’re using Lotus Connections in your organisation, you might want a way to backup the bookmarks you save to Dogear locally. Maybe there’s a lot of valuable content in there that you need should it go offline for a few hours, for example. I’m just paranoid, and I always like to have personal backups of anything important to me – which my bookmarks sure are.

So I wrote a quick and dirty Python script that backs up your bookmarks by connecting via the Dogear API and saving them to an XBEL file. It doesn’t support all fields – in particular, in doesn’t currently back up tags, only the title and the URL.

Feel free to take and adapt to your needs (as with all material on this site, this is not supported by IBM in any way and there are no guarantees that this will even work for you). Feedback appreciated as always.

You’ll need to pass in three command-line arguments to the script: hopefully the code is self-explanatory.

#!/usr/bin/python

import urllib2
import feedparser
import base64

from urllib import quote
from optparse import OptionParser

parser = OptionParser()

parser.add_option("-u", "--username", dest="username")
parser.add_option("-p", "--password", dest="password")
parser.add_option("-s", "--servername", dest="servername")

(options, args) = parser.parse_args()

print "<?xml version=\"1.0\"?>"
print "<xbel version=\"1.0\">"

PAGESIZE = 50
url = "https://" + options.servername + "/dogear/atom?email=" + quote(options.username) + "&access=all&ps=" + str(PAGESIZE)

entrieslength = PAGESIZE
currentpage = 1

base64string = base64.encodestring('%s:%s' % (options.username, options.password))[:-1]
authheader = "Basic %s" % base64string

while entrieslength >= PAGESIZE:
 req = urllib2.Request(url + "&page=" + str(currentpage))
 req.add_header("Authorization", authheader)
 data = urllib2.urlopen(req).read()
 feed = feedparser.parse(data)
 entrieslength = len(feed.entries)
 for entry in feed.entries:
  print "\t<bookmark href=\"" + entry.link + "\">"
  print "\t\t<title>" + entry.title.encode('utf-8') + "</title>"
  print "\t</bookmark>"
 currentpage = currentpage + 1

print "</xbel>"

Health Center with WebSphere ESB and Process Server

I attended a presentation last week by one of the developers of Health Center, a new monitoring and diagnostic tool IBM has made available for debugging Java Virtual Machines as they are executing. It’s available for any application that runs on an (IBM-based) JVM, but of particular interest to me is WebSphere ESB and Process Server.

I won’t repeat the installation instructions, which you can find here, but there are one or two gotchas you should be aware of:

  • At the time of writing, Java versions shipped with WebSphere ESB and Process Server (version 6.2.x) are sufficiently old that they don’t yet include the Health Center agent, so you will need to install this manually as described in the “Enabling an application for monitoring” link when you set up a connection in Health Center. Be careful to extract files into exactly the right directory.
  • I also suggest you then follow the instructions labelled “Configuring WAS to enable monitoring” in the Health Center Infocenter. If you are using the embedded Integrated Test Environment servers inside WebSphere Integration Developer, I suggest the topic “Configuring WAS test environment in RAD to enable monitoring”. Although the product names are different, the principles are essentially the same.
  • Be aware that (at the time of writing) Java 5 SR8 is used by WebSphere ESB and Process Server, so you’ll need to use the more complex form of JVM boot parameters as described in the help. This also means that it’s not yet recommended that use Health Center in production, although it will be useful in development, particularly when you’re focusing on performance, stability, or capacity issues. Hopefully this situation should change in later versions of WebSphere ESB and Process Server.

To give you a taster, once you’ve managed to connect, you’ll see some very cool screens, like this one that allows you to do trivial method profiling:

2009-07-21_160518

(sort by ‘Tree’ is particularly useful, as this includes time taken by methods that a given method has called).

Another handy view is this one, which allows you to watch your heap and JVM pause times over time (drag a box over a particular area to restrict all statistics to that period):

2009-07-21_160428

The best part of Health Center is that all data is updated in real time (and can be saved away and reloaded later), so you can (for example) watch your heap grow and shrink, your garbage collection happen, and so on. Overhead is generally minimal and since it uses a client/server architecture, is minimally invasive.

You can find out a lot more information on the Health Center website and the Java troubleshooting team’s blog.

Thanks to Toby Corbin for the original presentation and Dave Nice for assistance with Health Center.

Emulating modelled faults in WebSphere Integration Developer

Since version 6.1, WebSphere Integration Developer has come with the ability to create test projects containing test suites and programmatic emulators, allowing developers to create repeatable automated tests for their modules. Projects can contain any number of suites, test cases and variations to cover all the behaviours of the module.

One scenario often overlooked in user-defined test suites is the one where the partner reference returns a modelled fault.

For example:

Example interface with a modelled fault

Fortunately, it is possible to return a fault using a programmatic emulator. In this example we will use Java, but the same behaviour can be accomplished using a visual snippet.

First create the payload for the fault. If the payload is a String or other Java type, you can simply create it and assign it to a variable. If the object is a business object then locate the BOFactory and create it as you would any other SDO DataObject

BOFactory boFactory =
  (BOFactory) ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo/BOFactory");

DataObject reservationFault =
  boFactory.create("http://LB_Example","ReservationFault");

Once you have the object set any attributes that are required.

reservationFault.setString("faultCode", "100");

Next create a Java ServiceBusinessException. The exception has four constructor methods, and we want the one that accepts a String and an Object. The string will be name of the fault being returned, and the object will be the payload created above.

Finally, you throw (not return) the ServiceBusinessException

ServiceBusinessException sbe =
  new ServiceBusinessException(reservationFault,"unknownEventFault");

throw sbe;

For completeness, here is the same code represented visually.

Fault emulator as visual snippet