A tag de iniciante reúne artigos e perguntas para aqueles que estão começando com a InterSystems Data Platform
Quando precisamos integrar o Caché/IRIS com outros bancos de dados relacionais, uma pergunta comum surge: “Como configuro a conexão JDBC?”. A documentação oficial nem sempre fornece um guia passo a passo direto, o que pode ser frustrante, especialmente para iniciantes.
Neste artigo, vou guiá-lo por todo o processo de configuração de uma conexão JDBC com MySQL, desde o download do conector até o espelhamento de tabelas no Caché/IRIS.
Oi, Comunidade!
Precisa instalar um módulo da solução HealthShare? Siga este processo simples passo a passo para começar!
Implantando módulos de solução HealthShare com o InterSystems Package Manager
Olá, pessoal! Tendo me integrado recentemente à InterSystems, percebi que, apesar de ter uma Edição Comunitária totalmente gratuita e incrível, não é muito claro como obtê-la. Decidi escrever um guia destacando todas as diferentes maneiras de acessar a Edição Comunitária do InterSystems IRIS:
Trabalhar com uma instância em contêiner da Community Edition é a abordagem recomendada para quem está começando a desenvolver no InterSystems IRIS e, na minha opinião, é a mais simples. A Community Edition do InterSystems IRIS pode ser encontrada no DockerHub; se você tiver uma conta InterSystems SSO, também poderá encontrá-la no Registro de Contêineres da InterSystems.
Em ambos os casos, você vai querer extrair a imagem desejada usando o Docker CLI:
docker pull intersystems/iris-community:latest-em
// or
docker pull containers.intersystems.com/intersystems/iris-community:latest-emEm seguida, você precisará iniciar o contêiner: para interagir com o IRIS de fora do contêiner (por exemplo, para usar o portal de gerenciamento), você precisará publicar algumas portas. O comando a seguir executará o contêiner IRIS Community Edition com as portas do superservidor e do servidor web publicadas; observe que você não pode executar nada que dependa das portas 1972 ou 52773!
docker run --name iris -d --publish 1972:1972 --publish 52773:52773 intersystems/iris-community:latest-emO artigo do August Article Bounty sobre Global Masters, e um dos tópicos propostos me pareceu bastante interessante para uso futuro em minhas aulas. Então, é isso que eu gostaria de dizer aos meus alunos sobre tabelas no IRIS e como elas se correlacionam com o modelo de objeto.
Primeiro, o InterSystems IRIS possui um modelo de dados unificado. Isso significa que, ao trabalhar com dados, você não está preso a um único paradigma. Os mesmos dados podem ser acessados e manipulados como uma tabela SQL tradicional, como um objeto nativo, ou até mesmo como um array multidimensional (um global). Isso significa que, ao criar uma tabela SQL, o IRIS cria automaticamente uma classe de objeto correspondente. Ao definir uma classe de objeto, o IRIS a torna automaticamente disponível como uma tabela SQL. Os dados em si são armazenados apenas uma vez no eficiente motor de armazenamento multidimensional do IRIS. O motor SQL e o motor de objeto são simplesmente diferentes "lentes" para visualizar e trabalhar com os mesmos dados.
Primeiro, vamos ver a correlação entre o modelo relacional e o modelo de objeto:
| Relacional | Objeto |
| Tabela | Classe |
| Coluna | Propriedade |
| Linha | Objeto |
| Chave primária | Identificador de objeto |
Nem sempre é uma correlação de 1:1, já que você pode ter várias tabelas representando uma classe, por exemplo. Mas é uma regra geral.
(Um guia para iniciantes para manter seu código limpo, amigável e à prova de futuro)
Bem-vindo à selva do ObjectScript, onde seu código pode ter escopo global e natureza persistente. Vamos manter as coisas limpas, legíveis e resistentes a bugs.
1️⃣Nomeie como se fosse sério
Como todos sabemos, a InterSystems é uma ótima empresa.
Seus produtos podem ser tão úteis quanto complexos.
No entanto, nosso orgulho às vezes nos impede de admitir que talvez não entendamos alguns conceitos ou produtos que a InterSystems nos oferece.
Hoje estamos começando uma série de artigos explicando como alguns dos intrincados produtos da InterSystems funcionam, obviamente de forma simples e clara.
Neste ensaio, irei esclarecer o que é Machine Learning e como tirar proveito dele... porque desta vez, VOCÊ VAI SABER com certeza do que estou falando.
Olá Comunidade!
Você está trabalhando com dados clínicos em um ambiente de pesquisa? Veja como o InterSystems OMOP simplifica a integração e análise de dados.
Atualizado 01/04/25
Olá Comunidade,
Vocês podem desbloquear todo o potencial do InterSystems IRIS — e ajudar sua equipe a se integrar — com a gama completa de recursos de aprendizado da InterSystems oferecidos online e presencialmente, para todas as funções em sua organização. Desenvolvedores, administradores de sistema, analistas de dados e integradores podem rapidamente se atualizar.
Olá Comunidade!
Precisa de uma introdução à Generative AI? O Learning Services tem o prazer de anunciar o primeiro vídeo de uma nova série sobre os fundamentos da GenAI:
Como criar uma conexão ODBC no seu laptop Windows nativo para o IRIS em execução em uma VM Windows no mesmo computador, testar a conexão e extrair os dados do IRIS para o Excel.
Recentemente, descobri que o Excel pode se conectar a bancos de dados externos por ODBC. Isso inclui basicamente qualquer origem de dados ODBC. Como o IRIS é compatível com o ODBC pela API ODBC, podemos aproveitar o InterSystems ODBC Driver para estabelecer uma conexão ODBC com o IRIS no Windows que o Excel possa utilizar.
Antes de começar, verifique se você instalou o driver ODBC da InterSystems mais recente no seu Windows nativo, que pode ser encontrado na WRC ou no GitHub. Imagino que você está executando o IRIS em uma VM Windows usando a VMWare hospedada na sua máquina Windows. Também suponho que você tenha o Microsoft Excel instalado no seu Windows nativo. Além disso, você precisará de alguns dados pré-carregados no seu namespace para acesso. Para este post, estou usando os dados do Python Quickstart. Os dados podem ser encontrados no GitHub.
Primeiro, você precisa encontrar o endereço IP para a VM. (Lembre-se de que talvez seja necessário repetir essa etapa se você reiniciar a VM, conectar a uma rede diferente ou conectar/desconectar uma conexão VPN.)
Para encontrar seu endereço IP na VM do Windows, acesse o Prompt de Comando do Windows (cmd):
Agora, retorne ao sistema host Windows, abra o Administrador de Fontes de Dados ODBC (ODBC DSA) e configure a conexão:
Agora, podemos abrir o Microsoft Excel e acessar os dados pela origem de dados ODBC. Para isso, selecionamos a guia "Data" (1) e clicamos em "Get Data" (2). Clique em "From Other Sources" (3) e, depois, em "From ODBC" (4).
No menu suspenso, selecione a origem de dados criada anteriormente e clique em OK:
No Navigator, selecione a tabela que você quer conectar e clique em "Load" (Carregar):
Depois disso, podemos ver que a conexão com os dados no IRIS na VM teve êxito e podemos acessá-los no Microsoft Excel em execução no Windows nativo:
Concluindo, podemos nos perguntar por que acessar os dados IRIS no Excel. Várias pessoas têm anos de experiência com o Excel. Elas podem usar o Excel para explorar dados, criar tabelas dinâmicas, visualizações e painéis.
O diário (Journal) é um recurso essencial do IRIS e uma parte do que torna o IRIS um banco de dados confiável. Embora o diário seja fundamental para o IRIS, há nuances, então escrevi este artigo para resumir (mais brevemente do que nossa documentação com todos os detalhes) o que você precisa saber. Percebo a ironia de dizer que uma leitura de 27 minutos é breve.
Toda modificação em um banco de dados que tenha diário (sets e kills) é registrada com o carimbo de data/hora em um arquivo de diário. Isso é feito em paralelo com as gravações nos bancos de dados e no diário de imagem de gravação (WIJ) para a redundância. O IRIS usa os diários para reproduzir as mudanças no banco de dados em um cenário de recuperação, reverter transações e sincronizar bancos de dados para espelhamento.
Este artigo foca no que depende do diário e nos utilitários usados para gerenciar o diário. Também vamos mostrar uma breve visão geral das operações do IRIS relacionadas para explicar por que o diário é tão importante. Fique à vontade para entrar em contato com o WRC caso precise de suporte crítico com um problema no diário, mas conhecer os fundamentos pode ajudar você a configurar o diário corretamente e responder a cenários específicos da maneira apropriada.
Antes de começar, nossa documentação sobre o diário é robusta e pode ser encontrada abaixo. Às vezes, vou mencionar tabelas da documentação, em vez de reproduzi-las inline. Também vou adicionar um link para nossas melhores práticas de diário. - Recomendo muito a leitura desse documento.
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCDI_journal
A documentação mais recente (vinculada) no momento da escrita deste artigo é para o IRIS 2023.3 (CD), e a instância a que me referi está executando o IRIS 2023.1.2 (EM).
O portal de gerenciamento de sistemas é o local mais fácil para fazer alterações no diário (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário), mas há rotinas fora dele que também podem ser usadas para isso. Elas estão localizadas principalmente no namespace %SYS, e a maioria delas é indexada pela rotina ^JOURNAL, que chama os outros utilitários.
Observação: o portal de gerenciamento de sistemas será chamado de SMP para abreviar
O diário pode ser ativado principalmente no nível do sistema e no nível do banco de dados. Por padrão, o diário está sempre ativado em todo o sistema. Há pouquíssimas situações em que você deve desabilitar isso, portanto não há opção no SMP. Você precisará usar a rotina ^JRNSTOP. A interrupção do diário para o sistema dura até a reinicialização do IRIS, quando o diário é retomado automaticamente. Um erro também pode desativar o diário em todo o sistema, por exemplo, ficar sem espaço em disco no diário. Caso isso aconteça, você verá uma mensagem de messages.log avisando que o diário foi desativado. Você precisará usar a rotina ^JRNSTART para retomar o diário.
Para revisar o diário no nível do banco de dados, você pode acessar o SMP (Administração do Sistema > Configuração > Configuração do Sistema > Banco de Dados Local). O padrão é que os bancos de dados tenham diário.
Por padrão, os nomes dos arquivos do diário têm o formato aaaammdd.nnn e são armazenados em <install_dir>/mgr/journal/. Se o diário for compactado, o nome do arquivo terá o sufixo "z". O arquivo journal.log que registra o nome de cada arquivo do diário está em /mgr/. O log do diário limpará as entradas sequencialmente com base em se o próprio arquivo do diário foi limpo e se a entrada tem 30 dias ou mais. O journal.log é referenciado pelo IRIS para trocar e limpar diários, além de poder ser usado para ajudar a reproduzir diários. Ele nunca deve ser modificado manualmente.
Você pode ajustar algumas configurações do diário usando o SMP (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário) ou a rotina ^JRNOPTS, que é a opção 7 de ^JOURNAL. A maioria dessas configurações é armazenada no arquivo de parâmetros iris.cpf nas seções [config] e [journal]. Quase todas elas podem ser alteradas sem reiniciar o IRIS, mas podem incorrer em uma troca de arquivo de diário.
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=RCPF_config
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RACS_journal
As seguintes configurações estão tanto no SMP quanto na ^JRNOPTS.
O SMP contém outras configurações que não estão em ^JRNOPTS, incluindo "Congelar em caso de erro" - entender essa configuração é importante o suficiente para eu discutir suas implicações na seção a seguir. Resumindo, nossa recomendação é ativar essa configuração.
Há outras configurações disponíveis na página "Configurações do Diário" que são menos usadas, como "Sessão da Web do Diário", "Diretório do Diário de Imagem de Gravação" e "Tamanho alvo para o wij". Informações sobre essas configurações estão disponíveis na documentação do CPF. Não vou abordá-las porque são situacionais.
Há também configurações avançadas de diário disponíveis em outros locais do SMP.
Observação: a partir de 2023.3, um novo recurso de arquivamento de diário foi lançado para que os diários compactados possam ser movidos para um drive separado.
Em Administração do Sistema > Configuração > Configurações Adicionais > Memória Avançada, você pode modificar os buffers do diário (jrnbufs), que têm, por padrão, 64 MB, mas podem variar de 8 ou 16 MB a 1.024 MB, dependendo se a sua instalação for de 8 bits ou Unicode. Essa configuração controla o tradeoff entre desempenho e confiabilidade (os dados do diário armazenados na memória/buffers são mais rápidos, mas temporários em caso de falha).
Em Administração do Sistema > Configuração > Configurações Adicionais > Compatibilidade, temos a configuração "SynchCommit", que determina quando um comando TCOMMIT solicitará que os dados estejam no disco. True faz com que TCOMMIT espere a gravação do diário, mas o padrão false permite que TCOMMIT retorne antes da gravação. Isso está relacionado às transações, que são abordadas algumas seções abaixo.
A configuração "Freeze on error", ou "Congelar em caso de erro", (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário) determina como o IRIS responderá aos erros de I/O do diário. O tradeoff que você precisa considerar é a disponibilidade em relação à integridade dos dados e das transações.
Essa configuração está desativada por padrão. Caso ocorra um erro no diário, você pode esperar o seguinte comportamento. O daemon do diário tentará novamente a cada 1s (padrão) até passar 150s (padrão) ou a instância ficar sem memória (buffers globais) para as atualizações do diário. Nesse momento, o diário será desativado em todo o sistema, impedindo que os dados após esse ponto sejam recuperáveis em um cenário de desastre. Outras preocupações com o diário desativado são que a reversão da transação falhará, o espelhamento falhará e o bloqueio do ECP/recuperação da transação será comprometido. Quando o diário for desativado devido a um erro, uma mensagem será registrada em messages.log informando que você precisará reativar manualmente o diário usando ^JRNSTART. Além disso, recomendamos que, em caso de execução com o diário desativado, você resolva o problema, troque o arquivo do diário e faça backup dos bancos de dados.
Em geral, recomendamos ativar "Congelar em caso de erro", ou seja, se ocorrer um erro com o diário, o IRIS congelará para que você resolva o problema. Todas as atualizações de globais do diário serão interrompidas, e as atualizações de globais serão congeladas quando o daemon do diário ficar inativo por 30s. O daemon do diário continuará tentando e descongelará quando tiver sucesso. Isso provavelmente travará o IRIS até que o problema do diário seja resolvido. Você verá mensagens de gravidade 3 em messages.log avisando você ao tentar novamente a I/O com falha.
Para explicar melhor o comportamento em relação à reversão da transação, com "Congelar em caso de erro" desativado, um TROLLBACK com falha encerrará a transação e liberará os bloqueios. Com a configuração ativada, o processo de abertura da transação será interrompido e CLNDMN tentará repetidamente reverter a transação. Os bloqueios serão mantidos durante essa operação. Se CLNDMN estiver tentando reverter uma transação para um trabalho inativo (como mostrado em messages.log), você poderá usar Manage^CLNDMN para encerrar manualmente a transação. As considerações aqui são semelhantes às discutidas acima: disponibilidade x integridade.
Observação: isso só se aplica à reversão local (não ECP).
O diário é fundamental para a recuperação de desastres. Ao gravar em um banco de dados do IRIS, o IRIS grava essas mudanças duas vezes antes de tocar no banco de dados em si. Todos os sets e kills são registrados no diário, que é gravado pelo menos a cada 2 segundos (há alguns outros gatilhos que vou omitir para simplificar). As alterações também são gravadas no diário de imagem de gravação (WIJ), que armazena as modificações do banco de dados por até 80s antes de serem gravadas no banco de dados em uma passagem. A combinação de diários e do WIJ garante que, em caso de falha, seja possível verificar novamente o que gravamos nos diários, no WIJ e no banco de dados.
Essa é uma breve explicação. Para saber mais, nosso "Guia de integridade dos dados" é um excelente recurso.
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCDI
Quando o IRIS é inicializado após uma interrupção anormal, ele determinará se precisa reaplicar o WIJ ou não e reproduzirá diários (como os diários são gravados com mais frequência, eles podem estar mais atualizados). Se você restaurar um backup, os diários podem/devem ser aplicados em seguida para reproduzir a sequência de sets e kills e atualizar o banco de dados. Sem o diário, você só poderá restaurar até o ponto do backup, quando ele tiver sido feito.
Os diários também facilitam as transações. Resumindo, as transações são usadas para garantir que uma sequência de alterações no banco de dados possam ser tratadas como uma única operação. Você provavelmente já ouviu falar do exemplo do caixa eletrônico: você não quer sacar dinheiro de uma conta, mas fazer com que não alcance seu destino. Ao colocar uma sequência de sets e kills entre os comandos "TSTART" e "TCOMMIT", com o bloqueio adequado para lidar com vários processos, você pode ter certeza de que, se uma das mudanças for gravada no disco, todas as alterações terão persistido. Se um erro ou outro evento impedir que o processo alcance o TCOMMIT, nenhuma das mudanças na transação será feita. Se você iniciar uma transação, mas não conseguir fazer o commit devido a um erro ou outro evento, o IRIS pode consultar o diário para desfazer todas as mudanças no banco de dados, voltando ao TSTART. Pela natureza das transações, mesmo se um banco de dados não tiver um diário, uma transação ainda será registrada em um diário. Esteja ciente de que isso se aplica somente a reversões de tempo de execução e, para uma inicialização de recuperação, não ocorrerá a reversão.
Uma explicação mais detalhada sobre as transações está disponível em nossa documentação "Processamento das transações":
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCOS_tp
O espelhamento é a solução de alta disponibilidade / recuperação de desastres / réplica de dados da InterSystems. No espelhamento, uma instância do IRIS envia seus diários a uma ou mais instâncias do IRIS, que executam em sequência os mesmos sets e kills (esse processo se chama "dejournaling") para manter os bancos de dados sincronizados. Isso permite a réplica de dados lógica em nós. Você nunca pode desativar o diário em um banco de dados espelhado por esse motivo.
Depois de se tornar um membro espelho primário, os arquivos de diário criados terão "MIRROR" no nome e o log do diário será registrado em um mirrorjrn-mirror_name.log, bem como no journal.log regular. Os outros membros espelho armazenarão os diários espelho junto com seus próprios diários e manterão uma cópia do log do diário espelho; mirrorjrn-mirror_name.log é criado em install-dir/mgr/.
Há outras ressalvas para o diário e o espelhamento que tentarei mencionar quando relevante. Nossa documentação sobre o espelhamento está aqui:
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GHA_mirror
Esta seção provavelmente só é interessante para você se estiver usando o espelhamento. Ela discutirá como a localização dos arquivos de diário, o critério de limpeza e a configuração "Congelar em caso de erro" são afetados pelo espelhamento.
O critério de limpeza padrão para os arquivos de diário são um determinado número de dias ou backups. No entanto, se pelo menos um desses gatilhos for atendido, os arquivos do diário espelho podem ser preservados se forem necessários para a sincronização. Por exemplo, se um diário for necessário para concluir uma transação em qualquer membro espelho, ele não será removido.
Um membro de tolerância a falhas primário só limpará um arquivo de diário depois que o critério de limpeza for atingido e o arquivo tiver sido recebido por todos os membros espelho assíncronos e de backup. Isso é aplicável a menos que um assíncrono tenha sido desconectado há >14 dias.
Um membro de tolerância a falhas de backup ou assíncrono de recuperação de desastres limpará um diário após o arquivo passar por dejournaling, o critério de limpeza local for atendido e o diário for recebido por todos os assíncronos. É aplicável a mesma exceção de 14 dias conforme acima.
Em um assíncrono de relatório, os diários espelho são removidos imediatamente após o dejournaling por padrão. Isso pode ser modificado nas configurações do membro espelho (no CPF: AsyncUseSystemPurgeInterval).
O tempo limite de 14 dias pode ser modificado usando o método SYS.Mirror.JrnPurgeDefaultWait, documentado aqui:
A configuração de diário "Congelar em caso de erro" é ativada automaticamente para um membro espelho primário, já que não consegue continuar operando como um membro espelho sem o diário. Se o congelamento continuar por muito tempo, o membro de tolerância a falhas de backup deve detectar a inatividade e assumir como primário.
Agora temos uma ideia do motivo pelo qual o diário é usado e geralmente deve estar ativado. Mas há algumas situações em que você deve evitar o diário? Para isso, indico essa breve série de artigos escritos por Tani Frankel para Caché, mas aplicável ao IRIS, que aborda os seguintes tópicos:
https://community.intersystems.com/post/what-causing-journals-grow-rapidly
https://community.intersystems.com/post/my-growing-journals-how-do-i-minimize
Neste capítulo, vou abordar algumas operações de diário comuns que você pode precisar realizar. Uma lista mais completa de utilitários de diário poderá ser vista no terceiro capítulo, "Utilitários de diário".
Não é possível inicializar e interromper diários no nível da instância pelo portal de gerenciamento de sistemas. Você só pode fazer essa alteração através de ^JOURNAL ou usando ^JRNSTART e ^JRNSTOP.
As principais páginas de Diário no portal de gerenciamento estão localizadas em Operação de Sistema > Diários.
Para trocar os diretórios de diário, há um botão "Switch Directory" (Trocar diretório) na página de Diários no SMP, além do SWDIR^JOURNAL, que é a opção 13 em ^JOURNAL. Se você não tiver outro diretório definido, essa opção não estará disponível.
Para trocar para um novo arquivo de diário, você pode usar o botão "Switch Journal" (Trocar diário) na página de Diários no SMP ou utilizar o ^JRNSWTCH, que é a opção 3 em ^JOURNAL. Os arquivos de diário mudarão automaticamente após um backup bem-sucedido, se um arquivo de diário ficar cheio, se o diretório ficar indisponível e ao mudar as configurações do diário.
Se você quiser revisar o conteúdo de um arquivo de diário, poderá fazer isso no portal de gerenciamento de sistemas (Operação de Sistema > Diários) ou usando ^JRNDUMP. SELECT^JRNDUMP permitirá que você despeje registros de diário específicos em um arquivo, filtrando por uma variedade de critérios.
Observação: se você precisar conferir um arquivo de diário arbitrário, pode mudar o URL dessa página do SMP para que aponte para outro arquivo. Isso presume que o IRIS tenha permissões para acessar esse arquivo.
Para obter uma visão geral do conteúdo de um diário, você deve criar o perfil do diário usando a opção "Perfil" na página de Diários do SMP. Isso dará a você uma ideia dos globais que estão sendo alterados - a frequência e em quais bancos de dados. Você também pode ver um resumo dos metadados do arquivo de diário usando a opção "Resumo" na página de Diários. Isso contém informações como os bancos de dados envolvidos, se eles são criptografados e quando o arquivo de diário foi criado. A página de Diários também oferece a possibilidade de realizar uma verificação de integridade em um arquivo de diário.
Se você precisar limpar manualmente seus diários, por exemplo, se alguma atividade incomum de banco de dados causar registros excessivos no diário, é possível fazer isso usando PURGE^JOURNAL, a 6ª opção de ^JOURNAL. Assim, você pode fazer a limpeza com base no seu critério padrão ou remover todos os diários desnecessários para a transação ou recuperação da falha. A tarefa "Limpar Diário" padrão (Operação de Sistema > Gerenciador de Tarefas > Programação de Tarefas) é executada às 00:30, logo após a tarefa padrão "Trocar Diário" às 00:00. Se uma limpeza falhar, por exemplo, o arquivo de diário for necessário para uma transação ou espelhamento, você pode esperar uma mensagem de messages.log informando sobre isso. Você não deve tentar excluir arquivos de diário no nível do SO, já que isso pode causar o desalinhamento do sistema de arquivos com o journal.log e a quebra de operações de diário padrão.
Por fim, você pode se deparar com uma situação em que seja necessário executar uma restauração manual do diário. Os mecanismos exatos são mais discutidos na seção ^JRNRESTO, mas os conceitos básicos são os seguintes. ^JRNRESTO é a opção 4 de ^JOURNAL, e você deve garantir que os usuários não estejam no sistema, que o diário seja interrompido e que você tenha restaurado seu backup. Em seguida, pode executar o ^JRNRESTO e reiniciar o diário. Essa operação não está disponível no portal de gerenciamento de sistemas, porque só é usada em circunstâncias de força maior.
Para uso mais avançado, como determinadas soluções de problemas ou necessidades programáticas, o global ^%SYS("JOURNAL") contém informações detalhadas sobre o diário. O %SYS.Journal.System contém consultas e métodos do diário, conforme documentado aqui:
Nas duas seções anteriores, mencionei os utilitários do diário. Vários deles são agregados no ^JOURNAL, uma rotina disponível no namespace %SYS. Essa seção será mais detalhada do que as seções anteriores e darei exemplos específicos de caminhos de prompts. Você pode achar isso mais útil como uma referência do que um artigo para leitura.
A interface oferecerá essas opções:
1) Iniciar o diário (^JRNSTART)
2) Parar o diário (^JRNSTOP)
3) Trocar o arquivo do diário (^JRNSWTCH)
4) Restaurar os globais do diário (^JRNRESTO)
5) Exibir o arquivo do diário (^JRNDUMP)
6) Limpar os arquivos do diário (PURGE^JOURNAL)
7) Editar as propriedades do diário (^JRNOPTS)
8) Ativar ou desativar a criptografia do diário (ENCRYPT^JOURNAL())
9) Mostrar o status do diário (Status^JOURNAL)
10) -não disponível-
11) -não disponível-
12) Atualizar diário com os bancos de dados espelhados (MirrorCatchup^JRNRESTO)
13) Trocar diário para o diretório secundário (SWDIR^JOURNAL)
Vou descrever essas opções na ordem da quantidade de detalhes que fornecerei, da mais simples para a mais complexa. Observe que algumas opções (como 10 e 11 acima) podem aparecer como "-não disponível-" dependendo da sua configuração. Vou indicar isso.
Opções 1 "Iniciar diário (^JRNSTART)", 2 " Parar diário (^JRNSTOP)", 3 " Trocar arquivo do diário (^JRNSWTCH)" e 13 "Trocar diário para o diretório secundário (SWDIR^JOURNAL)" são simples, já que realizam uma única operação. A opção 13 ficará indisponível se a instância não tiver um diretório de diário alternativo configurado.
A opção 12 "Atualizar diário com os bancos de dados espelhados (MirrorCatchup^JRNRESTO)" também é uma operação básica para uma instância espelhada e iniciará uma atualização de espelho. O diário não precisa estar ativado nesse momento, mas precisa ter sido iniciado pelo menos uma vez desde a inicialização do IRIS para ter o diretório do diário atual na memória
A opção 7 "Editar propriedades do diário (^JRNOPTS)" permite que você modifique 5 configurações de diário básicas. Você pode mudar os diretórios do diário, o limite de tamanho do arquivo do diário, o prefixo do arquivo do diário e seu critério de limpeza.
A opção 10 oferece a "Restauração de cluster de diário (CLUMENU^JRNRESTO)". As considerações de cluster ECP estão além do que abordarei neste artigo, mas você pode encontrar informações sobre essa opção aqui na documentação do Caché:
A opção 8 é "Ativar ou desativar a criptografia do diário (ENCRYPT^JOURNAL())", e uma descrição profunda será omitida. Destaco que essa configuração se aplica a arquivos de diário futuros. Para configurar os arquivos de diário criptografados, veja esta documentação:
A opção 6 "Limpar arquivos de diário (PURGE^JOURNAL)" permite que você limpe com duas opções diferentes: com base no critério configurado (dias e backups bem-sucedidos) ou qualquer diário que não seja necessário para a reversão da transação ou recuperação de falhas. Ela relatará quais arquivos de diário foram removidos.
A opção 9 "Mostrar o status do diário (Status^JOURNAL)" oferece algumas metainformações sobre o diário. Ela dirá o status atual do diário, incluindo:
As opções 11, "Gerenciar reversão de transação pendente ou em andamento (Manage^JRNROLL)", 5 "Exibir o arquivo do diário (^JRNDUMP)" e 4 "Restaurar os globais do diário (^JRNRESTO)" são tão envolvidas que eu as separei em seus próprios cabeçalhos.
Em geral, a reversão da transação deve ser rápida, já que as transações só podem ser abertas por breves períodos, mas, se uma transação for deixada aberta por tempo prolongado, a instância pode precisar verificar um número significativo de arquivos de diário antes da inicialização normal do sistema. Verificamos as transações abertas na inicialização da instância e ao se tornar um membro espelho primário.
Se o tempo de atividade do sistema for essencial, Manage^JRNROLL pode suspender temporariamente o processo de reversão. Em geral, não recomendo usar esse utilitário, já que você quase certamente sacrificará a integridade transacional. Será preciso avaliar se o tempo de atividade é importante o suficiente para fazer esse tradeoff, e você também precisará se preparar para tomar qualquer medida necessária para solucionar o estado dos dados quando as transações não estiverem sendo resolvidas corretamente.
Não posso discutir todo cenário possível aqui, mas recomendo que você entre em contato com a WRC para receber ajuda se achar que precisa usar isso.
Além disso, Manage^JRNROLL permite que você monitore o processo de reversão. Ele dirá a você se a instância está verificando os arquivos de diário ou está realizando a reversão, quantos MB ainda precisam ser processados dos diários e quantas transações abertas foram encontradas. Outra opção para monitorar a reversão é o messages.log. Em versões modernas, você deve receber mensagens do messages.log relatando a quantidade de dados que ainda precisam ser processados e o número de transações abertas.
Depois de aplicar um backup, ^JRNRESTO é o utilitário usado para aplicar os arquivos de diário do momento do backup até o presente. Isso se chama "dejournaling." ^JRNRESTO só afetará os bancos de dados que estão definidos como diário ao executar a rotina.
^JRNRESTO oferece vários recursos para definir os diários que serão restaurados. Principalmente, você pode especificar vários arquivos de diário. Você também pode selecionar bancos de dados ou globais específicos para serem atualizados. Além disso, é possível selecionar bancos de dados ou globais individuais para a restauração. Para mais granularidade, você pode usar um filtro de diário personalizado de ^ZJRNFILT, que será abordado depois. Você também pode restaurar para a instância atual ou para os bancos de dados de outra instância do IRIS. ^JRNRESTO também pode ser usado para inicializar a atualização do espelho se você estiver tentando restaurar finais de diário espelho para um banco de dados espelhado no mesmo espelho. Nesse caso, ele simplesmente usará MirrorCatchup^JRNRESTO.
^JRNRESTO permite que você desative o diário para as atualizações de restauração, que melhorará o desempenho. Para aumentar ainda mais a velocidade do dejournaling, o dejournaling em paralelo pode usar até 4 jobs para atualizar vários bancos de dados ao mesmo tempo. Para usar isso, você precisaria de pelo menos 8 CPUs e heap de memória compartilhada suficiente configurada (gmheap). Cada job paralelo que você quer usar requer 200 MB de gmheap, ou seja, é necessário um mínimo de 400 MB de gmheap para usar o dejournaling em paralelo. Mesmo se você não alcançar esse limite, aumentar o heap de memória compartilhada pode melhorar o desempenho. É possível modificar a configuração de gmheap no portal de gerenciamento (Administração do Sistema > Configuração > Configurações Adicionais > Memória Avançada) e exige a reinicialização. Se a configuração permitir, por padrão, o IRIS usará o dejournaling em paralelo.
Você pode iniciar a restauração do diário ao trocar para o namespace %SYS e inserir "do ^JRNRESTO". A melhor forma de se familiarizar com esse utilitário é testar por conta própria, já que você pode ter uma ideia melhor do tipo de restauração de diário que talvez seja necessário em seu ambiente. Exemplos de prompts e amostras de saída estão disponíveis na documentação, e descreverei as etapas do processo, para você saber o que esperar.
Se a instância está em um espelho, o primeiro prompt perguntará se você quer "Atualizar bancos de dados espelhados? Não =>". Sua resposta aqui determinará se você será redirecionado para MirrorCatchup^JRNRESTO ou seguirá com mais prompts para especificar manualmente quais diários devem ser restaurados para quais bancos de dados.
Se você definiu um filtro de diário (ZJRNFILT, discutido abaixo), precisará responder se esse filtro deve ser usado ou não. MARKER^ZJRNFILT não é aplicável à grande maioria dos casos de uso:
"Usar filtro de diário atual (ZJRNFILT)?
Usar filtro de marcador de diário (MARKER^ZJRNFILT)?"
Depois disso, você pode especificar se quer "Processar todos os globais de diário em todos os diretórios?" ou não. Se você não quiser restaurar nada, precisará responder a uma série de prompts para declarar o que exatamente deseja restaurar. Você poderá escolher bancos de dados (mesmo para uma instância diferente do IRIS) e globais para cada banco de dados.
O primeiro esclarecimento solicitado será "Os arquivos de diário são importados de um sistema operacional diferente?" Isso determinará se ^JRNRESTO pode usar o formato de caminho de diretório padrão do SO.
A próxima etapa será especificar o caminho do diretório para o banco de dados de origem no prompt "Diretório para restaurar [? para ajuda]". Se você estiver restaurando diários espelhados para um banco de dados não espelhado, também pode usar o nome de espelho completo aqui (por exemplo, :mirror:<mirror_config_name>:<mirror_db_name>). O seguinte prompt é "Redirecionar para o diretório", para selecionar o banco de dados de destino. Você pode escolher o padrão e pressionar <enter> para selecionar a origem como o destino.
Para cada banco de dados, se devem ser restaurados todos ou alguns globais específicos.
"Processar todos os globais em <directory_to_db>? Não =>"
Depois de inserir todos os bancos de dados que você quer restaurar, você pode pressionar <enter> em "Diretório para restaurar [? para ajuda]:" a fim de prosseguir. Você precisará confirmar suas seleções.
OBSERVAÇÃO: se você estiver restaurando vários bancos de dados de origem para um banco de dados de destino, precisará fazer a mesma seleção de globais ou restaurar todos os globais.
^JRNRESTO tenta facilitar o máximo possível a restauração de uma sequência de arquivos de diário. Seja fazendo qualquer especificação de banco de dados acima ou restaurando todas as entradas, o primeiro prompt é "Os arquivos de diários foram criados por essa instância do IRIS e estão localizados nos seus caminhos originais? (Usa journal.log para localizar diários)?" Se você selecionar "sim", ^JRNRESTO poderá gerar uma lista de arquivos de diário disponíveis a partir do journal.log, em vez de exigir que o usuário direcione manualmente o processo para os arquivos de diário. Também é possível selecionar "não, você deverá responder se tem uma cópia do journal.log a partir da instância do IRIS de origem, e apontar para o diretório com os arquivos de diário que você quer restaurar.
Em ambos os casos, você receberá o prompt a seguir, onde poderá ver uma lista de arquivos de diário e fazer sua seleção. Os backups iniciam a troca de diário e registram uma mensagem (se você iniciar um congelamento externo para um backup externo, isso será registrado no messages.log), que pode servir como guia para os diários que você quer restaurar:
"Especifique a variedade dos arquivos que serão processados
Insira ? para abrir uma lista de arquivos de diário e selecione o primeiro e o último arquivo de
Primeiro arquivo para processar:"
Se você não tiver um arquivo journal.log para consulta, ainda poderá fornecer nomes de arquivos de diário e um diretório para procurar arquivos.
O IRIS deixará você revisar os arquivos selecionados e perguntará se você quer verificar a integridade dos arquivos de diário. Se você estiver tentando restaurar um arquivo de diário ativo, o IRIS exigirá e solicitará que você troque o arquivo.
Como descrito acima, o dejournaling em paralelo pode ser usado para melhorar o desempenho. Se você estiver usando o dejournaling em paralelo, o processo não será registrado em diário. Se você não estiver usando o dejournaling em paralelo, ainda terá a opção de desativar o diário dessas atualizações, melhorando o desempenho.
A escolha final que você fará antes de começar a restauração do diário será como responder a erros. Você pode selecionar respostas a erros nos níveis do banco de dados e do diário. É possível determinar se você quer continuar ou abortar o processo caso haja qualquer tipo de erro. Se você decidir abortar em qualquer um dos casos, o dejournaling em paralelo não poderá ser usado.
O processo começará a relatar seu progresso, informando qual arquivo de diário está sendo processado e a % de conclusão periodicamente. Quando a restauração for concluída, aparecerá um resumo dela.
Observação: ao restaurar diários, as transações abertas serão revertidas. Para garantir que você não tenha preocupações de integridade das transações, reverta ou use o commit nas transações. Se você tiver preocupações com a atividade do usuário, pode reiniciar o IRIS no modo de usuário único, conforme documentado aqui:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ASECMGMT#ASECMGMT_emerg
Você pode usar ^ZJRNFILT para criar um filtro personalizado para uso durante a restauração do diário, controlando os sets e kills aplicados. Você precisará criar uma rotina personalizada aceitando os seguintes parâmetros.
ZJRNFILT(jid,dir,glo,type,restmode,addr,time)
jid - ID do job para identificar o PID que gerou o diário
dir - caminho completo do diretório com o IRIS.DAT que será restaurado, especificado no registro do diário
glo - global no registro do diário
type - tipo de comando conforme especificado na documentação aqui:
restmode - defina isso como 1 ou 0 no seu código personalizado para determinar se um registro deve ser restaurado
addr - endereço do registro do diário
time - carimbo de data/hora do registro (formato $horolog). Observe que essa é a hora em que o buffer do diário é criado, e não quando realmente ocorre o set/kill.
Exemplos de como escrever um ^ZJRNFILT estão disponíveis na documentação. Se a rotina ^ZJRNFILT personalizada existir, a restauração do diário solicitará que você use o filtro. Ao usá-lo, o filtro será chamado em cada registro do diário. Isso usará a lógica que você escrever na rotina, envolvendo quaisquer parâmetros que você queira usar, para definir o restmode como 1 (aplicar) ou 0 (não aplicar).
Se o processo de inicialização ^STU chamar ^JRNRESTO, ele não aplicará seu filtro ZJRNFILT personalizado.
Quando a restauração do diário for concluída, você deverá renomear ou excluir o ^ZJRNFILT. Ao renomear a rotina, ela será copiada para ^XJRNFILT, e ^ZJRNFILT será excluído.
Se ^ZJRNFILT se deparar com um erro, o processo de restauração será abortado.
Às vezes, o portal de gerenciamento pode não ser suficiente para analisar os arquivos do diário. Isso pode acontecer devido ao arquivo do diário ser tão grande que ocorre um tempo limite. Nesses casos, você pode usar ^JRNDUMP ou SELECT^JRNDUMP para despejar os registros do diário, facilitando a visualização.
^JRNDUMP mostrará uma seleção de arquivos de diário e o diretório onde podem ser encontrados. Você pode usar as seguintes opções para navegar pela exibição: "Pg(D)n,Pg(U)p,(N)ext,(P)rev". Você também pode usar "(G)oto" para indicar diretamente um arquivo de diário para investigar.
A opção "(I)nfo" fornecerá metadados de um arquivo de diário, incluindo o arquivo GUID, tamanho máximo, data e hora de criação, número de arquivos, min trans, arquivo anterior, arquivo GUID anterior, final do arquivo anterior, próximo arquivo, próximo arquivo GUID. A maioria dessas entradas é facilmente compreensível, porém, "Min Trans" contém o arquivo do diário e o deslocamento em que sabemos que todas as transações estão fechadas. Depois desse ponto, pode haver transações abertas. A partir daí, "(D)atabases" dirá quais bancos de dados são afetados por esse arquivo de diário. Todas as informações "(I)nfo" também estão disponíveis na página "Resumo do Arquivo do Diário" no portal de gerenciamento de sistemas.
"(E)xamine" mostrará as entradas individuais do diário com o endereço, ID do processo, operação, diretório, global e valor. Você pode usar (N)ext, (P)rev, (G)oto e (F)ind para navegar por esses endereços do diário. "(E)xamine" mais para analisar uma única entrada em profundidade, que fornecerá quase as mesmas informações disponíveis na página "Ver diário" do portal de gerenciamento de sistemas. Isso seria o endereço, tipo de operação, se a operação estava em uma transação, ID do job, ID do processo, ID do sistema ECP (0 se não estiver configurado para ECP), carimbo de data/hora, ordenação, endereço anterior e próximo, além do global e do seu novo valor. Se a entrada foi gravada em uma transação, o valor antigo também será listado.
Uma lista completa das diferentes operações/tipos está disponível na documentação (vinculada na parte superior da seção ZJRNFILT).
Há três tipos principais de registros de diário: registros de dados, marcadores de diário e cabeçalhos de diário. ^JRNDUMP não mostrará cabeçalhos de diário, e marcadores de diário são indicados por Tipo: JrnMark. Os marcadores de diário são usados para várias operações de sistema diferentes, como backups. Quase todas as entradas que você verá serão registros de dados.
SELECT^JRNDUMP permite que você despeje entradas de diário filtradas no terminal ou em um arquivo. Você pode filtrar com base nos seguintes critérios:
SELECT^JRNDUMP(%jfile,%pid,%dir,%glo,%gloall,%operation,%remsysid)
%jfile - caminho completo de um arquivo do diário, o padrão é o arquivo atual
%pid - ID do processo, o padrão é "any"
%dir - diretório de um banco de dados, o padrão é "any"
%glo - referência do global, o padrão é "any"
%gloall - modificador de %glo. Se isso for 0, o filtro procurará exatamente pelo nome do global especificado por %glo. Se isso for 1, o filtro pegará os nomes dos globais com o parâmetro %glo
%operation - tipo de operação, o padrão é "any"
%remsysid - ID do sistema ECP, o padrão é "any"
Alguns exemplo de filtros especificados para SELECT^JRNDUMP estão disponíveis na documentação.
Se a inicialização do IRIS se deparar com um erro de restauração de transação ou diário, você talvez seja colocado no modo de usuário único. Você verá uma mensagem de messages.log assim:
12/28/18-07:06:43:099 (1234) 1 1 erros durante a restauração do diário,
veja mais detalhes no arquivo messages.log.
A inicialização foi abortada, entrando no modo de usuário único.
Entre no IRIS com
iris session IRIS -B
e execute ^STURECOV para ajudar na recuperação dos erros.
Dependendo do erro, ^STURECOV oferece diferentes opções para ajudar você a se recuperar.
Observação sobre o espelho: ^STURECOV não poderá ser executado em um banco de dados se a reversão de transação estiver em andamento, já que o banco de dados não montará a leitura/gravação até que a reversão seja concluída. A Opção 11 do ^JOURNAL acima: Manage^JRNROLL aborda o que você deve fazer nesse caso.
Especificamente para um erro de diário, o menu ^STURECOV ficará assim:
1) Exibir a lista de erros da inicialização
2) Executar a restauração do diário novamente
3) Derrubar o sistema antes de uma inicialização normal
4) Desmontar um banco de dados
5) Montar um banco de dados
6) Utilitário de conserto do banco de dados
7) Verificar a integridade do banco de dados
8) Redefinir o sistema para que o diário não seja restaurado na inicialização
9) Exibir instruções sobre como desativar o sistema >>>>> [somente Unix]
10) Exibir Menu do Diário (^JOURNAL)
Alerta: a opção 8 é irreversível e impedirá que a próxima inicialização faça a restauração do diário. Nesse ponto, se você quiser restaurar diários, precisará usar ^JRNRESTO. Isso geralmente só deve ser usado se houver uma necessidade de contornar a recuperação e inicializar o IRIS.
Esse utilitário pode ser usado para adicionar um marcador de diário ao arquivo do diário - você provavelmente não precisará usá-lo. Ele é usado da seguinte maneira:
SET rc=$$ADD^JRNMARK(id,text)
"rc" retornará o deslocamento do diário e o nome do arquivo do diário. O id pode ser qualquer valor inteiro (entradas inválidas são definidas como 0 por padrão) e o texto pode ser qualquer string de até 256 caracteres.
Você poderá ver o marcador do diário no arquivo do diário, porém, se quiser analisar o texto ou o id, precisará usar ^JRNDUMP. O portal de gerenciamento de sistemas não oferece essa funcionalidade.
^JRNUTIL inclui várias tags que permitem a manipulação de arquivos de diário programaticamente. Isso permite que você abra, exclua ou leia um arquivo de diário, entre outras opções.
Se você tiver interesse em usar essas funções, provavelmente deve falar direto com alguém da InterSystems.
Esses utilitários só são necessários para a conversão de DSM para Caché. Eles permitem que você converta arquivos de diário para um formato comum. Um exemplo está disponível na documentação, mas esse uso é específico o suficiente para que eu não o aborde aqui.
Apenas leia a primeira seção e a documentação de melhores práticas. Espero que você tenha achado essa visão geral do diário útil - ela foi escrita por um humano (admin de sistema) para um humano. Fique à vontade para fazer comentários ou perguntas abaixo. Você também pode me enviar uma mensagem direta.
Olá, comunidade,
Neste artigo, listei 5 funções SQL úteis com explicações e exemplos de consultas👇🏻
Estas são as 5 funções:
Vamos começar com a função COALESCE
A função COALESCE avalia uma lista de expressões na ordem da esquerda para a direita e retorna o valor da primeira expressão que não é NULL. Se todas as expressões forem avaliadas como NULL, é retornado NULL.
A declaração a seguir retorna o primeiro valor que não é nulo, ou seja, "intersystems"
SELECTCOALESCE(NULL, NULL, NULL,'intersystems', NULL,'sql').png)
Vamos criar a tabela abaixo como outro exemplo
CREATETABLE EXPENSES(
TDATE DATENOTNULL,
EXPENSE1 NUMBERNULL,
EXPENSE2 NUMBERNULL,
EXPENSE3 NUMBERNULL,
TTYPE CHAR(30) NULL).png)
Agora vamos inserir alguns dados falsos para testar nossa função
INSERTINTO sqluser.expenses (tdate, expense1,expense2,expense3,ttype )
SELECT {d'2023-01-01'}, 500,400,NULL,'Present'
UNION ALL
SELECT {d'2023-01-01'}, NULL,50,30,'SuperMarket'
UNION ALL
SELECT {d'2023-01-01'}, NULL,NULL,30,'Clothes'
UNION ALL
SELECT {d'2023-01-02'}, NULL,50,30 ,'Present'
UNION ALL
SELECT {d'2023-01-02'}, 300,500,NULL,'SuperMarket'
UNION ALL
SELECT {d'2023-01-02'}, NULL,400,NULL,'Clothes'
UNION ALL
SELECT {d'2023-01-03'}, NULL,NULL,350 ,'Present'
UNION ALL
SELECT {d'2023-01-03'}, 500,NULL,NULL,'SuperMarket'
UNION ALL
SELECT {d'2023-01-04'}, 200,100,NULL,'Clothes'
UNION ALL
SELECT {d'2023-01-06'}, NULL,NULL,100,'SuperMarket'
UNION ALL
SELECT {d'2023-01-06'}, NULL,100,NULL,'Clothes' .png)
Selecione os dados.png)
Agora, usando a função COALESCE, vamos recuperar o primeiro valor que não é NULL nas colunas expense1, expense2 e expense3
SELECT TDATE,
COALESCE(EXPENSE1,EXPENSE2,EXPENSE3),
TTYPE
FROM sqluser.expenses ORDERBY2 .png)
No SQL, há várias maneiras de atribuir uma classificação a uma linha, que vamos analisar com um exemplo. Considere novamente o mesmo exemplo acima, mas agora queremos saber quais são as despesas mais altas.
Queremos saber onde eu gasto mais dinheiro. Há diferentes maneiras de fazer isso. Podemos usar todas as ROW_NUMBER() , RANK() e DENSE_RANK() . Vamos ordenar a tabela anterior usando todas as três funções e ver quais são as principais diferenças entre elas usando a seguinte consulta:
Confira nossa consulta abaixo:
.png)
A principal diferença entre as três funções é a forma como lidamos com os vínculos. Vamos analisar mais a fundo as diferenças:
ROW_NUMBER()retorna um número único para cada linha começando em 1. Quando há vínculos, ele atribui arbitrariamente um número se o segundo critério não estiver definido.RANK()retorna um número único para cada linha começando em 1, exceto quando há vínculos, porque ele atribui o mesmo número. Além disso, uma lacuna segue a classificação duplicada.DENSE_RANK() não deixa lacunas depois de uma classificação duplicada.O total corrente é provavelmente uma das funções de janela mais úteis, principalmente quando você quer visualizar o crescimento. Usando uma função de janela com SUM(), podemos calcular uma agregação cumulativa.
Para fazer isso, só precisamos somar uma variável usando o agregador SUM() , mas ordenar essa função usando uma coluna TDATE.
É possível observar esta consulta correspondente:
.png)
Como você pode observar na tabela acima, agora temos a agregação acumulada da quantidade de dinheiro gasto conforme passam as datas.
O SQL é ótimo. As funções usadas acima podem ser úteis ao lidar com análise de dados, ciência de dados e qualquer outro campo relacionado a dados.
Por isso, você deve continuar a melhorar suas habilidades de SQL.
Obrigado
Está começando a codificar na plataforma de dados IRIS® da InterSystems? Experimente esse novo programa de aprendizagem para conhecer os conceitos básicos e ver como desenvolver um aplicativo com o InterSystems ObjectScript juntamente com a linguagem de sua escolha: Java, .NET, Python ou Node.js.
Com o meu conhecimento básico sobre o contêiner Docker e a API REST, queria tentar usar o InterSystems API Manager pela primeira vez para controlar APIs e microsserviços. Concluí esse curso online usando minha instância IRIS local como host (SO Windows) e o IAM em execução em uma VM Linux (convidado).
Primeiro, quero apresentar o InterSystems API Manager (IAM), explicar as etapas para configurar meu ambiente local e, por último, mostrar os capítulos do curso.
Atualmente, o gerenciamento de API é muito importante ao aproveitar as vantagens da fácil implantação, com um portal de IU centralizado para gestão, monitoramento e proteção do tráfego da API.
O InterSystems API Manager (IAM) controla APIs e microsserviços consumidos e expostos pelo aplicativo IRIS. É um gateway de API entre sistemas downstream e upstream e também tem uma maneira de rastreamento visual para descobrir como as APIs são chamadas, com que frequência elas são chamadas e quem as chamam.
Benefícios de usar o IAM:
O que eu instalei antes de começar a configurar o IAM
Ative a instância InterSystems IRIS para o usar o IAM
Abra o Portal de Gerenciamento da instância IRIS e ative o IAM.
Ative o aplicativo da Web IAM (confira se a sua licença do IRIS especifica "gerenciamento de API")
Faça o download e extraia os arquivos de instalação do IAM
Configure e inicialize o IAM
Nessa etapa, usei o usuário ROOT já que eu estava obtendo erros como "Não foi possível carregar o Portal de Gerenciamento corretamente" ou o script de configuração não estava transmitindo o valor das variáveis de ambiente para o arquivo docker-compose.yaml quando eu usei o sudo com meu usuário Linux. Uma solução para o último problema foi usar "**sudo -E" **para transmitir as variáveis de ambiente.
Se você não conseguir dar um ping no endereço host usando a VM, confira Firewall do Windows - Configurações Avançadas - Regras de Entrada. Habilite Ativar compartilhamento de arquivos e impressoras (Solicitação de Echo - ICMPv4-In) Perfil: Privado, Público
Teste o IAM
Dentro do kit de instalação, você encontrará um script chamado "iam-test.sh" no diretório de scripts.
Digite e execute "./iam-test.sh" para começar a testar a conexão entre o IAM e a instância IRIS.
Observação: se o resultado do teste disser "Error creating service. HTTP Status Code:000 ou Error creating service. HTTP Status Code:409" (Erro ao criar o serviço. Código de Status HTTP:000 ou 409), confira o status do docker. Se estiver íntegro, mas ainda não funcionar, encerre o contêiner e execute o docker compose novamente. Pela minha experiência, isso pode acontecer após você pausar a VM.
Para saber mais, encontre aqui a documentação de configuração do IAM: https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls?KEY=CIAM3.0_install#CIAM3.0_install_setupIAM
Exercício prático: https://learning.intersystems.com/course/view.php?name=IAMExercise
Depois de fazer esse exercício, concluí os três capítulos principais que eu gostaria de compartilhar:
Antes de começar a usar o IAM, esse exercício pediu que eu criasse uma solicitação REST usando o método GET, essa solicitação HTTP é do servidor cliente e aponta diretamente para o endpoint, que é um aplicativo da Web criado com base em uma instância IRIS.
Para as próximas etapas, esse exercício mostrou como configurar os serviços a que a solicitação API é encaminhada e a rota que analisa a solicitação de entrada e depois aloca para a API mais adequada.
Configuração de Serviços e Roteadores
O que é um serviço?
Um serviço é configurado para conectar a API Manager ao InterSystems IRIS. Geralmente, você tem um serviço por serviço REST ou aplicativo da Web no InterSystems IRIS. Por exemplo, se você tiver um aplicativo da Web com o caminho base /rest/coffeemakerapp, você configurará um serviço na API Manager para esse URL. Os serviços são geralmente definidos antes das rotas.
O que é uma rota?
Uma rota define o que será chamado pelos aplicativos clientes para o InterSystems API Manager. Geralmente, o serviço é definido antes de uma rota, porque a interface permite que você crie com facilidade as rotas correspondentes diretamente de um serviço definido. As rotas são normalmente versões simplificadas de caminhos no InterSystems IRIS. No exemplo a seguir, você criará rotas para /test, /coffeemakers, /coffeemaker e /newcoffeemaker. Quanto mais específicas forem suas rotas, maior controle você terá sobre suas APIs no API Manager, tanto para visualizar métricas quanto para adicionar plugins a rotas específicas.
Crie um serviço:
Crie uma rota:
Após criar o serviço e a rota, você pode usar um cliente REST como o Postman para enviar uma solicitação diretamente para o IAM e receber uma resposta "200 ok", por exemplo: GET http://10.0.0.1:8000/test (/test é a rota criada).
Observação: no meu caso, o URL da solicitação HTTP deve corresponder ao endereço IP da VM Linux. Você pode encontrar o endereço IP por Settings-Network ou executar o comando "ifconfig" no terminal.
Abra o Portal de Administrador do IAM, você verá que a solicitação para mostrar todos os coffeemakers foi registrada com êxito, do cliente REST para o IAM.
Até mesmo com as solicitações CRUD básicas, em vez de enviar a solicitação HTTP diretamente para o aplicativo da Web do IRIS, o uso do IAM proporciona uma representação visual para controlar as APIs e manter a segurança do endpoint.
Usando plugins
Um dos benefícios de usar o IAM é que há vários plugins disponíveis, como o plugin de limitação de taxa, para ajudar com o throttling, de ACL e de OAuth2.0. No meu caso, vou compartilhar minha experiência ativando basic-auth e criando um consumidor.
Ative o plugin basic-auth
Crie um usuário IRIS para a autenticação básica
Crie um consumidor e configure as credenciais
Agora concluímos todos os requisitos para o plugin basic-auth funcionar
Envie uma solicitação HTTP usando a autenticação básica com a credencial "CoffeeManager" que criamos na última etapa
Acesse a página de informações do CoffeeManager > Activity, você verá que uma solicitação foi registrada
Em suma, comecei apresentando o que é o InterSystems API Manager (IAM) e seus benefícios. Expliquei como configurar o IAM em uma VM Linux e como usar o IAM ao implementar suas funções básicas, criar serviços e rotas e ativar plugins e consumidores.
Se você tiver dúvidas e comentários, não hesite em entrar em contato.
Divirta-se e aproveite o IAM!
Oi, pessoal!
Neste artigo, quero revisar as extensões do VS Code que uso para trabalhar com a InterSystems e que facilitam muito meu trabalho. Tenho certeza de que este artigo será útil para quem está apenas começando a jornada de aprendizado das tecnologias da InterSystems. No entanto, também espero que este artigo seja útil para desenvolvedores com vários anos de experiências e abra novas possibilidades de uso do VS Code para desenvolvimento.
Recomendo que todo mundo que trabalhe com a InterSystems tenha essas extensões instaladas e, neste artigo, quero mostrar como usar algumas delas.
Você pode ler mais sobre a funcionalidade e o uso de cada extensão na seção "Extensions" do VS Code, onde também é possível baixar, atualizar e desinstalar extensões:
Após a instalação, os ícones da extensão aparecem na lateral ou na parte inferior do editor de código.
Extensões obrigatórias
Acho que faz sentido começar nossa jornada com estas extensões básicas, necessárias para trabalhar com a InterSystems no VS Code.
Juntas, essas extensões oferecem aos desenvolvedores uma maneira simplificada de criar, testar e implantar aplicativos de pilha completa criados na InterSystems.
Extensões adicionais
Além das extensões necessárias básicas, o VS Code oferece várias outras extensões. Você pode escrever código sem elas, mas o desenvolvimento fica mais eficiente ao usar qualquer outra pilha de tecnologia, incluindo as tecnologias da InterSystems. Vou descrever algumas que parecem ser essenciais.
Atualmente, é difícil imaginar o desenvolvimento de um projeto sem o controle de versões. Geralmente, é o Git que faz isso, e o Visual Studio Code oferece suporte mínimo para ele. Se isso não for suficiente para você, confira as duas extensões a seguir:
É indispensável para o trabalho em equipe!
Neste artigo, analisei apenas as extensões que já usei. Agradeceria se você reservasse um tempo para escrever nos comentários o que mais pode ser usado para facilitar o desenvolvimento. Então, este artigo será ainda mais útil!
Oi, pessoal!
Recentemente, eu precisava configurar um servidor FHIR local usando o IRIS For Health e acho que encontrei a maneira mais fácil e simples possível.
Basta executar estas duas linhas no terminal:
docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-communitye
docker exec -it my-iris iris session iris -U "USER" '##class(%ZPM.PackageManager).Shell("install fhir-server")'E o servidor FHIR será executado localmente em http://localhost:9092/fhir/r4.
É só isso!
O servidor FHIR usará a última versão do InterSystems IRIS for Health Community Edition e implantará o servidor FHIR a partir desse app pelo pacote IPM no namespace FHIRSERVER.
Isso se aplica ao Mac, então adicione nos comentários como funciona no Windows.
Esse é um breve artigo, já que é muito fácil configurar um servidor FHIR local com o InterSystems IRIS for Health e o IPM Package Manager.
Nesta série de artigos, quero apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com tecnologias da InterSystems e do GitLab. Vou cobrir tópicos como:
No primeiro artigo, abordamos os fundamentos do Git, por que um entendimento de alto nível dos conceitos do Git é importante para o desenvolvimento de software moderno e como o Git pode ser usado para desenvolver software.
No segundo artigo, abordamos o fluxo de trabalho do GitLab: um processo inteiro do ciclo de vida do software e a entrega contínua.
No terceiro artigo, abordamos a instalação e configuração do GitLab e a conexão dos seus ambientes a ele
Neste artigo, finalmente, vamos escrever uma configuração de CD.
Em primeiro lugar, precisamos de vários ambientes e branches que correspondam a eles:
| Environment | Branch | Delivery | Who can commit | Who can merge |
|---|---|---|---|---|
| Test | master | Automatic | Developers Owners | Developers Owners |
| Preprod | preprod | Automatic | No one | Owners |
| Prod | prod | Semiautomatic (press button to deliver) | No one | Owners |
E, como exemplo, desenvolveremos um novo recurso usando o fluxo do GitLab e o entregaremos usando a CD do GitLab.
Veja como isso ficaria (marquei as partes que precisamos desenvolver para o CD em itálico):
Ou o mesmo, mas em formato de gráfico:
Nosso aplicativo consiste em duas partes:
Com o plano acima, podemos determinar as etapas que precisamos definir na nossa configuração de entrega contínua:
Veja como isso fica no arquivo de configuração gitlab-ci.yml:
stages: - load - test - package - deploy
Em seguida, vamos definir os scripts. Documentos de scripts. Primeiro, vamos definir um script load server que carrega o código do lado do servidor:
load server:
environment:
name: test
url: http://test.hostname.com
only:
- master
tags:
- test
stage: load
script: csession IRIS "##class(isc.git.GitLab).load()"O que acontece aqui?
Observação importante
Para InterSystems IRIS, troque csession por iris session.
Para Windows, use: irisdb -s ../mgr -U TEST "##class(isc.git.GitLab).load()
Agora, vamos escrever a classe isc.git.GitLab correspondente. Todos os pontos de entrada nessa classe ficam desta forma:
ClassMethod method()
{
try {
// code
halt
} catch ex {
write !,$System.Status.GetErrorText(ex.AsStatus()),!
do $system.Process.Terminate(, 1)
}
}
Observe que esse método pode terminar de duas maneiras:
Dito isso, aqui está nosso código de carregamento:
/// Do a full load
/// do ##class(isc.git.GitLab).load()
ClassMethod load()
{
try {
set dir = ..getDir()
do ..log("Importing dir " _ dir)
do $system.OBJ.ImportDir(dir, ..getExtWildcard(), "c", .errors, 1)
throw:$get(errors,0)'=0 ##class(%Exception.General).%New("Load error")
halt
} catch ex {
write !,$System.Status.GetErrorText(ex.AsStatus()),!
do $system.Process.Terminate(, 1)
}
}
Dois métodos de utilitários são chamados:
Como podemos obter o diretório?
Quando o GitLab executa um script, primeiro, ele especifica várias variáveis de ambiente. Uma delas é a CI_PROJECT_DIR — o caminho completo onde o repositório é clonado e onde o job é executado. Ele pode ser obtido facilmente no nosso método getDir :
ClassMethod getDir() [ CodeMode = expression ]
{
##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR"))
}
####Testes
Aqui está o script de teste:
load test:
environment:
name: test
url: http://test.hostname.com
only:
- master
tags:
- test
stage: test
script: csession IRIS "##class(isc.git.GitLab).test()"
artifacts:
paths:
- tests.htmlO que mudou? O nome e o código do script, é claro, mas o artefato também foi adicionado. Um artefato é uma lista de arquivos e diretórios que são anexados a um job depois que ele é concluído com sucesso. No nosso caso, depois que os testes forem concluídos, podemos gerar a página HTML redirecionando para os resultados dos testes e disponibilizá-la a partir do GitLab.
Observe que há bastante copiar e colar do estágio de carregamento — o ambiente é o mesmo, partes do script, como ambientes, podem ser rotuladas separadamente e anexadas a um script. Vamos definir o ambiente de teste:
.env_test: &env_test
environment:
name: test
url: http://test.hostname.com
only:
- master
tags:
- testAgora, nosso script de teste fica assim:
load test:
<<: *env_test
script: csession IRIS "##class(isc.git.GitLab).test()"
artifacts:
paths:
- tests.htmlEm seguida, vamos executar os testes usando o framework UnitTest.
/// do ##class(isc.git.GitLab).test()
ClassMethod test()
{
try {
set tests = ##class(isc.git.Settings).getSetting("tests")
if (tests'="") {
set dir = ..getDir()
set ^UnitTestRoot = dir
$$$TOE(sc, ##class(%UnitTest.Manager).RunTest(tests, "/nodelete"))
$$$TOE(sc, ..writeTestHTML())
throw:'..isLastTestOk() ##class(%Exception.General).%New("Tests error")
}
halt
} catch ex {
do ..logException(ex)
do $system.Process.Terminate(, 1)
}
}
A definição do teste, nesse caso, é um caminho relativo à raiz do repositório onde os testes de unidade são armazenados. Se estiver vazio, pulamos testes. O método writeTestHTML é usado para gerar o html com um redirecionamento para os resultados dos testes:
ClassMethod writeTestHTML()
{
set text = ##class(%Dictionary.XDataDefinition).IDKEYOpen($classname(), "html").Data.Read()
set text = $replace(text, "!!!", ..getURL())
set file = ##class(%Stream.FileCharacter).%New()
set name = ..getDir() _ "tests.html"
do file.LinkToFile(name)
do file.Write(text)
quit file.%Save()
}
ClassMethod getURL()
{
set url = ##class(isc.git.Settings).getSetting("url")
set url = url _ $system.CSP.GetDefaultApp("%SYS")
set url = url_"/%25UnitTest.Portal.Indices.cls?Index="_ $g(^UnitTest.Result, 1) _ "&$NAMESPACE=" _ $zconvert($namespace,"O","URL")
quit url
}
ClassMethod isLastTestOk() As %Boolean
{
set in = ##class(%UnitTest.Result.TestInstance).%OpenId(^UnitTest.Result)
for i=1:1:in.TestSuites.Count() {
#dim suite As %UnitTest.Result.TestSuite
set suite = in.TestSuites.GetAt(i)
return:suite.Status=0 $$$NO
}
quit $$$YES
}
XData html
{
<html lang="en-US">
<head>
<meta charset="UTF-8"/>
<meta http-equiv="refresh" content="0; url=!!!"/>
<script type="text/javascript">
window.location.href = "!!!"
</script>
</head>
<body>
If you are not redirected automatically, follow this <a href='!!!'>link to tests</a>.
</body>
</html>
}Nosso cliente é uma página HTML simples:
<html>
<head>
<script type="text/javascript">
function initializePage() {
var xhr = new XMLHttpRequest();
var url = "${CI_ENVIRONMENT_URL}:57772/MyApp/version";
xhr.open("GET", url, true);
xhr.send();
xhr.onloadend = function (data) {
document.getElementById("version").innerHTML = "Version: " + this.response;
};
var xhr = new XMLHttpRequest();
var url = "${CI_ENVIRONMENT_URL}:57772/MyApp/author";
xhr.open("GET", url, true);
xhr.send();
xhr.onloadend = function (data) {
document.getElementById("author").innerHTML = "Author: " + this.response;
};
}
</script>
</head>
<body onload="initializePage()">
<div id = "version"></div>
<div id = "author"></div>
</body>
</html>E, para criá-la, precisamos substituir ${CI_ENVIRONMENT_URL} pelo seu valor. Claro, um aplicativo real provavelmente exigiria npm, mas esse é apenas um exemplo. Aqui está o script:
package client:
<<: *env_test
stage: package
script: envsubst < client/index.html > index.html
artifacts:
paths:
- index.htmlPor fim, implantamos nosso cliente ao copiar index.html para o diretório raiz do servidor web.
deploy client: <<: *env_test stage: deploy script: cp -f index.html /var/www/html/index.html
É isso!
O que fazer se você precisar executar o mesmo script (semelhante) em vários ambientes? Partes do script também podem ser rótulos, então aqui está uma configuração de exemplo que carrega o código em ambientes de teste e pré-produção:
stages:
- load
- test
.env_test: &env_test
environment:
name: test
url: http://test.hostname.com
only:
- master
tags:
- test
.env_preprod: &env_preprod
environment:
name: preprod
url: http://preprod.hostname.com
only:
- preprod
tags:
- preprod
.script_load: &script_load
stage: load
script: csession IRIS "##class(isc.git.GitLab).loadDiff()"
load test:
<<: *env_test
<<: *script_load
load preprod:
<<: *env_preprod
<<: *script_loadAssim, podemos fugir de copiar e colar o código.
Veja a configuração de CD completa aqui. Ela segue o plano original de mover código entre os ambientes de teste, pré-produção e produção.
A entrega contínua pode ser configurada para automatizar qualquer fluxo de trabalho de desenvolvimento necessário.
No próximo artigo, vamos criar a configuração de CD que usa o contêiner Docker do InterSystems IRIS.
Nesta série de artigos, quero apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com tecnologias da InterSystems e do GitLab. Vou cobrir tópicos como:
No primeiro artigo, abordamos os fundamentos do Git, por que um entendimento de alto nível dos conceitos do Git é importante para o desenvolvimento de software moderno e como o Git pode ser usado para desenvolver software.
No segundo artigo, abordamos o fluxo de trabalho do GitLab: um processo inteiro do ciclo de vida do software e a entrega contínua.
Neste artigo, vamos discutir:
Vamos instalar o GitLab no local. Há várias maneiras de instalar o GitLab — da fonte, pacote, em um contêiner. Não descreverei todos os passos aqui, há um guia para isso. Ainda assim, algumas observações.
Pré-requisitos:
Primeiro de tudo, você provavelmente precisa enviar e-mails com notificações.
Em seguida, recomendo instalar Páginas. Como discutido no artigo anterior — artefatos do script podem ser enviados para o GitLab. O usuário pode fazer o download deles, mas é útil poder abri-los diretamente no navegador e, para isso, precisamos de páginas.
Por que você precisa de páginas:
Como as páginas html podem ter um redirecionamento onload, elas podem ser usadas para enviar o usuário para onde precisamos. Por exemplo, veja este código que gera uma página html que envia um usuário para o último teste de unidade executado (no momento da geração do html):
ClassMethod writeTestHTML()
{
set text = ##class(%Dictionary.XDataDefinition).IDKEYOpen($classname(), "html").Data.Read()
set text = $replace(text, "!!!", ..getURL())
set file = ##class(%Stream.FileCharacter).%New()
set name = "tests.html"
do file.LinkToFile(name)
do file.Write(text)
quit file.%Save()
}
ClassMethod getURL()
{
set url = "http://host:57772"
set url = url _ $system.CSP.GetDefaultApp("%SYS")
set url = url_"/%25UnitTest.Portal.Indices.cls?Index="_ $g(^UnitTest.Result, 1) _ "&$NAMESPACE=" _ $zconvert($namespace,"O","URL")
quit url
}
XData html
{
If you are not redirected automatically, follow this link to tests.
}Encontrei um bug usando as páginas (erro 502 ao procurar artefatos), veja aqui a correção.
Para executar scripts de CD, você precisa de ambientes, servidores configurados para executar seu aplicativo. Presumindo que você tem um servidor Linux com o produto InterSystems instalado (digamos InterSystems IRIS, mas funciona também com o Caché e Ensemble), estas etapas conectam o ambiente ao GitLab:
Observação importante sobre a instalação do runner GitLab, NÃO clone servidores após instalar o runner do GitLab. Os resultados são imprevisíveis e muito indesejados.
Após executar o inicial:
sudo gitlab-runner register
você verá vários prompts e, embora a maioria das etapas seja bastante direta, várias não são:
Insira o token gitlab-ci para este runner
Há vários tokens disponíveis:
Conforme você conecta um runner para executar a CD para um projeto específico, você precisa especificar um token para este projeto.
Insira as tags gitlab-ci para este runner (separadas por vírgulas):
Na configuração de CD, você pode filtrar quais scripts vão ser executados em quais tags. Então, no caso mais simples, especifique uma tag, que seria o nome do ambiente.
Insira o executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker
Se você estiver usando o servidor habitual sem docker, escolha shell. O Docker será discutido nas partes posteriores.
Depois de conectar o runner ao GitLab, precisamos permitir que ele interaja com o InterSystems IRIS, para isso:
Para 2 e 3, outras abordagens podem ser usadas, como a transmissão de usuário/código, mas acho que a autenticação de SO é preferível.
Nesta parte:
Na próxima parte, escrevemos nossa configuração de entrega contínua.
Nesta série de artigos, quero apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com tecnologias da InterSystems e do GitLab. Vou cobrir tópicos como:
No artigo anterior, abordamos os fundamentos do Git, por que um entendimento de alto nível dos conceitos do Git é importante para o desenvolvimento de software moderno e como o Git pode ser usado para desenvolver software. Ainda assim, nosso foco foi na parte da implementação do desenvolvimento de software, mas esta parte apresenta:
O fluxo de trabalho do GitLab é uma sequência lógica de possíveis ações a serem tomadas durante todo o ciclo de vida do processo de desenvolvimento de software.
O fluxo de trabalho do GitLab leva em consideração o fluxo do GitLab, que discutimos em um artigo anterior. Veja como funciona:
Novamente, o processo em si não é novo (ou exclusivo do GitLab) e pode ser alcançado com outras ferramentas da sua escolha.
Vamos discutir várias dessas etapas e o que elas implicam. Também há documentação disponível.
As etapas iniciais do fluxo de trabalho do GitLab são centradas em um problema: um recurso, bug ou outro tipo de trabalho semanticamente separado.
O problema tem várias finalidades, como:
A etapa de planejamento nos permite agrupar os problemas por prioridade, marco, quadro kanban e ter uma visão geral disso.
O desenvolvimento foi discutido na parte anterior, basta seguir qualquer fluxo git que quiser. Depois que desenvolvemos nosso novo recurso e o mesclamos no master: o que vem depois?
A entrega contínua é uma abordagem de engenharia de software em que as equipes produzem software em ciclos curtos, garantindo que o software possa ser lançado de forma confiável a qualquer momento. Seu objetivo é construir, testar e lançar software com mais rapidez e frequência. A abordagem ajuda a reduzir o custo, o tempo e o risco da entrega de alterações, permitindo mais atualizações incrementais para aplicativos em produção. Um processo de implantação simples e repetível é importante para a entrega contínua.
No GitLab, a configuração da entrega contínua é definida por repositório como um arquivo de configuração YAML.
O script define uma ação e quais condições devem ser atendidas para executá-la:
Ambiente - é um servidor ou contêiner configurado no qual você pode executar seus scripts.
Runners executam scripts em ambientes específicos. Eles são conectados ao GitLab e executam scripts conforme necessário.
O runner pode ser implantado em um servidor, contêiner ou até mesmo na sua máquina local.
Como acontece a entrega contínua?
Por exemplo, aqui está um pipeline executado após um commit em um branch master:
Ele consiste em quatro etapas, executadas consecutivamente
Como podemos ver, todos os scripts foram executados com sucesso. Se um dos scripts falhar, por padrão, os scripts posteriores não são executados (mas podemos alterar esse comportamento):
Se abrirmos o script, podemos ver o log e determinar por que ele falhou:
Running with gitlab-runner 10.4.0 (857480b6)
on test runner (ab34a8c5)
Using Shell executor...
Running on gitlab-test...
<span class="term-fg-l-green term-bold">Fetching changes...</span>
Removing diff.xml
Removing full.xml
Removing index.html
Removing tests.html
HEAD is now at a5bf3e8 Merge branch '4-versiya-1-0' into 'master'
From http://gitlab.eduard.win/test/testProject
* [new branch] 5-versiya-1-1 -> origin/5-versiya-1-1
a5bf3e8..442a4db master -> origin/master
d28295a..42a10aa preprod -> origin/preprod
3ac4b21..7edf7f4 prod -> origin/prod
<span class="term-fg-l-green term-bold">Checking out 442a4db1 as master...</span>
<span class="term-fg-l-green term-bold">Skipping Git submodules setup</span>
<span class="term-fg-l-green term-bold">$ csession ensemble "##class(isc.git.GitLab).loadDiff()"</span>
[2018-03-06 13:58:19.188] Importing dir /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/
[2018-03-06 13:58:19.188] Loading diff between a5bf3e8596d842c5cc3da7819409ed81e62c31e3 and 442a4db170aa58f2129e5889a4bb79261aa0cad0
[2018-03-06 13:58:19.192] Variable modified
var=$lb("MyApp/Info.cls")
Load started on 03/06/2018 13:58:19
Loading file /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/MyApp/Info.cls as udl
Load finished successfully.
[2018-03-06 13:58:19.241] Variable items
var="MyApp.Info.cls"
var("MyApp.Info.cls")=""
Compilation started on 03/06/2018 13:58:19 with qualifiers 'cuk /checkuptodate=expandedonly'
Compiling class MyApp.Info
Compiling routine MyApp.Info.1
ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1]
TEXT: quit, "1.0" }
Detected 1 errors during compilation in 0.010s.
[2018-03-06 13:58:19.252] ERROR #5475: Error compiling routine: MyApp.Info.1. Errors: ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1]
> ERROR #5030: An error occurred while compiling class 'MyApp.Info'
<span class="term-fg-l-red term-bold">ERROR: Job failed: exit status 1
</span>O erro de compilação causou a falha do nosso script.
No próximo artigo, vamos:
Vamos discutir como a entrega contínua deve funcionar.
Em primeiro lugar, precisamos de vários ambientes e branches que correspondam a eles. O código entra nesse branch e é entregue ao ambiente de destino:
| Ambiente | Branch | Entrega | Quem pode fazer envios | Quem pode mesclar |
|---|---|---|---|---|
| Teste | master | Automático | Desenvolvedores Proprietários | Desenvolvedores Proprietários |
| Preprod | preprod | Automático | Ninguém | Proprietários |
| Prod | prod | Semiautomático (pressionar botão para entregar) | Ninguém | Proprietários |
E, como exemplo, desenvolveremos um novo recurso usando o fluxo do GitLab e o entregaremos usando a CD do GitLab.
Veja como ficaria:
Ou o mesmo, mas em formato gráfico:
Olá Comunidade,
Deseja obter ajuda, discutir um recurso interessante, fazer um anúncio ou compartilhar seu conhecimento? Neste post, vamos dizer-lhe como fazer tudo isso.
Para facilitar a navegação neste "como fazer" basta seguir o conteúdo:
Para começar, você precisa clicar no botão "Nova postagem" no menu superior do site da Comunidade de desenvolvedores:
.png)
Depois disso, você verá o editor que lhe dará a opção de criar uma Pergunta, um Anúncio, um Artigo ou uma Discussão. Diferentes tipos de postagens têm seus próprios conjuntos de campos obrigatórios e opcionais.
Se você sabe vários idiomas e gostaria de compartilhar seu conhecimento com usuários de outras partes do mundo que não falam Português?
Agora é sua hora de brilhar! 🤩
Com nossa Comunidade de Desenvolvedores é fácil associar seu artigo original com a sua tradução em outro idioma (ou mesmo solicitar que seja feita a tradução).
Vamos conversar um pouco sobre como criar sua própria tradução:
Todo mundo tem um ambiente de teste.
Algumas pessoas têm a sorte de ter um ambiente totalmente separado para executar a produção.
-- Desconhecido
.
Nesta série de artigos, gostaria de apresentar e discutir várias abordagens possíveis para o desenvolvimento de software com as tecnologias InterSystems e GitLab. Vou cobrir tópicos como:
Esta primeira parte trata do pilar do desenvolvimento de software moderno - sistema de controle de versão Git e vários fluxos Git.
Embora o tópico principal que iremos discutir seja o desenvolvimento de software em geral e como o GitLab pode nos capacitar nesse esforço, o Git, ou melhor, os vários conceitos de alto nível subjacentes no design do Git, são importantes para o melhor entendimento de conceitos posteriores.
Dito isso, o Git é um sistema de controle de versão, baseado nessas ideias (existem muitas outras, essas são as mais importantes):
Agora, não estou dizendo que Git inventou esses conceitos. Não. Em vez disso, o Git os tornou fáceis e populares e isso, juntamente com várias inovações relacionadas, ou seja, infraestrutura como código/conteinerização mudou o desenvolvimento de software.
Repositório é um projeto que armazena dados e metainformações sobre os dados.
O repositório pode ser armazenado:
Mas não há nenhuma diferença particular entre repositórios locais e remotos do ponto de vista do git.
Commit é um estado fixo do repositório. Obviamente, se cada commit armazenasse o estado completo do repositório, nosso repositório cresceria muito rapidamente. É por isso que um commit armazena um diff que é uma diferença entre o commit atual e seu commit pai.
Commits diferentes podem ter um número diferente de pais:
2 - pode acontecer quando unimos mais de 2 estados diferentes do repositório em um novo estado. Não seria particularmente relevante para nossa discussão, mas existe.
Agora, para um pai, cada commit diferente é chamado de commit filho. Cada commit pai pode ter qualquer número de commits filhos.
Branch é uma referência (ou ponteiro) para um commit. Veja como funciona:
Nesta imagem, podemos ver o repositório com dois commits (círculos cinza), o segundo é o head do branch master. Depois de adicionar mais commits, nosso repositório começa a ficar assim:
Esse é o caso mais simples. Um desenvolvedor trabalha em uma mudança de cada vez. No entanto, normalmente, existem muitos desenvolvedores trabalhando simultaneamente em diferentes recursos e precisamos de uma árvore de commit para mostrar o que está acontecendo em nosso repositório.
Vamos começar do mesmo ponto de partida. Aqui está o repositório com dois commits:
Mas agora, dois desenvolvedores estão trabalhando ao mesmo tempo e para não interferir um no outro, eles trabalham em branches separados:
Depois de um tempo, eles precisam unir as alterações feitas e para isso eles criam uma solicitação de mesclagem (merge) (também chamada de pull request) - que é exatamente o que parece - é uma solicitação para unir dois estados diferentes do repositório (no nosso caso, queremos mesclar o develop branch no master branch) em um novo estado. Depois de ser devidamente revisado e aprovado, nosso repositório fica assim:
E o desenvolvimento continua:
Conceitos principais:
Se você quiser ler mais sobre o Git, existem livros disponíveis.
Agora que o leitor está familiarizado com os termos e conceitos básicos do Git, vamos falar sobre como a parte do desenvolvimento do ciclo de vida do software pode ser gerenciada usando o Git. Existem várias práticas (chamadas de fluxos) que descrevem o processo de desenvolvimento usando Git, mas vamos falar sobre duas delas:
O fluxo do GitHub é tão fácil quanto parece. Aqui está:
E existem várias regras que devemos seguir:
master branch é sempre implantável (e funcionando!)
Não há desenvolvimento indo diretamente para o master branch
O desenvolvimento está acontecendo nos branches de recursos
master == ambiente** de produção*
Você precisa implantar na produção o mais rápido possível
** Ambiente é um local configurado onde seu código é executado - pode ser um servidor, uma VM, até mesmo um contêiner.
Veja como funciona:
Você pode ler mais sobre o fluxo do GitHub aqui. Também há um guia ilustrado.
O fluxo do GitHub é bom para pequenos projetos e para testes se você está começando com os fluxos do Git. No entanto, o GitHub o usa, portanto, também pode ser viável em projetos grandes.
Se você não estiver pronto para implantar na produção imediatamente, o fluxo do GitLab oferece um fluxo do GitHub + ambientes. É assim que funciona - você desenvolve em branches de recursos, como acima, mescla (merge) no master, como acima, mas aqui está uma diferença: o master é igual apenas no ambiente de teste. Além disso, você tem "Branches de ambiente" que estão vinculados a vários outros ambientes que você possa ter.
Normalmente, existem três ambientes (você pode criar mais se precisar):
O código que chega em um dos branches do ambiente deve ser movido para o ambiente correspondente imediatamente, isso pode ser feito:
Todo o processo é assim:
Veja como funciona:
Você pode ler mais sobre o fluxo do GitLab aqui.
Na próxima parte, iremos:
Fique ligado.
Olá membros da Comunidade de Desenvolvedores,
Nesta postagem nós gostaríamos de mostrar a vocês como usar as tags da Comunidade de Desenvolvedores. Vamos aproveitar o máximo desta funcionalidade da Comunidade de Desenvolvedores!
Olá Desenvolvedores,
Nós lançamos um novo canal educacional no Global Masters - o GM Academy!
Ele contém materiais educacionais selecionados do portal de Aprendizado Online da InterSystems.
No momento temos 2 cursos para iniciantes: a trilha de aprendizagem Caché e a trilha de aprendizagem InterSystems IRIS.
Mas, dependendo do que vocês gostariam de aprender, nós iremos adicionar mais e mais conteúdos. Então? O que vocês gostariam de aprender ?
Responda neste desafio inicial!
É possível ativar Ctrl + C / Ctrl + V no Terminal IRIS para Windows.
Para fazer isso, abra o Terminal e selecione Editar> Configurações do usuário e habilite os aceleradores de edição do Windows. Esta configuração especifica se o Terminal habilita os atalhos de edição comuns do Windows (Ctrl + C, Ctrl + V, Ctrl + Shift + V), além dos atalhos de edição básicos do Terminal (Ctrl + Insert e Shift + Insert).
Depois disso, Ctrl + C / Ctrl + V funcionaria.
Além disso, os erros <SYNTAX> após copiar / colar incorreto desaparecem.
Estou planejando implementar a Inteligência de Negócio (BI) com base nos dados de minhas instâncias. Qual é a melhor maneira de configurar meus bancos de dados e ambiente para usar o DeepSee?
Este tutorial aborda essa questão mostrando três exemplos de arquitetura para DeepSee. Começaremos com um modelo de arquitetura básico e destacaremos suas limitações. O modelo subsequente é recomendado para aplicações de Inteligência de Negócio (BI) de complexidade intermediária e deve ser suficiente para a maioria dos casos de uso. Terminaremos este tutorial descrevendo como aumentar a flexibilidade da arquitetura para gerenciar implementações avançadas.
Cada exemplo neste tutorial apresenta novos bancos de dados e mapeamentos globais, junto com uma discussão sobre por que e quando eles devem ser configurados. Ao construir a arquitetura, os benefícios fornecidos pelos exemplos mais flexíveis serão destacados.
Para tornar os dados altamente disponíveis, a InterSystems geralmente recomenda usar as soluções de espelhamento ou sombreamento e então basear a implementação DeepSee no servidor espelho/sombra. A máquina que hospeda a cópia original dos dados é chamada de servidor Primário, enquanto as máquinas que hospedam cópias dos dados e as aplicações de Inteligência de Negócio (BI) costumam ser chamados de servidores Analíticos (ou, às vezes, de Relatórios)
Ter servidores primários e analíticos é muito importante, o principal motivo é evitar problemas de desempenho em qualquer um dos servidores. Verifique a documentação sobre a Arquitetura Recomendada.
Armazenar dados de origem e código no mesmo banco de dados geralmente funciona bem apenas para aplicações de pequena escala. Para aplicações mais extensas, é recomendado armazenar os dados de origem e código em dois bancos de dados dedicados, o que permite compartilhar o código com todos os namespaces onde o DeepSee é executado, mantendo os dados separados. O banco de dados de dados de origem deve ser espelhado no servidor de produção. Este banco de dados pode ser somente leitura ou leitura-gravação. É recomendável manter o registro do diário habilitado para este banco de dados.
As classes de origem e as aplicações personalizados devem ser armazenados em um banco de dados dedicado nos servidores de produção e analítico. Observe que esses dois bancos de dados para o código-fonte não precisam estar sincronizados ou mesmo rodar a mesma versão do Caché. Normalmente, o registro no diário não é necessário, desde que o backup do código seja feito regularmente em outro lugar.
Neste tutorial teremos a seguinte configuração. O namespace do APP no servidor analítico tem o APP-DATA e o APP-CODE como bancos de dados padrão. O banco de dados APP-DATA tem acesso aos dados (a classe da tabela de origem e seus fatos) no banco de dados de dados de origem no Primário. O banco de dados APP-CODE armazena o código Caché (arquivos .cls e .INT) e outros códigos personalizados. Essa separação de dados e código é uma arquitetura típica e permite ao usuário, por exemplo, implantar com eficiência o código DeepSee e a aplicação personalizada.
As implementações de Inteligência de Negócio (BI) usando DeepSee geralmente são executadas a partir de namespaces diferentes. Nesta postagem, mostraremos como configurar um único namespace de APP, mas o mesmo procedimento se aplica a todos os namespaces onde a aplicação de inteligência de negócio é executada.
Recomenda-se familiarizar-se com a página de documentação Executando a Configuração Inicial. Esta página inclui a configuração de aplicações web, como colocar DeepSee globais em bancos de dados separados e uma lista de mapeamentos alternativos para DeepSee globais.
Na segunda parte desta série mostraremos com a implementação de um modelo básico de arquitetura