Overview

This document describes the process for adding custom code to Clio Operate environments and the recommended method of moving that code through environments.

Writing custom Operate code

There are two ways to add custom code to an Operate environment: via IDE components built into Operate or via Plugins.

IDE components

Operate has a built-in Integrated Development Environment (IDE). You can use this IDE to add custom components (Widgets, Aspects, Workflow Actions, etc.) to Operate without the need for an external development environment.

Plugins

Operate supports a ‘plugin’ model, allowing you to write .NET code that can be run in your Operate environments. You may choose this option if your requirements exceed the capabilities of the built-in IDE. For example, if you wish to expose new APIs in your Operate environment to facilitate a custom integration.

Plugins can be added to an environment using the ‘Manage Plugins’ panel in the Developer IDE:

If you wish to build a custom plugin, Clio will provide a dedicated GitHub repository. This repository contains an Operate plugin template, which developers can then extend for their own purposes. The repository also includes scripts to allow developers to ‘package’ the plugin locally.

Development/vNext environments typically allow this plugin to be uploaded and run without being digitally signed, but to move a plugin past this environment (e.g. to Production) it must have been packaged on Clio infrastructure using the code in the repository provided.

The process for this is as follows:

• Developers commit code to a branch on the provided repository
• Developers raise a Pull Request to merge this branch into main and notify Clio
• Clio will review the Pull Request and merge it
• Clio will build the plugin, and then either
  • Install it on a customer's environment, or
  • Provide the plugin package for manual upload using the Manage Plugins panel (if preferred)

The code review step is primarily to protect your environments by ensuring that arbitrary code cannot be run without a review from Clio. We are, however, happy to use this review to provide guidance on best practices and patterns. Please mention this in your pull request.

To request a new repository, please speak to your Clio Technical Consultant, Project Manager, or Customer Success Manager.

Sharedo In A Box (SIAB)

It is possible to develop both IDE Components and Plugins using only the vNext/Development environment and - in the case of a plugin - Visual Studio (or a similar .NET IDE).

However, Clio can provide an instance of Operate that can be run on a developer's own machine. This more closely mimics a typical Software Development Lifecycle (SDLC), by allowing multiple developers the freedom to work and test code locally, only pushing changes to vNext/Development when required.

Code is typically promoted from Sharedo In A Box to Development/vNext using the Import/Export feature of Operate (see below).

Deployment through environments

Once they are in the vNext/Development environment, we suggest using the solution modeller to export your plugins and components between environments. 

(This diagram shows a typical set of Operate environments. Yours may differ)

Both plugins and IDE components are available for selection in the Modeller export UI:

This method allows you to package the code and functional configuration into a single export pack, and move them through environments together. For instance, moving custom Workflow Actions and the associated workflows together, or moving custom Aspects with their associated Work Type configuration.