Share via

VPL Introduction

Glossary Item Box

VPL User Guide: Getting Started

VPL Reference: Basic ActivitiesVPL Menus

VPL Tutorials: VPL Tutorials Overview

See Also Microsoft Robotics Developer Studio Send feedback on this topic

VPL Introduction

Microsoft Visual Programming Language (VPL) is an application development environment designed on a graphical dataflow-based programming model. Rather than series of imperative commands sequentially executed, a dataflow program is more like a series of workers on an assembly line, who do their assigned task as the materials arrive. As a result VPL is well suited to programming a variety of concurrent or distributed processing scenarios.

VPL is targeted for beginner programmers with a basic understanding of concepts like variables and logic. However, VPL is not limited to novices. The programming language may appeal to more advanced programmers for rapid prototyping or code development. As a result, VPL may appeal to a wide audience of users including students, enthusiasts/hobbyists, as well as possibly web developers and professional programmers.


Figure 1 - Sample Microsoft VPL diagram

A VPL dataflow consists of a connected sequence of activities represented as blocks with inputs and outputs that can be connected to other activity blocks.


Figure 2 - Activity blocks have connections that represent messages sent from one activity to another

Activities can represent dataflow control or processing functions, pre-built DSS services or your own defined activities you create in VPL. The connections between activities pass data as messages. The resulting application is therefore often referred to as dataflow orchestration, the coordination of information between a connected set of processes.

Activities can also include constructions of other of activities. This makes it possible to compose your own activities by combining existing ones and then reuse the composition as a building block. In this sense an application built in VPL is itself an activity.

An activity block typically includes the activity’s name and its connection points. An activity block may also include graphics to illustrate the purpose of the activity or user interface elements like text boxes that may enable the user to enter values, assignments, or transformations for data used in an activity.


Figure 3 - Connections invoke actions such as SayText

Activities are connected through connection pins. A connection pin on the left side of an activity represents the connection point for incoming/input messages and a pin on the right represents the connection point for outgoing/output messages.

An activity receives messages containing data through its input connection pins. An activity’s input pins are connection points to its predefined internal functions known as actions or handlers. These can be either as functions provided by a service or nested dataflows.

An activity block activates and processes the incoming message data as soon it receives a valid incoming message. All data sent to the activity is consumed by the activity. For data to be forwarded through the activity’s output, the receiving activity must replicate the data and put it on its output connection.

An activity may have multiple input connection pins, each with its own set of output connection pins. Input pins are represented as arrows pointing into the block. Output connection pins can be one of two kinds: result output (also called a response output) or notification output (sometimes also referred to as an event or publication output). Result output pins are displayed as arrows pointing out of the block while notification outputs display as round connection pins.


Figure 4 - Connection pins

A response output connection pin is used in situations where the outgoing message data is sent as the result of a specific incoming action (or request) message. Notification connection pins can send information resulting from an incoming message, but more typically send a message as a result of an internal change to their state. Output pins can be connected to input pins on more than one other activity.

Response and notification output connections also differ in how they deliver message data. Since a response connection requires an incoming message, once that request is received and processed and resulting message is sent, it is finished. However, notification outputs can generate messages multiple times. As a result, response connections are typically used to query the current state of an activity, whereas notification output pins are used for providing continuous updates on an activity's state, eliminating the need to repeatedly request or poll for the state of an activity. The activity defines which types of connections which are provided.

For tutorials on creating VPL diagrams see VPL Tutorials Overview.

See Also 

VPL User Guide: Getting Started

VPL Reference: Basic ActivitiesVPL Menus

VPL Tutorials: VPL Tutorials Overview



© 2012 Microsoft Corporation. All Rights Reserved.