Case Life Cicle
Case types
Utilizados para modelar transações de negócios que se repetem
é um modelo abstrato de uma transação de negócio
CASE
é uma instância específica de uma transação
Técnica de modelagem que permite que usuários de negócio vejam e interajam com o CASE ao mesmo tempo que pensam nele
Organizados em STAGES
STAGES
Representam a mudança de um status do case para outro status
O Primary Stage é o primeiro passo do case life cicle
PROCESSES
Contém uma série de Tasks ( Tarefas) ou steps
São coleções de dados
STEPS
Pode ser uma ação do usuário ou uma ação automatizada do sistema
Para os STAGES procure usar nomes ou frases curtas de no máximo duas palavras, que descrevam de forma objetiva o propósito para o usuário de negócio
para PROCESSES e STEP utilize verbo+nome como convenção
STAGE
Quando o usuário completa as tarefas do primeiro STAGE, automaticamente ele muda para o segundo STAGE
Os cases normalmente migram entre os STAGES de forma sequencial, mas podem seguir fluxos alternativos, em um outro PATH
Alternate Stage
STEP
Quando um case avança um STEP, PEGA automaticamente atualiza o status do case para o valor definido para aquele STEP
CASE STATUS
CASE STATUS padrão definidos pelo PEGA são:
OPEN
PENDING APPROVAL
RESOLVED-COMPLETED
Uma instrução num STEP mostra para o usuário o que deve ser cumprido
Usuários veem as instruções no worklist, quando eles abrem um CASE
PEGA
É uma plataforma de desenvolvimento de baixa ou nenhuma codificação, orientada a modelo de negócios, onde o usuário do negócio trabalha junto com o desenvolvedor para configurar aplicações usando configurações visuais
Partes interessadas tanto de TI quanto de negócios podem utilizar ferramentas visuais compartilhadas para a captura de requisitos, DIRECT CAPTURE OF OBJECTIVES (DCO), de forma sincronizada
Para cada requisito de negócio, você pode modelar um WorkFlow em PEGA, que define os diversos processos de negócio necessários para se alcançar um objetivo
Permite a automação de vários processos, adicionando rotas dinâmicas, orquestrando mudança de dados para diversos sistemas de armazenamento.
Possui um conjunto de Modelos e boas práticas para garantir a mantenibilidade
Ao escolher uma de várias extensões PEGA, você poupa tempo e esforço no desenvolvimento de aplicações
Tem aplicações sob medida para áreas como Marketing , Vendas, prestação de serviços, ou uma gama de variedades para industria, financeiro, ou governamentais, além de médica e seguros.
Possui uma gama de recursos:
desenvolvimento de aplicações
gerenciamento de casos
gerenciamento de dados e integração
gerenciamento de decisões
Interface de usuário UI
relatórios
Administração de sistemas
DevOps
Mobilidade
Segurança
Automação e robótica
Workforce intelligence
Assistente Virtual Inteligente
java e Activities
Pode ser feito deploy na cloud ou sob premissas (Clouds terceirizadas)
Pega Cloud
Outra de sua escolha, de terceiros.
Otimizada para aplicações PEGA e com uma integração maior
Com a plataforma PEGA você pode reutilizar as funções em diferentes áreas de sua aplicação
Para tal se usa o Situational Layer cake
Ruleset
Rules
Common Aplication Ruleset Regras mais gerais comuns a todos, no layer principal... fica na aplicação principal, tudo que descende disso vai subindo no layer cake
SLA
Service Level Agreements
Organizações frequentemente estabelecem SLA para garantir o desempenho em um tempo específico
Estabelece a Deadline para conclusão de um trabalho
Quando se estabelece a Goal e a Deadline, PEGA cria as regras do SLA pra você
Você pode configurar SLA para STEPS, PROCESSES, STAGES, ou CASES
START
GOAL
DEADLINE
PASSED DEADLINE
O momento em que o SLA se inicia, o momento Zero
Define quanto o Assigment irá demorar, tipicamente mensurado para quando cada STEP, ASSIGMENT, ou CASE se inicia
O tempo que o CASE ou o STEP demanda antes que seja considerado atraso
è medido a partir de quando o CASE, STEP ou ASSIGMENT se inicia
O tempo que passou desde que se terminou a deadline
O nível de urgência é definido entre 10 e 100
Em PEGA, tarefas urgentes indicam prioridade
a funcionalidade GET NEXT WORK atribui alta urgencia a tarefas prioritárias em detrimento de tarefas menos prioritárias, de forma a tentar garantir que todas sejam cumpridas dentro do prazo
Optional Actions
Você pode definir ações opicionais que os usuários podem realizar enquanto o CASE está em qualquer STAGE ou STEP do CASE LIFE CICLE
Você pode programar para acontecer fora da sequência dos eventos de um CASE
Podem ser como PROCESSES ou USER ACTION
OPTIONAL PROCESSES
Pode carregar um processo opicional para atualizar informações em multiplos STEPS, podendo ou não retornar ao caminho primário de um CASE
OPTIONAL USER ACTION
Atualiza informação em um tela simples de usuário
Pode ser adicionada em qualquer parte do CASE LIFE CICLE, ou num STAGE específico
Conditional Execution
Você pode definir condições que controlam quando um PROCESSES ou um STAGE executa num CASE, e pode ser um campo, comparador ou valor
Pro default, processos iniciam e executam apenas quando uma condição se faz presente
Por padrão, STAGEs nunca pulam se uma condição não for configurada para tal
Você pode criar mais de uma condição para cada STAGE ou PROCESSES, e pode junta-las usando operadores lógicos tal como AND e OR
se os PROCESSES podem ocorrer em qualquer ordem, eles podem ser configurados em PARALELO
PARALEL PROCESSES permitem que o CASE avance em vários caminhos simultâneos ao mesmo tempo em um STAGE
São criados no DEVStudio
Você pode configurar dois ou mais processos para ocorrer em paralelo
Quando o CASE é processado, as tarefas (ASSIGMENTES) em paralelo podem ocorrer simultâneamente, aumentando a eficiência no processamento do CASE
DECISION POINTS
São baseados em condições e são configurados para avançar automaticamente
Usa-se estruturas de decisão para modelar decisões automáticas, através de uma ou mais condições, ou da regra de negócio.
Routing Work
Define quem faz o trabalho
É comum num processo que vários operadores sejam responsáveis por realizar tarefas diversas, e que o conjunto dessas tarefas cumpridas realizem o trabalho
Designar as tarefas de forma cuidadosa e correta assegura que grupos ou pessoas específicas executem determinadas tarefas, aumentando a eficiência do negócio.
Existem alguns tipos de designações (Routing Types)
Work queue
Você usa para designar a tarefa a pessoa mais adequada
É uma lista de tarefas em aberto em ordem de importância, por grupo de usuários
Work List
É uma lista de todas as tarefas em aberto por ordem de importância para um usuário específico
Routing Options
Current User, se o current user tem que concluir a tarefa específica
specifc user, se um usuário específico irá concluir aquela tarefa específica
work queue, para um grupo específico, onde uma pessoa do grupo pode completar a tarefa
Operator record
Em PEGA, usuários são associados com o operador de gravação (operator records), que contem informações úteis para designação (ROUTING)
Você pode adicionar condições adicionais de routing
OOTB Out-of-the-Box Routing Options
PEGA tem uma gama de opções de routing, dentre elas:
Work queue of Work group
Work list of a specifc user
Current User
Business logic based on a when condition
CASE APPROVAL
São pontos de decisão onde uma ou mais pessoas decidem se aprovam ou não um CASE
Quem precisa aprovar, um usuário simples ou vários usuários?
Para um Cascading approval, quantos devem aprovar, é necessária algum tipo de hierarquia?
Como as aprovações são manuseadas, deveriam ser trocadas para um outro case?
Approval Type
Single Approver
Você pode designar aprovações simples ( single approval use case) para uma Work list de um usuário específico ou work queue ( Fila de Trabalho)
Cascading Approval, reporting structure
Se baseia numa estrutura de reports que requer aprovação de um diretor, um gerente, ou maior
Cascading Approval, authorit matrix
É mais flexivel que o reporting strucuture, possibilitando designar outras entidades de fora do organograma de reporting
Você configura através do Approval/Reject Shape
Case Hierarchy
Rules
DEF-Instruções para criar, processar e resolver casos definidos pelo desenvolvedor ao modelar um case type
Descreve o comportamento de casos individualmente
A Pega Platform usa elas para gerar o código da aplicação
Rule Type 
Modelo abstrato do comportamento de um caso específico
A Pega Platform fornece diversos tipos
Modelo usado pelo SA para criar uma nova regra. Você primeiro seleciona o Rule Type e com isso determina as propriedades que serão necessárias para implementar o comportamento do caso associado
Pode ser definido como um template para criar uma regra
Wizards
PEGA fornece assistente que cria e modifica muitas das regras da aplicação para você
No AppStudio
Muito dos trabalho de designing pode ser conluido através dos assistentes
DevStudio - Caso preciso de regras mais especídifcas ou de modificações mais a fundo, deve ser feita através do DEVStudio
O uso de regras individuais faz sua aplicação modular
Ao descrever o comportamento de um CASE com regras modulares, focado em tarefas, você pode combinar e returilizar regras conforme necessário
Modularidade
Benefícios
Versionamento
Delegação
Reuso
System Archtects criam versões de numa nova rule, sempre que o comportamento de um CASE precisa mudar
SA delegam regras aos usuários de negócio para atualizar o comportamento do CASE conforme a condiçlão de negócio muda
SA reusam as rules de uma aplicação para incorporar um comportamento de um CASE existente
click to edit
Para empacotar regras da distribuição, como parte da aplicação, você ou( grup0
Rulseset - Identifica, grava e gerencia, um conjunto de regras que definem a aplicação na maior parte de set ciclo
Um conjunto de regras que definiem uma amplicação ou maior parte de uma aplicação
Rulesetes
SA coletam regras individuais como instâncias de uma ruleset, chamada rolesets versaio
Ruleset Versioning
São instâncias de uma ruleset
Permitem o SA atualizar a aplicação pela provisão do acesso a uma ruleset de um momento.
Você identifica uma ruleset pelo nome e pelo número
O número é dividido em três segmentos
Maior,
Menor
path
Representa a release liberada da aplicação
representa uma release intermediária ou uma atualização para uma release maior
Consiste de correções de bugs na aplicação
Ruleset stacks
São uma sequencia de rulesets
Determina a sequência com o que PEGA observa as rulesets para encontrara a que está sendo usada
Cada versão de uma aplicação contém uma única ruleset stacks
Classes and class hierachy
Um dos pontos fortes do PEGA é o reuso de regras nas classes e aplicações
O reuso de regras melhora o reuso da aplicação,
Diminui o tempo de coding
Group of Class
workclass
Integration Class
Data class
Quando você cria uma
Se você precisa de controle mais detalhados na cria~]ap de regras,
Contém regras que mostram como processar um case ou cases
Contém regras que definem como a aplicação interage com outros sistemas
Contém regras que definem os dataobjetos utilizados na aplicação
Uma classe que contém outra classe é chamada Parent Class
Uma classe que é contida por outra classe é chamada child class
Pode usar por herança as regras de uma Parent class
A hierarquia de Classes determinam com SA podem reutilizar regras na aplicação
Formada por um grupo de classes
Classes que descrevem um CASE type específico
Classes que coletam regras e elementos de dados comuns
Classes de outras aplicações
Classes Base da plataforma PEGA
Propósito de organizar regras na aplicação
Herança
Pattern inheritance
directed inheritance
è automática
Usa o classname para herdar regras disponíveis para reuso
A camada de organização contém todas as classes para aplicações em toda empresa ou organização
A camada de divisão contém todas as classes de dados, trabalho e integração da divisão
A camada de unidade contém todas as classes de dados, trabalho e integração da unidade
O class group contém todos os case types da aplicação
Onde uma classe pai é especificada explicitamente
Para reutilizar regras padrão da plataforma PEGA, e regras de outras aplicações, fora da classe herárquica de negócio.
Para reforçar uma hierarquia de classes se utiliza o WAIT
LIke a DAO
Like a MODEL
Like a CONTROLLER
Adding Fields to a Case Type
Data Elements
OS elementos de dados ou o conjunto de elementos de dados compreendem os data models do CASE TYPE
Os Data Models definem a estrutura do case type
Data Type ou Data Object
Coleção dos elementos relacionados
Contém mais que uma propriedade relacionada ao elemento
São chamados de Properies ou Fields
guardrails
garantem o conjunto de boas práticas PEGA
Usa as regras de criação para gerar código java, e as activities no sentido de classes que representam uma tela, como no Android
Agilie Workbench, metodologia ágil para entrega CI, C Delivery
report browser
Emitem 3 tipos de alertas diferentes
Data Storage in Memory
Cases são coleções de dados
Para resolver um CASE, em PEGA os dados são capturados, manipulados e apresentados através do processo de negócio
Enquanto se processa um CASE, os dados são armazenados na memória para serem utilizados por um ou mais usuários
Cada elemento de dados tem duas partes de informação
O nome
O valor
Cada elemento de dado é gravado na memória através de uma PAGE
PAGE é uma estrutura para organizar elementos de dados numa aplicação
Algumas são criadas pelo sistema para rastrear o usuário ou a Sessão
Durante o processamento de um CASE, cada PAGE mantem na memória uma estrutura conhecida como CLIPBOARD
CLIPBOARD é uma porção da memória reservada no servidor pelo PEGA para dados gerados na aplicação
Consiste de todas as PAGES utilizadas para rastrear os elementos de dados que representam o CASE e e a Sessão
PAGES podem serm adicionadas ou removidas do CLIPBOARD sempre que necessário
PyWorkPage
Grava todos os dados gerados durante a criação ou processamento de um CASE
é uma PAGE específica do CLIPBOARD
Quando você cria um CASE filho, o CLIPBOARD contém PAGE PyWorkCover, que contém dados do CASE pai
Uma embedded PAGE com PyWorkPAge armazena dados que descrevem um Data type
Cada PAGE num CLIPBOARD é uma instância de uma classe específica, que inclui o PyWorkPage
O CLIPBOARD Tool é organizada em 3 partes
Header
Painel direito
Painel Esquerdo
Seleciona a Thread a ser visualizada
Corresponde a uma ACTION sendo gerenciada pelo PEGA
O Clipboard possui um thread dedicada ao DEVStudio
As demais threads são para rules forms
Mostra cada PAGE definida no CLIPBOARD para um thread específica
Lista todas as properties para uma PAGE referenciada
E seus valores
As PAGES no clipboard são divididas em:
USER PAGES
DATA PAGES
LINKED PROPERTY PAGES
SySTEM PAGES
Páginas criadas por uma ação do usuário, direta ou indiretamente
Contém dados de leitura definidos pelos data page rules
dados de leitura reiados por propriedades linkadas , que contém informação de objeto de dados referenciado em LINKED PROPRETy
Contém PAGES que descrevem a sessão do usuário
Data Models
PAGE MODE
descreve um Data Object como se fosse um objeto em Java
Page
Como uma entidade simples, com alguns fileds
Page List
Um conjunto de objetos ordenado numericamente, tal como um filed group list
Page group
Um page list não ordenado
VALUE MODE
Descrevem uma pequena parte da informação como um total
Single Value, texto, numero, data, boolean
Value list
properties com mesma propriedade ordenados
Value Group
O mesmo do value list, só que não ordenado
PAGE MODE
VALUE MODE
Analogamente como tipos primitivos em JAVA, tal como int em relação a um Integer
Tal como um conjunto de tipos primitivos, como um conjunto de Inteiros, de forma não ordenada
Como um conjunto de inteiros, porém de forma ordenada
Tal como uma instância de objeto em JAVA
Data Model tab
Você pode usar no Case Designer para adicionar ou remover properties de um case type
Lá os properties são chamados fields
click to edit
Quando se cria um novo Field, ao especificar um tipo, as opções podem ser classificadas como:
SImple
Fancy
Complex types
Property Rule Form
Contém as definições de propriedades
As definições de propriedades são rules
Compartilha as propriedades de versionamento, herança e controle de acesso
As rules padrão possuem os seguintes prefixos:
px --> Propriedades especiais, a aplicação apenas pode ler esse tipo de proprey
py: -->VocÊ pode utilizar na sua aplicação
pz:-->Suporta os processos internos do sistema, Sua aplicação pode ler, mas não pode escrever essas propreties
USER VIEWS
User Views
Aplicações Corporativas normalmente requerem interação do usuários
São contruidas para os usuários completarem tarefas (Tasks)
Antes de criar uma View deve-se levar em conta as seguintes informações:
1) que campos o usuário necessita ver?
2) Como os usuários irão inserir valores nesses campos?
3)Quais usuários podem modificar os campos, ou apenas visualiza-los?
Picklist -> é um tipo de Field acicional onde você escolhe o tipo de lista (dropdown ou radiobutton)
Hieranchy
Routing
routing
case life cicle
Service Level Agreement
Optional Actions
Data Storage in Memory
Adding Fields to a Case type