...
This means that my dev team can not cannot take an existing Launcher from a platform provider.
...
- 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.
- TR applications from Eikon running on the user's desktop.
Workflow 1.
At startup the The launcher is started by the user in order to run their inhouse systems.
The launcher prompts the user to logon , and defaults to using the Enterprise's SSO setup.
The launcher has a list of Application Directories it is configured to connect to, and passes the user name and SSO identity/cookie of the logged in windows user id. The user is validated by some Enterprise specific SSO system. This user identity is used by some of the Application Directories to control which applications the user can 'see'.For inhouse applications that use the same SSO as the Launcher, 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 is passed to the apps as they are launched to avoid forcing the user to repeatedly sign on.
The key issues here are:
...
- In house and 3rd party applications
- Desktop Technologies.
...
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.Although this is a technical use case it represents real requirements that face FDC3 users
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 store and retrieve the saved Layouts available to the logged on user.