Next Hops, Hop Stacks, and Microbrewing Services in Rhapsody

Next Hops, Hop Stacks, and Microbrewing Services in Rhapsody

Rhapsody is an integration engine used primarily in healthcare. But it is by no means limited to this industry. 

Integration engines came about to connect the many to the many, or rather the 1..n to 1..n.

In the early days of integration engines (Rhapsody was not the first), this generally meant that data flowed from one endpoint to another with transformation of content and/or structure in between.

The engine was the switchboard directing provider data to subscribers.


The Emergence of Microservices

As those engines grew, so too did the demands, including the need to connect different kinds of endpoints beyond the venerable MLLP. In gaining access to databases and web services amongst others, the ability to enrich the data and create even smarter flows emerged.

During this time, Service Oriented Architecture (SOA) became popular, and Enterprise Service Bus (ESB) based products appeared on the scene. With this came the expansion of services and apps; rapidly developed and rapidly changing technology; and expectations for what could be done with that simple doctor’s office visit or purchase of a brand new thing.

One of the architectural styles that developed in response is known as microservices. The thrust of it is to make each your services do less, and to have more of them working independently. This independence means that improvements could made anywhere without needing to rebuild everywhere.

This doesn’t apply everywhere, but interoperability and integration platforms can almost always benefit from incorporating some elements of this pattern.


How Microservices Apply to Rhapsody

If you are Rhapsody developer or architect, then the term microservices is probably not a part of your daily vocabulary. However, you have probably heard of, or maybe even used products that do it. You likely see the use of microservices as niche or outside your domain.

But no more.

Rhapsody is very much a microservices-able application. It has all the elements that you need:

  • The ability to create small independent services
  • A centrally managed runtime repository architecture
  • An efficient request-response messaging system
  • Flexible business process modeling access
  • Access to other repositories
  • Repeatable testing functionality

These are in addition to what you already know and expect of Rhapsody: an open system of infinitely possible little things to do with your data.


Seeing the Microbubbles in the Beer

This may be true, you say. But I just don’t see it.  

A design approach that exploits the dynamic flow of messages across a myriad of services is all we need to get started. The keys are Dynamic Routers and the Hop Stack.

What is the hop stack? If you have ever read an exception stack trace, you have seen a stack at work. If you play any of a number of competitive “trading card” games (Magic the Gathering®, Yu-Gi-Oh!®, etc.), then you are familiar with the idea of a stack. You put things on the stack. You take things off the stack. You always work from the top down.

Here’s a simple example.

We receive a Clinical Document from an HTTPS service request. We want to:

  • Transform it into FHIR® document
  • Validate the transformation
  • Send the validation results back to the sender

Here, then, is our stack of dynamic router target names.

I like to call this the Hop Stack because it is the stack of next hops directing us to our different services.

Hop Stack

Service Oriented Rhapsody

What’s a Rhapsody service look like? For those familiar with Rhapsody, I am not referring to “Web Service”, though they are often part of our available services.

A Rhapsody service is a route with a specific set of components and conditions. To truly be a service, it should perform a narrowly defined function.

Here is one such route. It receives a request. It performs its “micro” service, which here is a FHIR® validator. It sends the response to the next hop in the stack.

Hop Stack FHIR Validator

That next hop could be another service, or it could go back to the requestor’s response router so that it can be delivered back to the sender. Like this one:

Hop Stack Requestor Response

This service transforms a message to a FHIR® Composition. After it does that, it goes back to the stack and gets the next-hop, the Validator.


JavaScript Next Hop Handling

Here’s how we do that in JavaScript filter.


// Consume the Top of the Next_Hop Stack.



next.setProperty("router:Destination", next_hop);



“next_hop” is a Property List. ( A property that has multiple values);

“hop_stack” is an array that we create from the Property List.

We “pop” the top off the stack and that becomes our next destination. (“rhapsody:routerDestination”);

We save the stack back to the “next_hop” property.


** Note: replace(/[\[\]]/g,'').split(',') strips away the [ ] from the property, serialized as a list when use addPropertyValue() method, and then creates an array.


Conditional Stacking

Now let’s say we’ve decided that if there are any errors in the validation, we should send the results to a Quality Control application.


We can add a hop.


// Add Hop.

If (validateErrorCount > 0 ) {



Or perhaps we’ve decided that we want the results to come back to this route before we finish.




Whenever we add a value, it goes on top of the stack. So, depending on what we want, we may add the next hop before or after we set the router:Destination.


Dynamic Routers Are Set to Use Dynamic Destination for Delivery Mode

Request Out Properties

Note: The Delivery Mode must be set to use Dynamic Destination.

The property “router:Destination” is automatically used to direct message to its target.


The Stack in Action

Here is the step-by-step view of the stack.

We received the message, and the set the stack.

We route the message through Dynamic routers by “popping” the first item off the stack.

Dynamic Routers Stack Response

We go on to the next service by consuming the next item on the stack.

Hop Stack Destination

Now let say we’ve decided we want to archive these results into an external Quality Control app, as mentioned above. 

We could then add to the top of the stack . . .

Quality Control Destination

. . . Leaving us with this stack:

Confirmed Quality Response

Now we pop the next hop, to Quality Control.

Next Hop Stack

Which leaves us with:

 Next  Hop Stack  Receive Response

And finally, we send the response back to our sender via the HTTPS endpoint that the message was received on.

 Next Hop Stack Response

Managing Complex Requirements

Now you may think, This is overly complex, and you could do the same all in one route. 

Yes, you could. But that doesn’t mean you should.

Any changes affect the entire flow.

What if you have other message flows that want to use one or more of these microservices?

If you have proliferated many of copies of the same microservices in several routes, what happens when you want to make a change in one of those services? 

Here’s a more complex example of what you could be asked to manage.

Let say a patient is discharged from the local urgent care facility. A Clinical Document is generated. There are several things we want to do with that document.

  • Send a Direct Secure Message to his Primary Care physician so they know about the visit
  • Send a copy of the document to his health plans EHR
  • Send a copy of the document to a regional HIE
  • Send a link to an ACO
  • Send a copy to his Cloud Health care record
  • Send a Get Well Soon card to their email box and ask, “How was the service you received?”

To do those things, we may need to get some additional information.

  • Determine his Primary Care Physician (PCP)
  • Get the PCP’s DSM mailbox
  • Find the patient identifiers for patient in those different EHRs
  • Get his Cloud Personal Health Record authorization information

Let’s make a stack of services that we are going to perform. We’ll also make some dynamic router targets names to go with them.

Target Routers

Organizing the services into a stack gives you flexibility to use many narrow services. Manipulating the stack is simple and straightforward. You can extend the concept further, but this basic approach will get you started.

Products | Services

Co-Creation Lab

About Lyniate

Knowledge Hub


Contact Support