New post

Find

Announcement
· Apr 8

Online Meetup with the Winners of the AI Programming Contest

Hi Community,

Let's meet at the online meetup with the winners of the AI Programming Contest: Vector Search, GenAI and AI Agents! It's a great opportunity to chat with the InterSystems Experts team and our contestants.

Winners' demo included!

Date & Time: Thursday, April 10, 12:00 pm EDT | 6:00 pm CEST

Join us to learn more about winners' applications and to have a talk with our experts.

➡️ REGISTER TODAY

See you all at our virtual meetup! 

1 Comment
Discussion (1)2
Log in or sign up to continue
InterSystems Official
· Apr 8

Alerte : InterSystems IRIS 2024.3 – Problème d'analyse JSON AIX et incompatibilités IntegratedML

Résumé des alertes

Alert ID Produit et versions concernés Exigences explicites
DP-439207 Plateforme de données InterSystems IRIS® 2024.3 (AIX) Installations AIX utilisant le traitement JSON et les caractères Unicode non-Latin-1
DP-439280 InterSystems IRIS 2024.3 (conteneurs avec IntegratedML) Conteneurs IntegratedML utilisant TensorFlow

 

Détail des alertes

DP-439207 - Problème d'analyse JSON Unicode AIX

Un bug a été identifié dans InterSystems IRIS 2024.3.0 sur les instances AIX. Il affecte l'analyse des chaînes JSON Unicode. Ce problème survient lorsque la méthode %FromJSON() ou %FromJSONFile() analyse des chaînes contenant des caractères dont la valeur est inférieure à $CHAR(256) suivis de caractères Unicode dont la valeur est supérieure à $CHAR(255). Le processus de conversion transforme incorrectement les premiers caractères en $CHAR(0), ce qui entraîne une corruption silencieuse des données. Ce problème concerne uniquement la version AIX 2024.3 des produits suivants :

  • InterSystems IRIS
  • InterSystems IRIS for Health
  • HealthShare® Health Connect

Évaluation d'impact

  • Dans ce cas, des caractères incorrects peuvent être stockés dans la base de données ou transmis aux interfaces sans générer d'erreur.
  • Le défaut a été introduit dans IRIS 2024.3.0 et a été résolu avec DP-439207.
  • Workflows concernés : Ce problème se produit uniquement sur les installations Unicode exécutant AIX et affecte les applications traitant des données contenant un mélange de caractères ASCII et Unicode.

Résolution

Si vous utilisez InterSystems IRIS 2024.3.0 sur des instances AIX, vous devez effectuer la mise à niveau vers InterSystems IRIS 2025.1.0 dès que possible.

Actions requises

  1. Identification des systèmes concernés :
  • Déterminez si vous exécutez InterSystems IRIS 2024.3.0 sur une instance AIX avec des bases de données Unicode et si vous utilisez un mélange de caractères Unicode et non Unicode.
  1. Mise à niveau :
  • Procédez à la mise à niveau vers InterSystems IRIS 2025.1.0 dès que possible.

DP-439280 - Problèmes TensorFlow du conteneur IntegratedML

Les clients utilisant l'une des versions conteneurisées suivantes d'IRIS 2024.3 peuvent rencontrer des erreurs d'apprentissage lors de l'utilisation d'IntegratedML.

containers.intersystems.com/intersystems/iris-ml:2024.3

Évaluation d'impact

  • Les clients utilisant IntegratedML sur les conteneurs IRIS 2024.3 fournis par InterSystems rencontreront des échecs d'apprentissage du modèle en raison de problèmes de compatibilité avec TensorFlow et les dépendances associées.

Résolution

  • Les clients souhaitant utiliser IntegratedML avec IRIS ou IRIS for Health dans des conteneurs sont encouragés à créer leurs propres conteneurs en suivant les conseils publiés sur la communauté des développeurs.

Actions requises par le client

  • Pour continuer à utiliser IntegratedML avec AutoML, les clients doivent gérer manuellement les dépendances à l'aide du gestionnaire de paquets pip, comme décrit ci-dessus. Cela garantit la compatibilité et le bon fonctionnement des composants AutoML tels que scikit-learn dans votre environnement Python IntegratedML.

Pour plus d'informations

Si vous avez des questions ou avez besoin d'aide, veuillez contacter le InterSystems Worldwide Response Center (WRC).

Discussion (0)1
Log in or sign up to continue
Article
· Apr 8 5m read

Lifting InterSystems IRIS to the Cloud: Migration Options

Migrating InterSystems IRIS and InterSystems IRIS for Health from on-premises to the cloud offers many advantages for Application Providers and Solution Providers. These advantages include simplified operations, access to flexible resources, and enhanced resilience. Companies no longer need to worry about the physical constraints and expenses associated with maintaining on-prem infrastructure, such as power and space requirements and expensive computer hardware.

One of the most compelling benefits is the ability to accelerate speed to market. By removing the burden of infrastructure maintenance, cloud environments enable faster development and deployment cycles, allowing businesses to respond quickly to market demands and opportunities. Operational costs are also lowered, because companies can scale resources up or down based on actual needs, leading to more efficient use of capital. Moreover, migrating to the cloud can contribute to a reduced carbon footprint by optimizing energy usage through shared cloud infrastructure.

Transitioning to the cloud may involve significant changes. Companies may benefit from a more operational focus, managing and optimizing cloud resources continuously. This shift may require changes to business models, reconsideration of margins, and strategies for scaling operations up or out. While requiring more investment, embracing these changes can lead to improved agility and competitive advantage in the marketplace.

Architectural Choices in Cloud Migration

When considering the simplest cloud migration, lifting an existing on-premises application to one of the public clouds requires companies to choose one or more services (AWS, Azure, Google, or another). Companies then face an important architectural choice: migrate entirely to the cloud or create a prem-to-cloud hybrid cluster. Both InterSystems IRIS and InterSystems IRIS for Health fully support either option. A hybrid cluster mirrors the on-prem instance to the cloud asynchronously. This alternative can be helpful in situations such as when the OLTP continues to run on-prem, but the cloud instance provides support for analytics, reporting, and other read-only operations.

Migration Options

Each architectural choice for cloud migration has advantages and limitations,  making it essential for companies to evaluate their specific needs and goals when planning a cloud strategy. The first step is to choose between a full move to the cloud or a hybrid setup.

Migration choice Number of  InterSystems IRIS deployments after migration Characteristics
Lift & Shift: full move to cloud 1 Local on-premises setup moved to a cloud-based architecture
Hybrid Cluster: on-prem plus cloud mirror copy (“stretch cluster”) 2 On-premises cluster mirrored to an asynchronously updated, read-only cloud copy

The Lift & Shift choice allows leveraging of cloud benefits while maintaining ownership of a single copy of InterSystems IRIS.

The Hybrid choice combines the stability and familiarity of on-premises systems with the flexibility and scalability of the cloud.

See our online documentation for more information on Mirroring.

Multi-Tenant vs. Single Tenant Architecture with InterSystems IRIS

Although migration does not require changes to your tenancy method, the cloud offers powerful options for scaling and billing. For this reason, you may want to re-evaluate your tenancy model. For any of our offerings, when deploying InterSystems IRIS applications in the cloud, companies can choose between the following architectures for multiple customers:

  • Single Tenant: Multiple deployments; one for each of your customers.
  • Multi-Tenant: Multiple customers on a single deployment.

Each architecture offers distinct advantages and drawbacks. This is especially important for application and solution providers with solutions built with InterSystems IRIS technology that have large numbers of customers, are destined for major expansion, or that house sensitive or regulated data.

Scaling of Resources and Operations

  • Multi-Tenant: Scaling a multi-tenant environment involves adding resources to a single shared instance for each customer (tenant), which can be more cost-effective and simpler to manage. However, the performance of one tenant can affect others if adequate resources are not allocated, leading to resource contention.
  • Single Tenant: Scaling a single tenant environment means provisioning more resources for each customer individually. While this offers more predictable performance, the need for additional infrastructure and management overhead can make this choice more complex to scale.

Isolation of Data

  • Multi-Tenant: In a multi-tenant configuration, multiple tenants share the same instance of the application and database. Data isolation is achieved through softwarelevel partitioning, ensuring that each tenant’s data remains secure and separate from others. This approach can be efficient in its use of resources but can require robust security measures to prevent data breaches.
  • Single Tenant: With a single tenant architecture, each customer has a separate instance of the application and database. This setup provides a higher level of data isolation, as each tenant’s data resides in a separate environment. This choice can be more secure and easier to manage, facilitating compliance with data protection regulations. 

Migration Methods

Multiple approaches are available to migrate your InterSystems IRIS solution from on-premises to the cloud service of your choice.

The two most common methods are described next. They both start with the same step of mirroring an existing deployment to the cloud, but then diverge.

Choosing Mirror or Lift-and-Shift

Both the mirror method and the lift-and-shift method start by copying your existing InterSystems IRIS from on-prem to a cloud platform. Once the cloud copy is synchronized with the on-prem instance, you make a final choice of where the migration path ends:

  • Mirror: Continue to use the on-prem instance as primary and the cloud instance for backup and read-only operations, like analytics and machine learning. The cloud instance is asynchronous but periodically updated.
  • Lift-and-Shift: With the on-prem primary instance and the cloud-based secondary instances now in sync, “fail over” operations from the on-prem instance to the cloud copy, which now becomes the primary subsequently for all operations (not just readonly). At that point, the on-prem deployment can be archived as a snapshot backup.

Mirroring your existing local InterSystems IRIS instance to the cloud is the most common, resilient, and straightforward way to migrate your on-prem deployment. For more information, see the Server Migration Guide in our online documentation.


More articles on the subject:

Source: Lifting InterSystems IRIS to the Cloud

Discussion (0)0
Log in or sign up to continue
Announcement
· Apr 8

Vídeos do InterSystems Developers, Recapitulação Março 2025

Olá e Bem-vindos a recapitulação do canal da Comunidade de Desenvolvedores no YouTube de Março de 2025.
 
InterSystems Global Summit
By Andreas Dieckow, Amy Farley
By Timothy Leavitt, Gerrit Henning, Stephan du Plooy
By Keren Skubach, Vic Sun, Steve Mallam
FHIR Object Model
By Patrick Jamieson, Jaideep Majumdar 
"Code to Care" vídeos
Is your data ready for AI?
By Don Woodlock, Head of Global Healthcare Solutions, InterSystems
Energy Consumption for AI
By Jessica Jowdy, Manager of Healthcare Sales Engineering, InterSystems
Mais de Desenvolvedores InterSystems 
[Hebrew Webinar]: GenAI + RAG - Leveraging Intersystems IRIS as your Vector DB
By Ariel Glikman, Sales Engineer InterSystems Israel
A better way of buidling index for IRIS
By Mihoko Iijima, Training Sales Engineer, InterSystems
Quick wins with InterSystems IRIS Vector DB
By Vivian Lee, Applications Developer, InterSystems
Building and Deploying React Frontend for the InterSystems FHIR server in 20 minutes with Lovable AI
By Evgeny Shvarov, Senior Manager of Developer and Startup Programs, InterSystems
Unlocking Hands-On Learning with Instruqt
By Dean Andrews, Head of Developer Relations, InterSystems
Developer Ecosystem: Latest News
By Dean Andrews, Head of Developer Relations, InterSystems
Discussion (0)1
Log in or sign up to continue
Question
· Apr 8

Best Practices for Git Integration with Developer Namespaces in IRIS

Greetings,

Our team is transitioning to Git in the foreseeable future, and I'm trying to figure out how to design the best development workflow. Being new to IRIS, I am having trouble wraping my head around a few concepts.

Current Setup:

  • All code is hosted on a remote server
  • Each developer works in their own dedicated Namespace, on that server
  • Classes are locked to avoid conflicts
  • Committed code is imported into the Development NS, then redestributed to developers

Challenge:

Initially, I assumed we could replace this setup with Git Branches, following a typical workflow (one shared repository, developers work in feature branches, merge into staging). But I’ve realized that while branches isolate code, they do not isolate runtime environments the way namespaces do.

Question:

What are the architectural options here?

  • Is it common to assign one repository per namespace?
  • If so, how are changes across namespaces coordinated and merged into a staging or production namespace?
  • Has anyone transitioned from a "namespace-per-dev" model to Git, and how did you handle runtime vs. version control isolation?

Thanks in advance for any insight or examples of how this is typically done in real-world IRIS projects.

Edit: We're planning to use the git-source-control package (https://github.com/intersystems/git-source-control) and work with both, the deprecated Iris Studio and VSCode (based on Developer preference). This should also have some impact, as you cannot easily change branches within Studio if I understand correctly.

2 Comments
Discussion (2)4
Log in or sign up to continue