Tracking the spread of illness with APIs

Reading Time: 3 minutes

Have you ever commented that a cold or a stomach bug seems to be “going around”? Does it seem like all your friends and family in a particular location are complaining about being sick all at once on social media?

Sickweather is an app that’s counting on social media users to do just that; it provides real-time “disease alerts” pushed to mobile phones based on social data collection.  But now, that data is going to be put to even better use. They have created an API to allow healthcare providers third parties access to the data in order to better understand health trends.

“”Our goal is to get more healthcare companies and other entities to plug in Sickweather to understand where real-time sickness trends are,” says CEO Graham Dodge. “It could help them do pre-diagnoses, and they can also share real-time data in a global database.”

We believe APIs could be truly transformative in healthcare, and that the use of data could substantially improve not only the patient experience, but patient outcomes. It’s incredible that something as simple as complaining about your stuffy nose on Twitter could create positive health benefits for lots of people.

Check out our webinar for more information on how APIs are impacting healthcare.

Being picky with JMS

Reading Time: 10 minutes

Mule ESB offers an amazing out-of-the-box integration which easily integrates with ActiveMQ. There is a plethora of examples on the internet that will show how to use ActiveMQ with Mule. But here we will explore how to use a filter with ActiveMQ and Mule that will help us picking up the right JMS messages we need.

Consider an environment where there is a JMS queue and there are multiple consumers listening to that queue; how can a Mule flow filter and pick up a particular JMS message of choice from all the messages available in the queue?

Let’s assume we have a JMS queue named MyQueue which many consumers listening to it:

beingpickywithjms_1

We can see the queue contains few messages in it. Now all these messages can be consumed by any of the consumers out there which are listening to this queue. But how can our JMS consumer in our Mule flow select particular messages and consume only a selection of messages out of it?

We can filter JMS messages based on JMS properties like JMS priority, JMS Type and Headers, etc. We will first look into how we can filter JMS messages based on JMS priority and then with Header.

To consume a JMS message based on JMS priority, we need to insert the message into the queue with that priority. Let’s consider first that we will only consume JMS messages whose priority will be, say, 9.

So, let’s first insert a couple of JMS messages in the queue MyQueue with priority 9.

beingpickywithjms_2

So, now we have our queue with total 5 messages out of which 2 messages have the priority 9 and remaining having default priority of 0.

beingpickywithjms_3

With this in place we will now consume the messages in the queue MyQueue with 2 consumers listening to the same queue; one that will consume only those messages with priority=9 and the other will consume the remaining messages with default priority.

beingpickywithjms_4

We will now create a flow that will filter and consume messages from the JMS queue based on priority. That means we will be consuming only those messages from the queue  MyQueue whose JMS priority is 9. We will be using jms:selector here to filter JMS messages as follows:-

So, now if we start our flow, we will find that our JMS consumer from our Mule flow has selectively consumed the messages from the queue MyQueue whose JMS priority is 9 leaving other messages in that queue.

beingpickywithjms_5

You can see here that it has consumed only those messages of priority 9 and remaining messages will be ignored.

So we can now configure JMS messages with a particular message priority and later we can consume the messages based on that priority.

Now let’s have another Mule flow, with another JMS consumer, and this time without a filter listening to the same queue MyQueue :-

This time we haven’t given any filter and now we will find all the other messages are consumed by the consumer leaving the queue empty:-

beingpickywithjms_6

Using a dynamic JMS selector:-

Now the question arises, can we do this dynamically? Can we select the messages by its JMS properties which are set dynamically?

Yes, we can. We use this selector option in an expression to use a dynamic JMS selector. To select dynamically we can use the select option of Mule Requester and can call it in the middle of a Mule flow, selecting and consuming the messages with dynamic selection:-

Here we have selected the messages with priority=9 dynamically from a variable with an expression. We can use values from variables, inbound properties, properties file or from a message payload directly to make it dynamic.

Pushing a message to JMS queue with JMS priority from Mule :-

Next we will see how to insert a message in our JMS queue, directly from our Mule flow, setting JMS priority of the message to 9.

Here is the Mule flow, which can directly set the message into JMS queue with a priority 9:-

Here we will set the priority in our message payload. To set priority in our payload we will be configuring it as the following:-

So, if we invoke the mule flow by hitting the url:- http://localhost:8081/jms   the message will now be pushed into the queue MyQueue with priority 9 as follows:-

beingpickywithjms_7

In a similar way we can also configure the JMS messages by setting other JMS properties like JMS header in our Mule flow as follows:-

Each message will be send to the queue MyQueue with a header attached with it. So, if we check the property of the message in the queue, we can see our header is attached to it:-

beingpickywithjms_8

And then consume it based on the Header:-

So here messages from queue MyQueue will be consumed only if its header is MyCustom-Header in the same way it filtered and consumed JMS messages based on priority.

Using dynamic JMS selector again:-

Again, if we want to consume it dynamic selection, we can use the expression in Mule Requester and select the message based on header while fetching the header from a variable:-

At this point, you should have a good idea on the way to configure JMS messages with JMS properties and consuming the messages from a Queue in a multi-consumer environment based on the properties by applying filters both statically and dynamically.

Now, you can experiment in your own way and configure JMS messages and implement the example.

Please do share your feedback and experiences in the below section for comments.


How is technology transforming the NFL?

Reading Time: 3 minutes

As the Denver Broncos and Carolina Panthers jog onto the field for Super Bowl 50 this Sunday, most eyes will be drawn to their large shoulder pads and shiny helmets. What many people won’t notice, however, are the tiny, quarter-sized RFID transmitters hidden in their shoulder pads. Made by Zebra Technologies, these connected, wearable devices pinpoint each player’s real-time field position, speed, distance traveled and acceleration by emitting radio frequencies to RFID receivers located around the stadium.

Wearable technology could have the potential to transform the NFL. From making the sport safer for the players to bringing fans closer to their favorite teams to providing more insight for coaches, data provided by wireless sensors has multiple uses. The NFL has already invested heavily in a number of IoT technologies and that trend is poised to accelerate.

We’ve noted before, when discussing IoT, that it won’t be the devices themselves, but rather the clever use of data from connected devices that will create value for businesses. There are lots of value niches in all kinds of professional sports that data derived from connected devices could enhance.

“We’ve always had these traditional NFL stats,” says Matt Swensson, senior director of Emerging Products and Technology at the NFL. “The league has been very interested in trying to broaden that and bring new statistics to the fans. Along the way, there’s been more realization about how the data can be leveraged to make workflow more efficient around the game.”

Take a look at more of my thoughts about how connected devices and IoT will change the NFL.

New Mule 3.8 & Studio 6.0 beta releases

Reading Time: 5 minutes

Things are shifting into high gear for the new year over at MuleSoft, and we’ve got two beta releases ready for everyone to kick the tires on: Mule 3.8 and Studio 6.0. The Mule 3.8 release is the first to bring together our Mule and API gateway runtimes in one single package. It also adds support in our high availability feature for multiple data centers with a new quorum feature. Studio features new API design round tripping with API Designer and DataWeave flat file support. And we’ve also greatly improved troubleshooting messages and the debugger.

Unified runtime for APIs and integration

When we first started our building our API solution, we created an extension of our core runtime specifically for API gateways.  As time moved on, APIs became more and more central to everything we do, so in this release, we’ve unified the API Gateway extensions  with the core Mule runtime, simplifying development and operations. Please see the migration guide for information on how to migrate.

API design collaboration across Studio & API Designer

Discover APIs to implement directly from API Manager, and easily synchronize API designs across Studio and API Designer projects.

push pull apis

Improved debugging and error messages

The Mule 3.8 runtime has improved error messages, which allow you to clearly see where the error is coming from, the payload at that point in time, the configuration for that element, and click to navigate to that point in the flow.

error messages

The debugger now also shows more detailed data for some connectors, such as HTTP and Database, making it easier to debug. Over time we’ll be adding support for more and more connectors

HttpInfo

Mule HA Improvements

Mule HA includes a number of new improvements. First and foremost, it contains a new quorum feature, which allows you to specify the minimum number of Mule instances to function. This allows you to more effectively deal with network splits in a cloud environment, such as AWS and Azure. It also now includes a persistence option, which allows you to store data in the ObjectStore in a database. This improves resilience and allows you to create backups for recovery situations.

And more

There are also many other enhancements in this release:

  • DataWeave now supports flat files, allowing to parse files that have hierarchical structures in a text delimited or fixed length form.
  • Users can now browse for WSDLs in the Anypoint Exchange and when configuring the WS Consumer.
  • TLS improvements: TLS context can be shared in a domain, the cipher suite and protocol configuration is allowed per connector, TLS 1.0 is now disabled by default and there is a new “insecure” mode for local testing which doesn’t perform certificate validation.
  • Support for nesting tests inside folders in MUnit and running multiple suites at a time.

Read the Documentation

We look forward to your feedback in this post’s comments and in our forum. Happy connecting!