Objectives

Upon completion of this tutorial, a new developer will be able to:

• Easily navigate around the Vantiq IDE
• Create a simple real-world Vantiq application

Tutorial Overview

This tutorial uses a practical example from the Internet of Things (IoT): processing data from engine temperature and speed sensors to detect and diagnose an overheating engine. The basic steps to creating this application are:

• Create a new Project
• Use the Design Modeler to create the initial Project resources
• Create Sources to receive simulated sensor data
• Use the Service Builder’s visual event handler to specify how the application reacts to asynchronous, real-time engine conditions
• Create a visual front-end with a Client
• Run the application in simulation

Note: if needed, you can import a finished version of this project using the Projects button and select Import. Select Tutorials for Import Type, then select Introductory from the second drop-down, then click Import.

Namespace Privileges

In addition, when following the Tutorials, please make sure you are logged in as the administrator of the Vantiq namespace to which you are assigned. You can check your privilege level by clicking on your username in the title bar. If the bottom of the popup says, “Developer” or “Namespace Admin” at the bottom, you have the needed privileges. If it says, “User (Developer),” then you need to change to a Developer namespace. You may need to first create your own Developer namespace, as described here: Creating a Developer Namespace.

1: Creating an Engine Monitoring Project

The first task in building the engine monitoring system is to create a Project in the Vantiq IDE.

Note: You will be alerted if you do not have permission to create a project in the current namespace. You need to change to, or create, a namespace where you have Developer or Namespace Admin privilege (see above).

Use the Project menu to select New Project, which displays the New Project Wizard. Either create a new Namespace (recommended) or add a new project to the current Namespace, select Design Model as the Project type, and click Continue.

Set the project name to EngineMonitorProject and click Go to New Design Model Dialog.

Define the Design Model as:

• Model Name: EngineMonitor
• Package: com.vantiq.engines
• Description: Determine if there is an engine malfunction
• Design Template: IoT System
• Service Name: com.vantiq.engines.EngineMonitor
• Number of Streams: 2

The Design Template selected is IoT System since it most closely matches the requirements of the engine simulation: receiving data from IoT devices (the sensors), processing that data, and updating a Client that represents an engine dashboard.

The Number of Streams value is set to 2 since our system will be receiving data from two engine sensors: speed and temperature.

Click OK to confirm. After the Design Model generation is complete, the com.vantiq.engines.EngineMonitor Design Model pane is displayed:

2: Understanding the Design Model

The Design Modeler is a visual IDE tool for building Vantiq systems. It allows the user to easily connect Services and Clients, which are the building blocks of a Vantiq system. The Design Model generated for the engine monitor Project contains six nodes:

• Sensors: this is an External System Design Modeler node, which graphically represents the engine’s temperature and speed sensors. External System nodes are used for documentation purposes only. They are meant to represent how the Vantiq system being built receives or transmits data external to the Vantiq system.
• EngineMonitorSensors: this is a Service Design Modeler node, which represents an actual Vantiq Service. This Service has a limited purpose: to receive messages from the temperature and speeds sensors and to forward those events to the EngineMonitor Service for processing.
• EngineMonitor: this is another Service Design Modeler node which represents the Service that will use data from the sensors, determine if that data indicates possible problems with the engine, then forwards the sensor data and engine status to the EngineMonitor Client for display. In this tutorial, the Service Builder is used to modify both Services in this Design Model.
• EngineMonitor: this is a Client Design Modeler node which represents the Client that will display engine status: speed, temperature and any error status. In this tutorial, the Client Builder is used to modify the Client in this Design Model.
• DataWarehouse: this is another External System Design Modeler node. It could represent a database, either Vantiq’s native database or an external database system, to store data received or calculated by the engine system. Since this is a real-time engine status system, this node won’t be used and is deleted as this tutorial progresses.
• OutsideWorld: like the DataWarehouse node and for the same reasons, this node is deleted later on.

This Design Model represents a flow of events in an IoT system. Here is how the data and events for the engine monitoring system will inform us to modify the Services and Clients to develop a working system:

1. Sensor data is captured from two MQTT Sources. The speed and temperature data is simulated by a public MQTT server hosted by Vantiq.
2. The receipt of the Sensor data is handled by the EngineMonitorSensors Service described above. This Service doesn’t need to transform data for our engine monitor system but instead simply publishes it as Outbound Event Types to the EngineMonitor Service for processing. The IoT System Design Template uses two Services to separate the receipt of raw sensor data from the processing of the data as Event Types. This architecture allows the EngineMonitor Service to be reused in other Vantiq systems that process temperature and speed similarly.
3. The EngineMonitor Service receives the temperature and speed Event Types in two separate Event Handlers.a. The speed Event Handler (SpeedEvent) simply saves the sensor data in a Service’s speed Global State variable and then republishes that event to an Outbound Event Type for use by the EngineMonitor Client. The speed Global State variable is necessary so the temperature Event Handler may retrieve and use the speed data without having to store it in the Vantiq database.b. The temperature Event Handler (TemperatureEvent) reads the temperature data to determine if there is an overheating condition (if the temperature reading is 210F or greater). If the engine is overheating, the handler reads the speed Global State variable and constructs an alert message based on the combination of the temperature and speed sensor values. The handler then publishes an event that contains temperature and overheat status data to an Outbound Event Type for use by the EngineMonitor Client.
4. The EngineMonitor Client receives speed, temperature, and overheat status from the EngineMonitor Service’s two Outbound Event Types. These events are processed by two Client Data Streams, each of which is used to run Client widgets (gauges, line charts, etc.) to display the data in a dashboard-like display.

Please note this is a simple example of a working Vantiq system. It demonstrates basic event handling and filtering and works well for a system with a low rate of data receipt (the simulated speed and temperature MQTT messages are received at a rate of one per second). The EngineMonitor Client can easily process the events produced by the EngineMonitor Service, which are produced at no more than two per second.

The system demonstrates the basic architectural principles required to build scalable systems that process thousands of events each second. The core principle is to process the events in memory as they arrive, maintaining any state required for real-time processing in memory as Service Global State. The traditional approach of storing the events in a database when they arrive and then querying the database to process the events is too slow when processing thousands of events each second.

This simple example is not scalable to thousands or more events per second because it does not exploit the flow control and filtering features that the Event Handler system provides to filter or combine data and reduce the overall number of events processed by the system and delivered to Clients.

Finally, this system also demonstrates a Client that does not have to retrieve data from a database and process it in order to display useful system status. It should be a goal of any scalable system to limit data transformation and modification operations to Service Event Handlers rather than delegating that work to Clients.

3: Create the Engine Sensor Sources

Two MQTT Sources must be created to simulate the speed and temperature data from a public MQTT server hosted by Vantiq.

Use the Add menu to select Source…:

Use the New Source button to display the New Source pane. Enter the following values to configure the source:

1. Source Name: SpeedSensor
2. Package: com.vantiq.engines
3. Source Type: MQTT

Add a Server URI from the Server URI tab: tcp://public.vantiq.com:1883

Add a Topic from the Topic tab: com.vantiq.mqtt.enginespeed

Save the Source then click the Test Data Receipt button from the pane’s toolbar. The Source pane will switch to the Subscription pane to display data received from the MQTT server:

Note the simulated data is sent approximately once per second and contains a JSON object with two properties: systemId and speed.

Follow similar steps to create a second Source to receive simulated temperature events. Enter the following values to configure the source:

1. Source Name: TemperatureSensor
2. Package: com.vantiq.engines
3. Source Type: MQTT

Add a Server URI from the Server URI tab: tcp://public.vantiq.com:1883

Add a Topic from the Topic tab: com.vantiq.mqtt.enginetemp

Save the Source.

4: Renaming the Design Model’s Events

In Lesson 2 above, a four-step description described the flow of data and events for the engine monitoring system to be built. This lesson shows how to rename the Service Event Types and Client Data Streams to more accurately reflect that flow of data and events.

1. Right-click the EngineMonitorSensors Service in the Design Model, then select Edit in Service Builder menu item. The pane for that Service is displayed. Expand the Outbound section under the Interface tab, then select Sensor0, as shown below:Change the Name of the Outbound Event to SpeedEvent. Save that change using the Save Changes button in the pane’s title bar.
2. Select Sensor1 from the same Outbound section. Change the Name of the Outbound Event to TemperatureEvent and again save that change.
3. Right-click the EngineMonitor Service (Service nodes have a green title bar) in the Design Model, then select Edit in Service Builder menu item. The pane for that Service is displayed. Expand the Inbound section under the Interface tab, then select SensorReading0. Change the Name of the Inbound Event to SpeedEvent and again save that change.
4. Select SensorReading1 from the same Inbound section. Change the Name of the Inbound Event to TemperatureEvent and again save the change.
5. Expand the Outbound section under the Interface tab, then select AnomalyDetected0. Change the Name of the Outbound Event to EngineStatus and again save that change.
6. Select AnomalyDetected1 from the same Outbound section. Change the Name of the Outbound Event to EngineSpeed and again save that change.
7. Right-click the EngineMonitor Client (Client nodes have a purple title bar) in the Design Model, then select Edit in Client Builder menu item. The pane for that Client is displayed. Click the Edit tab, expand the Data Streams tree item, as shown below:Click the AnomalyDetected0 Data Stream to display the Edit Data Stream dialog. Make the following changes in that dialog:a. Data Stream Name: EngineStatusb. Service: com.vantiq.engines.EngineMonitor

   c. Event: EngineStatus

   Click Save to save the Data Stream.

8. Click the AnomalyDetected1 Data Stream to display the Edit Data Stream dialog. Make the following changes in that dialog:a. Data Stream Name: EngineSpeedb. Service: com.vantiq.engines.EngineMonitorc. Event: EngineSpeedClick Save to save the Data Stream, then save the Client using the Save Changes icon in the pane’s title bar.

Note after these changes, the Service and Client node in the Design Model pane changes to reflect the new Event Type and Data Stream names. Use the Save Changes button in the Design Model pane’s title bar to save those changes.

5: Remove Unneeded External Systems

As explained in Lesson 2 above, this system doesn’t require storing any event data in an External System. This means we can delete the DataWarehouse and OutsideWorld Design Model nodes. Click each of those nodes then use the Delete toolbar button to delete them from the Design Model, then save the Design Model. Even though those two nodes are used for documentation purposes only, deleting them more accurately reflects the system being developed. The Design Model pane should now look like this:

6: Address the To Do List

Notice that in the screenshot from the previous lesson, there is a To Do List in the lower, left corner of the Design Model pane. The To Do List contains errors found in the two Services contained in the Design Model. At this point in the system development process, these errors are normal and are all associated with Inbound Event tasks in those Services that need to be configured for the engine system.

Clicking on a To Do List item in a Design Model causes the Service pane that contains the error to be displayed. Click on the first error in the list which will cause the com.vantiq.engines.EngineMonitor Service to display and automatically navigate to the Implement tab which contains the SpeedEvent Inbound Event Handler that is associated with the error. The Service pane should look like this:

This is the Event Handler which processes speed sensor data from the EngineMonitorSensors Service. Recall from Lesson 2 that the SpeedEvent Inbound Event Handler saves the sensor data in a Service’s speed Global State variable then republishes that event to an Outbound Event Type for use by the EngineMonitor Client. This involves the following changes to the Visual Event Handler shown in the screenshot above (it contains the SensorReading task (the orange rectangle contained in the Ingest task context):

1. From the Modifiers section of the Event Handler palette, drag and drop an AccumulateState task on the SensorReading task. Then click on the AccumulateState task and rename it SaveSpeed.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the procedure property. This allows you to write the code snippet for updating your Service’s state based on the incoming events. Select VAIL Block in the Edit union parameter dialog then replace the placeholder VAIL code with the following:var curSpeed = event.speed
state = curSpeedClick OK to return to the task configuration parameters. Enter speed as the stateProperty property. Click OK to complete editing the SaveSpeed task. The SaveSpeed task has now been configured to update the speed Global State variable every time a sensor reading is received by the SensorReading task. When the EngineMonitor Service gets saved, the SaveSpeed task will cause three Procedures to be generated: com.vantiq.engines.EngineMonitor.speedGet(), com.vantiq.engines.EngineMonitor.speedReset(), and com.vantiq.engines.EngineMonitor.speedUpdate(). These may be used to retrieve, reset and update the speed Global State variable.
2. Right-click the SaveSpeed task, select Link Existing Task to display a dialog. In the dialog, select React as the Task Name and event as the Downstream Event. Click OK. This will link the SaveSpeed task to the React task, which was the goal outlined in Lesson 2: save the speed sensor value then republish that data via the React task.
3. Click the React task and rename it to PublishSpeed. Click the Click to Edit link to edit the configuration for this task. The service property is correctly set (com.vantiq.engines.EngineMonitor). However, the eventTypeName property needs to reflect the renamed Outbound Event: replace AnomalyDetected0 with EngineSpeed. Click OK. The Event Handler graph should now look like this:
4. Since the speed sensor data will only be used when processing the temperature data to determine engine alert status, there are four tasks in the handler that are not needed. Click each of the following tasks and delete them using the Delete key or the Delete item in the pane’s toolbar: Analytics, GetStatistics, DetectAnomaly, and StoreAnalytics.
5. The blue rectangles in the graph are called “task contexts”. These are created by the Design Template to show how tasks are related. Now that some of the tasks have been deleted, two of the task contexts, Analysis and DetectSituation, are empty. Right-click each of those task contexts and select the Remove Task Context menu item.
6. To more accurately document the running system, the SaveSpeed task can be added to the React task context. Right-click React and select the Add Task to Context menu item. Select SaveSpeed from the Task Name menu, then click OK. The Event Handler graph should now look like this:Save the changes in the EngineMonitor Service using the Save Changes titlebar icon. Notice how the Service’s SpeedEvent Event Handler now has no errors and the To Do List in the Design Model has fewer items.

Click on the next To Do List item in the Design Model. This will cause the same com.vantiq.engines.EngineMonitor Service to display and automatically navigate to the Implement tab which contains the TemperatureEvent Inbound Event Handler that is associated with the error. The Service pane should look similar to the SpeedEvent Event Handler above because they both processed sensor events in the same way. Here’s how to restructure the TemperatureEvent Event Handler for the engine monitoring system:

1. From the Filters section of the Event Handler palette, drag and drop a Filter task on the SensorReading task. Then click on the Filter task and rename it OverheatCheck.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the condition property. Choose Visual Filter as the condition Type then click the Add Visual Condition + button. Enter the following Visual Condition parameters:Property Name: temperatureComparator: >=Filter Expression: 210

   Click OK. This Visual Filter determines if the engine is overheating by checking if the temperature sensor reading is greater than or equal to 210 degrees. Click OK to save the configuration.

2. Drag and drop a second Filter task on the SensorReading task. Then click on the Filter task and rename it NoAlert.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the condition property. Choose Visual Filter as the condition Type then click the Add Visual Condition + button. Enter the following Visual Condition parameters:Property Name: temperatureComparator: <Filter Expression: 210

   Click OK. This Visual Filter determines if the engine is not overheating by checking if the temperature sensor reading is less than 210 degrees. Click OK to save the configuration.

3. From the Modifiers section of the Event Handler palette, drag and drop a Transformation task on the NoAlert task.Then click on the Transformation task and rename it ClearAlert. Click the Click to Edit link to edit the configuration for this task. Click on the link next to the transformation property. Choose Visual Transformation as the transformation Type then click the Add a Transformation + button. Enter the following Visual Transformation parameters:Outbound Property: alertMsgTransformation Expression: “”Click OK. This Visual Transformation sets a new event property, alertMsg, to have a string value of “” which effectively means there is no alert to be displayed in the engine dashboard. This is because the NoAlert Filter task has determined that the engine is not overheating. Check the transformInPlace checkbox, which adds the new alertMsg property to the temperature event. Click OK to save the ClearAlert task configuration.
4. Right-click the ClearAlert task, select Link Existing Task to display a dialog. In the dialog, select React as the Task Name. Click OK. This will link the ClearAlert task to the React task, which was the goal outlined in Lesson 2: add the overheat status to the temperature then republish that data via the React task.
5. Move the new Filter and Transformation tasks to their proper task context boxes:
   1. Right-click the React task context and select the Add Task to Context menu item. Select ClearAlert from the Task Name menu, then click OK.
   2. Right-click the DetectSituation task context and select the Add Task to Context menu item. Select NoAlert from the Task Name menu, then click OK.
   3. Right-click the DetectSituation task context and select the Add Task to Context menu item. Select OverheatCheck from the Task Name menu, then click OK.
6. Since the temperature sensor data will only be used to determine engine alert status, there are four tasks in the handler that are not needed. Click each of the following tasks and delete them using the Delete key or the Delete item in the pane’s toolbar: Analytics, GetStatistics, DetectAnomaly, and StoreAnalytics.
7. Now that some of the tasks have been deleted, one of the task contexts, Analysis, is empty. Right-click that task context and select the Remove Task Context menu item.
8. Click the React task and rename it to PublishStatus. Click the Click to Edit link to edit the configuration for this task. The service property is correctly set (com.vantiq.engines.EngineMonitor). However, the eventTypeName property needs to reflect the renamed Outbound Event: replace AnomalyDetected0 with EngineStatus. Click OK. The Event Handler graph should now look like this:
9. Drag and drop a Transformation task on the OverheatCheck task. Then click on the Transformation task and rename it RetrieveSpeed.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the transformation property. Choose Visual Transformation as the transformation Type then click the Add a Transformation + button. Enter the following Visual Transformation parameters:Outbound Property: speedTransformation Expression: com.vantiq.engines.EngineMonitor.speedGet()Click OK. This Visual Transformation retrieves the speed Global State variable so that it can be used to choose between one of two engine overheating alert messages in subsequent tasks. Check the transformInPlace checkbox, which adds the retrieved speed property to the temperature event. Click OK to save the RetrieveSpeed task configuration.
10. Drag and drop a Filter task on the RetrieveSpeed task. Then click on the Filter task and rename it SpeedOverheat.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the condition property. Choose Visual Filter as the condition Type then add the following two Visual Condition parameters, in this order:Property Name: speedComparator: !=Filter Expression: null

    and

    Property Name: speed

    Comparator: >=

    Filter Expression: 45

    Click OK. This Visual Filter determines if the engine is overheating and the speed is not null and the speed is greater than or equal to 45. The speed can be null if a speed reading has not yet appeared. A subsequent task will set the overheat alert condition for use by the engine dashboard.

11. Drag and drop a Transformation task on the SpeedOverheat task. Then click on the Transformation task and rename it AddSpeedOverheat.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the transformation property. Choose Visual Transformation as the transformation Type then click the Add a Transformation + button. Enter the following Visual Transformation parameters:Outbound Property: alertMsgTransformation Expression: “Your engine is overheating: please reduce your speed.”Click OK. This Visual Transformation sets the alertMsg property to have a string value of “Your engine is overheating: please reduce your speed.” which means there is an alert to be displayed in the engine dashboard. This is because the SpeedOverheat Filter task has determined that the engine is overheating and the engine speed is above 45. Check the transformInPlace checkbox, which adds the new alertMsg property to the temperature event. Click OK to save the AddSpeedOverheat task configuration.
12. Drag and drop a second Filter task on the RetrieveSpeed task. Then click on the Filter task and rename it NonSpeedOverheat.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the condition property. Choose Visual Filter as the condition Type then add the following two Visual Condition parameters, in this order:Property Name: speedComparator: !=Filter Expression: null

    and

    Property Name: speed

    Comparator: <

    Filter Expression: 45

    Click OK. This Visual Filter determines if the engine is overheating and the speed is not null and less than 45. A subsequent task will set the overheat alert condition for use by the engine dashboard.

13. Drag and drop a second Transformation task on the NonSpeedOverheat task. Then click on the Transformation task and rename it AddNonSpeedOverheat.Click the Click to Edit link to edit the configuration for this task. Click on the link next to the transformation property. Choose Visual Transformation as the transformation Type then click the Add a Transformation + button. Enter the following Visual Transformation parameters:Outbound Property: alertMsgTransformation Expression: “Your engine is overheating: check for a malfunctioning fan or a coolant leak.”Click OK. This Visual Transformation sets the alertMsg property to have a string value of “Your engine is overheating: check for a malfunctioning fan or a coolant leak.” which means there is an alert to be displayed in the engine dashboard. This is because the NonSpeedOverheat Filter task has determined that the engine is overheating and the engine speed is below 45. Check the transformInPlace checkbox, which adds the new alertMsg property to the temperature event. Click OK to save the AddNonSpeedOverheat task configuration.
14. Right-click the AddSpeedOverheat task, select Link Existing Task to display a dialog. In the dialog, select PublishStatus as the Task Name. Click OK. This will link the AddSpeedOverheat task to the PublishStatus task, which was the goal outlined in Lesson 2: add the overheat status to the temperature then republish that data via the PublishStatus task.
15. Right-click the AddNonSpeedOverheat task, select Link Existing Task to display a dialog. In the dialog, select PublishStatus as the Task Name. Click OK. This will link the AddNonSpeedOverheat task to the PublishStatus task, which was the goal outlined in Lesson 2: add the overheat status to the temperature then republish that data via the PublishStatus task.
16. Move the new Filter and Transformation tasks to their proper task context boxes:
    1. Right-click the DetectSituation task context and select the Add Task to Context menu item. Select RetrieveSpeed from the Task Name menu, then click OK.
    2. Right-click the DetectSituation task context and select the Add Task to Context menu item. Select SpeedOverheat from the Task Name menu, then click OK.
    3. Right-click the DetectSituation task context and select the Add Task to Context menu item. Select NonSpeedOverheat from the Task Name menu, then click OK.
    4. Right-click the React task context and select the Add Task to Context menu item. Select AddSpeedOverheat from the Task Name menu, then click OK.
    5. Right-click the React task context and select the Add Task to Context menu item. Select AddNonSpeedOverheat from the Task Name menu, then click OK.

    Save the changes to the Service. The Event Handler graph should now look like this:

    

Click on the next To Do List item in the Design Model. This will cause the same com.vantiq.engines.EngineMonitorSensors Service to display and automatically navigate to the Implement tab which contains the com.vantiq.engines.EngineMonitorSensors.IngestSensor0 Internal Event Handler that is associated with the error. Here’s how to address the errors in this Event Handler for the engine monitoring system:

1. Click on the Ingest task and rename it IngestSpeed. Click the Click to Edit link to edit the configuration for this task. Select sources for the inboundResource and com.vantiq.engines.SpeedSensor for the inboundResourceId. Click OK. Click OK to save the IngestSpeed task configuration.
2. Right-click the IngestSpeed task, select Link Existing Task to display a dialog. In the dialog, select PublishEvent as the Task Name. Click OK. This will link the IngestSpeed task to the PublishEvent task, which means the Transform task may now be deleted.
3. Since the speed sensor data may be used as it is transmitted by the MQTT server, no data transformation needs to be done. Click the Transform task and delete it using the Delete key or the Delete item in the pane’s toolbar.
4. Now that the Transform task has been deleted, one of the task contexts, Transform, is empty. Right-click that task context and select the Remove Task Context menu item.
5. Click the PublishEvent task and rename it to PublishSpeed. Click the Click to Edit link to edit the configuration for this task. The service property is correctly set (com.vantiq.engines.EngineMonitorSensors). However, the eventTypeName property needs to reflect the renamed Outbound Event: replace Sensor0 with SpeedEvent. Click OK. Save the Service changes and wait for several seconds. The Event Handler graph should now look like this:Note the rectangular badges with numbers that appear over the IngestSpeed and PublishSpeed tasks. These badges increment as each task event is received. This means that the Source is configured correctly and that the EngineMonitorSensors service is successfully receiving those Source Events.

There should only be two remaining To Do List items in the Design Model. Click on one of them to automatically navigate to the Implement tab which contains the com.vantiq.engines.EngineMonitorSensors.IngestSensor1 Internal Event Handler that is associated with the error. Follow similar steps as above to receive temperature-related events:

1. Click on the Ingest task and rename it IngestTemperature. Click the Click to Edit link to edit the configuration for this task. Select sources for the inboundResource and com.vantiq.engines.TemperatureSensor for the inboundResourceId. Click OK. Click OK to save the IngestTemperature task configuration.
2. Right-click the IngestTemperature task, select Link Existing Task to display a dialog. In the dialog, select PublishEvent as the Task Name. Click OK. This will link the IngestTemperature task to the PublishEvent task, which means the Transform task may now be deleted.
3. Since the temperature sensor data may be used as it is transmitted by the MQTT server, no data transformation needs to be done. Click the Transform task and delete it using the Delete key or the Delete item in the pane’s toolbar.
4. Now that the Transform task has been deleted, one of the task contexts, Transform, is empty. Right-click that task context and select the Remove Task Context menu item.
5. Click the PublishEvent task and rename it to PublishTemperature. Click the Click to Edit link to edit the configuration for this task. The service property is correctly set (com.vantiq.engines.EngineMonitorSensors). However, the eventTypeName property needs to reflect the renamed Outbound Event: replace _Sensor1 with TemperatureEvent. Click OK.

Save the task changes by using the Save Changes icon in the pane’s title bar.

Notice that the Design Model’s To Do List is gone. This means Service-related all errors and missing task configurations have been addressed and the Service Event Handlers should be receiving and processing events. The next lesson will ensure their correct operation.

7: Create Event Schema Types

This lesson creates two schema Types based on the Service Event Handlers associated with the EngineMonitor Service. Creating the schema types serves two purposes:

1. ensures the correct operation of the Event Handlers
2. makes it easier to build the engine dashboard using the EngineMonitor Client, which happens in the next lesson.

Heres how to create the two schema Types:

1. Right-click the EngineMonitor Service (Service nodes have a green title bar) in the Design Model, then select Edit in Service Builder menu item. The pane for that Service is displayed. In the Implement tab, expand the Inbound section, then click the TemperatureEvent Event Handler. The Event Handler graph should look like this:
2. Let the graph run for a minute so that the task badges are displayed as the simulated sensor data is received and processed. All ten tasks should eventually show incrementing badges. The sum of the OverheatCheck and NoAlert task badge counts should equal the SensorReading task badge count since the filters check for temperature events above and below 210 degrees. The PublishStatus task badge count should also equal the SensorReading task badge count, which means every temperature reading is accounted for when creating engine status updates.
3. Click the PublishStatus task then expand the View Task Events section of the task’s configuration:An entry in the list should appear about one per second since temperature events from the MQTT source appear once per second. Click on one of the events to display the actual data being published on to the Outbound Event Type:Click the Create Data Type button, name the Type StatusEvent with the com.vantiq.engines package, then click Save. This creates the StatusEvent Type that contains three properties: alertMsg, systemId, and temperature.
4. Switch to the SpeedEvent Inbound Event as described in Step 1 above. Follow the similar instructions in Step 1 and 2 to create the SpeedEvent Type. The SpeedEvent Type contains two properties: speed and systemId.

To associate the two new schema types with the Outbound Event handlers, switch to the Service’s Interface tab, expand the Outbound section, then click the EngineSpeed Event Handler. Use the Event Schema pull-down menu to select com.vantiq.engines.SpeedEvent, then save the Service using the Save Changes icon in the pane’s title bar:

Click the EngineStatus Event Handler. Use the Event Schema pull-down menu to select com.vantiq.engines.StatusEvent. Save the Service.

8: Visualizing a Running System

This section uses the IDE’s Client Builder feature to create a visual interface for the engine simulation.

Right-click the EngineMonitor Client (Client nodes have a purple title bar) in the Design Model, then select Edit in Client Builder menu item. The pane for that Client is displayed:

From the Data Display menu, drag and drop one Line chart widget, one Column chart widget, two Gauge widgets,
one Pie chart widget and one Text widget to the canvas area below the widget palette to create a Client Builder layout similar to this:

We’ll get to configuring each widget later so don’t worry about the exact appearance of the widgets yet.

There are five display widgets and one text widget in the diagram above. What follows are the properties for each of those widgets.
Any property not mentioned is the default value for that widget. To display the property sheet for any widget, click on the widget.
For example, here is the property sheet for a gauge, configured for tracking your engine speeds:

For the Engine Simulation text widget (top, center):

 Specific -> Text: Engine Simulation
 Style -> Font Color: Dark Gray

For the Temperature line chart widget (top, left):

 Specific -> Title: Temperature
 Data -> Data Stream: EngineStatus
 Data -> X-Axis Property: Timestamp
 Data -> Y-Axis Properties: temperature

For the Speed bar chart widget (bottom, left):

 Specific -> Title: Speed
 Data -> Data Stream: EngineSpeed
 Data -> X-Axis Property: Timestamp
 Data -> Y-Axis Properties: speed

For the Speed gauge widget (top, left):

 Specific -> Title: Speed
 Specific -> Minimum:0
 Specific -> Low Range Zones: 0:45
 Specific -> Medium Range Zones: 45:55
 Specific -> High Range Zones: 55:65
 Specific -> Maximum: 65
 Data -> Data Stream: EngineSpeed
 Data -> Data Stream Property: speed

For the Temperature gauge widget (top, right):

 Specific -> Title: Temperature
 Specific -> Minimum: 180
 Specific -> Low Range Zones: 180:200
 Specific -> Medium Range Zones: 200:210
 Specific -> High Range Zones: 210:220
 Specific -> Maximum: 220
 Data -> Data Stream: EngineStatus
 Data -> Data Stream Property: temperature

For the Alert Status pie chart widget (bottom, right):

 Specific -> Title: Alert Status
 Data -> Data Stream: EngineStatus
 Data -> Data Stream Property: alertMsg

When selecting the Data Stream Property value, the menu choices may be restricted to those properties appropriate to the type of the widget. For example, when configuring a bar or line chart, only numeric properties are available for selection. Other display elements, such as pie charts or lists, accept either numeric or string properties.

When you have finished adding and configuring your client widgets, save the client and return to the IDE. Save the project in the IDE.

Use the Run icon button of the Client: EngineMonitor pane (small triangle in a square at the top, right of the pane). This will start the Client running and the various widgets to display data from the Data Streams configured by the Design Modeler.

9: Testing The App

Congratulations! You just built your first Vantiq application. However, there is an important piece missing. How can you ensure your application works and will always work as you expect?

Learn how to test the application you just built by clicking here: Testing the Intro Tutorial

Conclusion

Users who have successfully completed this tutorial can comfortably:

• Navigate through the Vantiq Integrated Development Environment (IDE) development phase
• Create and develop a Design Model
• Develop Design Model Services with visual Event Handlers
• Configure simulated incoming events using Sources
• Configure a visual interface with a Client