Tracing entire data flow

This lab will go over results of actions from the previous labs, validating messages from devices to broker and throughout the OpenWhisk ecosystem.

Exploring the AMQ Console

OpenShift supports accessing a user interface for the AMQ broker.

Select the iot-serverless project on the righthand side.

Click on the pod associated with the broker-amq deployment:

AMQ Pod

On the right side of the page under the broker-amq container, select Open Java Console

Getting to AMQ Console

From the AMQ broker console, we can view a variety of metrics.

AMQ Console Overview

First, expand clientConnectors. You will notice two child objects, mqtt and openwire. The MQTT client is the simulated software that is transmitting IoT related telemetry. The OpenWire client is the OpenWhisk feed provider that is reading values from the broker and firing the trigger to execute the sequence action.

AMQ Console Overview

Next, expand Topic. Each IoT asset communicates on a topic starting with .sf. The JMS selector .sf.> is also present and if you expand the folder, you will see the mqtt-provider which confirms that the OpenWhisk feed was successfully registered to the broker through the feed provider.

AMQ Console Overview

Now, select any one of the topics (starting with sf.) on the left hand side underneath the Topic dropdown. The various properties for the topic are displayed on the right side. Locate the Enqueue Count and Dequeue Count. They each should have a value greater than 0 and their values should also match. This represents that the broker received a certain number of messages from the IoT asset (Enqueue) and that the feed provider consumed a certain number of messages (Dequeue).

Verifying Messages Were Sent to OpenWhisk

In the previous section, we confirmed that the Feed Provider consumed the messages off of the topics, however, we should also confirm that those messages were then sent to the iotServerlessTrigger.

View the logs from the feed provider pod

 $ oc logs $(oc get pods -l=application=mqtt-provider -o 'jsonpath={.items[0].metadata.name}')

2018-05-06 23:23:52.645  INFO 1 --- [enerContainer-1] com.redhat.iot.service.OpenWhiskService  : About to Invoke: http://nginx.openwhisk.svc.cluster.local/api/v1/namespaces/_/triggers/iotServerlessTrigger
2018-05-06 23:23:52.656  INFO 1 --- [enerContainer-1] com.redhat.iot.service.OpenWhiskService  : Status: 202  Response body:{"activationId":"7912967ac688444192967ac688344197"}

A number of log messages similar to the output above should be seen (one for each message consumed off of the broker). As illustrated, the feed provider invoked an API endpoint in OpenWhisk for the trigger, and an HTTP 202 (Accepted) was returned. In addition, the activationId was also returned in a similar fashion to when we fired the trigger using the wsk CLI.

Viewing Results in the Database

At this point, OpenWhisk has accepted the request that was sent from the feed provider to the iotServerlessTrigger. Given that we have validated the sequence action previously, we should be able to skip right to the database and verify results have been persisted.

Obtain a shell session in the MongoDB pod by executing the following command:

$ oc rsh $(oc get pods -l=deploymentconfig=mongodb -o 'jsonpath={.items[0].metadata.name}') bash -c "mongo 127.0.0.1:27017/\${MONGODB_DATABASE} -u \${MONGODB_USER} -p \${MONGODB_PASSWORD}"

MongoDB shell version: 3.2.10
connecting to: 127.0.0.1:27017/iotserverless
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
	http://docs.mongodb.org/
Questions? Try the support group
	http://groups.google.com/group/mongodb-user
>

Finally list the rows in the results table

> db.results.find()

The entire end to end flow is validated if records are returned.

Exit out of the MongoDB shell and pod.

icon previous icon home icon next