Introduction

The Design Modeler is the 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. It also allows for the graphical visualization of how the events flow through a Vantiq system.

Tutorials

For an introduction to the use of the Design Modeler, follow the Introductory Tutorial. This tutorial introduces the basics of creating a new Design Model to implement a simple engine monitoring system. In addition, the System Model Tutorial shows how to model business process requirements and then produce a Design Model based on those requirements.

Creating a New Design Model

New Design Models are created using Add>Design Model and clicking the New Design Model button. The Design Modeler uses Design Templates to help the developer design Vantiq systems that are scalable and use best practices. The New Design Model dialog shows a diagrammatic representation and an explanation of each of the templates. Select a Design Template that most closely matches the system you’re trying to build.

There are five Design Templates:

1. Closed Loop System: receives events from an External System and checks the value against a target. If the current value is not yet at the target, computes a change or controller event and publishes the result to the Control System for further processing.
2. Event Driven Integration: receives data from an external system, performs transformations and analytics, and then publishes the resulting event to another external system for further processing.
3. IoT System: receives data from IoT devices, processes and summarizes it looking for anomalies, and updates Clients as needed.
4. Object Recognition System: receives events from an AI Camera or AI platform. These events contain details on what has been detected within the video stream and respond accordingly.
5. Empty: creates an empty Design Model to create a model from new and existing Services and Clients.

In addition to selecting the Design Template, two additional properties are available for all but the Empty Template:

• Number of Streams: the number of sources of data entering the application. As an example for the IoT System, the number of streams would be the number of different types of data (e.g. temperature and speed) to be received from IoT devices.
• Service Name: the name of the primary Service that will be generated for this model. Each of the templates create at least one Service. The default name of the Service is the name of the Data Model but another name can be specified using the Service Name property.

Click the OK button in the New Design Model dialog to start the Design Model generation. After the generation is complete, the Design Model pane will display. Here is an EngineMonitor Design Model generated from the IoT System template with two streams specified:

Understanding the Design Model Pane

The right side of the Design Model pane contains the graphical representation of the model. In the example shown above, there are six nodes in the graph:

• ExternalSensorEvents: this is an External System Design Modeler node, which graphically represents the IoT device’s two 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.
• IngestExternalSensorEventsService: this is a Service Design Modeler node, which represents an actual Vantiq Service. This Service has a limited purpose: to receive messages from the 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 those data indicate possible problems, then forwards the sensor data and problem status to the EngineMonitor Client for display. 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 sensor data and problem status. 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.
• OutsideWorld: like the DataWarehouse node, it could represent, for example, a REST API or MQTT server, that might consume data from this Vantiq system.

The left side of the Design Model pane contains two sections. The upper section is the Design Modeler palette. The palette contains five drag-and-droppable items that are used to create new nodes (External Systems, Services, and Clients) in the Design Model:

• New Service: add a placeholder Service. Placeholder Services are used to represent Services that are in development but have not been created as an actual Service. Using the graph, new Inbound and Outbound Event Types may be created between placeholder Services and other Services and Clients. New connections may also be created between placeholder Services and External Systems. See the next section for how to convert a placeholder Service to an actual Service.
• Service: add an existing Service. The developer must select a Service in the current Namespace or subscribe to or install one from a Catalog, if available. As with a placeholder Service, new Inbound and Outbound Event Types may be created using the graph between placeholder Services and other Services and Clients. New connections may also be created between placeholder Services and External Systems.
• New Client: add a placeholder Client. As with placeholder Services, placeholder Clients are used to represent Clients that are in development but have not been created as an actual Client. Using the graph, new Client Data Streams may be created between Service Outbound Event Types and placeholder Clients. See the next section for how to convert a placeholder Client to an actual Client.
• Client: add an existing Client. The developer must select a Client in the current Namespace or subscribe to or install one from a Catalog, if available. As with a placeholder Client, new Client Data Streams may be created using the graph between Service Outbound Event Types and placeholder Clients.
• External System: add a new External System node to represent data external to a Vantiq system.

The lower section of the left side of the Design Model pane is the To Do List. The To Do List contains errors found in any of the Services contained in the Design Model. When a Design Model is initially generated, these errors are normal and are all associated with Inbound Event tasks in those Services that need to be configured for the specific needs of the system being developed.

Clicking on a To Do List item causes the Service pane that contains the error to be displayed. An example from the Introductory Tutorial is shown below:

Use the To Do List to find and clear each error until the To Do List is empty and disappears. This indicates there are no Service configuration errors.

Click the Show Flow View checkbox in the toolbar to split the Design Modeler canvas into two sections: the Design Model graph and the Flow View:

The Flow View shows an event-processing view of the tasks in the Design Model. The majority of the nodes in the Flow View are related to Inbound Event Handlers found in Services (e.g. the Ingest and Transform nodes) but will also contain nodes representing Clients (e.g. EngineMonitor). The reason why there so many disconnected nodes in the Flow View shown above is that there are unconfigured tasks in this Design Model. Once the To Do List items are addressed, the Flow View graph should be highly connected.

Converting Placeholder Services and Clients

When the developer is ready to create an actual Service based on the placeholder Service, they double-click the Service’s node to display the Editing Service dialog:

Use the Service pull-down menu to select Create New Service. The Label text will change to reflect a suggested name (including a package prefix). Use the Label text to modify the name of the Service, if desired. As the dialog indicates, the new Service will be created when the Design Model is saved.

Creating an actual Client based on a placeholder Client follows the same pattern as for placeholder Services as described above.

Creating New Connections

The Design Model graph handles simple user gestures for creating new links between Services, Clients, and External Systems.

Please note that the Design Modeler is the only way to create working connections between Services to ensure that data produced by an Outbound Event Type is delivered to another Service’s Inbound Event Type.

New Service Connections

Consider the Design Model shown below, which represents a simple IoT system:

The IoTExample node represents a Service that is receiving IoT sensor data from the IngestExternalSensorEventsService Service. The DeviceManager node is a placeholder Service that is being developed to receive status update data based on sensor readings. To create a new connection between IoTExample and DeviceManager to allow those status updates, click and drag from the small blue circle next to the Add Outbound Event label of IoTExample to the small blue circle next to the Add Inbound Event label of DeviceManager:

When the mouse is released, a dialog is displayed:

Since the connection is supposed to represent status updates, we’ll name both Service Event Types UpdateStatus. Click OK to create the connection. The Design Model graph updates to show the new connection:

Save the Design Model using the Save Changes icon in the Design Model pane’s titlebar. Once the Design Model is saved, the IoTExample Service is updated with a new Outbound Event Type called UpdateStatus. To see that update, right-click the IoTExample Service node on the graph and select Open in Service Builder. The Service: com.vantiq.example.IoTExample pane is displayed. Click the Outbound tab to display the Outbound Events of the Service. Note there are now two Outbound Event Types: the preexisting AnomalyDetected0 Event Type and the newly-created UpdateStatus Event Type:

Since the DeviceManager Service in the Design Model is a placeholder Service, its UpdateStatus Inbound Event Type is also a placeholder for an Inbound Event Type. That Inbound Event Type will be created when the Service is converted to a real Service.

New Client Connections

Using the example from above, to create a new connection between the IoTExample Service (with the green node titlebar) and the IoTExample Client (with the purple titlebar), click and drag from the small blue circle next to the UpdateStatus label of the the Service to the small blue circle next to the Add Data Stream label of the Client:

When the mouse is release, a dialog is displayed:

Since the connection is supposed to represent the display of status updates, we’ll name the Client’s Data Stream DisplayStatus. Click OK to create the connection. The Design Model graph updates to show the new connection:

Once the Design Model is saved, the IoTExample Client is updated with a new Data Stream called DisplayStatus. Data sent via the IoTExample Service’s UpdateStatus Outbound Event Type can then be used in the Client by selecting its DisplayStatus Data Stream.

Bridge Services

Continuing to use the simple IoT system described above, consider the changes shown in this updated Design Model:

The placeholder DeviceManager Service has been converted to a real Service and defines a new Inbound Event Stream called UpdateDefect. To specify the format of the data received by the Service, the UpdateDefect Event Stream has been assigned an Event Schema com.vantiq.example.DefectiveDevice.

Next, we want to feed events published on the IoTExample Service’s AnomalyDetected0 Outbound Event Type to the new UpdateDefect Inbound Event Stream of DeviceManager. Click and drag from the small blue circle next to the AnomalyDetected0 label to the small blue circle next to the UpdateDefect label. When the mouse is released, a dialog is displayed:

This dialog appears when a new connection between existing Service Event Types is created but the Event Type schemas do not match. This means the outbound data has a different format than the Inbound Event Type expects. A “Bridge Service” is necessary in this case to transform the outbound data into the specified format expected by the Inbound Event Type. We’ll name the Bridge Service BridgeDefect. Click OK to create the BridgeDefect Service node, then save the Design Model. You must save the Design Model in order for the BridgeDefect Service to be created. The Design Model will now look similar to this:

The only purpose of the BridgeDefect Service is to implement a Transformation task in a Visual Event Handler that looks like this:

Configure the Transformation task to convert the data format from the schema associated with the AnomalyDetected0 Outbound Event Type into the data format for the schema associated with the UpdateDefect Inbound Event Type.

System Model Requirements

Design Models can be created from System Models using the System Modeler’s Generate feature. Design Models generated via the System Modeler will have an additional section on the left side of the Design Model pane called the Requirements List:

The Requirements List is the list of all of the System Model notes. As the Design Model is developed, check off each of the Requirements List items as they are developed in the Design Model. You can drag and drop list items to change the order of list items.