Perguntas Frequentes

Fluxo de Integração é uma maneira de criar um processo de tomada de decisão que pode ser integrado a fontes de dados. Por exemplo, permite que você processe em lote 1 milhão de seus clientes armazenados em um CRM ou banco de dados.

Para tais processos de tomada de decisão, estimamos uma duração de dezenas de segundos a horas.

Sim, se você trabalhar com tabelas grandes, pode exportá-las com um único clique para o Excel ou Google Sheets, onde você pode editá-las e depois importá-las de volta facilmente.

Se ocorrer um erro durante a importação, o DecisionRules mostrará interativamente qual célula precisa ser corrigida.

Todas as regras e processos de tomada de decisão podem ser exportados e importados. Graças à estrutura de pastas incorporada dentro de cada espaço, é possível exportar pastas individuais ou projetos inteiros.

O formato de exportação é JSON.

O DecisionRules pode lidar normalmente com 30.000 registros em uma única tabela. Esse limite é suficiente para a maioria dos clientes. Se você precisar de mais, esse limite pode ser aumentado individualmente.

Fluxo de Decisão é um recurso dentro do DecisionRules que permite criar processos de tomada de decisão mais complexos, consistindo em várias decisões menores, cálculos ou chamadas externas.

O Fluxo de Decisão permite combinar várias tabelas de decisão, iterar decisões individuais ou agregar dados.

Para tais decisões, estimamos que elas levam milissegundos a segundos.

O DecisionRules trabalha com Tabelas de Decisão, Árvores de Decisão, Fluxos de Decisão e Fluxos de Integração. Essas regras são sempre sem código e amigáveis ao usuário.

Se uma transformação de dados mais complexa for necessária, você pode usar uma Regra de Script, onde pode aplicar JavaScript.

Sim, elas serão. Todas as partes interessadas podem sempre olhar para o DecisionRules para ver como um caso específico é avaliado. Para monitoramento mais amplo, você pode facilmente conectar o DecisionRules ao PowerBI e visualizar decisões individuais estatisticamente.

Sim, temos uma variedade de SDKs disponíveis em nosso DecisionRules Github.

O DecisionRules pode ser integrado usando uma simples API REST Solver. Você simplesmente insere um objeto JSON como dados de entrada e recebe a saída da regra na resposta. Você pode encontrar exemplos de integração para idiomas e plataformas individuais diretamente na aplicação.

Sim, o DecisionRules é frequentemente usado com várias plataformas de integração, como Power Automate, SAP Platform, n8n, Workato e outras. A integração é muito simples.

Por meio da integração nativa de MCP, as ferramentas de IA podem acessar modelos predefinidos, componentes reutilizáveis, documentação, recursos da Academy e conteúdo estruturado, além de poder criar, atualizar, testar e executar regras em um espaço autenticado, com cada alteração revisada antes de entrar no ar.

Não. Você se conecta com a conta do DecisionRules que já possui e, durante a configuração, escolhe o Espaço em que o assistente trabalhará.

Claude, ChatGPT, Codex têm suporte nativo a conectores. Qualquer outro cliente compatível com MCP pode se conectar por meio do Smithery.

Sim, você pode. Muitos clientes escolhem essa abordagem, começando simplesmente com a variante em nuvem e depois migrando para uma solução de Nuvem Gerenciada Privada ou On-Premise. O projeto pode ser facilmente exportado e importado para o novo ambiente. Leva cerca de 1 minuto do seu tempo.

Isso permite que os clientes criem regras e integrem sistemas imediatamente.

Sim, o DecisionRules possui contêineres Docker disponíveis publicamente que qualquer um pode baixar. É aconselhável usar um script Docker compose pré-preparado que fará o download, instalará e executará tudo diretamente em seu computador. Você só precisa ter o Docker Desktop instalado, que está disponível gratuitamente.

Sim, o DecisionRules é projetado para escalar. A escalabilidade pode ser configurada automaticamente com base em múltiplos parâmetros, como utilização de CPU, número de conexões de entrada e mais. Você pode facilmente ter um ambiente que pode tomar dezenas de milhões de decisões por hora.

Sim, o DecisionRules usa Redis Cache, que é comumente disponível. O cache é usado como não persistente. Para aumentar a disponibilidade, é possível usar um Redis Cluster.

O DecisionRules suporta uma ampla gama de nuvens privadas, como AWS, Azure ou Google Cloud. Se você usar seu próprio Cluster Kubernetes, o DecisionRules funcionará perfeitamente para você.

Nosso cliente médio pode integrar o DecisionRules em seu sistema facilmente em algumas horas.

Esse processo leva aproximadamente 5 dias a partir da assinatura do contrato.

Você pode escolher entre mais de 30 locais da Amazon Web Services onde seu ambiente estará disponível.

Sim, o DecisionRules é um sistema que opera comumente em grandes corporações multinacionais.

Sim, usa normalmente várias zonas de disponibilidade em locais individuais. Graças à arquitetura única do DecisionRules, é possível escolher múltiplos locais que serão selecionados automaticamente com base na posição geográfica do usuário.

Você pode escolher entre mais de 30 locais da Amazon Web Services onde seu ambiente estará disponível.

O DecisionRules oferece 3 opções:

O DecisionRules usa MongoDB ou seus clones como CosmosDB ou DocumentDB para armazenamento de dados. Também é possível usar Mongo Atlas ou seu próprio cluster sem problemas. Usar MongoDB gerenciado é vantajoso para backup de banco de dados, que é uma operação de 1 clique.

A Nuvem Gerenciada Privada é projetada para empresas médias e grandes que desejam consumir o DecisionRules como um serviço sob um SLA pré-acordado e ter sua própria infraestrutura dedicada que não é compartilhada com ninguém.

Nuvem pública, nuvem privada gerenciada ou self-hosted com Docker e Kubernetes, incluindo on-premise.

Sim, o DecisionRules possui uma documentação extensa disponível publicamente, que enriquecemos e refinamos toda semana. A documentação está disponível em docs.decisionrules.io.

Sim, o DecisionRules possui uma academia disponível publicamente que o orienta passo a passo sobre como usar o DecisionRules. Também oferecemos treinamento online e offline para os clientes.

Interessado em treinamento? Entre em contato conosco.

Não. Qualquer pessoa com conhecimento em Excel pode usar o DecisionRules.

Sim, o DecisionRules versiona nativamente regras individuais.

O DecisionRules é adequado tanto para empresas médias quanto grandes. Se você tem problemas com mudanças nas configurações, lógica de negócios ou processos de tomada de decisão, então o DecisionRules é o sistema para você.

O DecisionRules economiza dinheiro eliminando a necessidade de desenvolvedores para mudar a lógica de negócios para cada modificação de regra de negócios. Todas as mudanças de regras podem ser feitas por um proprietário de produto qualificado ou um analista júnior.

Mudanças que levam dias ou semanas nas organizações podem ser feitas no DecisionRules em questão de minutos. Funciona realmente.

Sim, nossos clientes incluem corporações multinacionais, instituições financeiras e instituições de seguros, que estão entre as organizações mais complexas do mundo. Podemos lidar com a sua também.

A maneira mais fácil é fazer um upgrade para um plano mais alto. A mudança entra em vigor imediatamente.

Outra opção é uma oferta personalizada adaptada às suas necessidades específicas. Ficaríamos felizes em fornecer uma oferta sob medida.

Sim, o DecisionRules inclui um assistente de IA que ajuda você a criar todas as regras necessárias. Por exemplo, você pode pegar uma política interna que precisa ser convertida em uma tabela de decisão, e o DecisionRules criará automaticamente a tabela com base na política.

Esta é a unidade básica em torno da qual o DecisionRules é construído: o número de regras de negócios que você pode criar.

No caso de nós, refere-se ao número de nós que você pode colocar em um Fluxo de Decisão ou um Fluxo de Integração.

O número total de regras e nós utilizados não deve exceder o limite definido pelo seu plano.

Um Espaço é uma área compartilhada para regras que estão de alguma forma relacionadas. É um projeto independente dentro do DecisionRules que permite separar a lógica para diferentes departamentos ou equipes em sua empresa.

A API de Gerenciamento serve simplesmente para modificações automatizadas diretamente dentro do DecisionRules. Você pode usá-la para carregar dados sobre objetos do DecisionRules em seu sistema, como nomes de regras, versões disponíveis, etc.

Além disso, a API de Gerenciamento é usada para importação/exportação automatizada, backups ou integração com pipelines CI/CD.

O acesso à API de Gerenciamento é feito através de uma chave de API, que pode ser obtida diretamente na aplicação.

Tabelas de Decisão, Árvores de Decisão, Regras de Script e o tipo de regra do Agente de IA, compostos em Fluxos de Decisão.

Uma plataforma de automação de decisões determinística e sem estado. Ela executa suas regras de negócio sobre uma API REST, com versões e auditoria, para que a mesma entrada sempre gere a mesma decisão.

Sim, oferecemos suporte global aos nossos clientes em modos 5x8, 24x7, ou em horários individuais. Você pode facilmente entrar em contato com o suporte através do nosso Portal de Suporte.

Você pode lidar com a implementação sozinho sem problemas. Se você não tiver capacidade na equipe, podemos fazer a primeira iteração de regras para você ou gerenciá-las a longo prazo.

Claro, nossa experiente equipe de DevOps ajudará você a instalar e testar o DecisionRules em sua nuvem privada. Já realizamos inúmeras instalações.

Sim. A BI API é somente leitura, e há um conector nativo do Power BI. Sua ferramenta de BI lê os mesmos logs de auditoria lidos pela página Statistics, portanto existe uma única fonte de verdade e nenhuma cópia que possa se desalinhar.

Não. Ative o registro em log de uma regra, e o Statistics lê os logs produzidos por ela. O Data Dictionary descobre seus campos nos próprios dados de log, portanto não há esquema para declarar nem nada para manter sincronizado.

Sim, o DecisionRules permite o processamento de dados em lote usando jobs que podem durar várias horas. Alternativamente, o DecisionRules pode ser usado como parte de processos computacionais orquestrados em outras plataformas.

O DecisionRules é construído como um sistema robusto e de alto desempenho. Nossa infraestrutura pode lidar facilmente com dezenas de milhões de regras resolvidas por hora para um único cliente. A plataforma escala automaticamente sob carga maior.

Este é o limite de quantas regras você pode resolver dentro do seu plano – ou, quantas vezes você pode chamar com sucesso a API Solver.

O DecisionRules pode avaliar centenas de milhares de regras por minuto. O resultado pode variar dependendo das implantações individuais. Implantações de Nuvem Gerenciada Privada ou On-Premise oferecem o melhor desempenho porque a infraestrutura não é compartilhada com outros usuários.

Regras simples têm latência muito baixa, em torno de 20ms. Regras mais complexas podem ter latência em torno de 250ms, e processos de tomada de decisão verdadeiramente complexos com dezenas de tabelas de decisão e chamadas externas podem ter latência de vários segundos.

O DecisionRules é a única ferramenta no mercado que pode utilizar múltiplos data centers localizados em todo o mundo. Isso garante excelentes tempos de resposta, não importa em qual continente você esteja. Se você encontrar o DecisionRules ausente em uma determinada região, por favor, nos avise. Estamos abertos a expandir nossa infraestrutura.

Para ver o que uma nova versão faria antes de ela fazer isso. A versão atual continua atendendo à produção enquanto a candidata é executada nas mesmas solicitações e registra o que teria decidido, sem agir com base nisso. Você configura isso chamando a regra duas vezes, uma vez fixada em cada versão, e enviando a mesma entrada para ambas. O resultado da candidata é registrado, não usado. Quando ela se comporta como esperado, você a promove.

Ela permanece. A edição produz uma nova versão em vez de sobrescrever a anterior, e a versão antiga mantém seus próprios logs de auditoria. É isso que permite compará-la e responder a uma pergunta sobre uma decisão tomada sob uma política que você já substituiu.

Qualquer uma das duas. O seletor de comparação aceita qualquer regra. O único requisito é que o campo observado exista nos dois lados, pois um gráfico precisa de algo para desenhar. Comparar versões de uma mesma regra é o caso mais limpo porque todo o restante é mantido constante.

O DecisionRules é um sistema seguro. Todas as conexões são criptografadas, e seus dados também estão protegidos por criptografia.

O DecisionRules e nossos processos estão em conformidade com a certificação ISO 270001.

O DecisionRules e nossos processos estão em conformidade com a certificação ISO 270001.

Não. Suas regras e seus dados nunca são usados para treinar modelos de IA.

O acesso é limitado ao Espaço escolhido, todas as alterações são versionadas e reversíveis, e nada é publicado sem a sua autorização.

Sim, também fornecemos licenças offline.

A implantação On-Premise é sempre uma questão individual, onde você pode definir o número de ambientes, organizações, recursos e usuários que deseja ter disponíveis em seu DecisionRules. Nossos Engenheiros de Vendas terão prazer em analisar seu caso de uso e preparar uma solução personalizada para você. Uma licença ilimitada do DecisionRules também está disponível.

Organização permite o gerenciamento centralizado de projetos e usuários dentro da sua organização. Você pode definir equipes e grupos de permissão para projetos individuais. A Organização permite login via SAML Single Sign-On, como Microsoft Entra ID, Okta, 0Auth, etc. Essa função é especialmente útil para empresas maiores com estruturas organizacionais mais complexas.

Porque as versões nem sempre se sobrepõem. Quando você executa duas versões em paralelo, quer a mesma janela nos dois lados. Quando já fez a mudança, a versão antiga está nas semanas anteriores e a nova nas semanas posteriores; por isso, cada lado precisa da sua própria janela para ter algo a representar.

Um tipo nativo de regra que lê documentos, narrativas e sinais e retorna uma saída estruturada e tipada com raciocínio explicável. Ele é diferente do Assistente de IA.

Não. Ele cria e edita tanto Tabelas de Decisão quanto Regras de Script, gera funções e dados de teste, resume regras, recomenda modelos e responde perguntas a partir das documentações e da Academia.

Cerca de 60% menos tempo de autoria e até 3x mais produtividade diária, medido em um benchmark controlado.

Sim, para o Assistente de IA e para o Agente de IA: Gemini, OpenAI, Anthropic, Vertex AI ou Microsoft Foundry.

O DecisionRules usa IA para ajudar os usuários a criar e manter regras de negócio. O Assistente de IA pode transformar linguagem natural em Tabelas de Decisão, gerar funções e dados de teste, explicar a lógica de negócio existente, resumir regras complexas e responder a perguntas sobre o produto usando a documentação do DecisionRules. Depois de criadas, as regras de negócio são executadas pelo mecanismo do DecisionRules, onde permanecem versionadas, auditáveis e determinísticas, garantindo que a mesma entrada sempre produza a mesma decisão.

Ela coloca duas regras lado a lado e destaca cada diferença com cores. Responde rapidamente a uma pergunta: o que realmente mudou? É especialmente útil ao comparar duas versões da mesma regra, como a versão em produção e a nova versão que você está preparando.

Verde é a sua regra, aquela que está aberta. Azul é a versão usada para comparação. Amarelo significa que a linha, coluna ou célula existe nas duas versões, mas foi alterada. Tudo que não tem cor é idêntico. Depois de aprender uma vez, funciona da mesma forma em tabelas e árvores.

É uma contagem rápida das diferenças, separada entre linhas e colunas. Para cada uma, você vê quantas permaneceram iguais e quantas mudaram, divididas por cor.

Apenas regras do mesmo tipo: Tabelas com Tabelas, Árvores com Árvores, Scripts com Scripts. Isso mantém a comparação relevante, já que uma grade e um arquivo de código não têm como ser alinhados.

Use-a como a etapa final da revisão. Abra a nova versão ao lado da versão atual em produção, examine cada diferença, consulte as estatísticas para uma contagem rápida e confirme que toda alteração foi intencional. Isso transforma “Acho que está certo” em “Consigo ver exatamente o que alterei.”

Ao comparar duas versões da mesma regra. Também é possível comparar regras não relacionadas, mas quase tudo aparecerá como diferente, então isso raramente ajuda.

Use o mesmo logotipo e a mesma identidade visual que suas equipes já reconhecem em outros sistemas internos. Uma experiência consistente ajuda o DecisionRules a parecer parte do seu ambiente tecnológico existente, e não uma ferramenta desconectada.

Escolha um logotipo horizontal claro e cores de marca que permaneçam legíveis na interface do DecisionRules. Sua identidade visual deve tornar o ambiente reconhecível sem reduzir a usabilidade ou a clareza visual.

Não. A migração é uma tradução, não uma reescrita. A intenção de negócio por trás de cada regra permanece a mesma; apenas os artefatos subjacentes mudam de formato. A maioria dos tipos de regra é mapeada um a um: uma tabela de decisão continua sendo uma tabela de decisão, e uma árvore de decisão continua sendo uma árvore de decisão.

Sim. Se você tiver casos de teste do Decision Validation Services, nós os traduzimos junto com as regras e os executamos nas novas versões do DecisionRules. Se não tiver uma suíte de testes, o AI Assistant cria uma a partir da própria lógica da regra.

Quase nada. Sua aplicação continua enviando a mesma solicitação e recebendo o mesmo formato de resposta. O que muda é o destino: em vez de um Rule Execution Server no WebSphere, ela usa uma URL da Solver API gerada pelo DecisionRules ao publicar a regra. Na prática, você atualiza um endpoint e o protocolo, sem reconstruir a integração.

Sim. No ODM, mesmo regras BAL fluidas expõem apenas o vocabulário que um desenvolvedor preparou. No DecisionRules, usuários de negócio podem adicionar um campo por conta própria. A maioria das alterações do dia a dia deixa de exigir um desenvolvedor.

Depois de editar e publicar uma regra, a alteração fica disponível imediatamente. Não é necessária uma etapa separada de implantação nem um desenvolvedor para promovê-la, embora você ainda possa incluí-lo se o seu processo exigir uma revisão adicional.

Sim. O DecisionRules mantém Event Logs que registram quem fez uma alteração e quando, para que você sempre possa rastrear o histórico de uma regra.

Uma Organização é o nível mais alto de administração no DecisionRules. Ela permite que empresas gerenciem de forma centralizada usuários, autenticação, configurações compartilhadas e vários Spaces em um só lugar.

As Organizações são ideais para empresas que gerenciam várias equipes ou Spaces e precisam de uma administração centralizada, permitindo que cada equipe continue colaborando de forma independente.

Não. As equipes podem continuar trabalhando em seus Spaces existentes. As Organizações apenas centralizam a administração e as configurações de toda a empresa.

Teams agrupam usuários que trabalham nos mesmos projetos ou áreas de negócio, facilitando a administração e o gerenciamento de usuários.

Departments organizam vários Teams em unidades de negócio maiores, ajudando as empresas a refletir sua estrutura organizacional no DecisionRules.

Department Managers supervisionam Departments específicos e ajudam a distribuir as responsabilidades administrativas em organizações maiores.

As Organizações oferecem suporte a Single Sign-On por meio da Microsoft, do Google e da Okta.

As Organizações permitem configurar de forma centralizada a identidade visual da empresa, o provedor de IA, a autenticação, a estrutura organizacional e outras preferências para toda a organização.

Os administradores da Organização gerenciam usuários, Teams, Departments, autenticação, configurações compartilhadas e a estrutura organizacional geral.

Crie Teams e Departments que reflitam como sua empresa já funciona. Estruturas familiares simplificam a integração, melhoram a administração e facilitam o crescimento da organização.

Configure a identidade visual, a autenticação e o provedor de IA no nível da Organização para garantir uma experiência consistente em todos os Spaces e reduzir o trabalho administrativo.

As Pipelines de CI/CD automatizam a movimentação de regras de negócio entre Spaces e ambientes do DecisionRules. Elas usam a Management API e as Pipeline Tools do DecisionRules para exportar, comparar, fazer backup e importar projetos de regras como parte de um processo DevOps existente.

Não. O DecisionRules fornece a Management API e utilitários de pipeline que realizam as operações de regras. Sua plataforma de CI/CD existente orquestra quando elas são executadas, onde os artefatos são armazenados e se uma aprovação é necessária.

Você precisa de um Space de origem, um Space de destino, das URLs de ambiente do DecisionRules e de uma Management API key para cada Space. As Pipeline Tools oficiais são executadas com Node.js e podem ser adicionadas a um runner de CI/CD padrão. Um repositório Git protegido ou object storage é recomendado para artefatos e backups.

As ferramentas são scripts independentes de fornecedor. O DecisionRules fornece exemplos para Azure DevOps, AWS CodeBuild e Google Cloud Build. A mesma abordagem pode ser usada com GitHub Actions, Bitbucket Pipelines, Jenkins, OpenShift Pipelines e outras plataformas capazes de executar comandos Node.js.

Sim. As Pipeline Tools suportam DecisionRules Public Cloud, Regional Cloud, Private Managed Cloud e implantações on-premise. Cada origem e destino é identificado pela URL do ambiente e por uma Management API key específica do Space.

As Pipeline Tools padrão exportam e importam um Space completo, incluindo recursos de regras e estrutura de pastas. Para fluxos mais seletivos, a Management API também oferece operações para regras individuais, versões, Rule Flows e pastas.

Sim. Exporte os Spaces de origem e destino e execute a comparação antes da importação. As Pipeline Tools podem criar um artefato JSON de comparação que mostra aos revisores as mudanças de regras entre os dois ambientes.

Sim. A aprovação é configurada na sua plataforma de CI/CD. No fluxo documentado do Azure DevOps, comparação e migração são etapas separadas, e é necessária aprovação antes que a migração atualize o Space de destino.

Sim. Sua plataforma de CI/CD controla o gatilho. Uma pipeline pode ser iniciada manualmente, agendada ou conectada a um evento do repositório, como commit ou merge, conforme sua política de releases.

Não. A publicação é uma decisão de ciclo de vida separada. A pipeline movimenta o projeto de regras exportado e não deve ser tratada como aprovação automática de lógica de negócio inacabada. Defina e verifique os status esperados antes de direcionar tráfego de produção às regras importadas.

Sim. O fluxo documentado faz backup do destino, limpa seu conteúdo e importa o artefato de origem selecionado. Como é uma operação de substituição, backup, comparação de ambientes e aprovação são proteções importantes. Um fluxo personalizado com a Management API pode usar um escopo menor.

As Pipeline Tools padrão exportam e importam um Space completo, incluindo seus recursos de regras e sua estrutura de pastas. Para fluxos de trabalho mais seletivos, a Management API também oferece operações para regras individuais, versões, Rule Flows e pastas, permitindo que as equipes criem uma pipeline com o escopo necessário.

Sim. Exporte os Spaces de origem e destino e execute a etapa de comparação antes da importação. As Pipeline Tools podem criar um artefato de comparação em JSON que fornece aos revisores uma visão geral das alterações nas regras entre os dois ambientes.

Sim. A aprovação é configurada na sua plataforma de CI/CD. Por exemplo, o fluxo de trabalho documentado do Azure DevOps separa a comparação e a migração em estágios diferentes e exige aprovação antes que o estágio de migração possa atualizar o Space de destino.

Sim. Sua plataforma de CI/CD controla o gatilho. Uma pipeline pode ser iniciada manualmente, por agendamento ou vinculada a um evento do repositório, como um commit ou merge, dependendo da sua política de lançamento.

A publicação é uma decisão separada do ciclo de vida. A pipeline transfere o projeto de regras exportado; ela não deve ser tratada como aprovação automática de uma lógica de negócio inacabada. Defina os status esperados das regras no processo de lançamento e verifique-os antes de direcionar o tráfego de produção para as regras importadas.

Sim. O fluxo de trabalho documentado para um Space completo faz backup do destino, limpa seu conteúdo e depois importa o artefato de origem selecionado. Como essa é uma operação de substituição, o backup do destino, a comparação dos ambientes e a etapa de aprovação são medidas de proteção importantes. Um fluxo de trabalho personalizado com a Management API pode usar um escopo de implantação mais restrito quando a substituição completa não for adequada.

Antes da implantação, a pipeline salva o Space de Produção atual como backup. Se o novo release precisar ser revertido, uma pipeline de recuperação limpa o Space afetado e importa o backup selecionado. A produção volta ao estado registrado antes da implantação.

Não. O Rule Versioning gerencia iterações numeradas de uma regra dentro de um Space. A recuperação por pipeline restaura um snapshot salvo de um Space ou ambiente. Use Rule Versioning para o ciclo de vida de uma regra e backups de CI/CD para recuperação no nível do ambiente.

Armazene backups fora do Space de destino, em um repositório Git protegido, no armazenamento de artefatos de CI/CD ou em object storage como Amazon S3 ou Google Cloud Storage. Aplique as políticas de retenção e acesso exigidas pela sua organização.

Sim. Como a pipeline faz parte do seu fluxo DevOps, etapas de validação podem ser adicionadas antes da aprovação ou depois da importação. As equipes podem ampliá-la com verificações de políticas próprias ou smoke tests de Solver API após a implantação.

Sim. A pipeline faz parte do seu fluxo de trabalho DevOps, portanto, etapas de validação podem ser adicionadas antes da aprovação ou depois da importação. As Pipeline Tools oficiais se concentram em exportar, comparar, limpar e importar Spaces. As equipes podem ampliar a pipeline com suas próprias verificações de políticas ou testes rápidos pós-implantação usando a Solver API.

Antes da implantação, a pipeline salva o Space de produção atual como um arquivo de backup. Se for necessário reverter a nova versão, uma pipeline de recuperação limpa o Space afetado e importa o backup selecionado. A produção retorna então ao estado registrado antes da implantação.

Não. O Rule Versioning gerencia iterações numeradas de uma regra individual dentro de um Space. A recuperação da pipeline restaura um snapshot salvo de um Space ou ambiente. Use o Rule Versioning para o ciclo de vida de uma regra e backups de CI/CD para a recuperação de implantações no nível do ambiente.

Armazene os backups fora do Space de destino, em um repositório Git protegido, no armazenamento de artefatos da sua plataforma de CI/CD ou em um armazenamento de objetos, como Amazon S3 ou Google Cloud Storage. Aplique as políticas de retenção e acesso exigidas pela sua organização.

Armazene cada Management API key no secret store da sua plataforma de CI/CD. Use uma key separada para cada Space, limite quem pode executar implantações em produção e nunca faça commit de keys no repositório nem as imprima nos logs da pipeline.

Sim. Spaces separados criam uma fronteira clara entre trabalho em andamento e lógica pronta para produção. Muitas equipes usam Desenvolvimento, Teste ou Staging e Produção, mas o número de ambientes depende dos requisitos de revisão e compliance.

Exporte e faça backup do destino, compare-o com a origem, revise mudanças inesperadas, exija a aprovação adequada e retenha o artefato implantado. Após a importação, execute as validações ou smoke tests definidos no seu processo de release.

Mantenha a pipeline de recuperação separada da pipeline normal de implantação, proteja seu acesso e teste-a antes de precisar usá-la. A equipe deve saber qual artefato representa o último estado de produção conhecido e funcional e como selecioná-lo na recuperação.

Sim. Spaces separados criam um limite claro entre o trabalho em andamento e a lógica pronta para produção. Muitas equipes usam uma progressão de Desenvolvimento, Teste ou Staging e Produção, mas o número exato de ambientes depende dos requisitos de revisão e conformidade.

Exporte e faça backup do destino, compare-o com a origem, revise alterações inesperadas, exija a aprovação adequada e retenha o artefato implantado. Após a importação, execute os testes de validação ou testes rápidos definidos no seu processo de lançamento.

Mantenha a pipeline de recuperação separada da pipeline de implantação normal, proteja o acesso a ela e teste-a antes que seja necessária. Certifique-se de que a equipe saiba qual artefato representa o último estado de produção estável conhecido e como selecioná-lo durante a recuperação.

Armazene cada chave da Management API no armazenamento de segredos da sua plataforma de CI/CD. Use uma chave separada para cada Space, limite quem pode executar implantações em produção e nunca faça commit das chaves no repositório nem as exiba nos logs da pipeline.

Não. Você se conecta com a conta da DecisionRules que já possui e escolhe durante a configuração em qual Space o assistente trabalhará.

Sim. O Space precisa ter uma Management API Key configurada. Fora isso, ele pode estar vazio, e sua primeira solicitação pode criar algo nele.

Sim. O servidor Distribution opcional disponibiliza documentação, templates e funções reutilizáveis da DecisionRules na sua conversa sem exigir login. Ele nunca acessa seu Space.

É a conexão entre seu cliente de IA e seu Space da DecisionRules. Depois de conectado, seu assistente pode criar regras, explicá-las, gerar dados de teste, executá-las com entradas reais, gerenciar versões e tags e rastrear dependências.

O Model Context Protocol é um padrão compartilhado que permite que um cliente de IA se conecte diretamente a uma ferramenta e execute ações nela, em vez de ler documentação e fazer suposições. Ele é compatível nativamente com ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e outros.

Claude, ChatGPT, GitHub Copilot, VS Code e Codex têm suas próprias entradas de conector. Cursor e outros clientes compatíveis com MCP se conectam pelo Smithery. A DecisionRules também está publicada no Docker MCP Catalog e no Azure MCP Center.

Abra a lista de conectores no seu cliente, encontre a DecisionRules, faça login e escolha um Space. Clientes que não conseguem concluir um fluxo de login podem se autenticar com uma Management API Key.

Ela define tudo o que o assistente pode ver e alterar. Ele não pode acessar regras de outro Space nem trocar de Space por conta própria. Para um primeiro teste, use um Space de sandbox em vez de um que execute decisões de produção.

Normalmente, o Space errado foi selecionado. Conecte-se novamente e verifique o seletor de Space, especialmente se sua conta tiver vários Spaces.

Verifique se seu cliente está no modo agente, e não no modo de chat comum. No Copilot e no Cursor, essa é uma opção separada, embora as ferramentas possam continuar visíveis nos dois modos.

Sim. Você pode resolver uma regra com qualquer entrada e receber o resultado na conversa. Para uma suíte completa de testes de aprovação e reprovação, use Rule Tests no editor.

Sim. Clientes MCP podem manter várias conexões de servidor ao mesmo tempo, e seu assistente pode usá-las em uma única solicitação. Cada servidor é conectado separadamente, e a DecisionRules não precisa saber que os outros existem.

Qualquer coisa, de uma regra completa a uma única consulta. Pedidos comuns incluem criar uma Decision Table a partir de uma descrição, transformar uma lista de preços anexada em uma nova versão, gerar casos de teste, executar uma regra com dados de entrada, comparar versões e encontrar dependências.

Não. A geração passa pelo AI Assistant da DecisionRules, o mesmo presente no editor, treinado em lógica de regras real e boas práticas e ciente da estrutura das suas tabelas.

O assistente pode alterar regras, mas o acesso é limitado a um único Space, cada alteração entra no histórico de versões e nada chega aos chamadores até que uma versão seja publicada. Os Event Logs registram cada alteração e quem a iniciou.

O histórico da regra registra cada salvamento, as versões são instantâneos explícitos e ambos permitem reverter com um clique. O pior resultado realista é uma reversão.

Não. As solicitações são processadas sob termos empresariais, sem treinamento com seus dados. A DecisionRules possui certificações SOC 2 e ISO 27001, com residência de dados configurável e SSO disponível. Quando você usa seu próprio provedor de modelo, os termos dele determinam a garantia de não treinamento.

A API é para sistemas e chamadas repetíveis. O MCP é para conversas, criação e depuração. A maioria das equipes cria e depura pelo MCP e depois promove e mantém as alterações sincronizadas pela API.

Não. Tudo que é agendado, reproduzível ou de alto volume pertence à Management API. Um pipeline que ocasionalmente interpreta instruções de forma diferente não é um pipeline.

Sim. As regras podem ser criadas e depuradas pelo MCP e depois promovidas e mantidas sincronizadas pela API. O MCP escreve o rascunho, e a API faz a entrega.

Não. A personalização do logotipo e das cores é independente. Você pode configurar qualquer um deles separadamente ou combiná-los para criar uma experiência de marca mais completa.

Não. O White Labeling altera a identidade visual do seu ambiente, enquanto os recursos e fluxos de trabalho subjacentes do DecisionRules permanecem inalterados.

O White Labeling permite personalizar a identidade visual do seu ambiente DecisionRules com o logotipo e as cores da marca da sua empresa.

A identidade visual pode ser gerenciada em Organization → Settings → Organization Branding, onde há seções separadas para configurar o logotipo e as cores personalizadas.

Sim. As configurações do logotipo e das cores são independentes, então você pode atualizar o tema visual sem substituir o logotipo existente.

O formato SVG é recomendado para obter o melhor resultado. O logotipo é exibido dentro da área disponível para a identidade visual, portanto, um logotipo horizontal com dimensões adequadas ajuda a manter a legibilidade em toda a interface.

Sim. O White Labeling pode ser usado em implantações privadas do DecisionRules, incluindo Docker. A configuração da identidade visual permite que o ambiente implantado reflita a identidade visual da sua empresa.

Sim. A identidade visual pode ser alterada conforme ela evolui, sem afetar suas regras de negócio ou lógica de decisão.

As pipelines de CI/CD automatizam a movimentação de regras de negócio entre Spaces e ambientes do DecisionRules. Elas usam a Management API e as DecisionRules Pipeline Tools para exportar, comparar, fazer backup e importar projetos de regras como parte de um processo de lançamento DevOps existente.

Não. O DecisionRules fornece a Management API e os utilitários de pipeline que executam as operações com regras. Sua plataforma de CI/CD existente coordena quando essas operações são executadas, onde os artefatos são armazenados e se uma aprovação é necessária.

Você precisa de um Space de origem, um Space de destino, as URLs dos respectivos ambientes DecisionRules e uma chave da Management API para cada Space. As Pipeline Tools oficiais são executadas com Node.js e podem ser adicionadas a um runner de CI/CD padrão. Recomenda-se um repositório Git protegido ou um armazenamento de objetos para artefatos de lançamento e backups.

As ferramentas são scripts independentes de provedor. O DecisionRules fornece exemplos documentados para Azure DevOps, AWS CodeBuild e Google Cloud Build. A mesma abordagem pode ser usada com GitHub Actions, Bitbucket Pipelines, Jenkins, OpenShift Pipelines e outras plataformas capazes de executar comandos Node.js.

Sim. As Pipeline Tools são compatíveis com DecisionRules Public Cloud, Regional Cloud, Private Managed Cloud e implantações on-premise. Cada origem e destino é identificado pela URL do ambiente e por uma chave da Management API específica do Space.

Você precisa do DecisionRules App 1.26.1 ou posterior e do AI Engine 1.2.0 ou posterior. Sua conta de usuário deve ter permissão para usar o AI Assistant e editar a regra. A regra não pode estar bloqueada.

Seja específico sobre a alteração e o resultado esperado. Concentre-se no que deve mudar ou em como deve se comportar, em vez de solicitar uma reescrita completa.

Sim. Você pode atualizar células, adicionar colunas, modificar variáveis de regras e ajustar modelos de entrada ou saída em uma única solicitação. O Assistant processa todas as alterações relacionadas em conjunto para manter a consistência.

Não. A identidade da regra – nome, alias, versão e outras configurações da regra – é preservada.

Não. Nada é salvo automaticamente. O Assistant apenas cria uma proposta. Você precisa revisá-la e aplicá-la. É possível descartá-la ou desfazê-la a qualquer momento.

A proposta pode ficar desatualizada. Nesse caso, gere-a novamente para refletir a versão atual da regra. As alterações anteriores que você aplicou ainda podem ser desfeitas.

Nos testes, foi o limite de réplicas, não o motor. Até 100 clientes simultâneos, as configurações se comportaram de forma idêntica; depois disso, a implantação elástica continuou escalando e a limitada estabilizou em cerca de 9.800 resoluções/s.

Foram dois testes de carga k6 contra o DecisionRules no Kubernetes. Os geradores de carga estavam na mesma região do cluster e cada resposta foi validada pelo conteúdo. Todos os valores são tempos de ida e volta observados no cliente, incluindo a rede.

Para tabelas de decisão, a latência aumenta de 3 ms a 500 requisições/s para 10 ms a 100 mil requisições/s com uma carga de trabalho fixa. No entanto, isso pode ser evitado com escalabilidade.

Zero. Todas as requisições retornaram HTTP 200 e passaram pela validação de conteúdo.

Um fluxo com várias regras (até 10 regras) leva, em média, no máximo 5,5 ms dependendo de as regras serem executadas em paralelo ou em sequência.

É mais rápido em um fluxo. Um fluxo que executa 5 pequenas decisões em paralelo é apenas 0,1 ms mais lento do que uma única decisão. A maior parte do tempo de execução já é gasta na orquestração, não na avaliação.

Medimos mais de 106.000 decisões por segundo com 600 usuários virtuais simultâneos.

Uma tabela de decisão média (cerca de 20 linhas) ou uma árvore de decisão é processada em menos de 3 milissegundos a 500 requisições por segundo, incluindo a viagem de ida e volta pela rede.