#InterSystems IRIS

Have you ever needed to change an IP or port before deploying an interface to production? Needed to remove items from an export? What about modifying the value(s) in a lookup table before deploying? Have you wanted to disable an interface before deploying? What about adding a comment, category, or alert setting to an interface before deploying to production?

Template engines are essential for producing customizable dynamic content, without the need for compilation and opening up great possibilities of extensibility for the template user. Especially if the template engine supports Python. A popular solution for template engine is Mko. It is is a template library written in Python. It provides a familiar, non-XML syntax which compiles into Python modules for maximum performance. Mako's syntax and API borrows from the best ideas of many others, including Django and Jinja2 templates, Cheetah, Myghty, and Genshi.

Hi everyone,

It's me again😁. As usual I would like to share something I study recently, and today, I would like to share about the document DB😁.

I'm sure most of you are familiar with utility %SYS.MONLBL that is crucial when analysing code performance bottlenecks. It allows you to select a number of routines that you want to monitor at runtime and also specify what process(es) you want to watch. BUT, what if you do not know exactly, what process would execute your code? This is true with many web based (CSP/REST) applications today. You want to minimize the resource utilization on your production system that needs analysis. So, how about doing a small tweak?

1. Define an INC file with these macros:

Regardless of whether an instance of IRIS is in the cloud or not, high availability and disaster recovery are always important considerations. While IKO already allows for the use of NodeSelectors to enforce the scheduling of IRISCluster nodes across multiple zones, multi-region k8s clusters are generally not recommended or even supported in the major CSP's managed Kubernetes solutions. However, when discussing HA and DR for IRIS, we may want to have an async member in a completely separate region, or even in a different cloud provider altogether.

RabbitMQ is a message broker that allows producers (those who send a data message) and consumers (those who receive a data message) to establish asynchronous, real-time, and high-performance massive data flows. RabbitMQ supports AMQP (Advanced Message Queuing Protocol), an open standard application layer protocol.
The main reasons to employ RabbitMQ include the following:

• You can improve the performance of the applications using an asynchronous approach.
• It lets you decouple and reduce dependencies between services, microservices, and applications with the help of a data message mediator, meaning that there is no need for producers and consumers of exchanged data to know each other.
• It allows the long-running processing of sent data (with the results) to be delivered after utilizing a response queue.
• It helps you migrate from monolithic to microservices, where microservices exchange data via Rabbit in a decoupled and asynchronous way.
• It offers reliability and resilience by making it possible for messages to be stored and forwarded. A message can be delivered multiple times until it is processed.
• Message queueing is the key to scaling your application. As the workload increases, you will only have to add more workers to handle the queues faster.
• It works well with data streaming applications.
• It is beneficial for IoT applications.
• It is a must for Bots’ communication.

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.

In a project I'm working on we need to store some arbitrary XML in the database. This XML does not have any corresponding class in IRIS, we just need to store it as a string (it's relatively small and can fit in a string).
Since there are MANY (millions!) of records in the database I decided to reduce as much as possible the size without compressing. I know that some XML to be stored is indented, some not, it varies.

When working with InterSystems IRIS, database developers and architects often face a critical decision: whether to use Dynamic SQL or Embedded SQL for querying and updating data. Both methods have their unique strengths and use cases, but understanding their performance implications is essential to making the right choice. Response time, a key metric in evaluating application performance, can vary significantly depending on the SQL approach used. Dynamic SQL offers flexibility, as queries can be constructed and executed at runtime, making it ideal for scenarios with unpredictable or highly variable query needs. Conversely, Embedded SQL emphasizes stability and efficiency by integrating SQL code directly into application logic, offering optimized response times for predefined query patterns.

In this article, I will explore the response times when using these two types of SQL and how they depend on different class structures and usage of parameters. So to do this, I'm going to use the following classes from the diagram:

Thirteen years ago, I attained dual undergraduate degrees in electrical engineering and math, then promptly started full-time at InterSystems using neither. One of my most memorable and stomach-churning academic experiences was in Stats II. On an exam, I was solving a moderately difficult confidence interval problem. I was running out of time, so (being an engineer) I wrote out the definite integral on the exam paper, punched it into my graphing calculator, wrote an arrow with “calculator” over it, then wrote the result.

I have a new project to store information from REST responses into an IRIS database. I’ll need to sync information from at least two dozen separate REST endpoints, which means creating nearly that many ObjectScript classes to store the results from those endpoints.

When using standard SQL or the object layer in InterSystems IRIS, metadata consistency is usually maintained through built-in validation and type enforcement. However, legacy systems that bypass these layers—directly accessing globals—can introduce subtle and serious inconsistencies.

For my hundredth article on the Developer Community, I wanted to present something practical, so here's a comprehensive implementation of the GPG Interoperability Adapter for InterSystems IRIS.

Every so often, I would encounter a request for some GPG support, so I had several code samples written for a while, and I thought to combine all of them and add missing GPG functionality for a fairly complete coverage. That said, this Business Operation primarily covers data actions, skipping management actions such as key generation, export, and retrieval as they are usually one-off and performed manually anyways. However, this implementation does support key imports for obvious reasons. Well, let's get into it.