InterSystems ObjectScript é uma linguagem de script que opera com dados, usando qualquer modelo de dados da Plataforma de Dados InterSystems (Objetos, Relacionais, Chave-valor, Documentos, Globais) e, desenvolve a lógica de negócios para aplicações de servidor na Plataforma de Dados InterSystems.
Estamos analisando o que precisamos fazer para migrar do uso atual de relatórios Zen para o InterSystems Reports. Um dos desafios para nós é descobrir maneiras de interagir programaticamente com os relatórios do InterSystems Reports a partir de rotinas ObjectScript. Existe uma API Java para isso, mas também é possível gerar um relatório do InterSystems Reports para um objeto stream em ObjectScript sem recorrer ao Java, utilizando um %Net.HttpRequest.
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'.
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.
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.
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.
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?
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?
Na época em que eu trabalhava como Engenheiro de Suporte ao Desenvolvedor no Worldwide Response Center (WRC) da InterSystems, ocasionalmente eu recebia casos envolvendo grandes acúmulos (backlogs) de mensagens em um ambiente de produção.
O cliente descobria que um subconjunto das mensagens enfileiradas não era mais útil e fazia uma pergunta semelhante a esta:
Existe uma prática recomendada (best practice) consagrada para abortar em massa mensagens na fila de um componente específico que correspondam a um conjunto específico de critérios?
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.
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.
No artigo anterior, usamos o pyprod para criar componentes de produção enquanto dependíamos da interface de usuário (UI) para a configuração da produção. Essa mesma produção agora pode ser definida inteiramente em Python:
from intersystems_pyprod import Production, ServiceItem, ProcessItem, OperationItem
iris_package_name = "HelloWorld"
class MyProduction(Production):
services = [
ServiceItem(
"MyServiceName",
"HelloWorld.MyService",
host_settings={"target": "MyProcessName"},
)
]
processes = [
ProcessItem(
"MyProcessName",
"HelloWorld.MyProcess",
host_settings={"target": "MyOperationName"},
)
]
operations = [
OperationItem("MyOperationName", "HelloWorld.MyOperation")
]
O IRIS 2026.1 trouxe as Partitioned Tables (tabelas particionadas) como uma nova opção para grandes conjuntos de dados. É uma excelente melhoria, pois padroniza esse recurso de forma nativa.
No entanto:
Já era possível atingir esse mesmo objetivo antes, atendendo aos requisitos e deixando espaço para a criatividade. Uma abordagem menos elegante, com um pouco mais de código e menos automatismos.
Geralmente, parece haver um uso generoso de ClassMethods no código ObjectScript. Espero que minhas próprias experiências não sejam representativas, mas aposto que são. Perdoe-me por revelar o final deste artigo, mas em resumo: não os use. A menos que você consiga apresentar um argumento bastante convincente de que precisa, simplesmente nunca os use.¹
O que é um ClassMethod? Em uma classe ObjectScript, você pode definir métodos de duas maneiras diferentes: em um Method (método de instância), você deve instanciar uma instância da classe para chamar o método; e em um ClassMethod (método de classe), você pode chamar o método sem instanciar a classe. Claro que, em um ClassMethod, você não tem acesso a nenhuma propriedade do objeto (porque não há objeto), mas pode acessar globais (afinal, elas são globais) e Parâmetros (que são constantes da classe).
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ê.