While the classic solution followed rather close the concepts and design of the ancestors
Caché / IRIS allows a more modern approach to flexible/multidimensional properties

This short article was motivated by a problem of one of my customers. They use Ensemble to integrate many systems, some of them use just plain files.

So they naturally selected File Outbound Adapter to write into target file. Things were running smoothly for years, until recently, when the volume of data being written to the file reached large size of tens of megabytes. The operation took around half an hour to complete, causing timing problems where subsequent operations within the process had to wait, and third party system was not happy to wait so long.

One of the reasons why I love Cache and Iris is that not only you can do anything you can imagine, also you can do it in a lot of different ways!!.

Imagine that you have an integration running with IRIS connected by ODBC you probably only run SQL queries but you can also create stored procedures and inside write the code to do everything you can imagine.

I'm going to give you some examples but the limit is your imagination!!

Hi developers!

Today I would like to address a subject that has given me a hard time. I am sure this must have been the case for quite a number of you already (so-called “the bottleneck”). Since this is a broad topic, this article will only focus on identifying incoming HTTP requests that could be causing slowness issues. I will also provide you with a small tool I have developed to help identify them.

Our software is becoming more and more complex, processing a large number of requests from different sources, be it front-end or third-party back-end applications. To ensure optimal performance, it is essential to have a logging system capable of taking a few key measurements, such as the response time, the number of global references and the number of lines of code executed for each HTTP response. As part of my work, I get involved in the development of EMR software as well as incident analysis. Since user load comes mostly from HTTP requests (REST API or CSP application), the need to have this type of measurement when generalized slowness issues occur has become obvious.

As I mentioned in an early post the roots of COS were laid in the late 60ies of the 20th century.

Close to that time, BLISS was designed at Carnegie-Mellon University (January 15, 1970)
https://en.wikipedia.org/wiki/BLISS
Similarly in 1972 C language was written at Bell Labs.
https://www.bell-labs.com/usr/dmr/www/chist.html

Setting the Scene

I was editing the properties of a persistent ObjectScript class the other day and noticed that the storage definition wasn't updating to reflect my latest changes.

In this case, I deleted a property that was no longer needed from the class definition, saved, recompiled, and still saw it in the storage definition.

Integrating frontend React applications with backend services like IRIS database via REST APIs can be a powerful way to build robust web applications. However, one common hurdle developers often encounter is the Cross-Origin Resource Sharing (CORS) issue, which can prevent the frontend from accessing resources on the backend due to security restrictions enforced by web browsers. In this article, we'll explore how to tackle CORS issues when integrating React web apps with IRIS backend services.

Containers

With the launch of InterSystems IRIS Data Platform, we provide our product even in a Docker container. But what is a container?

The fundamental container definition is that of a sandbox for a process.

Containers are software-defined packages that have some similarities to virtual machines (VM) like for example they can be executed.

Containers provide isolation without a full OS emulation. Containers are therefore much lighter than a VM.

This tutorial is a follow on to Working with %Query
It was displaying the content of the input stream chopped in fixed-size chunks.
But often those streams are structured and have well-defined separators (e.g HL7)
So as a side subject of this tutorial, this chapter shows how to break a stream into PIECES.

It is exactly the same idea as the $PIECE() function for strings with some add-ons.

By now it's a commonplace how to implement a basic REST API in Caché and there is good documentation about it here: REST in Caché

A question that comes up from time to time is:

How can I make a parameter in my REST url optional?

Simply put, is it possible to create a URL map in Caché that maps a URL like this:

Hi All
This is the index to a series of articles I hope to create over the coming months.

ZEN and ZEN Mojo are no longer being actively developed by Intesystems - this is a great shame as it is a fine product that works so well for business applications.
However ZEN is a 15 year old product and I need a path forward to replace the ZEN UI with a supported development framework.

This article is an index of the other articles I have, or plan to write. - the articles will be subject to change as I develop my thoughts and climb the learning curve.

Working in support, I usually get asked how many days I should keep journals. Should it be two days or after two backups? More? Less? Why two?

The correct answer (for most of the environments) is that you should keep the journals since the last validated Backup. I.e., until you don't check if a Backup is valid (restoring the file and checking with the Integrity utility), you can't be sure there is a good copy of your data and can't purge the journals safely.

The offer of ZPM is growing daily and the short names and
acronyms of the offer are sometimes hard to understand and
also hard to type with my lazy fingers.

So I decided to have

• a listing with the descriptions from the repository,
• split in short junks to avoid backscroll,
• controlled forward / backward scrolling,
• the option to select my packages by number,
• to install or uninstall with limited typing.

It runs with do ^zpmshow

A snapshot from the screen:

HL7 (Health Level 7) is a set of technical specifications for computerized exchanges of clinical, financial and administrative data between hospital information systems (HIS). These specifications are variously integrated into the corpus of formal American (ANSI) and international (ISO) standards.

The L7 of HL7 indicates that it is a standard that operates at layer 7, in other words at the application layer, of the OSI model. This means that HL7 does not have to take into account exchange security considerations, or those of message transport (this being ensured by lower-level layers such as SSL/TLS for security or TCP for the transport of data for example). To be more precise, layer 7 supports communications for end-user processes and applications and the presentation of data for user-facing software applications. As the highest layer of the OSI model, and the closest to the end user, layer 7 provides application-specific functions such as identifying communication partners and the quality of service between them, determining resource availability, considering privacy and user authentication, and synchronizing communication, as well as connecting the application to the lower levels of the OSI model.

Returning to the HL7 standard, the HL7 version 2 standard (also known as Pipehat) was originally created in 1989 but is still being used and updated regularly, resulting in versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1, 2.8.2 and 2.9. The v2.x standards are backward compatible (e.g., a message based on version 2.3 will be understood by an application that supports version 2.6) and in higher versions, you will see some fields are left just for it.

Despite it being more than 30 years old, HL7v2 remains the most widely used healthcare interface standard by a large margin according to the HL7.org portal that tells that: