A Spotfire extension is the smallest functional unit added to the platform. It is developed in Visual Studio® and is included in a Spotfire add-in, enabling versioning, licensing, deployment and loading.
Overview
This page first describes the key concepts to develop extensions adding custom capabilities
to the Spotfire platform. Next, the development procedure is outlined from template
to deployment. Then, the artifacts that must be produced for different scenarios
are listed. Finally there is a recommendaton on the use of 32-bit DLLs on 64-bit
platforms.
See also:
-
Creating Extensions to the Spotfire Platform
A Spotfire solution to a complex problem may require a design with several specialized extensions. Still, a single extension based on an SDK example project will often do. The examples are fully functional solutions to common problems, and there are many ways to combine them.
This page describes the available extension points, often with links to pages detailing
the use, the limitations and the technical aspects of the extension point, mostly
referencing the applicable SDK example.
-
Spotfire SDK
The SDK provides required Spotfire developer resources: the Spotfire Extension Project Template, development assemblies, example projects, and the Package Builder application wrapping the extensions for deployment.
Concepts
Extensions are bundled for loading into Spotfire in units called add-ins. Spotfire
version handles, deploys and loads functionality as add-ins registering extensions.
A Spotfire add-in is implemented as a C# project in Visual Studio®.
The design guidelines for Spotfire extensions prescribes that every add-in contains
one class derived from the
AddIn
class. An add-in is basically defined by information provided when creating the
project from the SDK template. The add-in project contains one or more extensions.
Additional extensions can easily be added to the project at a later point in time
to build a new version.
Each extension is implemented in a set of classes, typically overriding
a base class defining a specific extension type. The add-in registrations are made
declaratively by overriding an extension type specific method,
Register[ExtensionType](). Each such method is passed a registrar
that allows the add-in to register the extension in the appropriate registry in
Spotfire. For instance, to register a new tool, the RegisterTools(ToolRegistrar)
is overridden. A similar procedure is used when
licensing extensions.
An add-in can also register services that can be used by other add-ins. This provides
a simple way for add-ins to provide extension points of their own.
A module is defined as qualified for loading in Spotfire if it has a valid
module definition file
file. It declares the add-in to the application by defining the fully qualified
type name for the AddIn class and the assembly name. It also declares
a unique project GUID and a strong name for the assembly. Combinations of these
uniquely identifies the project and the add-in. Extension assemblies must therefore
be signed with a strong name key using a strong name key file (.snk).
The extension project template contains a default key. You may replace this key
file with your own, but if you do, make sure to alter the module definition file
accordingly.
Construction Procedure from Template to Deployment
Extending the Spotfire Platform
is a straightforward procedure based on the extension mechanism:
- Break down the problem and determine the appropriate extension points to use.
- Register an extension for each point.
- Implement the base classes tied to the respective extension points.
The recommended procedure requires Visual Studio® and
Spotfire Package Builder:
- In Visual Studio®, open an existing extension or create a
new extension, preferably from the
TIBCO Spotfire Extension Template,
and build it.
- In Package Builder,
add the extension
to a configuration that includes the default Spotfire client.
- In Visual Studio®,
develop and debug
the extension.
- In Package Builder,
build
a Spotfire Package file containing the extension.
- In TIBCO Spotfire Professional of , use Administration Manager
to deploy the Spotfire Package file to a Spotfire Server.
Upon deployment, users will be prompted to download updates when they start their
clients and access the server. If the end user accepts the prompt, the extension
is downloaded to the client computer, the client is restarted and the extension
is loaded into the running Spotfire instance.
For Spotfire 2.0 and 2.1 extension development, refer to procedures based on the earlier Package Builder application.
Extension Artifacts
The Model-View division lies at heart of extension construction. It applies from
the setting up of the Visual Studio project with add-in definitions, to assembly
packaging when adding the corresponding project in Package Builder. An extension
containing a model and a view is implemented in a Visual Studio solution containing
at least two projects and two add-ins, and will be deployed as, at least, two Spotfire
packages.
Model Add-Ins
Implement the model parts using the core Spotfire APIs and define the add-in in a
Visual Studio project. When creating the Spotfire Package Builder project, set the
Intended client project option to TIBCO Spotfire Any Client.
View Add-Ins
Extension views are also set up as Visual Studio projects. They define their own
add-ins, registering the view by overriding the
RegisterViews
method. They must also define dependencies to the project implementing the model
that is used by view. Since views target either Spotfire Professional or Spotfire
Web Player, the Intended client for the Package Builder project corresponding
to the view is either set to TIBCO Spotfire Professional/Enterprise Player
or TIBCO Spotfire Web Player.
Extension Artifacts Example
The following figure illustrates an extension with one model component and two views,
one for Spotfire Professional and one for Spotfire Web Player:
Extensions on 64-Bit Platforms
64-bit (x64) platforms, as opposed to 32-bit (x86), are
becoming more common. For TIBCO Spotfire Web Player it can be considered the default
platform, mainly because of the ability to address up to 8TB of memory, considerably
higher than the maximum of 2 GB for 32-bit processes.
On a 64-bit platform, TIBCO Spotfire is always launched in a 64-bit process. This
is usually not a problem for a custom extension as long as the extension is compiled
for a neutral platform target (Any CPU). If the custom extension
uses a third party native 32-bit DLL to run on a 64-bit platform, the 32-bit DLL
must be executed in a separate 32-bit process. In this case the custom extension
must communicate with the third party DLL through inter-process communication (IPC).
In other words, 64-bit and 32-bit processes can exchange data using IPC techniques
such as out-of-process COM, sockets, message services or memory mapped files.
Implementing the IPC-based communication between your custom extension and the third
party component may require considerable work. Check if a 64-bit version of the
third party component is available. If it is, the recommended solution is to include
both the 32-bit and the 64-bit version in the distribution, using different names
for the DLLs, and perform a platform invocation call to the correct DLL based on
the current architecture. The following test determines if the current architecture
is 32-bit:
Marshal.SizeOf(typeof(IntPtr)) == 4
Note: When running a third party component in
a separate process it is not possible, for technical reasons, to have any UI interaction
(such as an ActiveX control) in that component. If such interaction is required,
make sure to do it in the custom extension executed in the main process.