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.

NewDesignModel

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:

DesignModelInitial

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:

FirstError

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:

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:

EditService

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:

IoTStart

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:

NewServiceConnection

When the mouse is released, a dialog is displayed:

NameServiceConnection

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: