zowe / zowe-explorer-vscode

Visual Studio Code Extension for Zowe, which lets users interact with z/OS Data Sets, Unix System Services, and Jobs on a remote mainframe instance. Powered by Zowe SDKs.
Eclipse Public License 2.0
159 stars 89 forks source link

An ability for extenders to login/logout API ML service via Zowe Explorer API #2851

Open roman-kupriyanov opened 2 months ago

roman-kupriyanov commented 2 months ago

Is your feature request related to a problem? Please describe.

As it stands, Explorer for Endevor extension which relies only on the dynamically imported Zowe Extenders API to get the custom profiles list, cannot login or logout to APIML using those profiles, even though they are defined to work under API ML service.

Describe the solution you'd like

It would be nice if extenders can login and logout to API ML without having to add the Zowe code as a static dependency to their project. This means having the login and logout methods exposed through the IApiExplorerExtender interface somehow.

This is a really high level example of how it may look like (might be adjusted if necessary):

  /**
  * This interface can be used by other VS Code Extensions to access an alternative
  * profile types that can be employed in conjunction with the primary profile to provide
  * alternative support.
  *
  */
  export interface IApiExplorerExtender {
  /**

  * Allows extenders access to the profiles loaded into Zowe Explorer.
  * This includes profiles of other extenders. Called reloadProfiles()
  * in case other extensions might have registered themselves before accessing.
  * See the ProfilesCache class for the available accessors. When making changes
  * to the profile in this cache remember that it shared with Zowe Explorer and
  * all other Zowe Explorer extensions
  * @version 1.18 or newer of Zowe Explorer
  * @returns {ProfilesCache}
  */
  getProfilesCache(): ProfilesCache;

  /**
  * After an extenders registered all its API extensions it
  * might want to request that profiles should get reloaded
  * to make them automatically appears in the Explorer drop-
  * down dialogs.
  */
  reloadProfiles(profileType?: string): Promise<void>;

  /**
  * After an extenders registered all its API extensions it
  * might want to check for an existing profile folder with meta-file
  * or to create them automatically if it is non-existant.
  */
  initForZowe(type: string, profileTypeConfigurations?: zowe.imperative.ICommandProfileTypeConfiguration[]): Promise<void>;

  /** PROPOSED PART **/

  /**
  * Register Common API for the alternative profile type
  */
  registerCommonAPI(
    profileType: string, 
    api: ZoweExplorerApi.ICommon): Promise<void>
  ): Promise<void>

  /**
  * Login to API ML service, using the alternative profile name
  */
  loginApiMl(profileName?: string): Promise<void>;

  /**
  * Logout from API ML service, using the alternative profile name
  */
  logoutApiMl(profileName?: string): Promise<void>;

  /** PROPOSED PART END */
  }

Suggested steps to use the new API:

  1. Together with registration of the custom profile type, an implementation of ICommon interface is also registered for the same profile type with registerCommonApi() call. Minimally it includes the getSession() implementation and getProfileTypeName() calls to let the API know how to create a session from the custom profile properly. The login/logout calls should be reused from the existing API’s if not overridden.
  2. Anytime the extension has to login or logout the API ML service, we can call loginApiMl() or logoutApiMl() with the profile name we want to use. The calls can throw errors if the profile cannot be used to login/logout, or it is not the API ML service.
  3. If no Common API is registered for this type of profile, try the default session creation (Zosmf profile API may be used or something different).

Describe alternatives you've considered

The only way to login to API ML service for the extenders easily at the moment is to use Zowe Explorer’s other profiles like Zosmf or Uss which also configured to be used with the same API ML endpoint, since only through those we can leverage the login/logout procedures. Alternatively, using Zowe CLI login/logout too. But we would prefer to avoid the users switching contexts all the time.

Additional context

It would be also nice if the login call will provide all the necessary prompting for extenders, like username/password to authenticate, that already exist in Zowe Explorer and can be nicely reused.

github-actions[bot] commented 2 months ago

Thank you for raising this enhancement request. The community has 90 days to vote on it. If the enhancement receives at least 10 upvotes, it is added to our development backlog. If it receives fewer votes, the issue is closed.