STUDY VLOCITY 🚀

INDUSTRIES ORDER MANAGEMENT

⁃ Industries Order Management era anteriormente Vlocity Order Management

Sistema que intermedia (ou troca) dados entre a solicitação do cliente do front office e os
sistemas de atendimento do back office.

Fluxo de Order Capture

• Proposta -> Oportunidade -> Ordem -> Ativo

• Oportunidade -> Proposta -> Ordem -> Ativo

Order management

⁃ Termo genérico da indústria

Industries Order Management

(APP) - aplicativo

⁃ Solução da Salesforce Industries para gerenciamento de pedidos.

⁃ Primeiro sistema de gerenciamento de pedidos baseado em catálogo para a

empresa.
Tem duas facetas principais:

1. Ordem de decomposição
2. Orquestração de pedidos


Objetivo

Garantir que os sistemas de atendimento recebam os dados de que precisam, no momento

exato em que precisam, para fornecer serviços de telecomunicações.

⁃ Integrar seu ecossistema de ponta a ponta usando um catálogo de produtos

corporativos compartilhados.

⁃ Equipes colaborem rapidamente e entreguem ofertas ao mercado.

⁃ Sistemas de front e back-office para se tornarem orientados por catálogo para

eliminar silos de dados e modelos de produtos fragmentados.

Funções

1. Validation of Orders

Fornece dois tipos de validação;

1. Garante que o pedido está bem estruturado

(validação sintática/syntactical validation).

2. Garante que os produtos e serviços do pedido possam ser atendidos

(validação comercial/commercial).
2. Decomposition of Orders

⁃ Converter informações de pedidos comerciais/commercial order em informações de

pedidos técnicos/technical order.

3. Communication with Fulfillment Systems

(APP) - aplicativo

⁃ Se comunica com os sistemas de atendimento para enviar e receber informações na

sequência correta.

4. Manage Fulfillment Lifecycle and Notifications

⁃ Gerencia o order lifecycle o, fornecendo notificações de eventos e tratando os erros

que ocorrem.

5. Zero-touch vs. Manually Driven

(APP) - aplicativo

⁃ Encontrar o equilíbrio certo entre tarefas manuais e automatizadas, para maximizar

a precisão e a eficiência.

TMForum identifica 2 áreas principais de order management.

1. Commercial Order Management (COM) ou Customer Order Management

2. Service Order Management (SOM)

• Industries Order Management abrange COM e SOM em conformidade com o TM
Forum.

Exemplo:

⁃ Catálogo incluir produtos, atuará automaticamente na função de Commercial Order

Management.

⁃ Catálogo incluir serviços, atuará automaticamente em uma função de Service Order

Management.

⁃ Quando seu catálogo incluir produtos e serviços; atuará para os dois COM e SOM.

Industries Order Management

⁃ Integrar modelos completos de produtos, serviços e recursos para impulsionar as

funções de vendas, CPQ, pedidos e atendimento.

⁃ Fornece uma interface de usuário com ferramentas comuns, permitindo que suas
equipes criem, gerenciem e entreguem ofertas ao mercado de forma colaborativa.

⁃ Abordagem evolutiva para transformar os sistemas de front-office e back-office

para se tornarem orientados por catálogo.

Best-in-Class Order Management

É responsável por fornecer várias funções importantes:

Fornecer dois tipos de validação:

⁃ Validação sintática - Certifique-se de que o pedido está estruturado corretamente.

• Validação do pedido - Garanta que os produtos, serviços e recursos do pedido
possam ser atendidos. As regras de negócios definidas no catálogo de produtos
compartilhados são usadas para realizar a validação comercial.

Necessidades operacionais importantes:

Orchestrations

⁃ Lidar com solicitações de atendimento de várias fontes com diferentes graus e

qualidade de informações.

⁃ Capaz de se comunicar com todos os sistemas de atendimento na pilha.

⁃ Permitir uma abordagem gradual para a transformação do ecossistema sem a

necessidade de uma mudança de paradigma.

Service agility

⁃ Introduzir novos serviços e se adaptar rapidamente às condições do mercado.

⁃ Fornecer um ambiente colaborativo para todos os usuários compartilharem ideias,

juntamente com ferramentas que permitam aos usuários visualizar e validar rapidamente
as configurações à medida que as criam.

Catalog-driven

⁃ Empregar uma arquitetura orientada por catálogo com base em um modelo de

produto, serviço e recurso central.

⁃ Permite que as regras de atendimento coexistam com essas configurações

principais.
Industries Order Management Solution Map

Entenda:

1. Pedidos são recebidos de vários sistemas, como varejo, web ou aplicativos móveis
(chamado de envio omni-channel).

2. Utiliza as relações e regras definidas no catálogo para enriquecer o pedido

comercial com as informações técnicas necessárias.

3. Rastreia pedidos através de um ciclo de vida de estados, gerando fluxos de trabalho

dinamicamente e controlando e sequenciando as interações com sistemas de
atendimento.

4. Fornece lógica de integração para comunicação com sistemas de atendimento,

usando tecnologias como DataRaptor, Apache Camel e Java.
Produtos

Produto comercial

São os produtos que o cliente e os representantes de atendimento ao cliente (CSRs)

veem e com os quais interagem.

Exemplo:

Vários telefones e pacotes de internet.

⁃ Produtos comerciais são as coisas que você pede de um catálogo e joga no carrinho
de compras.

Produto técnico

Não são "vistos" pelo cliente. Eles contêm detalhes técnicos necessários para vários
sistemas de atendimento de pedidos downstream/ externo.

Exemplo:

Detalhes sobre como agendar uma instalação de roteador no local quando um pacote de
internet doméstico é vendido.

(OBS: Sistemas de terceiros são chamados de sistemas externos, sistemas downstream,

sistemas de atendimento ou mesmo sistemas de orquestração.)
Principais processos de Industries Order Management

Order decomposition and order orchestration

Order Decomposition

Responsável por enriquecer um pedido com as informações técnicas necessárias para

atender o pedido durante a orquestração.

A decomposição prepara uma ordem para orquestração.

Transforma um pedido comercial em um pedido técnico e gera solicitações de

atendimento para usar durante o processo de orquestração.

Process Order Decomposition

• À medida que cada pedido é recebido, a decomposição do pedido usa o catálogo

para enriquecer o pedido comercial com os atributos técnicos necessários para o
atendimento.

• Em seguida, a decomposição do pedido verifica o estoque do assinante para garantir

que as ações de atendimento apropriadas sejam tomadas com base nos serviços que o
cliente já possui.

• Por fim, a decomposição do pedido gera uma série de subordens/solicitações de

atendimento, que incluem tarefas de atendimento relacionadas.

⁃ A saída do processo de decomposição após a submissão da ordem é a Solicitações

de atendimento.
Asset IOM

• Ativos são gerados a partir de Itens do Pedido

• Um ativo é um item de valor que uma conta ou contato possui. Podem representar
tanto produtos como serviços adquiridos pelos clientes.

• No Salesforce, assets são registros do objeto padrão Asset.

No IOM, os ativos são gerados após a ativação da Ordem

Order Orchestration

Depois que um pedido é enviado e decomposto, o plano de orquestração é gerado. A

Visualização do plano de orquestração mostra os itens de orquestração e suas
dependências entre si.

Process Order Orchestration

Garante que itens ou tarefas de orquestração no fluxo de trabalho sejam executados na

sequência correta e forneçam as informações corretas para cada sistema de atendimento
de acordo com a ação de atendimento executada.

⁃ Inclui interações automatizadas com sistemas de atendimento, bem como tarefas

manuais que devem ser concluídas por usuários com conjuntos de habilidades
específicas.

⁃ Itens de orquestração no fluxo de trabalho podem ser executados em sequência

ou em paralelo.
O aplicativo de order management é responsável por comunicar o status de atendimento
aos canais de captura de pedido

⁃ As cores das tarefas indicam seu status.

⁃ Segmentos entre tarefas mostram dependências.

-> Quando uma nova versão de um fluxo de orquestração é implantada, a versão anterior
do fluxo de orquestração é congelada e os pedidos atualmente em execução na versão
congelada podem ser concluídos.

Fulfillment Designer / designers de atendimento

Associa uma fila de erros a um item de orquestração ao configurar itens de orquestração.

Tipos de itens de orquestração podem ter filas de erro associadas:

• Callouts / Textos explicativos

• Auto Tasks/ Tarefas automáticas
• Push Events/ Eventos push

Três recursos da experiência do usuário que beneficiam os fallout managers e os

designers de atendimento.

1. Login único para todas as funções relacionadas ao cumprimento (Single-sign)

2. Navegação consistente e experiência do usuário.

3. Colaboração por meio do catálogo de produtos corporativos compartilhados.

Shared Catalog for Order Management

O Catálogo Compartilhado é a base para as Cotações de Configuração de Preços de

Indústrias (CPQ) e Gerenciamento de Pedidos de Indústrias (IOM).

-> Shared Catalog oferece suporte a todos os níveis de definições de produtos, incluindo
ofertas, especificações de produtos, serviços e especificações de recursos.

⁃ Catálogo Compartilhado armazena todo o modelo de produto.

Commercial - produtos os clientes e os representantes de atendimento ao cliente (CSR)
veem e com os quais interagem.

Offer - projetadas pelo marketing e vendidas para determinados canais e segmentos de

mercado por um preço designado.

Product Spec - descrevem os vários componentes do produto. Dependendo do seu

modelo de dados, pode ser uma hierarquia reduzida ou incluir relacionamentos pai/filho.

Technical - produtos que não são "vistos" pelo cliente. Eles contêm detalhes
técnicos necessários para vários sistemas de atendimento de pedidos downstream.

- Detalhes técnicos são atributos técnicos.

- Necessário para decomposição do pedido.

- Atributos técnicos são armazenados em Shared Catalog.

• IOM depende de atributos de produtos para criar mapeamentos entre campos e/ou
atributos.

Map from/Map to

Os campos e atributos de produtos comerciais são mapeados para atributos técnicos de

produtos.
(MAP FROM)

Os produtos técnicos contêm apenas atributos, não campos.

(MAP TO)
Modeling Technical Products

Exemplo:

Um cliente liga para comprar o serviço de banda larga para sua casa.

Representante de atendimento ao cliente (CSR)

1. O cliente liga e fala com um CSR sobre a compra de banda larga residencial.
2. Existe uma lacuna entre o que é realmente necessário para realizar a compra e o que
o cliente acha que precisa. (aqui entra IOM)

3. O cliente vê a necessidade de uma conexão com a internet para seus celulares,

tablets e computadores. Percebe também que um modem também será necessário no
local.

- O atendimento de pedidos requer mais detalhes técnicos do que um modem

e alguns dispositivos.

Exemplo:

- Distância do loop local pode influenciar qual porta DSLAM usar.



- Modelo, fabricante, protocolo sem fio e alcance específicos.

Modelagem de Produtos Técnicos

Product2 - No topo do produto hierárquico está o objeto Salesforce Product2 padrão

Commercial - Caixas azuis a esquerda, produtos do catálogo compartilhado.

Technical - Caixas douradas a direita, produtos do catálogo compartilhado.

- Produto técnico tem muitas informações detalhadas.

Exemplo:

- Portas SDLAM
- Tipo de conexão
- Código de trânsito.
- Produtos comerciais e produtos técnicos no IOM são registros do objeto Product2 da
Salesforce e utilizam o mesmo tipo de registro, porém apenas os produtos comerciais
têm o checkbox "Product2.vlocity_cmt__IsOrderable__c" ativo.

Modelagem para Industries Order Management

Item tangível específico:

Os produtos comerciais e os técnicos devem ter um código de produto único no catálogo

que os diferencie como comerciais ou técnicos.

• Produtos comerciais têm o sinalizador Orderable = True e um preço associado a

eles.

Orderable flag = True

• Produtos técnicos têm o sinalizador Orderable = False e não incluem um preço.

Orderable flag = False

Order Decomposition

Dentro do processo de decomposição, uma relação de decomposição cria uma relação

um-para-um (1:1) entre um produto de origem e um produto de destino, e criar
relacionamentos um-para-muitos (1:M) e muitos-para-um (M:1).

Tipos de relacionamentos

⁃ One-to-one (1:1)
⁃ One-for-many (1:M)
⁃ Many-for-one (M:1)

(OBS: Relacionamentos de vários níveis NÃO estão vinculados a nenhum modelo de

decomposição único (1:1, 1:M, M:1, etc.)
1. Uma relação de decomposição cria uma relação um-para-um (1:1) entre um produto
de origem e um produto de destino.

https://vlocity-university.litmos.com/course/2481130/module/5449977/Scorm?LPId=76739

⁃ Modelo de decomposição um-para-um geralmente se transforma em um modelo

um-para-muitos no setor de telecomunicações.

2. Criar um relacionamento um-para-muitos (1:M), você pode criar vários

relacionamentos de decomposição para qualquer produto de origem.

⁃ Uma maneira comum de testar uma relação de decomposição um-para-muitos é

fazendo um pedido e decompô-lo

3. Criar relacionamentos muitos-para-um (M:1) usando vários relacionamentos de

decomposição e a função Scope.

Definindo o Escopo do Produto

O Order Management gera um número de Fulfillment Request Lines (FRL) para itens de
pedidos downstream como resultado do processo de decomposição.

⁃ Às vezes, é necessário mesclar várias instâncias do mesmo produto técnico na

mesma FRL no item de pedido posterior.

Exemplo:

• As caixas azuis representam produtos comerciais (encomendáveis)

• A caixa verde representa um produto técnico
• Linhas pretas representam relacionamentos pai-filho
• Linhas azuis representam relações de decomposição
Usamos o campo no objeto do produto Vlocity (Product2) chamado Scope.

⚠ Considera Scope apenas para produtos técnicos porque eles são usados em
resultados de decomposição.

Configurações de escopo mais comuns;

1. Order Item / (padrão)

2. Account / Conta

O escopo da Account NÃO é a configuração padrão. No entanto, pode ser configurado

para consolidar Linhas de Solicitação de Cumprimento (FRLs) nos resultados da
decomposição.

• Escopo do item do pedido

Escopo do produto técnico definido como Item do pedido, as instâncias correspondentes

serão mescladas na seguinte estrutura e a origem da decomposição usará um item do
pedido pai direto.
• Escopo da conta

Escopo de um produto técnico como Conta cria uma única instância de solicitação de
atendimento. Existe apenas um item de estoque para o produto técnico para a conta
especificada. Se houver outro pedido solicitando o mesmo pacote, o processo de
decomposição gera um FRL com base no item de estoque existente.

Relacionamentos multiníveis
Relação típica de decomposição de 3 níveis com CFS' e RFS'.

⬆ na imagem acima, existem vários relacionamentos de decomposição que devem ser

criados de produtos Level 2 para produtos do Level 3.

Observe, que esta não é uma relação um-para-muitos (1:M) porque, em tempo de
execução, apenas um produto é selecionado no Level 2 de decomposição e esse único
produto será decomposto usando a relação de decomposição apropriada.
-> A decomposição pode ser usada em vários estágios para modelar o catálogo técnico em
vários níveis de acordo com a modelagem SID do TM Forum.

Modelar catálogo técnico com camadas (CFS) e (RFS).

• RFS - Suporta a rede e infraestrutura voltada para parte do serviço.

⁃ RFS têm um relacionamento direto com os CFS e os sistemas downstream de

atendimento de pedidos

• CFS - Serviços diretamente relacionados a produtos.

⁃ CFS têm uma relação direta com produtos e RFS.

As comunicações com sistemas externos são tratadas pelo mecanismo de orquestração

do IOM (não pela decomposição).

Condições e Regras de Mapeamento

As regras de Mapeamento são consideradas configurações de relacionamentos de

decomposição Obrigatório. Condições são opcionais.

Condições

As condições são poderosas e muito comuns, mas não são obrigatórias.

⁃ O padrão é não ter nenhuma condição no relacionamento de decomposição.

Exemplo:

A IOM inicia a decomposição de um item de pedido apenas se a condição especificada for

avaliada como verdadeira. Caso contrário, ignora a relação de decomposição.
Regras de condição

⁃ Funcionam de maneira muito semelhante a uma cláusula SQL Where.

Cláusula SQL Where

Filtra critérios que os valores do campo devem cumprir para que os

registros que contêm os valores sejam incluídos nos resultados da
consulta.

Em vez de restringir o conjunto de dados retornado de uma consulta, eles são usados
como lógica de controle para o processo de decomposição.

Decompose if <whatever> is true

Decomponha apenas se <whatever> for verdadeiro.

Exemplo:

Um cliente que seleciona um pacote de internet doméstico junto com as opções de

instalação. (CASO)

(CONDIÇÃO)
• Limites de velocidade de upload e download de mapas, dependendo do pacote
selecionado: Gold, Silver ou Bronze.

• Determine se uma instalação doméstica é necessária ou não (com base na compra de

seu próprio roteador ou na opção de aluguel)

Regras de Mapeamento

Regras utilizadas nas relações de representação para transformar campos e/ou atributos
dos produtos comerciais em atributos dos produtos técnicos.

Definem as informações passadas do produto de origem para o produto de destino e,

portanto, para os sistemas downstream.

Três tipos de regras de mapeamento;

1. Ad-verbatim

⁃ Copia o valor da origem para o destino, sem alterá-lo. Isso simplesmente passa os
dados.

2. List

⁃ Transforma o valor de origem em um novo valor de destino.

Exemplo:

Mapeie um plano "Gold" ou "Silver" para uma velocidade de transferência específica,

como "100 Mbps" ou "80 Mbps".

3. Static

⁃ Defina um valor predefinido para o atributo de destino.

Exemplo:

Mapea um valor fixo como "1.2.3.4" para o atributo de destino.

 Regras de Condição e Mapeamento são representadas como dados
JSON

⁃ Após configurar as Regras de Condição e Mapeamento para seu relacionamento de

decomposição, a seção Avançado revela o blob JSON.

É possível editar o JSON diretamente, mas não é recomendado.

IOM gera o JSON para você quando você define condições e regras de mapeamento.

Três maneiras de preencher dados JSON de mapeamento e condição.

⁃ Use the UI (interface de usuário) - menos propenso a erros

⁃ Copy, paste, then modify (copiando, colando e modificando)
⁃ Enter manually (manualmente) - mais propenso a erros

Product Class Decomposition

É um mecanismo utilizado para categorizar determinados produtos a fim de simplificar o
processo de configuração da decomposição do pedido.

⁃ Product Class é uma forma abreviada de se referir a um produto com o tipo de

registro definido como Class
⁃ O padrão é Produto. Para configurar "Product Class" você deve alterar manualmente
o Tipo de registro para Classe.

Decomposição por classe de produto inclui três etapas;

1. Crie a classe de produto.

⁃ Use a guia Console do produto e Produtos do Salesforce para criar e configurar a

Classe do produto.

É fundamental definir;

Tipo de registro de produto = classe

2. Associar produtos comerciais similares com a Classe de Produto

⁃ Associar produtos semelhante que compartilharam uma única relação de

decomposição devem ser associados á Product Class.

⁃ Defina o “Parent class” (produto comercial) para um produto com um tipo de registro
de Classe.

(Configure o campo “Parent class” com cada produto semelhante)

3. Criar uma única relação de decomposição

⁃ Criar um relacionamento de decomposição entre a classe de produto origem e

produto técnico (destino).
Teste

Testar a decomposição da classe do produto é o esperado.

⁃ Faça um pedido, adicione um dos produtos associados à classe de produto

configurada e decomponha-o.

⁃ Selecione produtos diferentes associados à mesma classe de produto.

⁃ Certifique-se de verificar se o atributo é transferido para o produto técnico.

Order Orchestration

É o processo usado para controlar a interação com sistemas downstream, para fins de
atendimento de pedidos.

Exemplo:

O Industries Order Management (IOM) interage com sistemas de agendamento, sistemas de

faturamento, sistemas de estoque etc.

-> Orchestration Plan - Plano de Orquestração

Cria e executa dinamicamente e de forma automática um plano de orquestração para o

pedido.

É um conjunto de tarefas agrupadas logicamente em um plano, usado para atender

pedidos em um ou mais sistemas de atendimento.

• As tarefas processadas são para as solicitações de atendimento que foram criadas

pelo processo de decomposição.
 (a decomposição alimenta o processo de orquestração)

-> Item Definition - Item de orquestração

Tarefas que compõem um plano de orquestração.

• São executados em sequência (síncrono) ou em paralelo (assíncrono).

Existem 5 tipos:

Milestone
Auto-Task
Callout
Manual Task
Push Event

-> Orchestration Scenario - Cenário de orquestração

Determinar quando um plano de orquestração deve ser executado.

Aciona a geração e execução de um novo plano.

• Estão vinculados a um produto e uma ação (geralmente um produto técnico).

(Ex: Roteador, modem ou serviço de instalação específico)

e uma ação

(Ex: Adicionar, Modificar ou Desconectar).

• Suportam subações.
Cenários de orquestração são definidos por:

• Produto Comercial + Ações/Sub Ações + Condicionais + Definição de Plano de

Orquestração

• Produto Técnico + Actions/Sub Actions + Condicionais + Definição de Item de

Orquestração

Tipos de itens de orquestração

Milestone

Tarefa simples usada como um marcador no processo de cumprimento.

• Sempre avaliam como verdadeiro.

Manual Task

Usada quando a entrada do usuário é necessária em um local específico no fluxo de

atendimento.

• São colocadas em Filas Manuais, onde podem ser retiradas da fila, trabalhadas e
eventualmente concluídas.

Exemplo:

Aprovação do supervisor, uma verificação de crédito ou a compra de mais café para a sala
de descanso.
Auto-Task

Tarefas executadas automaticamente invocando uma classe do Apex associada ao item

de orquestração.

• Ativos - Um modelo específico ou tipo de produto que um cliente possui.


• Assetization - O processo pelo qual o (IOM) converte OrderItems em Ativos e Linhas

de Solicitação de Cumprimento (FRLs) em Itens de Inventário.


⁃ Assetização deve ocorrer perto do final do plano. Como prática configura marcos
de Início e Fim em um plano de ponta a ponta, a apropriação de recursos costuma ser a
penúltima tarefa. Ou seja, somente o marco Fim viria depois dele.

Exemplo:

Criação de ativos para um pedido como uma das últimas etapas no atendimento do pedido.

• O Industries Order Management fornece uma classe Apex

chamada XOMAutoTaskAssetizer pronta para fazer isso.

• A implementação do item Assetize somente ativa produtos comerciais.

É considerada uma prática recomendada criar ativos como a penúltima tarefa no plano de
orquestração.

(A última tarefa é tipicamente "Complete Order", um marco que não pode falhar).
Callout

Interação automatizada com um sistema de atendimento externo usando um serviço da

Web ou API RESTful.

• Utiliza frequentemente sistemas de terceiros, mas também podem ser sistemas

internos.

Exemplo:

Sistemas de faturamento, sistemas de agendamento, sistemas de estoque etc.

-> Utiliza, uma única Fila manual de tratamento associado ao item de orquestração

Push Event

Evento push é ativado quando um sistema externo ou um usuário do Salesforce faz uma
alteração específica no pedido associado a um item de orquestração de evento push.

• Evento push pausa até que um evento (por exemplo, condição de evento) se
verdadeiro.

• Os gatilhos são usados para avaliar constantemente a condição do evento.

Gatilho é a tecnologia fundamental para a implementação de Push Event.

Visualização do processo de orquestração

Order Decomposition

Processo de decomposição de pedidos.

Design Time

• Administrador ou Designers de Fulfillment definem, criam, configuram (e testam) os

componentes de orquestração.

Run Time

⁃ Depois que o pedido é decomposto, a orquestração do pedido começa e o plano de

orquestração é gerado.

⁃ As tarefas no plano são sequenciadas e monitoradas. Cada novo pedido que flui
para o sistema gerará seu próprio plano.

Fulfillment Systems

⁃ Sistemas de atendimento de terceiros, conforme definido em tempo de design.

⁃ Os sistemas podem se comunicar de volta com o IOM para que o status do plano
de orquestração seja atualizado dinamicamente.
Visualização do Plano de orquestração

Status codificado por cores

⁃ Cada tarefa é representada por um cartão codificado

por cores na vista de planta. As cores do cartão
representam o status atual.

• Raias / Swimlanes- Agrupamento horizontal de itens no plano.

⁃ Cada definição de plano de orquestração é representada por uma raia e

normalmente representa um único sistema downstream para atendimento de pedidos.
Exemplo:

Faturamento, Ativação…

⁃ Plano de ponta a ponta que organiza ou invoca outras definições de plano de

orquestração, o que cria várias pistas de natação.

• Tipos de Tarefas - Observe abaixo de cada nome de tarefa no cabeçalho do cartão

é o tipo de tarefa.

⁃ O plano de exemplo inclui marcos, tarefas manuais, tarefas automáticas e

chamadas.

Exemplo:

A primeira tarefa concluída (verde) é um tipo de tarefa manual.

⁃ (Um Evento Push não está no exemplo acima, mas faz parte de um exercício prático.)

• Dependências - Os cartões de conexão de linhas mostram dependências, como

tarefas que dependem da conclusão de outras tarefas antes de poderem começar. 

⁃ Quando você passa o mouse sobre uma tarefa na visualização Plano de
Orquestração, as dependências dessa tarefa são realçadas em vermelho.

Diagrama UML (Unified Modeling Language)

É uma linguagem de modelagem comum, com um conjunto de símbolos bem definidos
conhecidos por muitos.

⁃ Mostra os símbolos e as notações usadas na documentação do diagrama UML.

Legenda UML explicativa: https://www.edrawsoft.com/symbols/umldiagramsymbols.php
Diagrama UML do plano de orquestração

O rótulo <<interface>> acima é mais complexo.

⁃ Não podemos ter uma instância do tipo fornecido.

(neste exemplo, nenhuma instância de Orchestration Item Definitions).

Em vez disso, existem classes que implementam essa interface, e essas podem ser
instanciadas.

Milestone
Autotask
Callout,
Manual Task
Push Event
Orchestration Queue / OM Plus

Define um atributo, como cliente VIP, em um pedido, conta ou produto que resulta no pedido
indo para uma fila prioritária.

São criadas para você como parte da instalação do pacote gerenciado.

-> As filas de orquestração no Order Management Plus atendem a dois propósitos:

• Colocar pedidos de clientes de alta prioridade em uma fila separada, atribuindo

poder de processamento diferente.

• Trabalho personalizado processando determinados itens de orquestração de

maneira diferente.

Exemplo:

Durante a pré-ativação, você pode colocar todas as chamadas de ativação específicas

em uma fila diferente e atribuir um trabalhador personalizado a essa fila, para que as
chamadas sejam agregadas em uma chamada, tornando-a uma solicitação em lote.

OBS:

⁃ Cada item de orquestração (Callout, tarefa automática etc.), cai em uma das filas de
orquestração que define qual trabalhador (um componente do sistema) é responsável
pelo processamento do item.

⁃ No Order Management Plus, você pode colocar diferentes itens de orquestração

em diferentes filas de orquestração.
Manual Tasks & Manual Queues

Task

Tarefas manuais requerem algum nível de intervenção humana, isso possa ser tão simples
quanto a aprovação do supervisor, também pode incluir uma URL de execução
personalizada que executa um OmniScript personalizado.

Exemplo:

Passar pela aprovação de crédito ou verificações de estoque do depósito.

URL de execução de tarefa personalizada - URL a ser executado quando a tarefa é retirada
da fila. A URL aponta para uma página do VisualForce ou OmniScript.

Queues

Tarefas manuais são colocadas em Filas manuais, são criadas por administradores ou
designers de atendimento.

É comum criar várias filas para ajudar a balancear as cargas de trabalho.

Exemplo:

Criar uma fila para cada raia. Dessa forma, um recurso muito utilizado (como o inventário)
não impõe limitações de largura de banda para outro que não o é (agendamento de
instalações domésticas).

Ações executadas em itens de fila manual

⁃ Retry/ tente novamente

⁃ Pickup/ pegar
⁃ Complete/ completo
Delete/ excluir não é um botão de operação para itens em uma Fila Manual.

Queue Type

Filas baseadas em atributsos que permitem que vc configure regras que determinam como
as tarefas são atribuídas.

Round Robin - Atribui tarefas aos membros do grupo de trabalho em sequência.

Least Used - Atribui tarefa a pessoas com o menor número de tarefas na fila.

Attributes-Based - Abordagem orientada por metadados para processar as regras de

atribuição correspondente.

(OBS: A atribuição automática é ignorada (não é possível) se o tipo de fila for deixado
como nulo.)

Dependências da orquestração

Mecanismo usado para especificar dependências entre itens de orquestração.

⁃ Segmento que se junta às Definições de Item de Orquestração

⁃ Definir dependências entre itens no mesmo plano ou entre itens em planos

diferentes.

⁃ Impõem a conclusão de uma tarefa antes que a próxima seja iniciada.

Exemplo:

Conclua <Task_X> antes de iniciar <Task_Y>.

As tarefas podem ser executadas de forma síncrona, não assíncrona.

Forma síncrona - (sem dependência) - em paralelo

Forma assíncrona - (com dependência) - em sequência

(OBS: As dependências não precisam permanecer dentro de sua própria "faixa de

natação", mas podem, de fato, se estender para outras raias de natação)
Exemplo:

Os segmentos vermelhos mostram dependências para a task Create Assets.

Existem dois tipos de dependências:

Depende de/ Depends On (padrão) - Faz com que o item de orquestração dependa da
conclusão bem-sucedida de outro item de orquestração.

Exemplo:

O complete Order depende da conclusão do Create Assets item.

Deve ser processado antes/ Should Be Processed Before- funcionalmente o mesmo que
depende, mas de um ponto de vista diferente.

Exemplo:
 O orchestration Item deve ser concluído antes de iniciar o próximo item na
sequência.

Orchestration Systems & Callouts

Orchestration systems

• Usado para se comunicar com sistemas externos (terceiros).

Sistemas de terceiros são chamados de sistemas externos, sistemas downstream,

sistemas de atendimento ou mesmo sistemas de orquestração.

Exemplo:

Sistemas de cobrança, estoque, programação e logística.

• O método de comunicação com esses sistemas é por meio de um item de

orquestração chamado callout.

Callout, fornece um tempo limite máximo, fornecido em milissegundos.

⁃ O valor de tempo limite máximo permitido é 999.999.999.999 milissegundos.

Existe dois pontos de extremidade da API para comunicação entre IOM e sistemas
externos é o “Caminho da interface do sistema” e a “URL do sistema remoto”.

(OBS: é NECESSÁRIO a configuração do sistema de orquestração no IOM, e as

configurações do site remoto do Salesforce).

Fallout Management

Gerenciamento de falhas, gira em torno do que o IOM realiza quando uma chamada de
sistema de atendimento externo falha.
Recursos:

• Políticas de repetição- recurso poderoso e oferecem maior controle sobre como o

IOM se comporta quando as chamadas falham.

⁃ O modo Platform Events oferece suporte às políticas de repetição de integração e à

capacidade de definir uma interface do sistema como online ou offline.

⁃ As tarefas administrativas para dar suporte às políticas de repetição de integração

são realizadas na configuração do Salesforce Setup e Vlocity XOM Administration.

⁃ Criar uma política de repetição de integração no Iniciador de aplicativos ou durante

a edição da própria Chamada.

Monotonous Forever: é um tipo de registro de uma nova política de integração.

- Não permite que você defina o número máximo de novas tentativas. No

entanto, quando você especifica o tipo de registro como monótono na política de
repetição, pode definir o número máximo de tentativas.

• Filas manuais como filas de erro Fallout

• Comportamento IOM para diferentes códigos de resposta HTTP

(Direcionam as políticas de repetição de integração do IOM sobre como se comportar)

• Registro de execução

• Status da interface do sistema (online/offline)

Order Itens

Order Itens podem ser transformados em Asset, enquanto Fulfilment Request Lines podem
ser transformados em Inventory Itens.

Communicating with Fulfillment Systems

Interface do Sistema

O fields Status para a Interface do Sistema pode ser alternado entre Online e Offline.

Offline: o status das tarefas são colocados em espera.

Exemplo:

As tarefas são enfileiradas para serem processadas posteriormente quando a interface for
colocada novamente online.

Push Events
Um evento de push pausa a execução até que um evento seja avaliado como verdadeiro.

Evento Push em execução (Push VAS)

Sequência de eventos

1. Início do marco VAS concluído (Status = Concluído)

2. Push VAS Push Event executado e aguardando evento (status = Running) ...
a. … até que sua condição de evento seja avaliada como verdadeira
b. em seguida, o status muda para completo (não mostrado)
c. Terminar as execuções do marco VAS, o status muda de Pendente para Concluído (não
mostrado)

Condição do evento

• O evento push pausa a execução até que a condição (ou condições) do evento seja
avaliada como verdadeira.

• Se não houver Condição de Evento, ela será avaliada como verdadeira (e o estado
da tarefa mudará para concluído).

• A lógica da condição do evento é a mesma das condições do cenário de

orquestração e das condições de definição do item de orquestração.

Está configurado para Push Events

• Campo de um item de pedido ou linha de solicitação de atendimento.

• Atributo de um item de pedido ou linha de solicitação de atendimento.



Exemplo de Push Event - Faturamento

Dois cenários diferentes de cobrança triple-play são mostrados para ajudar a ilustrar
como os eventos push podem alterar o fluxo de trabalho.

• Sem evento push (esquerda) - plano de orquestração típico em que, depois que todas
as três chamadas (ativar Internet, TV e telefone) são concluídas, o cliente é cobrado.
⁃ Com evento push (à direita) - um evento push é usado para iniciar a cobrança do
cliente quando qualquer uma das chamadas de ativação tripla for concluída. 


⁃ Os sistemas de ativação downstream atualizam um sinalizador no pedido. No

momento em que o sinalizador muda de 0 (falso) para 1 (verdadeiro), a condição do Evento
Push muda para verdadeiro e o item de orquestração do Faturamento Push muda do
status Pronto para Concluído.

Apenas uma única condição de evento é necessária ao configurar o evento push.

Exemplo:

Quando o atributo técnico TripleActivationFlag muda de 0 para 1 por qualquer um dos

sistemas de ativação (internet, TV ou telefone), o evento Push é avaliado como
verdadeiro e a execução do plano não é mais pausada.

MACD Orders
Pedidos MACD descrevem qualquer pedido de movimentação, adição, alteração ou
desconexão de serviços.
A alteração de um ativo para um pedido ou cotação inicia um processo guiado que move
um ou mais ativos entre os locais de serviço.

MACD

• Mover: mover produtos ou serviços de um local para outro.

• Adicionar: Adicione novos produtos ou serviços.
• Mudança: Alterar produtos ou serviços existentes.
• Excluir, desconectar ou descontinuar produtos ou serviços existentes.
-
 O cliente define as datas de entrada e saída, seleciona o local da mudança e gera um
pedido para desconectar os ativos do local original e conectá-los ao novo local.

Asset-based ordering garante que os dados sejam capturados com precisão por meio de
qualquer canal ou dispositivo.

Order Cancellation
Termos chave

• Pedido em andamento - Um pedido que foi enviado (do CPQ para o IOM), mas não
foi concluído.

• Pedido suplementar - Um pedido criado pelo CPQ para revisar um pedido em

andamento. Os pedidos suplementares substituem o pedido original durante o voo.

⁃ Pedidos suplementares são gerados automaticamente pelo CPQ após a emissão de

uma solicitação de cancelamento do pedido e a conclusão da pré-validação (o IOM
confirma que o PONR não foi alcançado).

• Point of no return (PONR) - Ponto no processo de orquestração do pedido que, uma

vez passado, o cancelamento do pedido não é mais possível ou permitido.

⁃ PONR quando avança para qualquer um dos seguintes

estados: Completed, Running, Failed, Fatally Failed .
Exemplo de Marco com PONR definido

Status

Order Status - Salesforce Status

Lista de opções com dois valores por padrão.

• Rascunho/ Draft - A configuração do Status do Salesforce desde a captura inicial do

pedido até o envio do CPQ ao OM e durante todo o processo de atendimento do pedido
permanece Rascunho.

• Ativado/ Activated - A configuração do Status do Salesforce muda de Rascunho para

Ativado quando o processo de atendimento do pedido é concluído ou cancelado.

IOM Order Status

Funcionalidade estendida, um campo adicional de Order Status é usado para oferecer suporte
a fluxos de trabalho muito específicos.

⁃ Fornece informações de status rapidamente, o que é útil ao aprender cancelamentos

de pedidos em andamento. Você também pode ver o status do pedido dentro do carrinho.
Orchestration Plan & Task States

É o estado geral do plano de orquestração.

Quando o atendimento do pedido é concluído, o State

mostrado aqui muda para concluído e o Status do
Salesforce muda de Draft para Activated.

Observação: o status do Salesforce, o status do pedido IOM, bem como os estados do plano
e da tarefa são observados durante o próximo exercício de laboratório sobre cancelamentos
de pedidos.
ATENÇÃO ⚠

• O cancelamento de pedidos usa pedidos suplementares que são gerados

automaticamente pelo CPQ

• Pedidos suplementares também são decompostos automaticamente.

• O cancelamento é no nível do pedido ou no item do pedido (dependendo do que for

selecionado no pedido e nas configurações do PONR)

-> Quando um pedido é cancelado pelo CPQ e aceito pelo IOM, o pedido original:

• O status foi alterado para cancelado
• O pedido está bloqueado.

-> Quando um pedido é cancelado pelo CPQ e aceito pelo IOM, o pedido suplementar:

• O status é alterado para em andamento (e eventualmente concluído quando o plano

de orquestração é concluído).

• É o modo somente leitura.


CPQ/IOM Communications

Standard Order

⁃ Inclui o status do pedido original conforme o andamento das ações padrão do usuário
(criar, enviar e atendimento do pedido pelo Gerenciamento de Pedidos de Indústrias).
Order Cancellation

Ações do usuário/eventos do sistema – criar, enviar e cancelar pedidos são iniciados pelo
usuário, outras ações são, na verdade, eventos do sistema acionados automaticamente com
base na configuração e em eventos anteriores do usuário.

• Criar/enviar pedido complementar (isso acontece em segundo plano sem intervenção

do usuário)

• Cancelamento e atendimento de pedidos pelo Gerenciamento de Pedidos das

Indústrias.

Status do pedido original – estados de pedido adicionais são necessários para implementar
cancelamentos de pedidos. Tanto o CPQ quanto o OM se comunicam e consultam os novos
estados.

• O pedido original transita de cancelar solicitado para Substituído (supondo que o

pedido não ultrapasse o PONR e o cancelamento seja executado).

Status do Pedido Suplementar – O pedido suplementar gerado pelo CPQ necessário para
implementar o cancelamento também requer novos estados do pedido.

• Se tudo correr bem entre CPQ e OM durante o processo de cancelamento, o estado

muda de Cancel in Progress para Canceled.

• O CPQ não apenas gera automaticamente o pedido complementar, mas também inicia
a decomposição e o vincula ao pedido original.

• Observe que, semelhante a um pedido bloqueado ou somente leitura, o pedido

suplementar cancelado não pode ser alterado.
Observação: embora esta apresentação se refira a “user Actions”, como o botão Cancelar
pedido no carrinho, o processo pode ser iniciado por meio da API do CPQ.

Run-time status of Orchestration Items

Congelado / frozen - O pedido de cancelamento foi solicitado,

mas não foi confirmado.

Cancelado/ canceled - Tarefa pendente ou foi cancelada com

sucesso.
 Descartado/ discarded - Não foi executado quando uma ordem
suplementar exigia que fosse cancelado.

Alterado/ amended - A tarefa foi alterada por uma ordem

suplementar.

Rollback Groups
• Grupos de reversão alteram a ordem de execução das raias de reversão.

• Por padrão, os Rollback Groups são executados na mesma ordem das raias de
orquestração originais.

• Grupos de reversão não alteram a ordem de execução das tarefas dentro deles. (Isso
continua sendo uma função de dependências.)

Exemplo:

• Existem quatro planos de reversão (A, B, C, D)



• Três planos têm apenas uma tarefa (A, B, D)


• Plano de reversão C tem três tarefas (C1->C2->C3)



A ordem de execução das tarefas em uma raia de reversão é especificada por

dependências.
Order Management Plus
O Industries Order Management Plus oferece o tipo de desempenho e disponibilidade
exigidos pelos provedores de serviços de alto volume.

⁃ Usa combinação de Salesforce para configuração de tempo de design e

monitoramento de tempo de execução, enquanto explora as melhores vantagens da AWS
para confiabilidade, escalabilidade, segurança e desempenho.

(Amazon Web Services - AWS)

Por que Amazon Web Services (AWS)? Quantidade/ volume

A implantação do IOM Plus permite centenas de milhares de pedidos por dia.

Enquanto o IOM Standard/padão permite centenas e alguns milhares de pedidos por

dia.

(Sendo uma opção viável para clientes com implantações menores e volumes de pedidos
menores.)