Pesquisar

Olá desenvolvedores, É um prazer anunciar o próximo webinar em Inglês chamado "InterSystems IRIS & roadmap da Indústria 4.0- Smart Factory Starter Pack"! 🗓 Data & horário: 31 de Março de 2021, 09:00 horário de Brasília 🗣 Palestrantes: @Marco.denHartog, CTO, ITvisors @Aldo.Verlinde9118, Sales Engineer, InterSystems As organizações de manufatura hoje estão transformando rapidamente suas fábricas existentes em "fábricas inteligentes". Em uma fábrica inteligente, os dados dos sistemas de Tecnologias Operacionais (TO) e os sinais em tempo real do chão de fábrica são combinados com os aplicativos empresariais de TI e analíticos. Isso permite que os fabricantes melhorem a qualidade e a eficiência, respondam mais rapidamente aos eventos e prevejam e evitem problemas antes que eles ocorram, entre muitos outros benefícios. Neste webinar, discutimos os 5 níveis de maturidade em relação à Indústria 4.0 de um ponto de vista baseado em dados e como o IRIS e o Smart Factory Starter Pack estão ajudando os fabricantes em cada nível: Coleta de dados: conexões fáceis para muitos tipos diferentes de fontes Unificação de dados: dados limpos, gerenciamento de dados, preenchendo a lacuna de TO / TI, ... Exploração de dados: variedade de ferramentas, conectividade (!), Banco de dados translítico, ... Operacionalização: Minimize a sobrecarga e os erros do operador, conexões bidirecionais (ERP, MES, fluxo de pedidos), banco de dados flexível e fácil de usar, ... Indústria 4.0: Modelagem de processos e equipamentos de produção, previsão de qualidade e desempenho, ciclo de melhoria contínua Descubra como o IRIS e o Smart Factory Starter Pack capacitam os fabricantes em suas iniciativas de fábrica inteligente Observação: O idioma do webinar é Inglês. ➡️ JUNTE-SE AO WEBINAR!

Migrando para InterSystems IRIS – Parte 02 (Instância única de Caché/Ensemble para IRIS) Olá, comunidade, nessa segunda parte do artigo vou dar dicas do processo de migração de uma instância única de InterSystems Caché e ou Ensemble para IRIS. Como comentado na 1ª parte do artigo, a ideia é passar dicas e não substituir os documentos oficiais que estão disponíveis no WRC, que são eles: InterSystems IRIS Adoption Guide; How to migrate to InterSystems IRIS. Vamos então agora colocar a mão na massa! O sistema operacional que estou usando como exemplo, é uma instalação em um ambiente Ubuntu: A instalação do Ensemble é a 2018.1.5: E nesta parte do artigo vamos tratar de uma instalação de única instância sem Mirror, Shadow ou ECP. Essa segunda parte vale ressaltar duas situações que podemos passar: 1º - Instalação do IRIS na mesma máquina onde se encontra o Caché ou Ensemble; 2º - Instalação do IRIS em uma nova máquina. Para ambos os cenários: consultar os pré-requisitos mencionados na primeira parte do artigo. Mas antes de entrar nas sessões aqui uma primeira dica válida para ambas as sessões: BACKUP / BACKUP / BACKUP / BACKUP / BACKUP / BACKUP / BACKUP / BACKUP / BACKUP Antes de iniciar quaisquer procedimentos de migração, a outra dica é execute em: AMBIENTE DE TESTE / AMBIENTE DE TESTE / AMBIENTE DE TESTE / AMBIENTE DE TESTE Queria me desculpar por repetir a palavra BACKUP e AMBIENTES DE TESTE, em caixa alta, mas essa dica é a mais primordial, quem nunca precisou de um backup em um momento tenso e alguém acabou esquecendo-o, que jogue a primeira pedra. Uma outra pergunta recorrente de clientes: Quais Releases Caché e Ensemble são suportadas para migrar o IRIS? No documento oficial que você pode executar o download através do WRC: “How to Migrate to InterSystems IRIS” existe um tópico chamado: “Supported Migration Paths”, neste tópico existe uma matriz da versão origem e qual versão destino do IRIS são compatíveis, um exemplo: No mesmo documento “How to Migrate to InterSystems IRIS” existe um tópico chamado: “Performing Pre-Migration Tasks”, a leitura deste tópico eu diria que é mandatório. Mas vamos lá, como podemos encontrar duas situações vou exemplificar ambas nesta parte do artigo em duas sessões: 1 – Sessão: Instalação do IRIS na mesma máquina onde se encontra o Caché ou Ensemble. No exemplo estou utilizando o usuário root, pois estou em um ambiente de laboratório. Lembre-se, de usar o sudo para execução dos comandos que necessitem de permissões root. Ambiente exemplo: Podem perceber que estou com uma instância que se chama: ENSEMBLE. Os passos que vou exemplificar aqui valem tanto para Caché ou Ensemble, salvo quando vamos falar de parar a Produção do Ensemble. O primeiro passo para ambientes Ensemble é desativar o início automático da Produção: O próximo passo é desligar a produção: Uma dica importante: caso você possua mais de uma produção, lembre-se que você pode para todas as produções via terminal: Agora vamos parar o Ensemble ou Caché com segurança: Lembre-se de passar o nome da instância, no nosso exemplo a instância se chama ENSEMBLE: Importante verificar o ccconsole.log se não ocorreu nenhum problema durante o shutdown: Reparem que as mensagens do Journal estão OK! Agora vamos executar o instalador do IRIS. Lembre-se que você precisa ter permissão de root nesta etapa, ou executar com sudo. No diretório onde você extraiu o kit de instalação, execute: irisinstall Vocês podem observar que ao executar o comando de instalação já foi identificado a nossa instância do Ensemble. Nesta opção vamos adicionar o nome da instância, que no caso do nosso exemplo é ENSEMBLE. Ao digitar o nome da instância, o instalador questionará sobre a atualização para IRIS: E olha aqui novamente a mensagem importantíssima: Você já tem BACKUP? Caso já tenha feito o Backup, vamos pressionar YES e seguir com a instalação. Após pressionar YES, o instalador questionará sobre a licença do IRIS: Lembre-se de informar o path correto, mais o nome da licença: Após a licença ser validada, agora é só pressionar YES para iniciar a conversão! Pronto! Processo de conversão finalizada: Você pode verificar aqui uma primeira mudança de comando, ao invés de utilizar o ccontrol list, agora você executará o iris list para verificar a instância. Vocês podem reparar que o nome da instância, local da instalação e portas são os mesmos, e que a instancia já está no ar. Eu utilizei de propósito o nome da minha instalação de ENSEMBLE para evidenciar que quando executamos a instalação na mesma máquina o instalador mantém todas as características da instalação corrente. Acessando a URL que você já estava acostumado a acessar, você pode entrar no portal do IRIS: O ambiente ainda não está pronto para ser liberado para os usuários! Agora você precisa revisar o seu código, mas como você seguiu as dicas iniciais você já leu o IRIS Migration Guide, e já tem mapeado o que foi deprecado ou renomeado para que você atualize seu código. Agora com o código revisado, vamos recompilar tudo! Lembre-se que você precisa executar esta etapa em todos namespace. Primeiro vamos compilar as rotinas. Lembre-se que você pode compilar as rotinas pelo portal ou pelo terminal. Portal: Terminal: Aqui você pode compilar por namespace: Um exemplo de erros que podem ocorrer durante a compilação das rotinas. Neste caso recebemos um PROTECT, ou seja, são rotinas que estão em READ ONLY, e são rotinas padrões do sistema, neste caso não temos com o que se preocupar. Também é possível executar a compilação de todas as rotinas em todos namespaces, executando: do ##Class(%Routine).CompileAllNamespaces() Agora vamos compilar as classes, como as rotinas podemos compilar pelo portal ou terminal: Portal: Terminal: Para as classes também é possível compilar por namespace ou todos os namepaces: Caso sua aplicação possua CSP pages, elas precisam ser recarregadas e compiladas. Lembre-se que você precisa mudar o namespace e passar o diretório de onde se encontram as CSP Pages. Pronto agora é testar sua aplicação: Nesta primeira sessão executamos a instalação no mesmo servidor, agora vamos para a próxima sessão deste artigo: 2 – Sessão: Instalação do IRIS em uma nova máquina. A Instalação do IRIS em uma nova máquina irei publicar em um outro artigo, como continuação deste.

Olá Desenvolvedores, Aprendam o básico do gerenciamento de mensagens HL7® V2 no InterSystems IRIS for Health™: ⏯ Introdução a Integrações HL7 V2 no InterSystems IRIS for Health Curtam no Canal de Desenvolvedores InterSystems no YouTube e fique ligado!

O AtScale extrai dados da base IRIS.  O produto AtScale forma um cubo OLAP virtual na camada intermediária, que pode ser acessado pelos aplicativos externos usando a linguagem padrão SQL e MDX (Expressões Multidimensionais). A solução inclui três componentes principais. O Design Center é usado para projetar cubos OLAP, formando links entre os metadados e as dimensões de um cubo virtual. Junto com a tarefa de criar um esquema de dados, os problemas da política de acesso a determinados dados e segurança são resolvidos aqui. Como o Cubo Virtual não armazena Big Data fisicamente, garantir um desempenho aceitável é um problema sério.   O Cache Adaptável possibilita não só armazenar em cache os dados recentes ou usados com frequência, mas também prever quais dados serão necessários em breve para a pré-busca no cache. Para conectar o Logi ao AtScale, use o tipo de conexão JDBC Hive2 com o driver org.apache.hive.jdbc.HiveDriver. A vantagem desse tipo de conexão é a adição de um número ilimitado de cubos a um Catálogo. Isso possibilita criar relatórios complexos com um grande conjunto de dados. Além disso, é possível criar um diagrama dentro do Logi com base em cubos e criar links entre cubos do AtScale, o que amplia as possibilidades de geração de dados. Também é possível criar consultas SQL para cubos manualmente. Esse recurso não é usado com frequência, mas pode ser empregado para estabelecer relações manualmente ou projetar fórmulas SQL.  A maior parte da lógica para a geração de um conjunto de dados ocorre no lado do AtScale. O Logi (InterSystems Report Designer) aceita os conjuntos de dados gerados e visualiza esses dados. Conjunto de dados de teste do aplicativo Sales Insights (versões do AtScale >= 2019.2.x) "Ganhe insights sobre as tendências de vendas, o desempenho dos produtos e os detalhes dos clientes usando estes dados de amostra baseados no conjunto de dados do AdventureWorks." Ele pode ser baixado no link  Veja como esse conjunto de dados aparece no InterSystems Reports Designer  ### As principais vantagens que ganhamos ao usar esse pacote são: Possibilidade de geração automática de relatórios de acordo com a programação Opção de receber relatórios em PDF por e-mail Oportunidade de usar parâmetros automaticamente calculados para o relatório (datas) Aceleração da geração de relatórios (UDAF, agregados e caching) Capacidade de clonar, fazer backup e rapidamente propagar as mudanças no cubo do AtScale Extensão de funcionalidade do Logi: alguns dos parâmetros comparativos não eram calculados no Logi e DeepSee anteriormente Substituição da funcionalidade do Logi: cálculo dos indicadores comparativos dependendo das configurações de parâmetro no lado do AtScale ## Por que o UDAF é necessário para a Análise Adaptativa e como configurá-lo A Análise Adaptativa da InterSystems (com a tecnologia do AtScale) é um complemento poderoso ao BI do IRIS. Ela permite aos usuários o desenvolvimento mais rápido de painéis. Além disso, os responsáveis pelo desenvolvimento e pela manutenção podem alternar rapidamente entre as origens de dados. Por último, mas não menos importante, são os instantâneos das versões dos cubos de dados. Eles oferecem a capacidade de fazer backup da lógica de estrutura de dados e reverter, se necessário. Algumas das funções já estão prontas para uso. No entanto, uma opção importante precisa ser configurada. Refiro-me à opção que aumenta a velocidade dos Painéis e Relatórios. Ela é chamada de UDAF. Sem a configuração, você não verá a otimização ou melhoria do mecanismo de camada de abstração. Você pode acessar a distribuição do UDAF no mesmo local que a Análise Adaptativa. ### O UDAF oferece à análise adaptativa duas principais vantagens:  - a capacidade de armazenar os resultados da execução de consultas (chamadas de Tabelas Agregadas), para que a próxima consulta, usando a agregação de dados, possa usar resultados já calculados do banco de dados. - a capacidade de usar funções adicionais (como Funções Agregadas Definidas pelo Usuário) e algoritmos de processamento de dados que a Análise Adaptativa é forçada a armazenar na origem dos dados.  Eles são armazenados no banco de dados em tabelas separadas, e a Análise Adaptativa pode chamá-los pelo nome em consultas geradas automaticamente. Quando a Análise Adaptativa usa essas funções, a velocidade das consultas aumenta. O local onde todas essas tabelas serão armazenadas é especificado ao criar uma conexão ao IRIS no item AGGREGATE SCHEMA. Se esse esquema não existir no banco de dados, ele será criado. É uma boa ideia armazenar esse esquema em outro banco de dados. Explicarei o motivo disso depois.  Agora, imagine que o IRIS, conectado à análise adaptativa, é destinado somente para análise e contém apenas uma cópia dos dados de um banco de dados em execução (para que as solicitações dos sistemas analíticos não carreguem os recursos do banco de dados principal). Após determinado tempo, os dados do sistema principal são copiados para nosso IRIS, substituindo os dados antigos. Nesse caso, no momento da reescrita, todos os dados registrados pela Análise Adaptativa desaparecem, e temos o seguinte resultado: - as consultas que estão tentando acessar as tabelas agregadas não as acham e acabam com um erro. - as solicitações que usam as funções armazenadas no banco de dados não conseguem acessá-las e acabam com um erro. - ao excluir caminhos antigos para agregar tabelas, a Análise Adaptativa discretamente cria novos, e depois a situação repete-se. O descrito acima é apenas um dos casos possíveis de substituição de dados no IRIS, mas nem por isso é o mais comum. O principal problema é que a Análise Adaptativa não usa mecanismos de fallback ao evitar usar opções de UDAF e criar consultas diretas no caso de erros. Ela falha em informar atualizações de painéis ou desenvolvimento.  Podemos tentar carregar a tabela com as funções na base de dados e as atualizações manualmente. No entanto, conforme mencionado acima, UDAF não é somente as funções de processamento de dados, mas também as tabelas agregadas, e salvá-las novamente é bastante problemático. A solução para os problemas descritos acima é a criação de uma tabela de dados separada, em que a Análise Adaptativa escreverá as tabelas do serviço. Essa solução é descrita na documentação para conectar a Análise Adaptativa ao IRIS: Vale a pena mencionar que o nome do esquema especificado após "/<instancePath>/mgr/" precisa corresponder ao especificado como AGGREGATE SCHEMA com a Análise Adaptativa. Caso contrário, uma base de dados separada será criada, mas a Análise Adaptativa escreverá os dados para o esquema criado dentro da base de dados, ignorando a base separada recém-criada. Os desenvolvedores de UDAF recomendam usar "AtScale" como o nome desse esquema. É também o nome dado como exemplo na documentação. Caso esse banco de dados seja corrompido e os dados não possam ser recuperados, você pode desativar as agregações na Análise Adaptativa para recriá-los automaticamente na próxima solicitação.  Para fazer isso, na guia de agregados/instâncias, você precisa desativar cada agregado. São exibidos 20 agregados por página, então acesse cada página para verificar se todos estão desativados. Se você for usar a Análise Adaptativa, preste atenção nesse pequeno ponto. No início do meu trabalho com a Análise Adaptativa, essa opção foi configurada com um erro, então não tive todos os benefícios possíveis. Lembre-se também de conferir o nome da base de dados. Ela diferencia maiúsculas de minúsculas na configuração e no script da instalação de UDAF. Acredito que talvez haja algumas opções que desconheço no momento, assim como a influência no desempenho dos meus sistemas analíticos. Se você encontrar algo, escreva nos comentários. 

Olá Comunidade, Vamos nos encontrar virtualmente na nossa Segunda Mesa Redonda da Comunidade!Esta será uma discussão envolvente de 45 minutos sobre um tópico específico: Qual é o melhor sistema de controle de fontes para desenvolvimento com InterSystems IRIS. >> Inscreva-se aqui << Palestrante: @Evgeny.Shvarov Co-palestrantes: @Dmitry.Maslennikov and @Timothy.Leavitt 📅 Data: 27 Outubro🕑 Horário: 10:00 horário de Brasília >> Inscreva-se aqui <<Você tem perguntas específicas sobre o tópico que será discutido na mesa redonda? Por favor compartilhe-os nos comentários!

[Nesta série de artigos](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-índice), 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: * Git básico * Fluxo Git (processo de desenvolvimento) * Instalação do GitLab * Fluxo de trabalho do GitLab * Entrega contínua * Instalação e configuração do GitLab * CI/CD do GitLab * Por que contêineres? * Infraestrutura dos contêineres * CD usando contêineres * **CD usando ICM** Neste artigo, vamos desenvolver a entrega contínua com o InterSystems Cloud Manager. O ICM é uma solução de provisionamento e implantação na nuvem para aplicativos baseados no InterSystems IRIS. Ele permite definir a configuração de implantação desejada e o ICM provisiona de maneira automática. Para mais informações, consulte [First Look: ICM](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=AFL_icm). Fluxo de trabalho Na nossa configuração de entrega contínua: * Enviamos código para o repositório do GitLab * Criamos a imagem docker * Publicamos a imagem no registro docker * Testamos em um servidor de teste * Se os testes forem aprovados, implantamos em um servidor de produção Ou em formato gráfico: Como você pode ver, é praticamente igual, exceto que usaríamos o ICM em vez de gerenciar os contêineres do Docker manualmente. ## Configuração do ICM Antes de atualizar os contêineres, eles devem ser provisionados. Para isso precisamos definir defaults.json e definitions.json, descrevendo nossa arquitetura. Vou fornecer esses 2 arquivos para um servidor LIVE, as definições para um servidor TEST são as mesmas, e os padrões são os mesmos, exceto para os valores Tag e SystemMode. #### defaults.json: { "Provider": "GCP", "Label": "gsdemo2", "Tag": "LIVE", "SystemMode": "LIVE", "DataVolumeSize": "10", "SSHUser": "sample", "SSHPublicKey": "/icmdata/ssh/insecure.pub", "SSHPrivateKey": "/icmdata/ssh/insecure", "DockerImage": "eduard93/icmdemo:master", "DockerUsername": "eduard93", "DockerPassword": "...", "TLSKeyDir": "/icmdata/tls", "Credentials": "/icmdata/gcp.json", "Project": "elebedyu-test", "MachineType": "n1-standard-1", "Region": "us-east1", "Zone": "us-east1-b", "Image": "rhel-cloud/rhel-7-v20170719", "ISCPassword": "SYS", "Mirror": "false" } #### definitions.json [ { "Role": "DM", "Count": "1", "ISCLicense": "/icmdata/iris.key" } ] Dentro do contêiner ICM, a pasta /icmdata é montada a partir do host e: * As definições do servidor TEST são colocadas na pasta /icmdata/test * As definições do servidor LIVE são colocadas na pasta /icmdata/live Depois de obter todas as chaves necessárias: keygenSSH.sh /icmdata/ssh keygenTLS.sh /icmdata/tls E colocar os arquivos necessários em /icmdata: * iris.key * gcp.json (para a implantação no Google Cloud Platform) Chame o ICM para provisionar suas instâncias: cd /icmdata/test icm provision icm run cd /icmdata/live icm provision icm run Um servidor TEST e um servidor LIVE seriam provisionados com uma instância do InterSystems IRIS independente em cada um. Consulte [ICM First Look](http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=AFL_icm) para ver um guia mais detalhado. Criação Primeiro, precisamos criar nossa imagem. Nosso código seria, como sempre, armazenado no repositório, a configuração de CD em gitlab-ci.yml. No entanto, além disso (para aumentar a segurança), armazenaríamos vários arquivos específicos do servidor em um servidor de compilação. #### iris.key Chave de licença. Como alternativa, ela pode ser baixada durante a compilação do contêiner em vez de armazenada em um servidor. É bastante arriscado armazenar no repositório. pwd.txt Arquivo contendo a senha padrão. Novamente, é bastante arriscado armazená-lo no repositório. Além disso, se você estiver hospedando um ambiente de produção em um servidor separado, ele poderá ter uma senha padrão diferente. load_ci_icm.script O script inicial: * Carrega o instalador * O instalador inicializa o aplicativo * Carrega o código set dir = ##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR")) do ##class(%SYSTEM.OBJ).Load(dir _ "Installer/Global.cls","cdk") do ##class(Installer.Global).init() halt Observe que a primeira linha é deixada em branco de maneira intencional. Várias coisas diferem dos exemplos anteriores. Em primeiro lugar, não habilitamos a autenticação do SO, pois o ICM interagiria com o contêiner em vez do GitLab diretamente. Segundo, estou usando o manifesto do instalador para inicializar nosso aplicativo para mostrar diferentes abordagens de inicialização. Leia mais sobre o Instalador [neste artigo](https://community.intersystems.com/post/deploying-applications-intersystems-cache-installer). Por fim, publicaremos nossa imagem em um Docher Hub como um repositório privado. ####   #### Installer/Global.cls Nosso manifesto do instalador fica desta forma: E implementa as seguintes mudanças: 1. Cria o namespace do aplicativo. 2. Cria o banco de dados de código do aplicativo (os dados seriam armazenados no banco de dados USER). 3. carrega o código no banco de dados de código do aplicativo. 4. Mapeia o pacote MyApp para o namespace USER. 5. Cria dois aplicativos para a Web: para HTML e para REST. gitlab-ci.yml Agora, para a configuração da entrega contínua: build image: stage: build tags: - master script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci_icm.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t eduard93/icmdemo:$CI_COMMIT_REF_NAME . O que está acontecendo aqui? Primeiro, como o [docker build](https://docs.docker.com/engine/reference/commandline/build/) pode acessar apenas subdiretórios de um diretório de compilação base — na raiz do repositório do nosso caso, precisamos copiar nosso diretório "secreto" (aquele com iris.key, pwd.txt e load_ci_icm.script) no repositório clonado. Em seguida, o primeiro acesso ao terminal requer um usuário/senha, então nós os adicionamos a load_ci.script (por isso a linha vazia no início de load_ci.script). Por fim, criamos a imagem do docker e a marcamos adequadamente:  eduard93/icmdemo:$CI_COMMIT_REF_NAME onde $CI_COMMIT_REF_NAME é o nome de um branch atual. Observe que a primeira parte da tag de imagem deve ter o mesmo nome do nome do projeto no GitLab, para que possa ser vista na guia GitLab Registry (instruções sobre a marcação estão disponíveis na guia Registry). Dockerfile A criação de uma imagem docker é feita usando o [Dockerfile](https://docs.docker.com/engine/reference/builder/): FROM intersystems/iris:2018.1.1-released ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly Começamos a partir do contêiner básico iris. Primeiro, copiamos nosso repositório (e diretório "secreto") dentro do contêiner. Em seguida, copiamos a chave de licença para o diretório mgr. Em seguida, alteramos a senha para o valor de pwd.txt. Observe que pwd.txt é excluído nessa operação. Depois disso, a instância é iniciada e load_ci.script é executado. Por fim, a instância iris é interrompida. Estou usando o [executor GitLab Shell](https://docs.gitlab.com/runner/executors/), e não o executor Docker. O executor Docker é usado quando você precisa de algo de dentro da imagem, por exemplo, você está criando um aplicativo Android em um contêiner java e precisa apenas de um apk. No nosso caso, precisamos de um contêiner inteiro e, para isso, precisamos do executor Shell. Então, estamos executando comandos do Docker pelo executor GitLab Shell. ## Publicar Agora, vamos publicar nossa imagem em um Docker Hub publish image: stage: publish tags: - master script: - docker login -u eduard93 -p ${DOCKERPASSWORD} - docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME Observe a variável ${DOCKERPASSWORD}, é uma [variável secreta](https://docs.gitlab.com/ee/ci/variables/#protected-variables) do GitLab. Podemos adicioná-la em GitLab > Project > Settings > CI/CD > Variables:  Os logs de job também não contêm valor de senha: Running with gitlab-runner 10.6.0 (a3543a27) on icm 82634fd1 Using Shell executor... Running on docker... Fetching changes... Removing ci/ HEAD is now at 8e24591 Add deploy to LIVE Checking out 8e245910 as master... Skipping Git submodules setup $ docker login -u eduard93 -p ${DOCKERPASSWORD} WARNING! Using --password via the CLI is insecure. Use --password-stdin. Login Succeeded $ docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME The push refers to repository [docker.io/eduard93/icmdemo] master: digest: sha256:d1612811c11154e77c84f0c08a564a3edeb7ddbbd9b7acb80754fda97f95d101 size: 2620 Job succeeded e no Docker Hub podemos ver nossa nova imagem:    Executar Temos nossa imagem, agora vamos executá-la em nosso servidor de teste. Aqui está o script. run image: stage: run environment: name: $CI_COMMIT_REF_NAME tags: - master script: - docker exec icm sh -c "cd /icmdata/test && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME" Com o ICM, precisamos executar apenas um comando ([icm upgrade](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_using#GICM_using_deploy_manage_icmupgrade)) para fazer upgrade da implantação existente. Estamos chamando-a executando "docker exec icm sh -c ", que executa um comando especificado dentro do contêiner icm.  Primeiro, entramos no modo /icmdata/test, onde a definição da implantação do ICM é configurada para um servidor TEST. Depois disso, chamamos icm upgrade para substituir o contêiner existente por um novo contêiner. ## Teste Vamos fazer alguns testes. test image: stage: test tags: - master script: - docker exec icm sh -c "cd /icmdata/test && icm session -namespace USER -command 'do \$classmethod(\"%UnitTest.Manager\",\"RunTest\",\"MyApp/Tests\",\"/nodelete\")' | tee /dev/stderr | grep 'All PASSED' && exit 0 || exit 1" Novamente, estamos executando um comando dentro do nosso contêiner icm. A sessão icm executa um comando em um nó implantado. O comando executa testes de unidade. Depois disso, ele canaliza todos os resultados para a tela e também para o grep para encontrar os resultados dos testes de unidade e sair do processo com sucesso ou com um erro. ## Implantar A implantação em um servidor de produção é absolutamente igual à implantação em teste, exceto por outro diretório para a definição da implantação LIVE. Se os testes falhassem, essa etapa não seria executada. deploy image: stage: deploy environment: name: $CI_COMMIT_REF_NAME tags: - master script: - docker exec icm sh -c "cd /icmdata/live && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME" Conclusão O ICM oferece uma maneira simples e intuitiva de provisionar uma infraestrutura na nuvem e implantar serviços nela, ajudando você a entrar na nuvem<nobr>agora</nobr> sem grande desenvolvimento ou reorganização. Os benefícios da infraestrutura como código (IaC) e da implantação em contêiner facilitam a implantação de aplicativos baseados no InterSystems IRIS em plataformas de nuvem públicas, como Google, Amazon e Azure, ou na sua nuvem privada VMware vSphere. Defina o que você quer, emita alguns comandos e o ICM faz o resto. Mesmo se você já estiver usando infraestrutura de nuvem, contêineres ou ambos, o ICM reduz drasticamente o tempo e o esforço necessários para provisionar e implantar seu aplicativo automatizando várias etapas manuais. Links * [Código do artigo](https://github.com/intersystems-ru/GitLab/tree/master/icm) * [Projeto de teste](http://gitlab.eduard.win/test/docker) * [Documentação do ICM](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM) * [First Look: ICM](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_using)

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: * Git básico * Fluxo Git (processo de desenvolvimento) * Instalação do GitLab * Fluxo de trabalho do GitLab * Entrega contínua * Instalação e configuração do GitLab * CI/CD do GitLab * Por que contêineres? * Infraestrutura dos contêineres * **CD usando contêineres** No [primeiro artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-i-git), 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](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-ii-fluxo-de-trabalho-do), abordamos o fluxo de trabalho do GitLab: um processo inteiro do ciclo de vida do software e a entrega contínua. No [terceiro artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-iii-instalação-e), abordamos a instalação e configuração do GitLab e a conexão dos seus ambientes a ele No [quarto artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-iv-configuração-da-cd), escrevemos uma configuração de CD. No [quinto artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-v-por-que-contêineres), falamos sobre contêineres e como (e por que) eles podem ser usados. No [sexto artigo](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-vi-infraestrutura-dos), vamos discutir os principais componentes necessários para executar um pipeline de entrega contínua com contêineres e como eles trabalham juntos. Neste artigo, criaremos a configuração de entrega contínua discutida nos artigos anteriores. ## ## Fluxo de trabalho Na nossa configuração de entrega contínua: * Enviamos código para o repositório do GitLab * Criamos a imagem docker * Testamos * Publicamos a imagem no nosso registro docker * Trocamos o contêiner antigo pela nova versão do registro Ou em formato gráfico: Vamos começar. ## Criação Primeiro, precisamos criar nossa imagem. Nosso código seria, como sempre, armazenado no repositório, a configuração de CD em gitlab-ci.yml. No entanto, além disso (para aumentar a segurança), armazenaríamos vários arquivos específicos do servidor em um servidor de compilação. #### GitLab.xml Contém o código dos hooks de CD. Foi desenvolvido no [artigo anterior](https://pt.community.intersystems.com/post/entrega-contínua-de-sua-solução-intersystems-usando-gitlab-–-parte-iv-configuração-da-cd) e disponibilizado no [GitHub](https://github.com/intersystems-ru/GitLab/releases). É uma pequena biblioteca para carregar código, executar vários hooks e testar código. Como alternativa preferencial, você pode usar [submódulos git](https://git-scm.com/book/en/v2/Git-Tools-Submodules) para incluir este projeto ou algo semelhante no seu repositório. Os submódulos são melhores porque é mais fácil mantê-los atualizados. Uma outra alternativa seria marcar as versões no GitLab e carregá-las com o comando [ADD](https://docs.docker.com/engine/reference/builder/#add). #### iris.key Chave de licença. Como alternativa, ela pode ser baixada durante a compilação do contêiner em vez de armazenada em um servidor. É bastante arriscado armazenar no repositório. #### pwd.txt Arquivo contendo a senha padrão. Novamente, é bastante arriscado armazená-lo no repositório. Além disso, se você estiver hospedando um ambiente de produção em um servidor separado, ele poderá ter uma senha padrão diferente. #### load_ci.script O script inicial: * Ativa a autenticação do SO * Carrega GitLab.xml * Inicializa as configurações do utilitário GitLab * Carrega o código set sc = ##Class(Security.System).Get("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) set AutheEnabled = Properties("AutheEnabled") set AutheEnabled = $zb(+AutheEnabled,16,7) set Properties("AutheEnabled") = AutheEnabled set sc = ##Class(Security.System).Modify("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) zn "USER" do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk") do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/") do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/") do ##class(isc.git.GitLab).load() halt Observe que a primeira linha é deixada em branco de maneira intencional. Como algumas configurações podem ser específicas do servidor, elas não são armazenadas no repositório, mas separadamente. Se o hook inicial for sempre o mesmo, você pode simplesmente armazená-lo no repositório. #### gitlab-ci.yml Agora, para a configuração da entrega contínua: build image: stage: build tags: - test script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME . O que está acontecendo aqui? Primeiro, como o [docker build](https://docs.docker.com/engine/reference/commandline/build/) pode acessar apenas subdiretórios de um diretório de compilação base — na raiz do repositório do nosso caso, precisamos copiar nosso diretório "secreto" (aquele com GitLab.xml, iris.key, pwd.txt e load_ci.script) no repositório clonado. Em seguida, o primeiro acesso ao terminal requer um usuário/senha, então nós os adicionamos a load_ci.script (por isso a linha vazia no início de load_ci.script). Por fim, criamos a imagem do docker e a marcamos adequadamente: docker.domain.com/test/docker:$CI_COMMIT_REF_NAME onde $CI_COMMIT_REF_NAME é o nome de um branch atual. Observe que a primeira parte da tag de imagem deve ter o mesmo nome do nome do projeto no GitLab, para que possa ser vista na guia GitLab Registry (instruções sobre a marcação estão disponíveis na guia Registry). #### Dockerfile A criação da imagem docker é feita usando o [Dockerfile](https://docs.docker.com/engine/reference/builder/): FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0 ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly Começamos a partir do contêiner básico iris. Primeiro, copiamos nosso repositório (e diretório "secreto") dentro do contêiner. Em seguida, copiamos a chave de licença e GitLab.xml para o diretório mgr. Em seguida, alteramos a senha para o valor de pwd.txt. Observe que pwd.txt é excluído nessa operação. Depois disso, a instância é iniciada e load_ci.script é executado. Por fim, a instância iris é interrompida. Veja o registro do job (parcial, os registros de carregamento/compilação foram ignorados): Running with gitlab-runner 10.6.0 (a3543a27) on docker 7b21e0c4 Using Shell executor... Running on docker... Fetching changes... Removing ci/ Removing temp.txt HEAD is now at 5ef9904 Build load_ci.script From http://gitlab.eduard.win/test/docker 5ef9904..9753a8d master -> origin/master Checking out 9753a8db as master... Skipping Git submodules setup $ cp -r /InterSystems/mount ci $ cd ci $ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt $ mv temp.txt load_ci.script $ cd .. $ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME . Sending build context to Docker daemon 401.4kB Step 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0 ---> cd2e53e7f850 Step 2/6 : ENV SRC_DIR=/tmp/src ---> Using cache ---> 68ba1cb00aff Step 3/6 : ENV CI_DIR=$SRC_DIR/ci ---> Using cache ---> 6784c34a9ee6 Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR ---> Using cache ---> 3757fa88a28a Step 5/6 : COPY ./ $SRC_DIR ---> 5515e13741b0 Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt && iris start $ISC_PACKAGE_INSTANCENAME && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script && iris stop $ISC_PACKAGE_INSTANCENAME quietly ---> Running in 86526183cf7c . Waited 1 seconds for InterSystems IRIS to start This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement %SYS> 1 %SYS> Using 'iris.cpf' configuration file This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement 1 alert(s) during startup. See messages.log for details. Starting IRIS Node: 39702b122ab6, Instance: IRIS Username: Password: Load started on 04/06/2018 17:38:21 Loading file /usr/irissys/mgr/GitLab.xml as xml Load finished successfully. USER> USER> [2018-04-06 17:38:22.017] Running init hooks: before [2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/ [2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global [2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.375] Importing dir /tmp/src/ Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl Compilation started on 04/06/2018 17:38:22 with qualifiers 'c' Compilation finished successfully in 0.194s. Load finished successfully. [2018-04-06 17:38:22.876] Running init hooks: after [2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.Global Removing intermediate container 39702b122ab6 ---> dea6b2123165 [Warning] One or more build-args [CI_PROJECT_DIR] were not consumed Successfully built dea6b2123165 Successfully tagged docker.domain.com/test/docker:master Job succeeded Estou usando o [executor GitLab Shell](https://docs.gitlab.com/runner/executors/), e não o executor Docker. O executor Docker é usado quando você precisa de algo de dentro da imagem, por exemplo, você está criando um aplicativo Android em um contêiner java e precisa apenas de um apk. No nosso caso, precisamos de um contêiner inteiro e, para isso, precisamos do executor Shell. Então, estamos executando comandos do Docker pelo executor GitLab Shell. ###   ### Executar Temos nossa imagem, agora vamos executá-la.  No caso de ramificações de recursos, podemos simplesmente destruir o contêiner antigo e iniciar o novo. No caso do ambiente, podemos executar um container temporário e substituir o contêiner do ambiente caso os testes tenham êxito (isso fica como um exercício para o leitor). Aqui está o script. destroy old: stage: destroy tags: - test script: - docker stop iris-$CI_COMMIT_REF_NAME || true - docker rm -f iris-$CI_COMMIT_REF_NAME || true Esse script destrói o contêiner em execução no momento e é sempre bem-sucedido (por padrão, o docker falha se tentar parar/remover um contêiner inexistente). Em seguida, iniciamos a nova imagem e a registramos como um ambiente. [Contêiner Nginx ](https://cloud.google.com/community/tutorials/nginx-reverse-proxy-docker) faz proxy automático de solicitações usando a variável de ambiente VIRTUAL_HOST e a diretiva de exposição (para saber em qual porta fazer o proxy). run image: stage: run environment: name: $CI_COMMIT_REF_NAME url: http://$CI_COMMIT_REF_SLUG. docker.domain.com/index.html tags: - test script: - docker run -d --expose 52773 --env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win --name iris-$CI_COMMIT_REF_NAME docker.domain.com/test/docker:$CI_COMMIT_REF_NAME --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log ###   ### Testes Vamos fazer alguns testes. test image: stage: test tags: - test script: - docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()" ### Publicar Por fim, vamos publicar nossa imagem no registro publish image: stage: publish tags: - test script: - docker login docker.domain.com -u dev -p 123 - docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME O usuário/código pode ser transmitido usando [variáveis secretas do GitLab](https://docs.gitlab.com/ee/ci/variables/#secret-variables). Agora, podemos ver a imagem no GitLab:  E outros desenvolvedores podem a extrair do registro. Na guia de ambientes, todos os ambientes estão disponíveis para a fácil navegação:    Conclusão Nessa série de artigos, discuti abordagens gerais de entrega contínua. É um tema extremamente vasto e essa série de artigos precisa ser vista mais como uma coleção de receitas do que algo definitivo. Se você deseja automatizar o desenvolvimento, os testes e a entrega do seu aplicativo, a entrega contínua em geral e o GitLab em particular é o melhor caminho. A entrega contínua e os contêineres permitem que você personalize seu fluxo de trabalho conforme necessário. ## Links * [Código do artigo](https://github.com/intersystems-ru/GitLab/tree/master/docker) * [Projeto de teste](http://gitlab.eduard.win/test/docker) * [Configuração de CD completa](https://github.com/intersystems-ru/GitLab/blob/master/docker/.gitlab-ci.yml) ## O que vem a seguir É isso. Espero que eu tenha abordado os conceitos básicos da entrega contínua e dos contêineres. Há vários tópicos sobre os quais não falei (talvez mais tarde), especialmente em relação a contêineres: * Os dados podem ser persistentes fora do contêiner. Veja a [documentação](http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_containers) relacionada. * Plataformas de orquestração como [kubernetes](https://kubernetes.io/) * [InterSystems Cloud Manager](http://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GICM_using) * Gerenciamento de ambiente - criando ambientes temporários para testes, removendo ambientes antigos após a mesclagem de ramificações de recursos * [Docker compose](https://docs.docker.com/compose/compose-file/) para implantações de vários contêineres * Diminuindo o tamanho da imagem docker e os tempos de construção * ...

Olá Comunidade, É hora de votar! Vote nos melhores aplicativos em nosso concurso de programação IRIS for Health, focado na criação de soluções FHIR para a saúde da mulher: 🔥 VOTE NOS MELHORES APPS 🔥 Como votar? Detalhes abaixo. Nominação de Especialistas: O júri experiente da InterSystems escolherá os melhores aplicativos para indicar os prêmios na Nomeação de Especialistas. Dê as boas-vindas aos nossos especialistas: ⭐️ @Alexander.Koblov, Especialista de Suporte⭐️ @Alexander.Woodhead, Especialista Técnico⭐️ @Guillaume.Rongier7183, Engenheiro de Vendas⭐️ @Alberto.Fuentes, Engenheiro de Vendas⭐️ @Dmitry.Zasypkin, Engenheiro de Vendas Sênior⭐️ @Daniel.Kutac, Engenheiro de Vendas Sênior⭐️ @Eduard.Lebedyuk, Senior Cloud Engineer⭐️ @Steve.Pisani, Arquiteto de Soluções Sênior⭐️ @Patrick.Jamieson3621, Gerente de Produto⭐️ @Nicholai.Mitchko, Gerente, Engenharia de Vendas de Parceiros de Soluções⭐️ @Timothy.Leavitt, Gerente de Desenvolvimento⭐️ @Benjamin.DeBoe, Gerente de Produto⭐️ @Robert.Kuszewski, Gerente de Produto⭐️ @Stefan.Wittmann, Gerente de Produto⭐️ @Raj.Singh5479, Gerente de Produto⭐️ @Jeffrey.Fried, Diretor de Gestão de Produtos⭐️ @Aya.Heshmat, Especialista de Produto⭐️ @Evgeny.Shvarov, Gestor do Ecossistema de Desenvolvedores⭐️ @Dean.Andrews2971, Chefe de Relações com Desenvolvedores Nominação da Comunidade: Para cada usuário, uma pontuação mais alta é selecionada nas duas categorias abaixo: Condições Posição 1º 2º 3º Se você tiver um artigo publicado no DC e um aplicativo carregado no Open Exchange (OEX) 9 6 3 Se você tiver um artigo publicado no DC ou um aplicativo carregado no Open Exchange (OEX) 6 4 2 Se você fizer qualquer contribuição válida para a DC (postar um comentário/pergunta, etc.) 3 2 1 Nível Posição 1º 2º 3º Nível VIP no Global Masters ou Gerentes de Produto ISC 15 10 5 Nível Ambassador no GM 12 8 4 Nível Expert no GM ou Moderadores da Comunidade 9 6 3 Nível Specialist no GM 6 4 2 Nível Advocate no GM ou funcionários ISC 3 2 1 Voto cego O número de votos para cada aplicativo será ocultado de todos. Uma vez por dia, publicaremos a tabela de classificação nos comentários desta postagem. A ordem dos projetos na página do concurso será a seguinte: quanto mais cedo uma inscrição for enviada para o concurso, mais alta ela estará na lista. PS Não se esqueça de se inscrever nesta postagem (clique no ícone do sino) para ser notificado sobre novos comentários Para participar da votação, você precisa Entrar no Open Exchange – as credenciais da Comunidade funcionam. Faça qualquer contribuição válida para a comunidade de desenvolvedores – responda ou faça perguntas, escreva um artigo, contribua com aplicativos no Open Exchange – e você poderá votar. Verifique esta postagem sobre as opções para fazer contribuições úteis para a Comunidade de Desenvolvedores. Se mudou de ideia, cancele a escolha e dê seu voto para outro aplicativo! Apoie o aplicativo que você gosta! Observação: os participantes do concurso podem corrigir os bugs e fazer melhorias em seus aplicativos durante a semana de votação, portanto, não perca e assine para acompanhar os lançamentos de aplicativos!

Se quiser experimentar o novo processo de instalação do projeto NoPWS, você pode obter acesso ao Early Access Program (EAP) aqui. (https://evaluation.intersystems.com/Eval/) Depois de se registrar, envie à InterSystems o endereço de e-mail que você usou para se registrar no EAP para nopws@intersystems.com. Veja aqui: Post Original

Olá Comunidade! Estamos na reta final do nosso 🏆 2º Concurso de Artigos Técnicos em Português da InterSystems 🏆.Restam apenas 5 dias 👀 para o encerramento do prazo de participação do concurso, e em seguida inicia-se o período de votação. Para aqueles que ainda estão elaborando o seu artigo, atenção para não perderem o prazo de publicação que vai até o dia 12 de junho de 2023. Fiquem ligados no prazo e não percam a chance de participarem! 😉Estamos aguardando por seus artigos. Boa sorte a todos 🍀

WEBCAST: PLATAFORMA DE DADOS INTERSYSTEMS: O DIFERENCIAL NOS PROJETOS DE DATA FABRIC DO SETOR FINANCEIRO 27 de Maio de 2021Das 11h ás 12h Inscreva-se agora! DESTAQUES

Durante a pandemia de Covid-19 tornou-se evidente a necessidade de transformação digital na área da saúde e muito foi questionado sobre como aperfeiçoar processos, melhorar gestão de recursos, modernizar e humanizar os atendimentos ao paciente. Neste tópico abordaremos especificamente a gestão de medicamentos e vacinas, mais especificamente, a perda desses materiais. De acordo com a Organização mundial de Saúde (OMS), no ano de 2020, pelo menos 25% de todas as vacinas chegaram degradadas aos cidadãos e 50% das vacinas distribuídas podem ser ineficazes, devido ao armazenamento incorreto e falha de refrigeração, entre outras questões de logística, que de modo geral estão relacionadas a baixa temperatura ideal para conservação. E essas perdas custam primordialmente a saúde da população e muito dinheiro. O cenário pandêmico escancarou nossas necessidades na área da saúde, impulsionando investimentos em tecnologia e inovação. Hoje nosso cenário é favorável para integração do monitoramento da cadeia fria da saúde com IoT (Internet of Things). OBJETIVO Este artigo visa abordar conceitos e discussões sobre IoT como apoio a métricas e monitoria de temperatura em refrigeradores de laboratórios da saúde, tais como: Laboratórios de análises clínicas e farmacêuticos. Abordando tecnologias InterSystems e frisando seus benefícios. DESENVOLVIMENTO A cadeia fria se trata de um sistema de conservação, manuseio e transporte de produtos com temperatura controlada, dentro da logística de medicamentos e vacinas. Esse modelo é fundamental para garantir qualidade e integridade para o paciente que irá recebê-los. A IoT abre um leque de possibilidades em nossas casas e cidades, a ideia é trazê-la para o laboratório, entregando uma monitoria IoT para aumentar o potencial de rastrear e restringir as temperaturas dentro desses ambientes controlados, contando com disparo de e-mails, SMS e push notifications. Podemos contar com a possibilidade de incorporar ferramentas de análise de dados a fim de auxiliar possíveis decisões sobre as alterações de temperatura ou identificar possíveis falhas no equipamento de refrigeração. Em resumo, estaríamos aplicando a tecnologia InterSystems IRIS Data Platform ao desenvolver, executar e manter nossa aplicação para informar através de vários canais, tanto para consumir quanto para enviar dados. Com recursos de integração e analíticos e possuindo um banco de dados multimodelo transacional incorporado, a InterSystems IRIS também será fundamental para armazenar os dados necessários de modo seguro e eficiente. A plataforma de integração de dados e sistemas, IRIS Interoperability, será nosso componente de mensageria usando o protocolo MQTT (Message Queuing Telemetry Transport) para os disparos de notificações citados anteriormente. O IntegratedML como recurso incorporado da plataforma IRIS InterSystems, escolhido para o gerenciamento dos dados coletados nos refrigeradores para possíveis tomadas de decisões para auxiliar a alteração de temperatura automaticamente quando necessário por meio de análise preditiva e para gerar insights para quando houver falhas nos equipamentos. Abaixo segue a explicação de cada escolha e o porquê. MQTT (Message Queuing Telemetry Transport) É um protocolo de comunicação M2M (Machine to Machine) com foco em IoT que funciona em cima do protocolo TCP. Sua comunicação se baseia entre o cliente que pode realizar tanto postagens quanto captação de informação e o broker que administra os dados a serem recebidos e enviados. Para essa comunicação, usa-se um paradigma chamado publish-subscribe. Por que MQTT e não outros protocolos? Criado em 1999 pela IBM para ser usado no setor de petróleo e gás, o MQTT surgiu a partir da necessidade de um protocolo para largura de banda mínima e perda de bateria mínima para monitorar oleodutos via satélite, sendo, dessa forma, um recurso simples, de baixo consumo de dados e que possibilita uma comunicação bilateral. Por que mensageria e não HTTP? Para abordar esta questão é preciso iniciar apontando suas diferenças na arquitetura. O HTTP funciona com um modelo cliente/servidor ou request-response, como exemplifica a figura abaixo, enquanto o MQTT funciona por meio de publicações e assinaturas de um tópico (publish-subscriber). No MQTT a conexão é mantida e pings podem ser compartilhados para mantê-la aberta, já o HTTP cria uma conexão apenas quando uma solicitação necessita ser enviada. E, por fim, é válido acrescentar que o HTTP mantém uma conexão TCP half-duplex (transmissões são realizadas nos dois sentidos da comunicação, mas alternadamente, nunca simultâneas) enquanto o MQTT mantém uma full-duplex (transmissões são simultâneas, um dispositivo pode transmitir informação ao mesmo tempo que a recebe), permitindo comunicações assíncronas entre os serviços para que os mesmos não esperem a resposta do serviço de recebimento, sendo um modelo necessário para mensageria. Além das diferenças apontadas acima, a mensageria torna a aplicação escalável, visto que o modelo publish-subscriber oferece suporte à mudança de números de serviços. Após essa breve explicação, podemos dizer que o MQTT é muito mais otimizado para esse cenário em comparação ao HTTP em taxa de transferência, consumo de bateria e largura de banda, tornando-se uma melhor opção para a maioria das aplicações IoT e sendo reconhecido como o padrão de mercado de mensageria nesse contexto. O IRIS Interoperability, uma plataforma de integração de dados e sistemas, desempenha um papel fundamental como broker para este protocolo e no cenário descrito deste artigo. Ele permite que os dispositivos IOT publiquem mensagens em tópicos específicos, neste caso o tópico de monitoria de temperatura, e também que a aplicação faça um subscribe para receber as mensagens. O IRIS fornece extensões integradas para usar o MQTT. InterSystems IntegratedML O AutoML (Automated Machine Learning) é um recurso que surge como opção para o uso do ML (Machine Learning) para desenvolvedores com conhecimento em SQL, mas pouco ou nenhum em ML. Com ele é possível automatizar a criação, treinamento e implementação do aprendizado de máquina, a organização que opta por sua utilização pode poupar tempo e esforço significativos de sua equipe de cientistas de dados, visto que o AutoML abstrai os detalhes e conhecimentos especializados exigidos. Certo! Mas onde entra o InterSystems IntegratedML? IntegratedML (Integrated Machine Learning) se trata de um recurso integrado da plataforma de dados InterSystems IRIS que simplifica e fornece recursos AutoML, permitindo o uso de funções automatizadas diretamente do SQL para gerar e manusear modelos preditivos. Sua inclusão ao IRIS permite uma execução dinâmica, atuando em tempo real diretamente nos dados, sem extrair ou mover quaisquer modelos ou bases. Para exemplificar sua funcionalidade, assume-se que, “no Brasil todo mês de janeiro é quente” e que teremos registros de aproximadamente três anos armazenados na base de dados, obtida por estações meteorológicas. É importante que para essa exemplificação tenhamos em mente que os dados foram preparados e estamos desconsiderando informações abrangentes como mudanças climáticas. A partir dessa premissa, é necessário treinar nosso modelo para que, ao iniciar cada mês de janeiro, as temperaturas tendem a ser mais elevadas, portanto deve reduzir em 1°C (grau Celsius) a temperatura. Se a temperatura externa aumentar, demanda-se que o sistema de refrigeração seja acionado, resfriando o ambiente interno, mantendo temperaturas indicadas pelos fabricantes e mantendo a integridade dos insumos ali armazenados. Junto ao IRIS, o IntegratedML “automatiza o trabalho básico, como identificar os modelos mais apropriados, definir parâmetros e construir e treinar modelos” e permite melhorias contínuas dos modelos de ML. O objetivo aqui é criar e implantar modelos de aprendizagem de máquina com um menor esforço, no sentido de não precisar de especialistas para começar aplicar as funcionalidades necessárias de ML, complementar o trabalho do time e dedicar tempo a melhorias e suporte à aplicação e análises. Após a preparação dos dados e criação do modelo, o IntegratedML será responsável por gerenciar os dados coletados dos refrigeradores para auxiliar às possíveis tomadas de decisões, assim como, após o treinamento do modelo, deve ser capaz de ajustar a temperatura de forma automática quando necessário, por meio de análise preditiva, além de gerar insights em caso de falhas nos equipamentos. A seguir, apresentamos uma imagem ilustrativa da nossa arquitetura e onde o IntegratedML, IRIS Interoperability e o MQTT estão sendo aplicados. CONCLUSÃO Mesmo tendo outras soluções disponíveis no mercado, há muitas razões pelas quais aplicar tecnologias InterSystems ao IoT podem ser benéficas. A InterSystems é reconhecida na área da saúde, principalmente pelos produtos InterSystems IRIS for Health e o InterSystems TrakCare, e oferece recursos robustos de integração, permitindo conexão e comunicação eficiente entre diferentes sistemas e dispositivos, flexibilidade, escalabilidade, conformidade. A sua interoperabilidade pode simplificar a implantação e gerenciamento de um sistema abrangente. É interessante ressaltar que a mesma lógica pode ser aplicada em outros segmentos além dos laboratórios de saúde, como os refrigeradores industriais. Porém, aplicando regras de ML específicas para o uso industrial. REFERÊNCIAS Aprendizagem e Análise de Máquina - Plataforma de Análise de Big Data. InterSystems. Disponível em <https://www.intersystems.com/br/sistema-de-gerenciamento-de-banco-de-dados/grande-analise-de-dados/> Acesso em 24 de maio de 2023. Desperdício de medicamentos: como evitar perdas. NEXXTO, 2022. Disponível em <https://www.linkedin.com/pulse/desperd%C3%ADcio-de-medicamentos-como-evitar-perdas-nexxto/?trk=organization-update-content_share-article> Acesso em 16 de maio de 2023. Gestão de Bases de Dados. InterSystems. Disponível em <https://www.intersystems.com/br/sistema-de-gerenciamento-de-banco-de-dados/gestao-de-bases-de-dados/> Acesso em 19 de maio de 2023. Introduction to IntegratedML. InterSystems. Disponível em <https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=GIML_Intro> Acesso em 29 de maio de 2023. IoT with InterSystems IRIS. Marx Y., 2023. Disponível em <https://community.intersystems.com/post/iot-intersystems-iris> Acesso em 20 de maio de 2023. Implementation of IoT based Smart Laboratory. M. Poongothai, 2018. Disponível em <https://www.researchgate.net/publication/327723745_Implementation_of_IoT_based_Smart_Laboratory> Acesso em 20 de maio de 2023. Interoperabilidade - Integração Potente e Flexível com InterSystems IRIS. InterSystems. Disponível em <https://www.intersystems.com/br/sistema-de-gerenciamento-de-banco-de-dados/interoperabilidade/> Acesso em 19 de maio de 2023. InterSystems IntegratedML - Aprendizagem da máquina facilitada. Intersystems. Disponível em <https://www.intersystems.com/br/solucoes/integratedml/> Acesso em 20 de maio de 2023. IoT Sample. GOMES Y. , 2023. Disponível em <https://openexchange.intersystems.com/package/IoT-Sample> Acesso em 01 de junho de 2023. MQTT: Get started with IoT protocols. Sola R., 2016. Disponível em <https://www.opensourceforu.com/2016/11/mqtt-get-started-iot-protocols/> Acesso em 24 de maio de 2023. Machine Learning Made Easy: InterSystems IntegratedML. InterSystems. Disponível em <https://www.intersystems.com/resources/machine-learning-made-easy-intersystems-integratedml/> Acesso em 20 de maio de 2023. "MQTT vs HTTP: ¿qué protocolo es mejor para IoT?". H. Angel, 2020. Disponível em <https://borrowbits.com/2020/04/mqtt-vs-http-que-protocolo-es-mejor-para-iot/> Acesso em 24 de maio de 2023 "O que é MQTT?". Amazon. Disponível em <https://aws.amazon.com/pt/what-is/mqtt/> Acesso em 24 de maio de 2023. Talk2Lab: The Smart Lab of the Future. IEEE, 2020. Disponível em <https://ieeexplore.ieee.org/abstract/document/9094640> Acesso em 20 de maio de 2023. Parabéns pelo excelente artigo! Parabéns!!! Sucinto e objetivo. Parabéns!!! Excelente trabalho. Excelente artigo! Eu trabalho com arquitetura orientada a eventos, e foi muito interessante ver como os serviços de mensageria pode ser utilizado pra outras finalidades. Sem falar da grande integração com as ferramentas da InterSystems. Muito obrigada, Filipe! Muito obrigada! A ideia era ser mesmo objetivo, pois é uma comunidade de tecnologia, então descarta algumas introduções nos temas apresentado e vai direto ao ponto. Muito obrigada, fico feliz que tenha gostado da leitura. Muito obrigada pelas palavras, fico muito feliz em saber que estou entregando valor com este artigo e que tenha gostado de como abordei o tema e as ferramentas da InterSystems. Muito bom o artigo. Parabéns! Muito legal!!! Parabéns! Aliás, quando vc terminar a graduação, vamos participar do mestrado na FAMERP? Começa com a Disciplina Inovação e Empreendedorismo na Saúde. Topa??? Oi Thaís! Parabéns pelo seu artigo, ficou objetivo, técnico e interessante. Independente de prêmio, você realizou um excelente trabalho. Excelente…artigo muito bem elaborado Uau! Meus parabéns Thais! Este artigo ficou show de bola! Você pretende continuar este trabalho após a sua formatura? Parabéns Thais ótimo artigo. Oi Thaís ... parabéns pelo artigo.. Orgulho! Boa sorte! muito bom!! Parabéns @Thais.Pinheiro Excelente artigo Thais, muito bem elaborado e interessante! Excelente artigo Thais, acompanhei de perto o manuseio de vacinas e medicamentos que necessitam de refrigeração,é realmente muito falho esse controle. interessante demais conhecer esse a tecnologia... Sucesso 🙏 Parabéns pelo artigo @Thais.Pinheiro , excelente trabalho. Muito obrigada! Fico muito lisonjeada pelo convite e agradeço muitíssimo, é uma ótima oportunidade. Vou pensar com carinho e volto a falar com a senhora. Muito obrigada, Márcio! Admiro-o muito, então para mim é muito gratificante que tenha gostado. Obrigada, Mariangela! Muito obrigada, Lucimar! No momento tenho em mente trabalhar esse tema no meu TG para realizar a parte prática. Se tudo der certo acredito que eu dê continuidade, sim. Obrigada, Katia! Olá! Muito obrigada, Adriana. Fico honrada de ver a senhora por aqui. Uma professora que tenho um carinho enorme. Muito obrigada, Taciana! Fico feliz que tenha gostado. Muito obrigada, Laura! Agradeço pela leitura e fico feliz que tenha gostado. Muito obrigada, Cristiane! Conversei com algumas pessoas da área e elas comentaram sobre o gerenciamento de algumas vacinas, o que reforçou ainda mais para mim que foi um tema legal. Que bom que gostou e agradeço novamente. Muito obrigada, Marcio! Agradeço pela leitura e fico feliz que tenha gostado. Muito obrigada, Lucas! Parabéns pelo artigo, Thais! Parabéns pelo artigo!!! Great article Thais. Very complete and useful! Congratulations! Muito bom seu artigo, parabéns. Parabéns, excelente artigo! Bem claro e objeto! Muito obrigada, fico contente que tenha gostado. Muito obrigada, Reginaldo! Obrigada, Felicio! Muito obrigada, Daniele!