Local/Remote IOM connection - Support SAS 9 server file system

[snlwih]

Is your feature request related to a problem? Please describe. I need to be able to work with files that are stored on the file system of the (remote) SAS Server

Describe the solution you'd like Similar to connections to Viya 4, I would like to see a SAS Explorer panel that allows me to navigate the SAS server file system, create/edit/delete/rename files and folders, and Upload Files and Folders from the local file system where VSCode is running.

Environment SAS version: SAS 9.4

[clangsmith]

This should likely be done in coordination with the same feature request for Viya (#417), since they should have a largely consistent experience.

[scottdover]

Hey @smorrisj and @clangsmith. I'm wondering if I can get your thoughts on design approach for this (assuming this will include implementing SAS server for ITC/COM & Viya)

Here's some background of how things work currently. Right now, we have the following concepts:

• ContentNavigator: This is the outer most layer for sas content. It registers our commands and delegates those to our ContentDataProvider
• Our ContentDataProvider houses the tree structure for all of sas content. It's kind of like our application service for sas content in that it talks to our ContentModel and prepares the data for the ui
• Our ContentModel interacts with our rest api to call endpoints and turn raw data into ContentItems for the outer layers to consume
• ContentItem is a representation of a file/folder in the tree

Right now, these are all viya specific and SAS content specific. Here's how I'm thinking of changing things to support SAS server. As an aside, right now I'm going with the assumption that the "content" references above are not about "SAS Content" specifically, but more about "content" (as in the contents of a file).

• Update ContentNavigator to accept a "config" which will contain: treeIdentifier (string), mimeType (string), and sourceType (either "SASContent" or "SASServer")
• Update ContentDataProvider to accept a ContentModel, a treeIdentifier, and a mimeType (treeIdentifier and mimeType will need to be distinct between sas content/sas server)
• In our extension, I'll update things to construct two content navigators. One with things relevant to sas content; one with things relevant to sas server. This will basically mean seeing "SAS Content" and "SAS Server" as two of the accordions in the extension
• I'll create a ContentAdapterFactory that returns a ContentAdapter based on connection type and sourceType. Here are the adapters I think we'll need:
  • SASContentAdapter: This will contain a lot of what is in ContentModel right now, but will basically be responsible for connecting the viya api and generating ContentItems. Common functionality will still reside in ContentModel
  • RestSASServerAdapter: This will contain the code for connecting to sas server under viya connections
  • ITCSASServerAdapter: will contain the code for connecting to sas server via itc
• We'll use ContentAdapterFactory in ContentNavigator to get the ContentAdapter and instantiate ContentModel with it.
• Everything else should come down to the specific implementations of the adapters

I think there will also need to be some considering/refactoring of converting notebooks to flows

[clangsmith]

I do not have good familiarity with the current code, but the way you describe it and your suggested updates makes sense to me -- common architecture to share what we can and use adapters (similar to interfaces) to customize/handle the differences.

[clangsmith]

We are working on routing an internal requirement (PMSTUDIO-976) to appropriate folks to consider adding the file navigation root options to the Compute Context, so it is under admin control (like it is in V9 and SAS Studio on Viya 4) and so that anyone (or client) who uses a specific Compute Context will get a consistent file navigation root. Otherwise, the best we can do is probably like EG, which stores the file navigation options in the profile, thus can be changed by any end user.

[smorrisj]

@scottdover approach looks good here. I like the separation of concerns, with keeping connection specific code in those respective feature areas. Based on prior conversation, it also sounds like we could potentially enable/disable it for workbench connections as well, depending on what we want feature wise for that.