Scenario: Fan-in per device notification

In this scenario, many publisher devices publish messages to one topic string. There is one subscriber device that subscribes to this topic string.

Background to this scenario

A hospital wants to be able to monitor the blood pressure of individual patients. Patients take their blood pressure by using a device at home. An application on the device publishes to a topic string. These publishing devices sit in the internet. The published message contains information including the patient ID, blood pressure, and timestamp.

At the hospital, the IBM® IoT MessageSight sits within the DMZ. An application that runs on a device within the hospital intranet subscribes to the blood pressure device topic string, and remotely monitors the blood pressure of each patient. Alerts are generated when necessary. Complete the steps in the following section to understand how to set up this scenario.

Planning and implementing the solution

Use the following information to help you to plan, and implement a fan-in per device notification scenario.

Understanding your publish/subscribe architecture

In this scenario, there are many publisher devices that publish messages to one topic string. There is one subscriber device that subscribes to this topic string. Therefore, this scenario is a fan-in per device notification. The following diagram shows the architecture of a fan-in per device notification scenario.

Fan-in per device notification diagram. Many publisher devices publish messages to one topic string. There is one subscriber device that subscribes to the topic string.
Understanding the required messaging behavior for your solution

Do you want durable or non-durable subscriptions? What quality of service do you need?

If a subscription is durable, when the subscribing application disconnects, the subscription remains in place and can be used by the subscribing application when it reconnects. In this scenario, the subscriptions are durable because only one message per day is being sent from patients that are high risk, and therefore it is important that the subscriber device receives each message.

A quality of service of 1 is appropriate because the message delivery across the network must be guaranteed at least once. It is acceptable to have duplicates as any duplicates can be discarded. QoS 1 messages are persistent. The message is stored on the IBM IoT MessageSight until the message is received by the subscriber of the message.

Planning your solution
In this scenario, consider the following key points:
  • Which protocol is appropriate?

    IBM IoT MessageSight natively supports MQTT and JMS. You must consider which protocol is appropriate for your business needs. The amount of data sent between the devices is small. If some patients do not have internet access, then expensive mobile connections are used. The messages between the devices must be sent reliably. The MQTT protocol is designed for exchanging messages between small devices on low bandwidth, or expensive connections, and to send messages reliably. Therefore, MQTT protocol is appropriate in this scenario.

  • What message size is appropriate?

    In this scenario, the publisher devices send small, persistent messages. The information that is contained within the message is about patient ID, blood pressure, and time. Therefore, the message can be relatively small. You can limit the message size that is allowed to be sent through IBM IoT MessageSight by using the maximum message size attribute of an endpoint. For more information about endpoints, see Message hub, endpoints, and policies.

  • What message count is appropriate?

    Consider what maximum message count is sensible for your messaging needs. In this scenario, the quality of service is 1, so messages are stored until a subscriber receives the message. Therefore, a higher message count might typically be considered.

  • What is the maximum number of topic levels that you need?

    You can have up to 32 levels in a topic string. Fewer levels are easier to manage, but many levels might be required to set up specific solutions. In this scenario, the topic string length can be relatively short. For example, Hospital name/Blood Pressure. By including the level of /Blood Pressure, the hospital can easily include other measurements, such as heart rate, in the future. For example, the topic string Hospital name/Heart Rate might be added.

  • How are you going to ensure that all of your user IDs are unique?

    In this scenario, it is crucial that all user IDs are unique so that the blood pressure for each patient is recorded against the correct patient. In this scenario, you might decide to use the patient ID number as that number is unique to each patient.

  • What message depth is appropriate?

    When the maximum message depth is reached, you cannot publish any more updates to that topic string until the number of messages is reduced. All devices publish to the same topic string, therefore you need to ensure that the maximum message depth is sufficient to cope with the messages that are published from a given number of patients.

For more information about planning your solution, see Planning.

Writing your applications

In this scenario, you must decide the name of the topic strings that you are publishing and subscribing to. For this messaging pattern, each publisher must publish to one topic string. The subscriber device subscribes to the same topic string. In this scenario, the name of the topic string is Hospital/Blood Pressure.

Setting up your IBM IoT MessageSight infrastructure, and security

Create the infrastructure by configuring message hubs and endpoints. Set up your security by creating connection and messaging policies.

In this scenario, the hospital requires one message hub because there is one goal - recording blood pressure. The hospital requires two endpoints to ensure that internal and external network traffic is kept separate.

Complete the following steps to set up a message hub and endpoints for this scenario:

  1. Create your message hub. A message hub is an organizational configuration object to collect the endpoints, connection policies, and messaging policies that are associated with a specific goal in a single place. In this scenario, the message hub is called Blood Pressure Monitoring Hub.

                curl -X POST \
                    -H 'Content-Type: application/json'  \
                    -d  '{
                             "MessageHub":  {
                                "Blood Pressure Monitoring Hub":  {
                                     "Description": "Message Hub for monitoring blood pressure "
                                }
                             }
                          }
                        '  \
                     http://127.0.0.1:9089/ima/v1/configuration
  2. Create your connection policies. A connection policy is used to authorize a client to connect to an endpoint.
    • Create a connection policy for the publishers. In this scenario, the connection policy is called Blood Pressure Monitoring External ConPol.

      In this scenario, the hospital restricts publisher access so that the publisher device must use MQTT protocol. Additionally, publisher access is restricted on appliance messaging group, where all publishers must be a member of the Patients group.

    • Create a connection policy for the subscriber. In this scenario, the connection policy is called Blood Pressure Monitoring Internal ConPol.

      In this scenario, the hospital restricts subscriber access so that the subscriber device must use MQTT protocol.

    You can use the following cURL commands to create the connection policies:


                curl -X POST \
                    -H 'Content-Type: application/json'  \
                    -d  '{
                             "ConnectionPolicy":  {
                                "Blood Pressure Monitoring External ConPol":  {
                                "UserID": "*",
                                "Protocol": "MQTT",
                                "AllowDurable": false,
                                "Description": "Hospital external connection policy"
                                }
                             }
                          }
                        '  \
                     http://127.0.0.1:9089/ima/v1/configuration

                curl -X POST \
                    -H 'Content-Type: application/json'  \
                    -d  '{
                             "ConnectionPolicy":  {
                                "Blood Pressure Monitoring Internal ConPol":  {
                                "UserID": "*",
                                "Protocol": "MQTT",
                                "AllowDurable": false,
                                "Description": "Hospital internal connection policy"
                                }
                             }
                          }
                        '  \
                     http://127.0.0.1:9089/ima/v1/configuration

  3. Create your topic policies. A topic policy is a messaging policy that is used to authorize a client to publish or subscribe to a topic.
    • Create a topic policy for the publisher. In this scenario, the topic policy is called Blood Pressure Monitoring External TopicPol.

      The hospital restricts publisher access so that the publisher devices can publish to the topic string Hospital name/Blood Pressure only.

    • Create a topic policy for the subscriber. In this scenario, the topic policy is called Blood Pressure Monitoring Internal TopicPol.

      The hospital restricts subscriber access so that the subscriber device can subscribe to the topic string Hospital name/Blood Pressure.

    You can use the following cURL commands to create the topic policies:


                curl -X POST \
                    -H 'Content-Type: application/json'  \
                    -d  '{
                             "TopicPolicy":  {
                                "Blood Pressure Monitoring External TopicPol":  {
                                   "Topic": "Hospital name/Blood Pressure",
                                   "UserID": "*",
                                   "ActionList": "Subscribe",
                                   "Protocol": "MQTT",
                                   "MaxMessages": 5000,
                                   "Description": "Hospital external topic policy"
                                }
                             }
                          }
                        '  \
                     http://127.0.0.1:9089/ima/v1/configuration

                curl -X POST \
                    -H 'Content-Type: application/json'  \
                    -d  '{
                             "TopicPolicy":  {
                                "Blood Pressure Monitoring Internal TopicPol":  {
                                   "Topic": "Hospital name/Blood Pressure",
                                   "UserID": "*",
                                   "ActionList": "Publish",
                                   "Protocol": "MQTT",
                                   "MaxMessages": 5000,
                                   "Description": "Hospital internal topic policy"
                                }
                             }
                          }
                        '  \
                     http://127.0.0.1:9089/ima/v1/configuration

  4. Create your endpoints. An endpoint authorizes a client to connect to the IBM IoT MessageSight on one, or all configured ethernet interfaces, and a specific port. You create endpoints on a message hub.
    • Create an endpoint for internet network requests. In this scenario, the endpoint is called Blood Pressure Monitoring External Endpoint. Apply the Blood Pressure Monitoring External ConPol, and the Blood Pressure Monitoring External TopicPol to the endpoint.
    • Create an endpoint for intranet network requests. In this scenario, the endpoint is called Blood Pressure Monitoring Internal Endpoint. Apply the Blood Pressure Monitoring Internal ConPol, and the Blood Pressure Monitoring Internal TopicPol to the endpoint.

    You can use the following cURL commands to create the endpoints:


                curl -X POST \
                    -H 'Content-Type: application/json'  \
                    -d  '{
                             "Endpoint":  {
                                "Blood Pressure Monitoring External Endpoint":  {
                                   "Enabled": true,
                                   "Port": 1884,
                                   "MaxMessageSize": "1024KB",
                                   "ConnectionPolicies": "Blood Pressure Monitoring External ConPol",
                                   "TopicPolicies": "Blood Pressure Monitoring External TopicPol",
                                   "MessageHub": "Blood Pressure Monitoring Hub",
                                   "Protocol": "MQTT",
                                   "Interface": "All",
                                   "Description": "Hospital external endpoint"
                                }
                             }
                          }
                        '  \
                     http://127.0.0.1:9089/ima/v1/configuration

                curl -X POST \
                    -H 'Content-Type: application/json'  \
                    -d  '{
                             "Endpoint":  {
                                "Devices Update Internal Endpoint":  {
                                   "Enabled": true,
                                   "Port": 1885,
                                   "MaxMessageSize": "1024KB",
                                   "ConnectionPolicies": "Blood Pressure Monitoring Internal ConPol",
                                   "TopicPolicies": "Blood Pressure Monitoring Internal TopicPol",
                                   "MessageHub": "Blood Pressure Monitoring Hub",
                                   "Protocol": "MQTT",
                                   "Interface": "All",
                                   "Description": "Hospital internal endpoint"
                                }
                             }
                          }
                        '  \
                     http://127.0.0.1:9089/ima/v1/configuration

Testing your solution

For information about troubleshooting any problems that arise during testing, see Troubleshooting.

Monitoring your solution

There are various statistics that you can monitor. In this scenario, use topic monitor, connection monitor, and subscription monitor to understand the health of the solution.

Strengthening your security

You can increase the level of security of a solution in a number of ways:

  • Using a server certificate.
    1. Create a certificate profile.
    2. Create a security profile to encrypt wire traffic.
      • Set UsePasswordAuthentication to True on your security profile in order to force authentication on user ID and password.
    3. Apply the security profile to your endpoints.
    4. Add the server certificate that you are using to the clients so that the clients can authenticate the server.

    For more information about certificates, see Transport Layer Security.

  • Using a client certificate. You must have a sever certificate installed before you use a client certificate.
    1. Upload a client certificate, or CA certificate and key on each client.
    2. Add the specific client certificate, or the CA certificate to the trustStore on IBM IoT MessageSight. The trustStore points to a file containing trusted certificates, so that the server can authenticate the client.
  • Using FIPS.

    FIPS increases message security by using cryptography that complies with the Federal Information Processing Standards (FIPS). Enable FIPS mode by setting the FIPS parameter to True. You can set FIPS to True either by using REST Administration APIs, or by using the IBM IoT MessageSight Web UI. For more information about enabling FIPS mode, see Configuring security.