Dynamo Application Integration Guide

Who Is This Document For?

This document is for application engineers interested in building an integration with Dynamo. It provides high level documentation of each of the pieces of the Dynamo architecture which deal with things like transaction management, element binding, etc. For in-depth documentation and examples of how each of these work, please refer to the source code in the Dynamo for Revit repository.

Why Do a Dynamo Integration?

Integrating Dynamo with your application allows your users to experiment with your API using a visual programming language. By using a visual programming environment, you invite even those users who have never written source code to experiment with your API. As those users gain proficiency, and want to further extend Dynamo, they might want to try scripting in python or compiling their own "zero touch" node libraries using any .net language. Because the Dynamo Workspace is compiled to Design Script, users can also experiment with turning their nodes into code, enhancing their understanding of how code is generated from the visual programming interface.

Can My Application Integrate with Dynamo?

An application can integrate with Dynamo using the components described here-in if:

• It has a .net API. This is not a hard and fast rule as we also have a version of Dynamo that runs on the mono run-time as a service, and can therefore be called from any application on any platform. Integration of that type will be covered in a separate document.
• It exposes unique ids for elements. Unique ids are required to bind nodes in Dynamo to the elements which they create.
• It has persistent storage of elements. Dynamo handles element binding, but does not store elements for your application.

Core Components

Dynamo Model

The DynamoModel is the core component of any Dynamo application integration. It contains all the models and logic that are needed to define a Workspace, compile that Workspace to Design Script, and execute the Workspace using the Design Script virtual machine. The first thing your application integration will do is construct an instance of DynamoModel.

For an example of constructing a DynamoModel, see Dynamo for Revit's example.

Element Binder

The Element Binder generates serializable Ids from your document elements' Ids, and manages the storage and retrieval of those ids during execution. This allows Dynamo to "bind" to elements in your document.

• These bound element ids are used by CallsiteData objects. These objects are serialized to the .dyn file allowing re-loading of CallsiteData objects to happen at startup. This allows Dynamo to re-bind to elements in your document.
• Used in Element Wrapper types to wrap a native model element from your application in a Dynamo-compatible type which selectively exposes properties on the internal object.
• Element references are transient. Between executions, Dynamo disposes of all references to wrapper types. You must use the Element Binder to maintain an association between an element and a call site between executions.

For an example, see the ElementBinder class

Element Id Lifecycle Manager

The Element Id Lifecycle Manager is a singleton which keeps track of Elements in the model that have been deleted.

• Uses reference counting to ensure that an Element is not deleted from the document if other references to the Element still exist. This protects against the case where

Transaction Manager

The Transaction Manager is a singleton, responsible for opening and closing transactions in your application as necessary to support batch operations on the application’s API.

Element Wrapper