Exporting Interoperability settings and other configuration items

[intersystems-au]

I'd like to export configuration settings from my namespace,

• Deployable System Default Settings,
• Business Partners,
• Scheduled Specs
• External-Service Registry

into nominated target folders similar to how objectscript.export.addCategory automatically maps CLS, RTN etc.

With the above (especially System default Settings), developers will be able to export these settings into a repository folder that will go into source control

A corresponding script import application code and these settings can be created. Doing the above would mean that users do not need to adopt the community git-source-control utility (which has export SystemDefaultSettings), and can work completely detached, and use VSCode GIT extensions and tools (instead of git-source-control UI for inspecting history, etc)

Steve

[isc-bsaviano]

Hi Steve, I recommend writing a ClassMethod that performs the export for you. This will give you full control over which documents get exported and where they get exported. This can be done easily using the StudioOpenDialog query and $system.OBJ.ExportUDL(). It will also perform way better than VS Code for large exports. Here's a skeleton method:

ClassMethod InitializeVSCodeFolder(folder As %String = "/Users/Steve/MyWork/")
{
  set stmt = ##class(%SQL.Statement).%New()
  do stmt.%PrepareClassQuery("%Library.RoutineMgr","StudioOpenDialog")
  set rs = stmt.%Execute(/* args */)
  while rs.%Next() {
    set docName = rs.%Get("Name")
    set file = /* determine file name relative to folder */
    do $system.OBJ.ExportUDL(docName,file)
  }
}

Note that for abstract documents like the types you listed the names of the files must match the server name for them to be imported correctly by VS Code. For example, HIPAA_4010.X12 needs to be exported to a location /path/to/HIPAA_4010.X12. The file extension is case-insensitive on disk. I also recommend not splitting classes and routines into separate folders. If a class and a routine are in the same package then you probably want them in the same folder on disk for ease of access.

[isc-bsaviano]

Closing because I don't think we will make any changes in this extension to address this.

[pisani]

Thanks Brett.
I was going to say here that - ok, for sure I have enough years of experience in objectscript to write my own function to export whatever I need from IRIS into whatever folder I want. But that's not the point, as I was lookingn for an enhancement.
I was hoping the VSCode extension would allow me to map out how and where different class types (and class names following some pattern) end up when exported. For example (beside LUT's and HL7), - You will see that Classes starting with UnitTest*.cls typically reside in a seperate subfolder /Tests. - so they are loaded seperately as part of a testing cycle.

All server-side driven source control tools have this feature, (eg git-source-control) so I was surprised, given its use mentioned above, to find out that this extension does not allow for this level of control, or that you do not think it is warranted to make this change.

Perhaps - at least - there may be a way to export classes or routines based on their name (eg UnitTest*) to specific folders, but I haven't found that - I will be forced to implement my own for this

[isc-bsaviano]

Hi Steve, I see your point about not everyone being comfortable enough with ObjectScript to do this through code.

find out that this extension does not allow for this level of control

Once the files are on disk this extension will support syncing them with the server regardless of layout. The only rules that must be followed are the one for abstract documents mentioned in my first comment and that web app files must have the web app name in the path (for example, /csp/user/a.csp must be the end of the file system path for that file to be synced correctly). Otherwise files can be organized in whatever folder structure the user likes. We know users need that freedom.

you do not think it is warranted to make this change.

I do not this it's warranted to make the change you suggested. We support almost unlimited freedom for folder structure layout. Making the export settings allow for that flexibility is not trivial. There will always be some use case that we don't support. I don't see the value in solving this problem in that way considering that in an ideal world a user should only be exporting once per existing project. I will re-open this issue and discuss it with product management to see if there's an alternate approach that could help.