New post

Find

Article
· 12 hr ago 4m read

templated_emailを使ったInterSystems IRISでの動的テンプレートメール


メール送信は、統合シナリオでは一般的な要件です。クライアントへのリマインダー、自動レポート、トランザクション確認などに使用されます。 固定メッセージは、管理やパーソナライズが難しくなりがちです。 そこで登場するのが templated_email モジュールです。InterSystems IRIS InteroperabilityをJinja2テンプレートの機能を組み合わせます。

メール作成でJinja2を選ぶ理由

Jinja2はPythonエコシステムで人気のあるテンプレートエンジンで、完全に動的なコンテンツ生成を可能にします。 次をサポートします:

  • 変数 — 統合メッセージや外部ソースから動的にデータを取り込みます
  • 条件(if/else)— ランタイムデータに基づいてコンテンツを変更します
  • ループ(for)— テーブル、項目リスト、反復セクションを生成します
  • フィルターとマクロ — 日付や数字のフォーマット、テンプレートブロックを再利用します

簡単なメール本文テンプレートの例:

Discussion (0)0
Log in or sign up to continue
Article
· 19 hr ago 2m read

IRIS BI Dependent Cube Update Changes

Starting with InterSystems IRIS 2025.1, the way dependent cubes are handled in cube builds and cube synchronizes was changed.

This change may require modifying custom build/synchronize methods. If you are using the Cube Manager, these changes are already considered and handled, which means no action is needed.

Prior to this change, cubes were required to be built and synchronized in the proper order and account for any cube relationships/dependencies. With this change, dependent cubes are automatically updated as needed when using the %BuildCube or %SynchronizeCube APIs.

The negative symptom you may see if you have a custom build method would be that your dependent cubes may be built multiple times. This should not cause any errors, but it may mean your builds take considerably longer depending on how many dependent cubes you have.

The biggest consideration in modifying your custom build/synchronize methods is that the first parameter of %BuildCube and %SynchronizeCube now accept a list of cube names. Dependencies in this list will be resolved so they are not built multiple times.

Example using old logic:

do ##class(%DeepSee.Utils).%BuildCube("relatedcubes/cities")
do ##class(%DeepSee.Utils).%BuildCube("relatedcubes/doctors")
do ##class(%DeepSee.Utils).%BuildCube("relatedcubes/patients")
do ##class(%DeepSee.Utils).%BuildCube("relatedcubes/cityrainfall")
do ##class(%DeepSee.Utils).%BuildCube("relatedcubes/allergies")

Calling the cube builds like this will trigger dependent builds multiple times. This results in the following cube builds happening:

Building cube [RELATEDCUBES/CITIES]
Building cube [RELATEDCUBES/CITYRAINFALL]
Building cube [RELATEDCUBES/DOCTORS]
Building cube [RELATEDCUBES/PATIENTS]
Building cube [RELATEDCUBES/ALLERGIES]
Building cube [RELATEDCUBES/DOCTORS]
Building cube [RELATEDCUBES/PATIENTS]
Building cube [RELATEDCUBES/ALLERGIES]
Building cube [RELATEDCUBES/PATIENTS]
Building cube [RELATEDCUBES/ALLERGIES]
Building cube [RELATEDCUBES/CITYRAINFALL]
Building cube [RELATEDCUBES/ALLERGIES]

Example using updated logic:

do ##class(%DeepSee.Utils).%BuildCube($LB("relatedcubes/cities","relatedcubes/doctors","relatedcubes/patients","relatedcubes/cityrainfall","relatedcubes/allergies"))

This will simply build the cubes in a dependency-compliant order:

Building cube [RELATEDCUBES/CITIES]
Building cube [RELATEDCUBES/CITYRAINFALL]
Building cube [RELATEDCUBES/DOCTORS]
Building cube [RELATEDCUBES/PATIENTS]
Building cube [RELATEDCUBES/ALLERGIES]

 

The documentation’s “Upgrade Considerations” page references this compatibility change: https://docs.intersystems.com/iris20251/csp/docbook/DocBook.UI.Page.cls?KEY=GUPE_upgrade#GUPE_upgrade_buildcube

Discussion (0)1
Log in or sign up to continue
Announcement
· 22 hr ago

[Video] How Big Research Bets Are Made Without a Crystal Ball

Hey Community!

We're happy to share the next video in the "Code to Care" series on our InterSystems Developers YouTube:

⏯  How Big Research Bets Are Made Without a Crystal Ball

Learn how research organizations set priorities without relying on precise future predictions, about the concept of “inevitable futures” as a way to ground long-term research decisions in real-world trends, with examples drawn from healthcare and demographic change. Hear about a structured framework for balancing short-term problem solving, long-term exploration, disruptive innovation, and sustained improvement across multiple domains.

Presenters: 
🗣 @Don Woodlock, Head of Global Healthcare Solutions, InterSystems
🗣 Dr. Peter Lee, President, Microsoft Research

Enjoy watching, and subscribe for more videos! 👍

Discussion (0)1
Log in or sign up to continue
Article
· Jan 21 3m read

Usando o Postman para testar o OAuth2.0 do repositório InterSystems FHIR - Parte 2

Olá, agora gostaria de continuar com o tópico que discutimos anteriormente

Usando o Postman para testar o OAuth2.0 do repositório InterSystems FHIR - Parte 1

 


Pergunta 1: De onde vêm meu client_id e meu client_secret?

Resposta curta: Do Servidor de Autenticação.

 

Se você não possui um Servidor de Autenticação, pode configurar um da seguinte forma:

 

Forneça o hostname (o host deve suportar Https), pelo menos 1 tipo de concessão (escolhemos client credential aqui) e a configuração SSL/TLS

 

Insira os escopos (aqui inserimos user/.read e user/.write, que são baseados no suporte de escopo do servidor FHIR (servidor de recursos)). Caso haja algum escopo que esquecemos, marque "Allow unsupported scope".

 

Na configuração de JWT, escolha RS256 (este é apenas um exemplo, você pode escolher o que melhor se adapta à sua arquitetura)

 

Altere a Generate token class para %OAuth2.Server.JWT. E atualize o namespace se necessário.

Salve a configuração

 


Pergunta 2: Como verificar o client_id e o client_secret vindos do Servidor de Autenticação?

Resposta curta:  Configure um Cliente OAuth2.0 (se não tiver um) e crie um cliente

 

Abaixo estão as etapas para configurar um Cliente OAuth 2.0.

 

Clique em Create Server Description

 

 

Insira o Issuer end point e a configuração SSL/TLS aqui

e clique em Discover and Save

 

 

Você pode encontrar as informações relacionadas na página de configuração do Servidor OAuth2.0

 

 

Após o Discover and Save, você verá algo semelhante ao abaixo. Podemos precisar dar uma olhada no token endpoint, que precisaremos para solicitar um token

 

 

Após a configuração acima, agora é hora de criarmos um cliente chamado Postman 😁

Clique no botão OAuth 2.0 Client

 

 

Clique em Client Configurations

 

 

Clique em Create Client Configuration

 

 

Insira o Application name e o Client name, escolha o Client type confidential, insira o Hostname for the Client redirect URL e escolha o Required grant types como Client credentials

Clique em Dynamic Registration and Save

 

 

Você verá algo semelhante ao seguinte.

Agora, é hora de verificar nosso client_id e client_secret😁😁

Clique na aba Client Credential

 

 

Você pode copiar seu client_id e client_secret aqui 😉

 

 

 


Pergunta 3: Como adicionar meu servidor FHIR como um servidor de recursos e relacioná-lo ao Servidor de Autenticação?

Resposta curta:  Configure um Cliente OAuth2.0 (se não tiver) e crie um servidor de recursos. Em seguida, aplique o servidor de recursos à configuração do servidor FHIR

 

 

Para criar um servidor de recursos

 

 

Clique em Client Configurations

 

 

Clique em Create Client Configuration

 

 

Insira o Application name e o Client name, escolha o Client Type Resource Server

Clique em Dynamic Registration and Save

 

 

Agora que o Servidor de Recursos está configurado, devemos aplicá-lo ao servidor FHIR

Vá para Health

 

 

Depois, FHIR Server Management

 

 

Escolha o servidor FHIR para Editar (Edit)

 

 

Na aba FHIR Server Authorization Setting, escolha o OAuth Client Name na lista e Salve

 

Uhuuu!! Acho que isso é tudo o que precisamos para configurar nosso servidor InterSystems FHIR com a funcionalidade OAuth😁

 

 


Para testar com o Postman, você pode consultar o artigo anterior

Usando o Postman para testar o OAuth2.0 do repositório InterSystems FHIR - Parte 1

Muito obrigado pela leitura!😆😀

Discussion (0)1
Log in or sign up to continue
Article
· Jan 21 2m read

Archiving my OEX packages

Over the last 9 years, I published more than 90 packages in OEX.
And over this time, conditions and environments changed.
In the beginning, there was

  • no Docker
  • no IPM/ZPM
  • no embedded Python, no AI
  • Caché, Ensemble, CSP, ZEN, .... were dominating

As time changed, also product versions and external languages changed.
Adjustment of a few packages was no issue in the beginning,
and was a matter of support quality to my "consumers".

With the actual volume, I see no way to keep this target up for all my packages.
and based on the quality checks, I have the impression it is not just my problem.
Recent changes caused enough issues just by version updates.

So I proposed the Idea of a DEPRECATED label to OEX packages

It would be fair to signal to other users of OEX that there is no
intention to do any maintenance for a package.
Also, as a kind of warning, if it is used.

In addition, a DEPERCATED package should be free for
adoption and reworking, and eventually fixing
by some other member of the community.

There was almost no echo. 
Actually, my only option was to unpublish it. ~90 packages in total.
A lot of once well-working code was unavailable that could be an
example for beginners or a source of some tricks.
So I changed my mind and marked packages that could be useful,

 no maintenance or update

As a temporary workaround, also using GitHub Archiving feature
to prevent changes by accident. 

So I expect most of these 90 packages to reappear over time.
And with them also all comments and related articles.
I understand this as a kind of museum to show how easy
or complicated the environment once was. 
And without ignoring past achievements.
 

Discussion (0)2
Log in or sign up to continue