· Jul 26, 2022

Add REST Service Classes To VS Code Project

I have successfully created REST service classes on my local IRIS server following this book: Using the /api/mgmnt/ Service | Creating REST Services | InterSystems IRIS Data Platform 2021.2

I am now 1) trying to edit impl.cls in VS Code and 2) export it to my local repo so I can push to the remote repo.

When I click on my project in VS Code and 'Add to project' and choose the new package, spec.cls and impl.cls, I get the following error:

ERROR #5540: SQLCODE: -114 Message: Unable to acquire lock for INSERT of child row for parent table '%Studio.Project' with parent id = 'Default_project'

Has anyone experienced this?

As for exporting to my local repo, I think it's just a matter of right clicking and selecting 'Export'? Correct?

Thanks in advanced!

$ZV: IRIS for Windows (x86-64) 2020.1.1 (Build 408U) Sun Mar 21 2021 22:04:09 EDT
Discussion (12)2
Log in or sign up to continue

Opening this back up because getting the classes to my local repo is proving to be challenging.

In VS Code I was able to open the code on the server, click 'Download' on the package and download it to my local repo.  Problem is that the only two classes that show up are impl and spec, but not disp.

In a similar vein, if I used the API to update the spec the updated code was now on the server (just as it first got there when I did the create using the API).  Now when I try to download the updated package to my local, well, it won't let me.  I have to download each file which isn't too cumbersome, but it's just one.  

How can I:

1) Get the disp class to get to my local so I can ship it to the remote repo and other servers

2) Make the update process using the API smoother

3) Bonus: create a web app programmatically so when my colleague starts to use it for his front end dev, he's ready to go.

@Michael Davidovich

As a first step I suggest you read through our online documentation to familiarize yourself with common workflows. The extension supports a client-side workflow where you export files to the currently open local folder and handle the source control yourself. To edit client-side, you can use the ObjectScript Explorer to export files. You can also use the Export Code From Server command, which uses the objectscript.export configuration settings to determine what to export. Our extension does not support VS Code's "Download" menu option.

Since the disp class is generated from the spec class you probably don't want to store it in source control but if you still want to export it, you can have the Explorer show generated files before you export a package or if you're using the command you can set the objectscript.export.generatedto true.

@Brett Saviano 

Thanks for your reply!  I am familiar with that doc but didn't reference it because we already set up for client side development.  Yes I could just edit the spec and impl classes on the server, but since our source control isn't hooked into the server, so I would still have the issue of getting the code generated and updated on the server (from /api/mgmt/) to my local repo.  

I tried the ObjScript Explorer to export, but it seems I can only export ALL the files.  That's not practical when I just want to export one package.  

However, using the Export Code From Server command does let me select individual classes so that's great! 

Question: if we scale up with use of OpenAPI 2.0, the use of /api/mgmt/ and stick with client side dev, how can we make source control more smooth?  In other words, is there a way to automatically export impl and spec classes to the client whenever they are updated?

Good to know about the disp class and makes sense.  One less thing to worry about.  

While I was playing around with this, a few times after compiling changes to the impl class, the disp class was then removed from the server (this was in Studio before I figured out to get them on the client).  Have you experienced this before and know what might cause that to happen?

@Michael Davidovich 
You can export individual packages or files from the ObjectScript Explorer. Simply right-click on the node(s) that you want to export and click the "Export" menu option. The command may be better in your use case though because once you have your settings configured properly, you don't need to do anything else besides run the command to update your local copies.

Unfortunately there isn't a way to automatically update your copy if changes are detected. If you make an edit and then try to save it to the server the extension will check if there's a conflict and help you resolve it. If you are working client-side then I wouldn't expect a server conflict though because your local copies (synced with source control of course) should be the "source of truth". You can always re-run the export command before you edit if you want to avoid conflicts.

As for the disappearing disp class, editing the impl class will not force the disp class to be regenerated so its state shouldn't change. That may be due to your Studio configuration being set to hide generated files.

Thank you, Brett.  I must still be missing something.

In the ObjectScript explorer, if I right click on the project I have an option to 'Export Project Contents'.  If I right click on any package or file, I only have three options: Remove from Project, Server Source Control and Server Command Menu.

I've skimmed the doc again but don't see anything obvious in terms of settings that I might be missing. 

Any ideas?

@Michael Davidovich 
If you have a local folder open there should be two tree views within the ObjectScript view container (the left pane that is shown after clicking the InterSystems logo in the activity bar on the far left). The bottom one is the Projects Explorer and it's only used to create/modify/export server-side project contents (also known as Studio Projects). The top tree (with the Explorer name) is the ObjectScript Explorer where you can Compile/Export/Delete packages and files. Since you don't use server-side source control and need files in your local file system, you can safely ignore the Projects Explorer since they won't be useful for your workflow. Here's a screenshot of what this looks like for me in a locla folder called "langauge-server":

EDIT: If the ObjectScript Explorer isn't showing, make sure you don't have the setting "objectscript.showExpolorer" set to false.

@Brett Saviano 

Sorry, back again. Feeling like a dunce here . . . I updated my API using my OpenApi 2.0 JSON spec and the /api/mgmt POST call and looking in Studio, I can see my spec.cls is showing v 1.5 as I expect. When I refresh the explorer view (which is the live server, yes?) I'm still on v 1.4 which is my old spec.

Is there some other setting that might be preventing this refresh?

I looked here: Settings Reference - InterSystems ObjectScript for VS Code (, but I didn't find anything that stood out as a setting that would stop a refresh of the explorer view from showing updated classes on the server.