OpenFin

OpenFin Services

Overview

OpenFin Desktop Services are singleton processes that provide functionality to all applications running on an OpenFin enabled desktop. Desktop Services are started and managed by the RVM.

Key points

  • Applications declare the services they want to use in the Application Manifest.
  • The lifecycle of OpenFin Desktop Services is managed by the RVM and will exist for as long as any applications that require the service are running.
  • Only one version of a service will be running on the desktop, and it will extend across all runtime instances on the desktop.
  • Services are delivered to the desktop via the OpenFin Cloud or an equivalent on-premise source.
  • Each application that wishes to connect to the Service Provider should require into their code the corresponding version of the client-side API from npm.

Prerequisites

  • OpenFin Desktop Services currently cannot penetrate through runtimes in security realms that are not connected to the runtime mesh via ‘enable-mesh’ runtime argument.
  • The version of the Service Provider is determined by the desktop owner. Any applications that wish to connect to the service Provider should be aware of this Provider version and use the corresponding Client version.
  • OpenFin Desktop Services may require a minimum OpenFin runtime or RVM version.

Enabling Desktop Services

To enable the an OpenFin Desktop Service you only need to add a single reference to the service in your application’s config file (app.json).

"services" :[{ "name":"layouts" }] //replace "name" 

Some OpenFin Desktop Services may have a client-side API that enables application developers to interact with and to further enhance their integration with the service. This API can be imported into your code as a module by utilizing npm. The API may also be imported via a script tag from our CDN for testing and development purposes, but this method should not be used in production.

npm install --save openfin-layouts

A desktop service has two components: a service Provider and a client side API that exposes the service API to OpenFin applications. There can be many service Clients connected to one service Provider. OpenFin Desktop Services uses the InterApplicationBus Channels API but this is generally abstracted away in the client API that is provided via npm.

DesktopOwnerSettings file

The Desktop Owner Settings file allows Desktop Owners to set most global desktop settings in an easy-to-update, remote JSON file as opposed to setting them in the registry. Learn more about how to enable Desktop Services in the Desktop Owner Settings file here.

Architecture and lifecycle

Lifecycle

  1. During normal application startup the RVM is pointed to an OpenFin Application manifest specifying an OpenFin Desktop Service dependency.
  2. The RVM resolves the location of the service(s) (resolving detailed below), defaulting to the OpenFin public cloud.
  3. The RVM starts the service(s) if not already running.
  4. The RVM starts the OpenFin Application.
  5. The Client side API running in the OpenFin Application connects to the service via an InterApplicationBus Channel.

The RVM will shut down a service when the last application that has required the service is closed.

Hosting services on-premise

OpenFin Desktop Services can also be hosted on-premise. To enable this you will need to download the service as a zip file, self-host it, then use DesktopOwnerSettings to point the RVM to the correct location:

  • Download the service Provider code from the OpenFin Desktop Services versions page as a zip file (under “Hosting”).
  • Unpack the zip file and host on a server where it will be reachable without any authentication.
  • The RVM needs to be instructed to look for the service in the new location. You can accomplish this by specifying the service location in the DesktopOwnerSettings (RVM version 4.7+).
"services": [{
   "name": "layouts", "manifestUrl": "https://[PATH_TO_UNPACKED_ZIP]/app.json"
}]

Running a specific version

Without further specification, you will get the latest stable version of an OpenFin Desktop Service. Please follow the directions below if you need to do things like test the next version of the service. Relevant version dependencies will be detailed in the OpenFin Desktop Services version page.

We recommend that application providers assume the latest stable version in production as the versioning of the service Provider should be handled by the desktop owner.

Service Provider

The version of the Service Provider should be managed by the desktop owner. Unless otherwise informed, application providers should assume that the latest stable version of a service will be used in production. If you want to target a specific version of a desktop service, please use DesktopOwnerSettings OwnerSettings on a desktop-by-desktop basis as described below in the notes regarding hosting the service on-premise.

Client-side API

If you need to run a specific version of a service client, it’s as easy as supplying the version when installing from npm. Client-side API’s served from NPM will strive to be backwards and forward compatible. For example:

npm i --save [email protected]

You will need to ensure that the service version matches the major client version per semver convention. We do not recommend pointing to a particular version of the client in production.


#Open Source

OpenFin Desktop Services codebases are open-sourced under the Hadouken Github organization, which is part of FINOS, the Fintech Open Source Foundation. This allows for increased transparency, collaboration, and customization. OpenFin will be monitoring the issues page in the repos and we encourage and welcome pull requests. Please contact [email protected] to find out more about the Hadouken or FINOS organizations.

Support

All services provided by OpenFin and served from an OpenFin supported endpoint are fully supported for Enterprise customers. Please reach out to support@openfin.co with any issues.

Updated 29 days ago


OpenFin Services


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.