Something like this would make that much, much easier. Cloverleaf would route to this Apache product, which would then route to the appropriate service. The data on traffic, etc., would be especially useful (i.e., the service that sends faxes is slow, etc.)
Each processor in the flow receives the full flow file, so each step along the way gets the "state" in full. This helps in case something interrupts the flow - you can resume an hour or a day later.
Does the NiFi designer have the ability to do something like this, the ability to create abstractions in the front end?
At my last startup, we did user tests every week, and my cofounder was very careful never to let on which test items were made by us. We didn't have our name on the door or on the buzzer. Nothing with our logo was visible between the entryway and the user interview room. And when he started showing products, he'd always start with somebody else's.
It was great. We got some incredibly honest feedback (sometimes brutally so) on what we were building. It helped us kill a lot of bad directions early. Most people just don't want to tell you that your baby is ugly, but they'll happily dish if they think it's somebody else's.
For example, you could set up a fake market research org, and have them say they are "conducting a study on [your market] and are looking for users of products like [competitor 1], [competitor 2], and [your product]". Then for the user testing sessions you could rent a conference room from somebody like Regus, or even rent a user testing lab. Then during the tests, make sure to start with general questions and test (or show screens from) the other products before you get to testing yours.
I'm not sure if those specifics will work in your environment, but I hope you see what I mean.
However, the functionality of the engine itself is top notch. We've had some Mirth servers running for a year at this point without incident. It handles alot of things around the nuances of HL7 nonchalantly, which has usually been my hang-up with non-healthcare specific toolsets like Mule or Camel.
That being said, I'll definitely be checking this out.
That's what I did for a long time. HL7 contains information such as "Admissions, Discharges, and Transfers (ADT)" which is sent from the Hospital Information System (HIS) to other department's systems (radiology, pharmacy, medical records, and possibly dozens more) and vice versa (LAB results back to HIS, for example).
HL7 interface engines unpack the HL7 data into separate segments, fields, and subfields, identify the type/subtype of message, route to various destinations based on the type and any other fields, map the data and reformat as necessary for the destination, encode back into HL7, and send it. It also needs to queue the messages as needed, re-transmit or set aside the message, or just stop sending depending on what it gets back in the form of response codes. So you can see in the diagram some of those steps. The also handle input/output either in the form of TCP/IP ports, reading/writing files (for batch processing), or pretty much any other method you can send and receive data (serial ports, in some old cases).
I'm kind of curious how (and how easy it is) to define which fields in the input for a given event goes to the output (and do certain transformations on those fields if needed).