Estava montando uma Production com algumas Business Operations diferentes e percebi que os campos das mensagens se repetiam. RequestCode, Payload, SourceSystem apareciam em praticamente todo request que eu criava. A tentação foi imediata: fazer uma classe genérica, reutilizar em todo lugar e seguir em frente.

Mas aí bati em uma dúvida real: isso era uma boa prática ou era preguiça disfarçada de reaproveitamento?

Venho do C# e do .NET, onde essa discussão tem um paralelo bastante concreto: a escolha entre um DTO genérico compartilhado por vários endpoints e contratos específicos por fluxo.

Ao salvar o seguinte ClassMethod:

ClassMethod create() [ Language = python ] {

 print("python") 

}

o seguinte erro foi recebido: Compilation started on 06/03/2026 02:15:21 with qualifiers 'cuk /multicompile=0'

 ERROR #7802: Worker job/s '1078:17' unexpectedly shut down in group '#Default:(9119826733444):0'.

 ERROR #7802: Worker job/s '1078:17' unexpectedly shut down in group '#Default:(9119826733444):0'.  

Com as flags de compilação "cuk", o retorno é:

ERROR #7802: Worker job/s '1160:34' unexpectedly shut down in group '#Default:(6933525859080):0'.

Olá, Comunidade!

Temos o prazer de compartilhar um novo vídeo do nosso InterSystems Developers YouTube:

⏯  Query Optimization in Hybrid Databases @ Ready 2025

Vou compartilhar algumas das coisas que acho muito úteis no VS Code, depois de muitos anos desenvolvendo no Studio.

A primeira e mais óbvia para mim é o fato de ele não travar no meio do desenvolvimento quando perde a conexão com a rede por algum motivo, te forçando a reiniciar o Studio e correndo o risco de perder código valioso. Também acho o VS Code muito mais rápido que o Studio, e a interface de usuário muito melhor, com inúmeras formas de personalizá-la ao seu gosto.

Na França, usamos nomes de animais de fazenda para nossos ambientes de desenvolvimento e teste.

Há algumas semanas eu estava tentando entender por que uma mensagem enviada por uma Business Service não chegava do jeito esperado na Business Operation. No Management Portal eu conseguia ver a mensagem entrando na fila e, mais tarde, uma entrada no Event Log dizendo que algo tinha saído errado. Entre esses dois pontos, porém, eu não enxergava nada. A mensagem passava pela Business Process, sofria alguma transformação no meio do caminho, e o resultado final não batia com o que eu esperava. Eu simplesmente não sabia em qual dos três componentes o problema estava.

Introdução

Na semana passada eu estava criando a terceira Business Operation do mesmo projeto de integração e parei no meio do código com uma sensação familiar. Eu já tinha escrito aquele trecho antes. A montagem dos headers HTTP (Content-Type, Authorization com o token) e o parsing da resposta JSON apareciam praticamente idênticos nas três classes. Só mudava o endpoint e o corpo da requisição.

Em C#, essa situação tem solução óbvia para mim. Eu extrairia esse comportamento para uma classe de serviço e injetaria ela onde precisasse, ou criaria uma classe base com os métodos comuns.

Olá pessoal,

Eu exportei uma Production do namespace de produção (live) e tentei importá-la no namespace de TEST pelo Management Portal, atualizando o Test a partir do Live. O problema é que não consigo fazer o deploy no test porque algumas queries usam tabelas legadas que não existem mais, nem mesmo no nosso sistema de produção atual.

Então, existe alguma forma de copiar a production entre os sistemas pulando o processo de compilação no Deployment?

Obrigado

Uma das principais diferenças é o sistema de plugins. No VS Code, tudo é construído em torno de extensões. Por exemplo, para desenvolvimento InterSystems, existe o "InterSystems ObjectScript Extension Pack", que inclui as ferramentas essenciais. Com esse plugin você pode se conectar a servidores InterSystems, navegar pelo código, editar classes, compilar e trabalhar com ObjectScript diretamente do VS Code.

E não é só para ObjectScript. O VS Code também suporta Git, Docker, clientes REST, YAML, JSON, Python e muitas outras tecnologias.

Como parte de um esforço para melhorar a velocidade de ingestão de payloads FHIR, na v2026.2 (já disponível como Developer Preview), estamos introduzindo uma opção para pular a validação estrutural de recursos. Isso pode economizar, por exemplo, 25% do tempo, o que em ingestões de larga escala pode ser significativo.

Eu tinha uma mensagem chegando numa Production e três destinos possíveis. Dependendo de um campo do request, ela precisava seguir para uma Business Operation diferente. Abri o meu Business Process, escrevi um IF, um ELSEIF e um ELSE, apontei cada caminho para a operação certa, compilei e testei. Funcionou de primeira. A dúvida veio alguns minutos depois, quando parei para olhar o que eu tinha feito e me perguntei se aquela decisão deveria mesmo morar ali dentro.

Foi essa pergunta que acabou virando um post na comunidade, e foi a partir das respostas que recebi que escrevi este artigo.

Olá Comunidade,

As ferramentas de Inteligência Artificial estão se tornando parte do dia a dia de muitos desenvolvedores, e estou curioso para saber como outras pessoas estão usando essas ferramentas dentro do ecossistema InterSystems.

Vocês estão usando IA para:

- Gerar código ObjectScript?
- Resolver erros?
- Escrever documentação?
- Escrever documentação?
- Aprender novas tecnologias InterSystems mais rápido?

Tenho percebido que a IA pode ser uma ferramenta útil de produtividade, mas estou interessado em ouvir experiências reais da comunidade.

Introdução

No .NET, serializar um objeto para JSON virou para mim um problema resolvido. Eu decorava a classe com alguns atributos, chamava JsonSerializer.Serialize ou JsonConvert.SerializeObject, e seguia em frente. Raramente eu parava para pensar no que acontecia embaixo.

Quando comecei a mexer com integrações no IRIS durante o estágio na Shift, encontrei o %JSON.Adaptor e tive uma sensação familiar: parecia o mesmo atalho. Você faz a classe herdar de , ganha %JSONExport() e , e o objeto vira JSON. A pergunta que não saiu da minha cabeça foi outra: até onde isso vai?

Tenho uma Business Operation chamando um método SOAP via InvokeMethod, passando vários parâmetros individuais. A chamada retornou $$$OK sem nenhum SoapFault, mas o objeto de saída voltou indefinido, causando um erro quando tentei utilizá-lo.

Descobri que o método do WebClient gerado havia sido refatorado para aceitar um único objeto de requisição em vez de parâmetros individuais - então minha chamada já não correspondia mais à assinatura.

Introdução

Estava configurando uma Business Operation dentro de uma Production no Portal de Gerenciamento, no meu estágio. Preenchi host, porta, um caminho de arquivo e o endpoint de um serviço externo. Tudo certo, a Production subiu. O problema veio um minuto depois, quando pensei em levar aquilo para o ambiente de teste. No .NET, esse pensamento nem chega a virar pergunta: eu teria um appsettings.Test.json com os valores de teste e pronto. Fui procurar o equivalente no IRIS e não achei.

Quando comecei a trabalhar com Productions no InterSystems IRIS, achei que entendia bem os papéis de cada componente. O Business Service recebe a mensagem do mundo externo. O Business Process coordena o fluxo. O Business Operation entrega o resultado. Parecia simples.

Aí veio a primeira dúvida real: se eu preciso validar uma mensagem antes de rotear, onde essa validação deve ficar? No Business Service, antes de enviar para frente? Ou no início do Business Process, que é quem vai decidir o que fazer com ela?

Durante minhas primeiras semanas estudando IRIS, cheguei a um momento que mudou bastante minha forma de olhar para essa plataforma. Eu estava explorando uma classe persistente simples, daquelas que a gente cria seguindo qualquer tutorial introdutório, e decidi abrir o Management Portal para ver como os dados estavam armazenados de fato. Esperava encontrar algo parecido com uma tabela do SQL Server, com linhas e colunas bem definidas. Em vez disso, encontrei uma global.

Para quem vem do modelo relacional, como é o meu caso, isso quebra um pouco a intuição.

Há um aumento constante na quantidade de metadados que preciso construir no fluxo de mensagens (entre BPs e DTLs) e estou interessado em um bom padrão a seguir que permita uma mistura de tipos de metadados (ex.: json, lista xml, etc.) e que seja acessível rapidamente tanto dentro de DTLs quanto de BPs.

Um exemplo disso seria adicionar diversos conjuntos de códigos localizados aos metadados durante os DTLs, que seriam usados posteriormente para enviar uma solicitação de tradução FHIR para um servidor de terminologia.

Olá pessoal!

Suponha que uma nova versão da sua incrível solução de software construída sobre o IRIS precise de alguma mudança de persistência: alguns dados precisam ser convertidos, algumas classes recebem novas propriedades ou até são renomeadas, e alguns dados devem ser pré-populados para classes persistentes recém-introduzidas, para manter toda a base de dados da aplicação consistente.

Quais são as abordagens de vocês?

Scripts baseados em SQL? ObjectScript, ou Python? Para as duas direções da migração, up e down?

Vocês geram isso automaticamente com Claude/Codex?

Olá!

Estou tentando compilar uma classe com Embedded Python e recebo este erro:

Compilation started on 06/12/2026 11:44:17 with qualifiers 'cuk'
Compiling class User.VectorSearch
ERROR #7802: Worker job/s '749:33' unexpectedly shut down in group '#Default:(446070926892):0'.
ERROR #7812: Work queue unexpectedly removed, shutting down.
ERROR #5002: ObjectScript error: <THROW>WaitForComplete+215^%SYS.WorkQueueMgr *%Exception.StatusException ERROR #7802: Worker job/s '749:33' unexpectedly shut down in group '#Default:(446070926892):0'.
ERROR #7812: Work queue unexpectedly removed, shutting down.
Detected 3 errors during compilation in 1.020s.

Introdução

Quando comecei a trabalhar com InterSystems IRIS no meu estágio, o primeiro obstáculo não foi o banco de dados nem a arquitetura da plataforma. Foi a linguagem em si. Olhei para o ObjectScript (COS) pela primeira vez e não consegui ler o que estava na tela. Parecia familiar o suficiente para me dar confiança, e diferente o suficiente para me confundir logo em seguida.

Venho do C# e do .NET, com foco em arquitetura em camadas, Windows Forms e SQL Server.

Assim como no pacote anterior, tudo roda a partir de uma página CSP. O código é todo escrito no estilo clássico de CSP, usando InterSystems ObjectScript, JavaScript e HTML.
Além do gráfico, você também obtém números concretos coletados em tempo real da sua instância local ou de instâncias remotas que também tenham o pacote instalado. 

O resultado final

As etapas do processamento

• Uma página CSP é chamada pela sua URL
• No método OnPreHTTP
  • A System Query preenche a tabela temporária a partir do %SYS
  • Se o parâmetro de URL correto for fornecido: 

Introdução

Quando comecei meu estágio com foco em desenvolvimento usando InterSystems IRIS, uma das primeiras dificuldades que encontrei foi justamente a configuração do ambiente local. Documentações técnicas, instaladores e extensões — parecia muita coisa para ligar ao mesmo tempo.

Se você está chegando agora ao ecossistema InterSystems, possivelmente com background em outra linguagem (C#, Java, PHP, ou qualquer outra), este artigo é para você.

Recentemente comecei a usar o Cursor/VSCode com um container IRIS para desenvolvimento, em vez do Studio/Terminal.

Percebi que sempre que uso o %G (ou seja, praticamente o tempo todo), ao sair do %G, a janela do terminal simplesmente fecha, em vez de me retornar ao prompt do namespace habitual.
O %G também não mantém o histórico de comandos como acontece no terminal antigo, então sou obrigado a redigitar constantemente cada referência de global.

Alguém encontrou uma solução para isso? É um problema relativamente pequeno no geral, mas consome tempo e é irritante.

Olá, Comunidade,  

Qual é a maneira mais eficiente e segura em termos de memória para obter os nomes dos índices corrompidos em tabelas muito grandes, a fim de reconstruí-los? O problema é que, se um índice possui milhões de linhas corrompidas, o array .errors do %ValidateIndices cresce demais e lança um erro .

Entrada do #North American Demo Showcase . 

>>Responda a pergunta abaixo para participar do sorteio!

⏯️ Health Galaxy: Habilitando IA em Aplicações de Saúde 

O Health Galaxy cria um ponto de acesso com IA sobre qualquer servidor FHIR, trazendo a área da saúde para o futuro da inteligência artificial, uma realidade que já chegou a muitos outros setores.

• Acesso via IA: O Health Galaxy oferece aos agentes de IA um único gateway para qualquer sistema de saúde, permitindo que eles consultem dados de pacientes, agendem consultas e verifiquem planos de saúde automaticamente, sem necessidade de intervenção humana manual.
• Facilidade de uso: Basta apontar para um endpoint FHIR existente, clicar em um botão, e o sistema gera automaticamente um endpoint MCP a partir do capability statement. 
• FHIR: Por utilizar FHIR, é possível aproveitar tanto as capacidades de armazenamento quanto as de troca de dados do InterSystems IRIS.

🗣 Apresentador: @Zelong Wang, Engenheiro de Vendas na InterSystems

Mais um passo nessa jornada: IrisCluster distribuído entre múltiplas nuvens e regiões com Mirroring + Disaster Recovery usando o Intersystems Kubernetes Operator (IKO) e Tailscale

Embora seja algo relativamente simples, quero ir multi-cloud com o IrisCluster distribuído por algumas razões — para demonstrar o poder do WireGuard quando ele fornece a rede para um IrisCluster devidamente zonificado, adicionando mais um papel de mirror na Amazon Web Services no datacenter da costa oeste dos Estados Unidos, em Oregon.