Regras em aplicativos da Pega
Quando você joga um jogo de xadrez, você e seu oponente concordam em seguir um conjunto especÃfico de instruções. Essas instruções governam o jogo, tal como a maneira como cada peça se move no tabuleiro. Por exemplo, no primeiro lance, o peão pode andar uma ou duas casas para frente. As instruções básicas são as regras do xadrez.
Ao modelar um tipo de caso em um aplicativo da Pega Platform™, você configura o aplicativo com instruções para criar, processar e resolver um caso. Estas instruções são as regras do tipo de caso.
Réguas são os blocos de construção básicos de um aplicativo da Pega que a equipe do projeto pode configurar para criar uma solução de negócios para a organização do cliente e dos clientes dele. A Pega Platform usa regras para gerar código de aplicativo Java em segundo plano. Os aplicativos da Pega Platform contêm muitos tipos de regras que especificam diferentes tipos de comportamento do aplicativo. As regras são flexÃveis e reutilizáveis, o que permite que a equipe de projeto projete recursos de aplicativos com mais eficiência para implementá-los em vários tipos de casos e aplicativos.
Neste tópico, você examina as regras com mais detalhes.
Criação de regras automatizadas no App Studio
A abordagem low-code da Pega significa que os usuários podem concluir grande parte do trabalho de criação de um aplicativo no App Studio, especialmente no inÃcio do processo de desenvolvimento do aplicativo. Com a adição de uma automação de fluxo de trabalho no App Studio, a Pega Platform cria e gerencia automaticamente as regras associadas no Dev Studio. Por exemplo, ao configurar um tipo de caso (case type) no App Studio, você usa o Designer de ciclo de vida do caso e os painéis de configuração para adicionar uma visualização (view) a uma etapa de coleta de informações. Em segundo plano, a Pega Platform cria e gerencia as regras que definem os fluxos de processo e a IU.
No centro da imagem a seguir, deslize a linha vertical para ver o ciclo de vida do caso com um processo (process) criado no App Studio e a regra de fluxo do processo que o sistema cria em segundo plano.
A capacidade de criar regras complexas com a interface prática do App Studio é a chave para a funcionalidade low-code da Pega Platform.
Enquanto desenvolvedores de todos os nÃveis de habilidade técnica estão no App Studio criando automações de fluxo de trabalho usando modelagem visual low-code, a Pega Platform trabalha arduamente em segundo plano criando as regras técnicas que correspondem a essas automações. Como resultado, os Business Architects e outros desenvolvedores menos técnicos da equipe do projeto, como desenvolvedores cidadãos, podem se concentrar na definição de tarefas de negócios em vez de código.
Verifique seu conhecimento com a seguinte interação:
Modularidade do aplicativo com regras
O uso de regras individuais torna o seu aplicativo modular. Ao descrever o comportamento do caso com regras modulares e focadas nas tarefas, é possÃvel combinar e reutilizar regras conforme necessário. Por exemplo, você cria uma regra para descrever o conteúdo do e-mail para um cliente sobre o status de uma mudança de endereço. Ao criar a mensagem de e-mail como uma regra separada, em vez de integrar a mensagem ao ciclo de vida do caso, você pode atualizar o conteúdo do e-mail sem afetar o restante do processo de negócios.
Essa modularidade oferece três benefÃcios significativos: versão, delegação e reutilização.
| Versão | Os desenvolvedores criam uma nova versão de uma regra sempre que é necessário alterar o comportamento do caso. A Pega Platform mantém um histórico de alterações de uma regra, permitindo que os desenvolvedores revisem o histórico de alterações e desfaçam alterações quando necessário. Como cada regra descreve um comportamento especÃfico do caso, o restante do caso não é afetado. | Por exemplo, um desenvolvedor atualiza um formulário da IU com instruções e remove um campo crÃtico. Você pode revisar o histórico do formulário e reverter para a versão anterior à s alterações sem alterar outras regras no aplicativo. |
|---|---|---|
| Delegação | Os desenvolvedores delegam regras a usuários de negócios para permitir que eles atualizem o comportamento do caso conforme as condições de negócios mudem. O usuário de negócios atualiza a regra delegada, enquanto outras partes do aplicativo permanecem inalteradas. | Por exemplo, relatórios de despesas que totalizam US$ 25 ou menos recebem aprovação automática. Você cria uma regra para testar se um relatório de despesas totaliza US$ 25 ou menos e delega a regra ao departamento de contabilidade. O departamento de contabilidade, por sua vez, pode atualizar a regra para aumentar o limite de aprovação automática para US$ 50 sem enviar uma solicitação de mudança ao aplicativo. |
| Reutilização | Os desenvolvedores reutilizam regras quando é necessário que um aplicativo incorpore o comportamento de um caso existente. Caso contrário, é preciso reconfigurar o comportamento a cada vez que você precisar dele. | Por exemplo, você cria uma IU para coletar informações dos segurados para sinistros de seguro automotivo. Depois, você pode reutilizar esse formulário de IU para sinistros de seguro imobiliário e de seguro marÃtimo. |
Organização das regras
Embora você não gaste tempo trabalhando diretamente com as regras do aplicativo no Dev Studio, é imperativo que você colabore com seu Lead System Architect para entender a organização das regras do seu aplicativo.
No Dev Studio, as regras são agrupadas em classes e rulesets para que possam ser facilmente usadas para desenvolver aplicativos.
Classes
Na Pega, uma Classe descreve uma coleção de regras que o sistema agrupa de acordo com sua capacidade de reutilização. Cada aplicativo consiste nos três tipos de classes a seguir:
- Classe Work (Trabalho): A classe Work contém as regras que descrevem como processar casos, tais como processos, elementos de dados e interfaces de usuário.
- Classe Data (Dados): A classe Data contém as regras que definem os objetos de dados (data objects) que seu aplicativo usa.
- Classe Integration (Integração): A classe Integration contém as regras que definem as interações entre o aplicativo e os sistemas de registro externos, como um banco de dados externo mantido pelo cliente.
Classes parent e child (pai e filho)
Uma classe também pode conter outras classes. Uma classe que contém outra classe é uma classe pai, enquanto uma classe contida em outra classe é uma classe filho. Uma classe filho pode reutilizar ou herdar qualquer regra definida por sua classe pai.
Na imagem a seguir, clique nos Ãcones + para saber mais sobre as classes pai e filho.
Verifique seu conhecimento com a seguinte interação:
Rulesets
As regras são organizadas em rulesets (conjuntos de regras) para identificar, armazenar e gerenciar o conjunto completo de regras que definem um aplicativo. Os rulesets armazenam a funcionalidade reutilizável que você pode migrar de um aplicativo Pega para outro. Por exemplo, você pode criar um ruleset para armazenar regras de acordo de nÃvel de serviço (SLA). Você pode reutilizar o ruleset de SLA em qualquer aplicativo que processe casos que exijam os mesmos SLAs. A capacidade de salvar e reutilizar rulesets acelera o tempo e reduz o custo de desenvolvimento de aplicativos para o cliente.
Cada conjunto de regras tem um nome, provavelmente o nome do seu aplicativo e o número da versão. Quando você cria um novo ruleset, a versão padrão é01-01-01. Um exemplo de combinação de nome e versão do ruleset é GoGoRoad 01-01-01.
O número da versão é dividido em três segmentos: uma versão principal, uma versão secundária e uma versão de patch. Cada segmento é um número de dois dÃgitos iniciando em 01 e aumentando até 99. A numeração da versão do ruleset começa em 01-01-01 e vai aumentando.
Na imagem a seguir, clique nos Ãcones + para saber mais sobre a convenção das versões dos rulesets.
A partir de 2023, as versões dos produtos Pega Infinity seguem o formato Ano.Secundária.Patch. Para o Pega Infinity '23, a versão do produto é 23.1.1. A semântica da versão do ruleset da Pega segue o formato Principal-Secundária-Patch. Para o Pega Infinity '23, a versão do ruleset é 08-23-02.
Rulesets bloqueados e desbloqueados
Quando um ruleset é criado, ele é especificado como bloqueado ou desbloqueado. Os desenvolvedores trabalham em rulesets desbloqueados, e os bloqueios de ruleset impedem que os desenvolvedores façam alterações acidentais. Os desenvolvedores devem inserir uma senha antes de desbloquear e editar um ruleset bloqueado.
O Lead System Architect (LSA) gerencia o controle de versão e o bloqueio de qualquer ruleset relacionado a um aplicativo durante o processo de desenvolvimento. Consulte o LSA do seu projeto quando surgirem dúvidas relacionadas a regras e rulesets.
Verifique seu conhecimento com a seguinte interação:
This Topic is available in the following Module:
Quer nos ajudar a melhorar esse conteúdo?