gj :: configExplorer is a new VS Code extension integrating with Server Manager and leveraging Structurizr to produce configuration diagrams of your servers.

Here's a short introductory video.

By using the InterSystems IRIS Native API for Node.js it avoids the need for any support code to be installed on the servers. This technology choice also qualifies it for entry into the current Developer Community contest.

The initial release focuses on two aspects of server configuration:

• Namespaces and databases
• ECP connectivity

Suggestions for what to add next are welcome, as is general feedback.

Introduction

My guess is that most IRIS developers create their applications using its native ObjectScript language or, if using an external language, then most likely using either Java, Python or perhaps C++.

I suspect that only a minority have considered using JavaScript as their language of choice, which, if true, is a great shame, because, In my opinion and experience, JavaScript is the closest equivalent to ObjectScript in terms of its ability to integrate with the IRIS's underlying multi-dimensional database.

UPDATE: since version 0.0.4 of the extension was published on 2025-11-23 it is now possible to use gj :: configExplorer directly in VS Code on Windows.

In my previous article introducing gj :: configExplorer I flagged up how an apparent bug in the Windows elements of the Native API for Node.js means it's not currently available to run in VS Code on a Windows desktop. In a comment on that article I offered a workaround, but this requires a Docker-equipped Linux host you can SSH to.

If you don't have a suitable target it's now possible to leverage your local Windows Docker Desktop.

While working with external languages for IRIS (such as Python and Node.js), one of the first things you must accomplish is making a connection to an IRIS instance.

For instance, to make a connection in python (from https://pypi.org/project/intersystems-irispython/):

import iris

# Open a connection to the server
args = {
	'hostname':'127.0.0.1', 
	'port': 1972,
	'namespace':'USER', 
	'username':'username', 
	'password':'password'
}
conn = iris.connect(**args)

# Create an iris object
irispy = iris.createIRIS(conn)

# Create a global array in the USER namespace on the server
irispy.set("myGlobal", "hello world!") 

Overview

The typeorm-iris project provides experimental support for integrating TypeORM with InterSystems IRIS, enabling developers to interact with IRIS using TypeORM’s well-known decorators and repository abstractions. This allows a more familiar development experience for JavaScript and TypeScript developers building Node.js applications with IRIS as the backend database.

While the project implements key integration points with TypeORM and supports basic entity operations, it’s not yet battle-tested or suitable for production environments.

Reviewing my published packages, I identified a nasty bug in IRIS Native API

• There is a method in  %Net.DB.Iris named function ()
• It's equivalent to  ObjectScript $$label^routine(param) 
• It used to work fine 2 years ago, when I published my command-line-extension packages
• Now it is broken since at least 1 year and throws <PROTECT>
• I identified it for ObjecScript, Java, Python, Node.js
• It is reported as WRC# 1002589
• For all 4 cases, I also verified a workaround
  • Instead of calling an ObjectScript Function you call a Classmethod
  • It's by %Net.DB.Iris ClassMethodValue(.

Overview I'm excited to announce the release of testcontainers-iris-node, a Node.js library that makes it easy to spin up temporary InterSystems IRIS containers for integration and E2E testing. This project is a natural addition to the existing family of Testcontainers adapters for IRIS, including testcontainers-iris-python and testcontainers-iris-java.

Why testcontainers-iris-node? As a Node.js developer working with InterSystems IRIS, I often faced challenges when setting up test environments that mimic production. testcontainers-iris-node solves this by leveraging the testcontainers-node framework to create isolated IRIS environments on-demand.

This is particularly valuable for:

• Integration testing with IRIS databases
• Testing data pipelines or microservices
• Automating test environments in CI pipelines

Features

• Launches IRIS in Docker containers using Testcontainers
• Supports custom Docker images and configuration
• Wait strategies to ensure IRIS is ready before tests begin
• Clean teardown between test runs

Hi Developers!

This is the second post on the resources for Developers. This part is about Open Exchange

Using Open Exchange to Learn InterSystems

InterSystems Open Exchange is a applications gallery of tools, connectors, and libraries which InterSystems Developers submit to share the experience, approaches and do business. All the applications are either built with InterSystems data platforms or are intended to use for development with InterSystems data platforms.

If you are a beginner developer you can take a look at applications in Technology Example category. All the applications in this category come with open source code repositories, so you are able to run the samples and examples in a docker container with IRIS on your laptop or in the cloud IRIS sandbox. Examples:

We recently uploaded to OpenExchange a small application that I developed a while ago (and that @Jose-Tomas Salvador improved and refined) that I often use when I need to generate large volumes of HL7 messaging.

The application is developed in NodeJS and works by generating patient and doctor data from seed files that you can modify to your liking to personalize the generated patients. The application will use the generated patients to prepare different types of HL7 messages. At the moment the application can generate the following types of messages.

Intro

Most server-client communication on the web is based on a request and response structure. The client sends a request to the server and the server responds to this request. The WebSocket protocol provides a two-way channel of communication between a server and client, allowing servers to send messages to clients without first receiving a request. For more information on the WebSocket protocol and its implementation in InterSystems IRIS, see the links below.

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In the previous part, we created a basic front-end React application. In the second part of this article series I will show how to choose the right back-end technology for your application. You will see Caché allows you to use many different approaches to link your front-end to your Caché server, depending on your application's needs. In this part we will set up a back-end with Node.js/QEWD and CSP/REST. In the next part we will enhance our basic web app and connect it to Caché using these technologies.

The concept of low code development is getting more and more important across all industries. Everybody who is starting to get into low code programming, will inevitably come across Node-RED. InterSystems IRIS is renowned for its interoperability and so should be accessible via Node-RED.

For those who have not heard of Node-RED yet: Node-RED is a Low-Code programming application, which is based on so called nodes that are connected with wires. Nodes process incoming messages and forward them to the next connected node.

I wrote a step by step tutorial in the qewd-howtos repository how you can write state of the art multi-page web apps with Node.js using a QEWD-Up WebSocket/REST api back-end integrated with a mainstream web framework like NuxtJS & Vue.js. In particular with the latest NuxtJS/Vue.js frameworks, writing web applications becomes fun again, allowing you to write your applications very efficiently, hiding all boilerplate code from you.

The tutorial should be very easy to try out on your development machine and consists of two parts:

• instructions for creating a basic Node.

I've posted this video on YouTube:

https://www.youtube.com/watch?v=gHUifpuav9I

Expand this article for some background to what it shows and what it's all about...

I've submitted what I've called qewd-jsdb-kit-iris to the Multi-model competition - it's a suite of applications and tutorials that demonstrate how IRIS Global Storage is used to provide the unique Node.

QEWD is assumed by most people to only integrate with IRIS (or Cache) via a connection through IRIS's high-performance C interface.  This requires QEWD (and its Node.js environment) to be installed and configured on the same machine as IRIS.

I'm frequently asked if QEWD can run on a separate server (or servers), and access IRIS (or Cache) over a network connection.  The answer is yes it can, but the information on how to set it up in this way has been admittedly a bit tricky to discover.

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. Previously, I outlined the basic steps to install and connect Node.js to Caché and make it's powerful multi-model database capabilites available for use with Node.js. You can use Caché as a NoSQL-, document- (with unique key-level access!), SQL- and object-database with Node.js. When developing JavaScript applications, you'll see how powerful this combination is and makes Caché a perfect fit for Node.js.

In the first part of this article series I will show how to get started with the React framework, one of the most popular frameworks currently taking over front-end development. In the next parts you'll learn how to connect a basic web app to a Caché back-end.

You'll see, it's very easy to get started with this technology - you can even compare the amount of basic knowledge you need to COS because you only need to know a few basic concepts to start!

Those of you who are following the FullStack competition here in the Developer Community will know that I submitted an entry named qewd-conduit.  I wanted to summarise why I think it's something worth you taking a bit of time to check out.

qewd-conduit uses the Node.js-based QEWD framework alongside IRIS to implement the back-end REST APIs for something known as the RealWorld Conduit application:

https://github.com/gothinkster/realworld

Some time ago I got a WRC case transferred where a customer asks for the availability of a raw DEFLATE compression/decompression function built-in Caché.

When we talk about DEFLATE we need to talk about Zlib as well, since Zlib is the de-facto standard free compression/decompression library developed in the mid-90s.

Zlib works on particular DEFLATE compression/decompression algorithm and the idea of encapsulation within a wrapper (gzip, zlib, etc.).
https://en.wikipedia.org/wiki/Zlib

Using the IRIS native API for Node.JS was the opportunity to present
a MicroService operating in a Docker container.
A demo video is now also available to watch the demo in operation.

Instead of a utility you call directly on your IRIS host you now send a work-packages
to the MicroService as would typically do with System Interoperability (aka.ENSEMBLE):
of course, you have the option of more than one WebSocket Server.
Once the WebSocket Client Service has done its job you get back the result from it.

Full-Stack JavaScript development allows you to create state-of-the-art applications with Caché. With any (web) app you build nowadays, one has to make a lot of architectural decisions and you want to make the right ones. With the Node.js connector available for Caché, you can create a very powerful server side application server, allowing you to use the latest JavaScript technology and frameworks client- and server-side.

With all these new technologies, the most important is to integrate them in the most efficient way and to create a very productive development experience. This article willl get you started step-by-step with Node.js technology.

ˮ This is one of my articles which was never published in English. Let's fix it!

Hello! This article is about quite a practical way of developing InterSystems solutions without using the integrated tools like Studio or Atelier. All the code of the project can be stored in the form of "traditional" source code files, edited in your favorite development environment (for example, Visual Studio Code), indexed by any version control system and arbitrarily combined with many external tools for code analysis, preprocessing, packaging and so on.

It will demonstrate the wide range that is openend by making use
of the power embedded in Node.js and its adapter to Caché, Ensemble, Health,..*
Node / JavaScript have wide reputation to work as a WebSocket client.
By using the Caché adapter it becomes easy to control it and to consume the results as a
Client for WebSocket Servers and to collect the replies in Caché, Ensemble, ..

I used node-v6.16.0-x64.msi and cache610.node as cache.node

You provide a Global for input:

 ^WsockIn="wss://ws.postman-echo.com/raw"
 ^WsockIn(0)=6
 ^WsockIn(1)="Hello"
 ^WsockIn(2)="World !"
 ^WsockIn(3)="Robert"
 ^WsockIn(4)="is waiting"
 ^WsockIn(5)="for replies"
 ^WsockIn(6)="exit"

This post is intended to guide you through the new JSON capabilities that we introduced in Caché 2016.1. JSON has emerged to a serialization format used in many places. The web started it, but nowadays it is utilized everywhere. We've got plenty to cover, so let's get started.

There's a new and exciting enhancement to QEWD that has just been released - it's an additional layer of abstraction known as QEWD-Up.  QEWD-Up hides away all the mechanics of QEWD itself, allowing you to focus on just your REST APIs and the code that implements them.

Additionally, and importantly, QEWD-Up simplifies the maintenance of your REST APIs, allowing you (and others) to quickly and easily understand their life-cycle and implementation.

QEWD-Up supports both monolithic application designs and MicroService-based architectures where APIs are broken down by, for example, functional role.

Intro

Recently I reread this article by @Bernd.Mueller. It's about calling DELFATE function from zlib library. In this article I'll demonstrate several different approaches to callout libraries, we'll build the same functionality (compress function) in several different languages and compare them.

As a result of Evgeny's recent questions regarding the use of QEWD.js with IRIS in another post, I thought it would be a good idea to create a separate post focusing specifically on how to use QEWD.js to create REST APIs for IRIS.

QEWD.js is,  of course, a Node.js framework, and all the REST API code can be written entirely in JavaScript. 

The RealWorld Conduit reference application makes a great exemplar for this kind of thing, as the APIs are all published and there are numerous implementations of both front-ends and back-ends for it, using different technologies, frameworks and databases.

Here I’ll walk you through the process of creating a simple Node/Express API and connect it to a InterSystems IRIS instance.

I won't go into much detail about how to work with any of the technologies I will mention in this tutorial but I will leave links, in case you want to learn more.

The objective here is to give you a practical guide on how to set up and connect a node.js back-end API to IRIS.

Before we get our hands dirty, make sure you have Node.js running on your machine. So I'll check:

Version 8.12.0 is the current LTS (Long Term support) version of node.js.

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In this third part of this article series I will show how to link our React app to our three back-ends we created in part 2.

If your looking to develop a Node.JS to Caché library then you might want to consider using a pure TCP connection with a custom message transport protocol. This bypasses the native Caché connector libraries that can get stale with a new release.

Node.JS is very good at non blocking code development, so building a performant solution isn't that complex. 

The idea behind this example is that we have a node HTTP server that maps HTTP requests to a Caché TCP connection.

One of the most important features during application development is the ability to debug your code easily. Because of the asynchrnous nature, a standard Node.js application server works single-threaded by default. When you are developing applications using an IDE like Visual Studio Code, you can very easily debug your Node.js process:

First, download the free Visual Studio Code IDE (@code) and install it on your development machine.

We will start with basic debugging using a very small test.