Hi developers. Just want to share with you a finding that might save you a few important minutes of your developer life with InterSystems IRIS.

But!

It should work; you deployed the REST API correctly, and everything is just in place.

What can go wrong?

Hi developers!

Observing the avalanche of AI-driven and vibe-coding developer tools that have been appearing lately almost every month with more and more exciting dev features, I was puzzled whether it is possible to leverage it with InterSystems IRIS. At least to build a frontend. And the answer - yes! At least with the approach I followed.

Here is my recipe to prompt the UI vs InterSystems IRIS Backend:

1. Have the REST API on the IRIS side, which reflects some Open API (swagger) spec.
2. Generate the UI with any vibe-coding tool (e.g., Lovable) and point the UI to the REST API endpoint.
3. Profit!

Here is the result of my own exercise - a 100% prompted UI vs IRIS REST API that allows to list, create, update delete entries of a persistent class (Open Exchange, frontend source, video):

What is the recipe in detail?

We have classes in a Production environment that are causing us some issues - example attached.

When we export them from the production environment the XML contains a snippet like the following:

<UDLText name="T">
<Content><![CDATA[
//Property any As list Of %XML.String(XMLNAME = "any", XMLPROJECTION = "ANY") [ SqlFieldName = _any ];

]]></Content>
</UDLText>

When imported and compiled into an Ensemble instance this class works as expected.

InterSystems ObjectScript extension for VS Code, version 3.0.1

Am also asking this question on the extension's GitHub page: Request textDocument/documentSymbol failed. Error: name must not be falsy · intersystems-community/vscode-objectscript · Discussion #1530 - but suspect more eyes will see it here, which might help gather additional information.

The VS Code extension development team is looking for beta testers to provide feedback on a proposed overhaul of the client-side editing workflow. The full list of changes can be found in the GitHub pull request description. Here are the highlights:

Hi colleagues!

Often, while developing a frontend app or any other communication vs REST API, it is worth having a Swagger UI - a test UI for the REST API that follows Open API 2.0 spec. Usually, it is quite a handful as it lets have quick manual tests vs REST API and its responses and the data inside.

Recently I've introduced the Swagger support to the InterSystems IRIS FHIR template for FHIR R4 API:

How to get it working.

Visual Studio Code releases new updates every month with new features and bug fixes, and the January 2025 release is now available.

Hi fellow developers in InterSystems IRIS!

I'm often being asked, especially related to technical bonuses we encourage for every Open Exchange contest why do we constantly give bonuses for Docker, IPM and ObjectScript Quality pass.

In fact, this is very easy to answer.

The InterSystems platforms have always offered dynamic documentation of the packages and classes in a namespace, a feature known informally as Documatic. But what if you need to publish this class reference information on a website without requiring the site to be connected to an IRIS server containing the actual classes?

A benefit of using Doxygenerate is that Doxygen does more than just HTML output. Tweak the Doxyfile that tells Doxygen what to do and you can easily create a PDF. Our example MARINA application yielded a 524-page PDF. Here's what page 94 looks like:

You can browse the whole file here.

I’m trying to connect to an InterSystems Caché database from my local development environment using an IPv4 address. Most examples I’ve found show how to connect using the ODBC driver with the localhost or the default IP address (127.0.0.1). However, I want to know how to connect using my local IPv4 address.

Here’s what I need help with:

We have Webterminal around for quite a while, but it was limited, not all features worked there. There was no shell support or the latest feature as embedded Python support. There are some issues with tools that require programmer mode. Basic Authorization, not as handy as simple login page, where you could have options to add own login page, in case if you would wish to change the way how to login to the application, such as using SSO.

With the original iris terminal, wrapped into a web form, using most used in the web world xterm.js, used in tools like VSCode as well, with some magic from Python, which helped with interprocess tty. We can get the the terminal in the web, in the full capacity.

We are doing healthcare interface development.

Developers have Ensemble installed locally on their laptops - code will be developed locally then deployed to integration, test/UAT and ultimately production servers in due course.

One of the other applications we are developing around happens to utilise an Iris desktop client to a remote Iris server. We want to have the application available on the developers laptops alongside the local Ensemble instance.

Hi everyone,

In this article, I’m excited to introduce CodeInspector, a tool designed to simplify code validation by applying custom rules tailored to your development requirements. Whether you're managing a large codebase or working in an agile environment, CodeInspector helps ensure code quality by offering flexibility and adaptability to specific project needs.