OpenFin’s Interop API is the next generation of OpenFin’s interoperability capabilities across the financial desktop. It consists of two primary components: the Interop Broker and the Interop Client. These components comprise a hub and spoke model for sharing context.
We are very excited about this new API and are interested in customer feedback surrounding specific use cases. We plan to add additional support to the Interop API for intents and high-performance data transfer.
Interop connects applications — called views — using context groups and intents. Each web view can be thought of as its own microservice, ready to be connected to serve a greater purpose. Interop gathers these views into a cohesive whole.
The Interop Broker is the key to Interop. The Interop Broker is responsible for keeping track of the Interop state of the platform, and for directing context messages to their proper locations.
The Interop Client participates by using an event handler to listen to context updates (
addContextHandler), and speaks up when it has a context update to share (
setContext). It also can participate by using an event handler to handle intents (
registerIntentHandler), and by firing intents (
So what is a context, and what is an intent?
At its most fundamental level, a context is a description of a thing. An instrument context, for example, is a description of a financial instrument such as a stock (TSLA, MSFT), stock option, or futures contract. Other contexts could be a country context that describes a country (United States, Japan), or a contact context that describes a person's contact information.
Apps receive context updates and perform an action based on that update. A new instrument context would cause a charting app to update a price history chart with the new instrument.
The list of FDC3 standard context types can be found here, though you are free to create your own contexts to use for your purposes.
A context group is a way to group views to share context information. In Workspace, grouping views by the green color code puts those views into the "green color code" context group. A new instrument context sent by one view in the "green color code" context group will be received by all members of the context group who request instrument context updates.
A context update is an update in the form of a JSON string sent as a parameter to the callback registered by the
addContextHandler function. The context update informs apps of a new context object being published in the context group. If the user changes the instrument from TSLA to MSFT, a context update will be sent to all apps that registered an interest in instrument context updates.
When an app joins a context group, the Interop Broker sends a series of context updates to the app’s context handler to give the new app all the current contexts the app requests from that context group, and all future context updates will be sent to the app’s context handler.function. For example, an app that wants instrument and country contexts would receive two context updates to the app’s context handler function, one with the current instrument and one with the current country. Then any further instrument and country context updates will be sent to the app’s context handler function.
The context paradigm is based on the FDC3 schema. FDC3 provides a collection of standard types that have been identified in industry-wide working groups, and that collection of FDC3 contexts is expected to grow over time.
Contexts based on FDC3 standard contexts are compatible with OpenFin Interop. You are free to use FDC3 contexts that follow this simple schema in your own applications.
The list of FDC3 standard context types can be found here.
The “intent” concept is borrowed from the mobile phone development world. If you tap an address, a “get-directions” intent is fired which launches the map program to give the user directions to that address. Tap a phone number; call that number. Tap an email address; compose an email to that address.
In OpenFin, a similar process is used to fire and resolve intents. First, applications that resolve intents -- for instance, a “show-chart” intent -- register with the Interop Broker by using the
// register an intent fin.me.interop.registerIntentHandler('show-chart', showChart);
When an app wants to show a chart, all the app needs to do is to fire the intent with the data payload of the stock ticker symbol to chart.
// dispatch an intent fin.me.interop.fireIntent('show-chart', payload);
Views are applications used by your users. A stock quote application is an example of a view.
Platforms coordinate and contain groups of application views into platform windows, and give a UI to the user to group together their views into context groups. OpenFin Workspace is an example of a platform.
Interop reduces the complexity of connecting views together by reducing what views and platforms need to care about.
To put it simply:
Views only care about their context. They care about contexts sent to them and sent from them. They don’t care about what context group they’re in.
Platform Windows only care about grouping views into context groups. They don’t care about what contexts those views are listening to.
So how straightforward is it to make a view or platform work with Interop?
There are two core API functions that views use to participate in Interop contexts, and two core API functions for intents.
|Context API call||Description|
|Declares a handler for incoming context events.|
|Sends a context to all other members of the context group.|
|Intent API call||Description|
|Declare a handler for an application’s incoming intent.|
|Fire an intent.|
That's it for views. Those four functions are all you need. For context,
addContextHandler specifies the function that will receive context messages from the context group, and
setContext sends context messages to the context group. For Intents,
registerIntentHandler announces the function to call to handle a fired intent, and
fireIntent fires an intent and passes the relevant data to the intent handler.
OpenFin Workspace is a platform that takes care of managing context groups and giving users a UI to group apps as they wish. If, however, you would prefer to create your own platform, you can use the Interop API to create your platform by using these two core functions:
|getContextGroups||Returns a list of context groups for an entity to join.|
|joinContextGroup||Joins an entity to a specified context group.|
That's pretty much it. Yes, there are other APIs to manage other nuances of a platform, but these are the two primary APIs to know to get the job done. Use
getContextGroups to get the list of context groups available, then use
joinContextGroup to join an entity to the context group of choice.
Updated 19 days ago