Defining my first REST API within InterSystems using iris-rest-Api-template as a basis and I am seeing if someone could provide me some guidance to see if I can make it work.

I have been struggling sometime with trying to take a FHIR Bundle Response, extract the "entry.resourceType", extract the MRN and Name from the Patient FHIR Response...

Going through learning.intersystems.com, it suggested that I try using fhirPathAPI to parse and search my response for certain values, however I am not sure my syntax is correct. Using the AI code, it suggested to set my tree = "Bundle.entry.resource.resourceType"

You probably know this situation:
Some time ago, you found a very special $ZU function for a very specific type of problem. Some kind of mystical formula. It became popular and was used by many developers throughout your code and across all your installations.

Several versions and updates later, you are informed by ISC that your mystical $ZU is deprecated and no longer supported. You are advised to replace it with a new $something().

Here is what is currently used.

..CurrentDateTime("%Y%m%d%H%M%S")

The format is not the issue.

I need to make it our current time as it is five hours ahead.

How can I access the header property of either of these.

Or, if I can't do that, subtract five hours or the equivalent time in seconds.

example, if I receive 20201224161922, how can I make it 20201224111922?

Thanks,

Jonathan

Hi developers!

There is a neat feature of ObjectScript classes - Query element, which allows you to write in a clear SQL (without any & or ()), pass parameters to it and call it from ObjectScript as do QueryNameFunc() or via Call SQLProcedureName via SQL, .e.g.

Hi developers!

There is a very neat variable in IPM ${ipmdir} that lets packages be installed on a particular IRIS server and ensures that the data and resources they bring don't mess around as ${ipmdir} variable during the installation transforms into:

iris installation dir/ipm/package_name/version/whatever_you_install_here

It is very convenient, e.g., to bring some data and resource files that can be useful during the installation setup, e.g., via FILECOPY. Indeed, suppose you bring some csv_file, e.g. titanic.csv via FILECOPY as:

<FileCopy Name="data/titanic.csv" Target="${ipmdir}data/titanic.csv"/>

or even the whole folder of data in the source code repo into the package:

<FileCopy Name="data/" Target="${ipmdir}data/"/>

And in the case of Iris in Docker it resides in:

/usr/irissys/ipm/package_name/1.0.0/data/titanic.csv

This is all great, but is there any way for the installed code to determine the location of the data files? It'd be neat to let the installed app know somehow where is the data that came with it? Could it be the method in the IPM client that will resolve ${ipmdir} for the app?

Hello!!!

Data migration often sounds like a simple "move data from A to B task" until you actually do it. In reality, it is a complex process that blends planning, validation, testing, and technical precision.

Over several projects where I handled data migration into a HIS which runs on IRIS (TrakCare), I realized that success comes from a mix of discipline and automation.

Here are a few points which I want to highlight.

1. Start with a Defined Data Format.

Before you even open your first file, make sure everyone, especially data providers, clearly understands the exact data format you expect. Defining templates early avoids unnecessary bank-and-forth and rework later.

While Excel or CSV formats are common, I personally feel using a tab-delimited text file (.txt) for data upload is best. It's lightweight, consistent, and avoids issues with commas inside text fields.

PatID   DOB Gender  AdmDate
10001   2000-01-02  M   2025-10-01
10002   1998-01-05  F   2025-10-05
10005   1980-08-23  M   2025-10-15

Make sure that the date formats given in the file is correct and constant throughout the file because all these files are usually converted from an Excel file and an Basic excel user might make mistakes while giving you the date formats wrong. Wrong date formats can irritate you while converting into horolog.

In this article, we will discuss all the debugging tools included in the Microsoft Visual Studio Code IDE.

What will be covered:

• Breakpoints
• Watch window
• Call Stack

Let's start by learning about debugging requirements!

Prerequisites

There are two plugins (extensions) for debugging ObjectScript:

The first is part of the InterSystems ObjectScript Extension Pack. The second is Serenji, a standalone plugin that provides an editor, file manager, and debugging functionality. Both plugins can be installed from the plugin store. To activate key functionality, Serenji requires a license. For this article, we'll use the InterSystems ObjectScript Extension Pack to reduce the learning curve. After you've mastered the basics, you can consider purchasing a paid license for Serenji.

InterSystems FAQ rubric

If you try to kill a global that is mapped at the subscript level from the top node, you will get a <SLMSPAN> error and it will not be deleted. This is because the kill command for subscript-level mapped globals cannot be used across mappings.

Hi,

I need a simple function for formatting a string, like in Python or C#. That's easy:

Class Very.Very.Long.Class.Name
{
ClassMethod Format(fmt As %String, args...) As %String [ Language = python ]
{
return fmt.format(*args)
}
}

To simplify calls, I want to wrap the function into a macro:

The previous article introduced IrisOASTestGen, a tool designed to generate REST API test code for InterSystems IRIS based on OpenAPI 2.0 specifications. It demonstrated how to scaffold test cases using the default templates bundled with OpenAPI Generator.

This follow-up focuses on the next natural step: customizing the generated test code.
By extending the code generation logic with Mustache templates, it becomes possible to express richer semantics, implement CRUD-aware tests, and create more meaningful test suites.

FastJsonSchema: High-Performance JSON Validation in IRIS

Validating JSON data against JSON Schema is a common requirement for modern applications. FastJsonSchema brings this capability natively to InterSystems IRIS, combining speed, simplicity, and full schema compliance.

Unlike traditional validation approaches, FastJsonSchema generates native ObjectScript code from your JSON Schemas and compiles it directly to iris object code, enabling idiomatic performance without relying on external libraries or runtimes.

There's a pattern I've encountered several times where I need to use a temp file/folder and have it cleaned up at some point later.

The natural thing to do here is to follow the patterns from "Robust Error Handling and Cleanup in ObjectScript" with a try/catch/pseudo-finally or a registered object to manage cleanup in the destructor. %Stream.File* also has a "RemoveOnClose" property that you can set - but use with care, as you could accidentally remove an important file, and this flag gets reset by calls to %Save() so you'll need to set it back to 1 after doing that.

There's one tricky case, though - suppose you need the temp file to survive in an enclosing stack level. e.g.:

Introduction and Motivation

A unit of ObjectScript code (a ClassMethod, say) may produce a variety of unexpected side effects by interacting with parts of the system outside of its own scope and not properly cleaning up. As a non-exhaustive list, these include: