O banco de dados InterSystems Caché é um arquivo onde todos os dados, scripts de aplicações e usuários, funções e configurações de segurança são armazenados. Normalmente, o nome do arquivo é cache.dat.
Olá, comunidade, este artigo tem como o objetivo dar discas à clientes e parceiros que estão migrando ou tem planos de migrar as atuais aplicações que estão em InterSystems Caché e InterSystems Ensemble para a plataforma de dados Intersystems IRIS.
Não tenho intensão de substituir os documentos oficiais que se encontram disponíveis no WRC, inclusive vou fazer várias menções aos documentos oficiais e recomendo fortemente a leitura deles.
Olá Desenvolvedores!
Aqui estão os bônus tecnológicos para o Concurso InterSystems de Datasets 2021 que lhes darão pontos extras na votação:
Vejam os detalhes abaixo.
Olá Comunidade,
É um prazer convidá-los para nosso próximo Webinar de Lançamento do Concurso de Datasets InterSystems! O tópico deste webinar é dedicado ao Concurso de DataSets InterSystems.
Neste webinar faremos um passeio rápido pela nova funcionalidade LOAD DATA além de abordarmos como empacotar dados em globais ou em arquivos utilizando o ZPM e executar um script de geração de dados como parte de um método na instalação ZPM.
Como sempre nossos especialistas irão responder questões sobre como desenvolver, construir e implantar conjuntos de dados utilizando a plataforma de dados InterSystems IRIS.
Data & Horário: Terça-feira, 28 de Dezembro – 11:00 horário de Brasília
Palestrantes:
🗣 @Benjamin De Boe, Gerente de Produtos, InterSystems
🗣 @Evgeny Shvarov, Gestor do Ecossistema de Desenvolvedores InterSystems
Queremos conjuntos de dados!
Com o lançamento da Prévia do InterSystems IRIS 2021.2 e a nova funcionalidade LOAD DATA, gostaríamos de colocá-los a prova com o novo Concurso InterSystems de DATASETS !
🏆 Concurso InterSystems de Datasets 🏆
Duração: de 27 de Dezembro a 16 de Janeiro de 2022
Nosso prêmio aumentou para US$ 9,450!
Olá Comunidade,
Participem do Webinar de Lançamento do Concurso de Interoperabilidade InterSystems dedicado ao Concurso de Interoperabilidade.
Neste webinar, você irá receber uma visão geral das capacidades de interoperabilidade da plataforma de dados InterSystems IRIS e iremos mostrar como utilizar o PEX. Além disto iremos debater e responder perguntas de como criar soluções de interoperabilidade utilizando o InterSystems IRIS e o IRIS for Health.
Data & Horário: Segunda-feira, 4 de Outubro — 13:00 horário de Brasília
Palestrantes:
🗣 @Stefan Wittmann, Gerente de Produto InterSystems
🗣 @Bob Kuszewski, Gerente de Produto InterSystems
🗣 @Evgeny Shvarov, Gerente de Ecossistema de Desenvolvedores InterSystems
Bom dia!!!
Vaga Especialista de Integrações.
AFIP - Associação Fundo de Incentivo à Pesquisa.
Requisitos
* Conhecimentos avançado em Ensemble/Caché
* Integração com bancos Oracle /SQL Server
Será um diferencial ter atuação na área da saúde sistemas (LIS/HIS/RIS). Profissional deve atuar como líder técnico.
- Documentar estrutura dos sistemas;
- Participar de Reuniões técnicas com fornecedores/colaboradores;
- Responsável técnico pela arquitetura de integrações entre sistemas;
- Responsável pela homologação de sistemas de terceiros;
- Responsável por manter catálogo de serviços de integração de dado;
Boa tarde a todos. Meu nome é Helberth, sou sócio diretor de uma empresa de TI em BH e temos um cliente que nos solicitou um profissional com experiencia sólida, nivel senior, no banco de dados Caché. Se você tem esta experiencia e tem interesse em conversar comigo me envie um email em particular como titulo vaga em Caché - helberth.soares@bhs.com.br. Obrigado
No coração do IRIS e do Caché está uma arquitetura de banco de dados muito interessante que nós, na M / Gateway Developments, chamamos de "Armazenamento Global". Se você sempre quis saber mais sobre os fundamentos e recursos desse banco de dados subjacente, pode ler uma análise importante que reunimos:
https://github.com/robtweed/global_storage
Entre outras coisas, você descobrirá que:
- O armazenamento global fornece a base de um banco de dados multi-modelo completo, algo que chamamos de "NoSQL universal", embora, como você já sabe do IRIS e do Cache, ele também tem suporte relacional.
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
Caché: 2017.2.1.801.0
Fala pessoal, tenho uma dúvida relacionada um problema especifico que eu estou tentando entender, onde ainda não tenho muitas informações, porém estou tentando criar uma forma de levantar dados precisos para expor mais detalhes aqui na comunidade ou até mesmo consultar o suporte da IS, a questão é muito simples:
Precisava saber através de código/rotina a seletividade de uma propriedade de tabela, atualmente consigo realizar um SET utilizando o comando:
SYSTEM.SQL.SetFieldSelectivity("#PACOTE","#TABELA","#PROPRIEDADE","#SELETIVIDADE","")