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 xadrez

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