As a dev team lead in a large Enterprise, I want to provide a launch pad / toolbar for my users that incorporates a number of non FDC3 in-house services such as :
- searching for an instrument which can then be viewed in the applications.
- Providing the primary UI access point for in house notifications
This means that my dev team cannot take an existing Launcher from a platform provider.
The Launcher will to be able to launch applications defined from multiple source, so it will need to connect to multiple FDC3 App Directories. Example Application Directories include :
- In house, container hosted, applications. The Enterprise will typically have a single container such as OpenFin, Glue42 or an in-house container.
- 3rd party container hosted applications.
NB In our experience this is not currently a real use case but the goal of FDC3 is to enable this use case - In house applications written in .Net which are installed onto the user' desktops using inhouse installers.
- Applications from a 3rd party Desktop terminal application such as Eikon or Factset, which is running on the user's desktop.
Workflow 1.
The launcher is started by the user in order to run their inhouse systems.
The launcher prompts the user to logon using the Enterprise's SSO system.
The launcher has a list of Application Directory URLs it is configured to connect to, and passes the user name and SSO identity/cookie of the logged in user to each App Directory as part of its sign on.
The In-House app directory holding details of the in-house applications uses this identity and internal entitlement information to define what applications this user is permissioned to run. This is reflected in the list of applications the App Directory presents to the user.
Workflow 2.
When the Launcher runs an in-house application, the Launcher should provide details of the logged on user including the SSO identity/cookie to the apps as they are launched to avoid forcing the user to repeatedly sign on.
NB The use case is not saying that SSO is part of the FDC3 interfaces but that mechanisms should be defined to allow SSO information to be passed to App Directories and App Launchers who are free to use it if they have that capability.
Workflow 3.
The launcher starts a container based application using the container selected by the Enterprise. The selection of the container has been built into the Launcher design.
Workflow 4.
The Launcher starts a desktop exe. The exe has been defined by the one of the App Directories and includes the path to the installed application. There is no attempt to install desktop applications for which the user is permissioned but which have not been installed.
Workflow 5.
The Launcher runs an application from a 3rd party vendor such as an TR Eikon window.
Workflow 6.
The Launcher dev team have created the ability to save and restore layouts, possibly by extending capabilities from one or more of the Platforms deployed. They have extended their in-house App Directory to allow storing and retrieve the Layouts available to the logged on user. This capability is also used to make 'standard layouts' available to users. The layouts made available depend on the user's role.
Workflow 7.
The Launcher dev team want to allow the user to search for a Client and then launch applications for the selected client. The Client search capability is an in-house function, but the FDC3 Intent capability will be used to launch the application. The Launcher will need to create a context that defines the selected client, this may involve using multiple context formats to describe the client, and then collecting the set of Intents which can handle the client format.