A slightly more in-depth review of Rhapsody 5.4

We recently moved from Rhapsody version 3 to version 5. Here's some tedious info about that.

From what I can tell Rhapsody is made-up of 3 components

1. The engine that does the message processing - Windows service
2. The IDE (development environment) - Windows application
3. The Management Console - web page

The engine is a black box so who knows what improvements have been done there.  It's always been pretty good, so let's just assume it hasn't got worse.

The IDE looks and feels the same, so has continued with the kind-of-clunky-user-interface and random-weird-errors way of working.  This is kind of expected because it's just developers that use this and no one cares about the development experience because:

1. This stuff is complicated & hard to get right
2. No one listens to developers as they will generally complain anyway, because they are basically the high tech version of the boy who cried wolf

There is some new functionality here (e.g. webservices communication points) but whatever, this is pretty much the same as version 3.  It's still pretty buggy; in version 3 I have had deployments to production fail and leave components in weird states, and then had the IDE refuse to restore backups (giving random errors). I haven't encountered bugs that big yet but have seen some along the lines of:

• When changing the value of a variable an error occurs and the new value is not pushed out to the components (restarting the service fixed this)
• An altered property on a checked out component is forgotten as soon as the component loses focus (restarting the IDE fixed this)

Yep, still looks like crap

The Management Console is where a lot of improvements are noticeable.  

• When looking at com points/routes you can collapse folders and apply filters - no more scrolling around like an idiot (well, less of that at least).  The state of this (whether a folder is collapsed) is remember when coming back to the page.
• In the old version the refresh on com point front page was a bit rubbish and would scroll you to the top of the page and make you lose your place etc.  It is now very seamless and continuous (seems to bring in updated data every few seconds via ajax calls).
• There's a heap of automated (but configurable) warnings and errors that give you a good idea of the current state of the engine.

Makes it easy to see problems so that I can then pretend I haven't seen them and hope my colleagues fix 'em

• When you log in it never tells you "Your security key session has expired; please log-in again. " and makes you log in again!
• The component details view is pretty cool now. Mostly the same information but better organised and accessible.

• When looking at a message, navigating to different messages is a lot easier e.g. you can now do a single click to go to the next or previous message. Yeah that's right. You don't need to mash that back button till you get back to the search then clown around trying to find the message id you were just looking at and then click the one before/after it. 

The expertly placed red triangles indicate where you can click to move to different messages

• It doesn't look like total pants anymore.

Lessons learnt from migration

• If you have communication points that are polling a database, when you move them to a new machine they will not remember the last polled value.  This is bad!  This means they basically start from the default value again.  You can update this from the management console under the Database Key Values menu.

• There will be some small errors generated when moving to the new version (like some directory com points will need the configuration updated - I think additional validation has been added) but all can typically be easily worked through.
• It will take you eternity to move all your crap because no one knows what it does, how to test it, or how to gain access to the systems that are sending/receiving the messages to change their configuration.
• You're going to need some training in the new version.  This is kind of a guess, because I haven't had any training yet and there's a whole heap of stuff happening that I don't understand (like com points have input and output queues now) - I am assuming training would fix that.

The Rhapsody 'Database Message Extraction' filter is a bit pants but you have to use it anyway

We were in a situation where we needed generic patient information to be displayed in an application. How do we get this info and maybe make it so the process can be reused by other applications? Everything else in the hospital goes through Rhapsody, so can we do this in Rhapsody? Seems easy enough; send a message to Rhapsody and say 'hey, I want data for ward ABC', then Rhapsody runs a query against the database and sends back all the required information as an XML message. Man, that was so easy, this integration stuff is a piece of cake.

The Rhapsody Database Components Best Practice Guide says "If you want to retrieve data from a database table for every message it receives, use the Database Message Extraction filter."

I'm a good little developer. I read the documentation. I believe in the documentation. So, when we use the Database Message Extraction filter we are following best practice. Good for us!

Unfortunately the Database Message Extraction filter has some problems. It seems that when the Rhapsody route that holds the DB Message Extraction filter starts up it connects to the database at that point. It then holds that connection open. If that connection is disrupted for some reason (network issues, database goes offline then comes back online) the DB Message Extraction filter WILL NOT be able to recover that connection. It will remain in a broken state until the Rhapsody route is restarted. When this happens you will see errors like this:

We have a lot of outages. We have upgrades, we have server moves, we had a server room move. The connect gets broken between the Rhapsody server and the database server a lot. We have backups that can potentially make servers unavailable for very short periods and so for a while we were in a situation where every night the Rhapsody route was breaking and having to be restarted. The system engineers managed to solve the problem with the backups but we still have the problem every time the database becomes unavailable.

So, I don't have a good solution to this. If you want to follow the pattern of extracting and returning data for each message sent then you have no choice but to use the DB Message Extraction filter (according to Rhapsody support). I reckon you should avoid using it if at all possible. If not, you might be able to work around the problem by scheduling a route restart (if your version of Rhapsody will allow this - ours doesn't). If you have this problem I don't really have any help for you, I'm just letting you know I share your pain and advising everyone else not to use this filter.

Calling the command line from Rhapsody - the Execute Process Filter

Also known as 'why can't my version of Rhapsody manipulate files'.

We had a situation where we needed Rhapsody to move a file from one location to another location. There does not appear to be any file system manipulation components available in Rhapsody so we settled on this guy:

So the Execute Process Filter (what is it filtering? heck if I know) seems to have been designed to run programs or scripts. Which is cool. You could write custom apps and then trigger them from Rhapsody. But I'm far too lazy to write my own exe if I don't have to. I'd rather just pass cmd.exe the appropriate arguments and make it do the work for me.

There are a couple of questions that need to be answered to make this filter more useful:

1. How do you access the command line and get it to run a given command?
2. What if the command is dynamic? e.g. you're building the command in a javascript filter and then want to run it in the command prompt.

Getting a cmd.exe to run a command

This is easy(ish), the executable you want to call is just cmd.exe.  So you can enter the full path to it, along the lines of c:\windows\system32\cmd.exe

But, we want to pass a specific command to cmd.exe so that cmd.exe will run it.  Do this using the /C argument that cmd.exe accepts:

c:\windows\system32\cmd.exe /C [your command here]

Cmd.exe will treat the string that you pass in as a command and run it in the same manner it would if you had typed it in a command line window.

Building a dynamic command and then using that in the Execute Process Filter 

In a Javascript filter that runs before the Execute Process Filter you need to build your command and then save it so the Execute Process Filter can use it later:

We build up our command in the moveCommand variable, and then we save it into the moveCommand property against the message.

Then in the Execute Process Filter properties we use that moveCommand property by surrounding it with $ signs.