O lançamento mais recente do Serenji apresenta nossa inovadora tecnologia gj :: locate. Era uma ferramenta autônoma que criamos originalmente para um concurso da Comunidade de Desenvolvedores no início deste ano, mas nós a incorporamos em nosso depurador após alguns ótimos comentários dos desenvolvedores.

Ele funciona navegando diretamente para a fonte de seus erros do lado do servidor em apenas alguns cliques - permitindo que você corrija os erros rapidamente sem a necessidade de contar linhas tediosas de código ... e sejamos realistas, quem tem tempo para que quando você está sob pressão para consertar esse bug?

É simples e fácil de usar:

1. Clique no painel gj :: locate na barra de status

2. Insira a mensagem de erro do ObjectScript ou a referência de linha de uma rotina class / .mac.

3. gj :: locate então faz o trabalho para você, levando-o diretamente para a linha correspondente em seu código-fonte.

Muito fácil ... e com tempo de sobra para fazer um café antes do prazo!

Abaixo há um link do vídeo que mostra isso em ação - diga-nos se você já tentou. Ou, se você estiver interessado em experimentá-lo, oferecemos uma licença de avaliação gratuita de 30 dias, apenas me mande uma mensagem através da Comunidade de Desenvolvedores ou envie um e-mail para info@georgejames.com.

Serenji 3.2.0 utilising gj::locate technology

Olá Comunidade!

Quero apresentar a você um novo recurso poderoso do objectscriptQuality, nosso analisador de código estático.

Cada vez que uma nova versão do IRIS é lançada, você precisa preparar um roadmap para a migração, gastando muito tempo em testes para descobrir onde o seu código não funciona com a versão mais recente. Ou, talvez, você precise que o seu código seja compatível com várias versões do IRIS ou Caché.

Olá desenvolvedores!

Só quero compartilhar uma prática recomendada antiga, mas sempre relevante, sobre a alteração de namespaces @Dmitry Maslennikov compartilhada comigo (de novo).

Considere o método:

classmethod DoSomethingInSYS() as %Status

{

set sc=$$$OK

set ns=$namespace

zn "%SYS"

// try-catch in case there will be an error

try {

// do something, e.g. config change

}

catch {}

 zn ns    ; returning back to the namespace we came in the routine

return sc

}

E com o novo $namespace, o método pode ser reescrito como:

classmethod DoSomethingInSYS() as %Status

{

set sc=$$$OK

new $namespace

set $namespace="%SYS"

// do something

return sc

}

Então! A diferença é que não precisamos alterar o namespace manualmente, pois ele voltará automaticamente assim que retornarmos o método.

e não precisamos do try-catch (pelo menos para esse propósito) também.

O InterSystems IRIS 2019.1 já foi lançado há algum tempo e gostaria de abordar algumas melhorias para lidar com JSON que podem ter passado despercebidas. Lidar com JSON como um formato de serialização é uma parte importante da construção de aplicativos modernos, especialmente ao interagir com terminais REST.

Recentemente, eu queria obter uma lista de todas as consultas em cache e seus textos. Veja como fazer isso.
Primeiro, crie um procedimento SQL retornando texto de consulta de cache a partir de um nome de rotina de consulta em cache:

Uma VIEW em SQL é basicamente uma instrução SQL preparada.
Deve ser executado e montado como qualquer outra consulta SQL.
VIEW MATERIALIZADA significa que o conteúdo é coletado antes das mãos e pode ser recuperado com bastante rapidez.
Eu vi o conceito primeiro com meu concorrente favorito chamado O * e eles fizeram muito barulho sobre isso.

{ favorite: because I could win every benchmark against them }

Migrando do Java Business Host para o PEX

Introdução

Suponha que você desenvolveu uma nova aplicação utilizando a parte de Interoperabilidade do InterSystems IRIS e você tem certeza de que será um sucesso! No entanto, você ainda não tem um número concreto de quantas pessoas irão utilizá-la. Além disso, pode haver dias específicos em que há mais pessoas utilizando sua aplicação e dias em que quase ninguém irá acessar. Deste modo, você necessita de que sua aplicação seja escalável!

O mesmo serviço com a possibilidade de receber várias consultas SQL diferentes e sempre entregar o resultado independente de quantas colunas distintas tenham essas diferentes consultas. Aqui demonstro como pode ser possível montar esse tipo de serviço utilizando o Service Bus da Intersystems.

Possível cenário (Desconsiderar o uso de um BI):

Vamos pensar em um painel real time onde iremos fornecer as informações de consumo de um material por região para o setor de compras e teremos as informações do nome do produto, fabricante e quantidade por exemplo.

Além do IntelliJ IDEA, agora é possível configurar o SublimeText3 para poder compilar o código lá também. E o que você precisa é apenas do servidor de idioma que eu usei.

Uma coisa interessante sobre informação é que sempre podemos descobrir algo novo.

Partindo com essa ideia em mente, nós criamos uma nova página, para exibir um pouco mais sobre o universo ZPM!

Houve alguns artigos muito úteis na comunidade que mostram como usar o Grafana com IRIS (ou Cache/Ensemble) usando um banco de dados intermediário.

Mas eu queria chegar diretamente às estruturas IRIS. Em particular, eu queria acessar os dados do monitor de histórico do cache que podem ser acessados por SQL, conforme descrito aqui

https://community.intersystems.com/post/apm-using-cach%C3%A9-history-mon...

E não queria nada entre mim e os dados.

Se você precisar escrever a Arquitetura de Dados de sua organização e mapear para o IRIS da InterSystems, considere o seguinte Diagrama de Arquitetura de Dados e referências à documentação da íris entre sistemas, consulte: