Hi everyone! 👋
I’m excited to share the project I’ve submitted to the current InterSystems .Net, Java, Python, and JavaScript Contest — it’s called IRIStool and Data Manager, and you can find it on the InterSystems Open Exchange and on my GitHub page.

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!") 

I was really surprised that such a flexible integration platform with a rich toolset specifically for app connections has no out-of-the-box Enterprise Service Bus solution. Like Apache ServiceMix, Mule ESB, SAP PI/PO, etc, what’s the reason? What do you think? Has this pattern lost its relevance completely nowadays? And everybody moved to message brokers, maybe?

Wiki time: An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA) .

I'm a huge sci-fi fan, but while I'm fully onboard the Star Wars train (apologies to my fellow Trekkies!), but I've always appreciated the classic episodes of Star Trek from my childhood. The diverse crew of the USS Enterprise, each masterminding their unique roles, is a perfect metaphor for understanding AI agents and their power in projects like Facilis. So, let's embark on an intergalactic mission, leveraging AI as our ship's crew and  boldly go where no man has gone before

Hi Community,
In this article, I will introduce my application iris-HL7v2Gen .

IRIS-HL7v2Gen is a CSP application that facilitates the dynamic generation of HL7 test messages. This process is essential for testing, debugging, and integrating healthcare data systems. The application allows users to generate a wide variety of HL7 message types, validate their structure against HL7 specifications, explore the message hierarchy, and transmit messages over TCP/IP to production systems. These features are particularly useful in settings where compliance with HL7 standards is mandatory for interoperability between different healthcare organizations or systems.

Hey Community,

More than 1,100 applications are already available for everyone to download on the InterSystems Open Exchange. 

And now it's time to announce the best developers and the most downloaded apps of 2025!

Let's take a closer look at our heroes and their apps:

Data Collection

This is a step-by-step instruction guide for creating a task to collect data about the InterSystems database and globals therein (as seen in the associated Open Exchange App - find all the associated code there)

UPDATE (Aug 1 2024): Recently I've been asked about the differences between this and the History Monitor functionality. In short, the data collection monitor builds on the history monitor by adding the ability to track growth of individual globals.

Disclaimer: This software is merely for TEST/DEMO purposes.

Welcome to the monthly recap of updates and releases to VS Code and InterSystems-related extensions relevant to IRIS developers. We'll break down the updates that are relevant to InterSystems developers with tips on how they can be applied to your day-to-day projects. 

Don’t forget, if you’re migrating from InterSystems Studio to VS Code, or want to deepen your knowledge, check out the VS Code training courses from George James Software: georgejames.com/vscode-training.
VS Code version 1.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.
The rating reflects the experience of the reviewer with the status found at the time of review.
It is kind of a snapshot and might have changed meanwhile.
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.
Some were accepted and merged, and some were just ignored.
So if you made a major change and expect a changed review, just let me know.

Over the last 9 years, I published more than 90 packages in OEX.
And over this time, conditions and environments changed.
In the beginning, there was

• no Docker
• no IPM/ZPM
• no embedded Python, no AI
• Caché, Ensemble, CSP, ZEN, .... were dominating

As time changed, also product versions and external languages changed.
Adjustment of a few packages was no issue in the beginning,
and was a matter of support quality to my "consumers".

With the actual volume, I see no way to keep this target up for all my packages.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.