I am currently trying to better my development process by using Visual Studio Code because I'm more familiar and comfortable with it than Studio.

I've followed the guide here, but I'm still having issues. I initially didn't have the Web Socket protocol allowed on my Web Gateway server, but I enabled that and restarted the server with no luck.

I'm attempting to configure VS Code's InterSystems Server Manager to establish a connection to an IRIS for Health server. It has a standalone CSP gateway running on an Apache server with TLS enabled. The port for all IRIS api and browser traffic is 443.

I've configured the webServer section's host, port, and variations on pathPrefix (including no pathPrefix entry), and have the correct user ID set. The password is stored in the server keychain.

The connection simply fails with "Server could not be reached." Nothing in the Output or Problems tabs.

Hello everyone, I’m a French student in academical exchange for my fifth year of engineering school and here is my participation in the FHIR for Women's Health contest.

This project is supposed to be seen as the backend of a bigger application. It can be plugged into a Front End app and help you gather information from your patients. It will read your data in local and use a Data Transformation to make it into a FHIR object before sending it to the included local FHIR server.

Hi guys,

Open question for all of you...

We are getting some warnings in our code of a class definition when switching namespaces in the code, because the classes we use in different namespace wouldn't exist in each other's... an example:

ClassMethod DoSomething() {
     set oldNS=$zutil(5)
     znspace "SECONDNS"
     set ok=##class(MyPackage.MyClass).MyMethod()
     znspace oldNS
}

In that example, the vscode "Intersystems Language Server" extension would tag "MyPackage.MyClass" as a problem because that class only exists in the second namespace.

Adding VSCode into your IRIS container

One of the easiest ways to setup repeatable development environments is to spin up containers for them. I find that when iterating quickly, it was very convenient to host a vscode instance within my development container. Thus, I have created a quick container script to add a browser-based vscode into an IRIS container. This should work for most 2021.1+ containers. My code repository can be found here

As you have probably noticed, online product documentation has advanced tremendously in the last few years. Among numerous improvements under the hood, documentation has become easier to read and navigate. And we now have a powerful search engine that gets you to what you need more accurately than we could ever do with the old system of shipping documentation in the product. While most of you have probably had nothing but positive impacts on your workflows, it has come to my attention that some of you may be having a slight problem accessing custom class documentation.

Hi developers!

Let me share with you a minimal embedded python template, that I can recommend as a starting point for any general project with InterSystems IRIS that will use embedded python.

Features:

• Embedded Python ready;
• Examples of 3 ways of Embedded python development;
• VSCode development ready;
• Docker enabled;
• Online demo enabled;
• ZPM First development ready.

Let's discuss the features below!

Context: Ensemble development with ObjectScript in a healthcare context - lots of HL7, and some web service stuff. We've used Studio up till now, alongside a lot of leaning on an external developer, but are expanding our team and doing more in-house. We are wondering about Visual Studio Code - not least because it looks easier to hook up to source management solutions. And we've noticed that the test environments that you get connected to when doing many of the online training courses on learning.intersystems.com give you a Visual Studio Code environment.

Hi developers,

We're excited to let you know about the latest release of Serenji, your on-the-spot debugger from George James Software. Version 3.2.0 focuses on the debug experience and introduces zero configuration for users. No matter where you are or what you're doing, Serenji is always ready to go in just one click, so you won't lose focus by spending time setting up a launch configuration.

This enhanced debugger also takes advantage of the latest features of VS Code itself. With this powerful combination you'll be able to smoothly identify and quickly fix errors in your code, contributing to the production of quality, maintainable code... and isn't that what everyone wants?!

In this latest release you will experience:

• Debugging in just one click with zero configuration.
• Navigation directly to the source of an error using our gj :: locate technology.
• Intuitive prompting for entrypoint and arguments.
• Configurable break on error.
• Program output in debug console.
• Run and Debug CodeLenses.
• Run multiple concurrent debug sessions and consoles.
• Shaded background for read-only documents.

If you're a new user, it's now easier for you to get started. The introduction of a welcome page Walkthrough and guidance on the Explorer and Run and Debug views means you can effortlessly create your initial workspace and start debugging.

Download Serenji directly from the VS Code marketplace and take a look at our release notes to find out more about these new features and how to use them.

We offer a free 30 day trial so if you're not yet a user of Serenji but you're interested in how it can help you, drop me a message through the Developer Community or email us at info@georgejames.com.

Happy debugging!

Issue

Server Manager is a Visual Studio Code extension that helps you manage the server connection definitions you probably need when working with the InterSystems ObjectScript extension for VS Code.

For the past ten months version 3 of Server Manager has been available as a pre-release extension, providing better security for stored passwords.

Today Server Manager came out of preview. If you use Server Manager please check for updates in VS Code's Extensions view. The version number of today's release is 3.2.1.

Hi folks!

We have a bunch of templates on OEX that provide a handy foundation for building a particular application with IRIS. And the basic principle of each and every template is that we take vanilla IRIS images, load code, and files into the image using Dockerfile, and create a new docker image as a solution. And then we develop running this image and rebuilding it when returning to development.

Some developers ask me why we need to build the docker image to work with the code. Indeed, if at the end of the day I need to develop a ZPM package and not a docker image why don't run the vanilla image and load the code and everything in it?

The problem I have with the building image approach is that often I can wait a lot to build an image and it fails on some Objectscript problem in the source that I cannot fix as the image is not building. and

Any thoughts? How do you develop with docker?

Hey Community,

Don't miss the new video on InterSystems Developers YouTube channel:

⏯ Working with ObjectScript Classes in VS Code for Client Side Editing

https://www.youtube.com/embed/nZd3UGDu4Rc
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]

Upgraded IRIS/Connect to 2022.1 and /api/atelier no longer works through a Web/CSPGateway. Also upgraded the Web/CSPGateway to version WebGateway-2022.1.0.152.0 on Ubuntu and HTTPD Server version: Apache/2.4.29 (Ubuntu) with no luck as well.

It doesnt seem to matter if I add /api/atelier or /api/monitor to the enabled applications list, these routes do not make it back to the instance, however /csp, /csp/sys still does.