Use Case 3: In house cross platform Launcher

As a user in a large Enterprise, I am running a mixture of in-house and thrid party applications. There are hundreds of in-house and 3rd party applications, and I am only permissioned for a subset of those applications.

I want single launch pad / toolbar to access my applications and which can also provide the primary UI access point for notifications and alerts.

In order to work with all of the Applications I use, the Launcher will to be able to launch applications defined from multiple locations (in FDC3 terms the Launcher 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 parties including e-mail applications and Desktop terminal application such as Eikon or Factset, which are running on the user's desktop.

Workflow 1.

The launcher is started by the user, or automatically run after login, in order to provide access to Applications. 

The launcher may prompts the user to logon using the Enterprise's SSO system, which may be different to the Desktop login. 

The launcher has a list of Application Directory URLs  it is configured to connect to, and passes the logged on user name and SSO identity/cookie of the logged in user to each App Directory as part of its sign on.
NB It is possible that some of the systems used may ignore the SSO login and may prompt for their own login identity, however by having a first login in the launcher and sharing those details the user may avoid multiple logins to the same Identity system. 

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 any SSO information to be passed to App Directories and App Launchers who are free to use this information if appropriate. 

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, instead the launcher may show a 'failed to start' error message of some kind. 

Workflow 5.

The Launcher runs an application from a 3rd party vendor such as a Desktop terminal application.
NB These 'Desktop terminal applications' typically support tens or even hundreds of different window types which are referred to here as FDC3 Applications even when they are hosted in a single Desktop Application.  

Workflow 6.

One or more FDC3 Platforms offer save and restore layout functions. The Layout save and restore functionality is available from the The Launcher.  The Enterprise may also make  'standard' pre-built layouts available to users. The layouts made available depend on the user's role.

Workflow 7.

As a User with a sales focus, many of the applications I run are related to a client (aka a customer or prospect of my organisation) and I want to launch applications with a customer pre-selected, rather than being forced to select the customer (aka Client) in the application. Therefore the Launcher provides a Client search capability that allows selection of a customer or prospect from an in-house client databases and/or CRM system.

NB The FDC3 Intent capability will be used to launch the applications. Since the applications may come from multiple sources, in particular in-house and 3rd party teams, the Launcher will need to create a context that defines the selected client using multiple context formats to describe the client, and then collecting the set of Intents which can handle the various client formats.

Workflow 8.

As a User with a trading focus, I have a similar requirement to Workflow 7, but instead I want to Select an Instrument.