O objectivo deste artigo é apresentar uma visão geral sobre a funcionalidade de Salesforce designada por Platform Events, através da descrição de conceitos relacionados, da arquitetura de software e com a apresentação de um exemplo de implementação.
Conceito
Platform Events (PEs) são basicamente mensagens escaláveis que contêm dados. Em Salesforce, representam uma entidade semelhante a um sObject no sentido em que também têm campos de sistema e podem ser customizadas com a criação de outros. No entanto, os registos de PEs não podem ser actualizados, apagados nem apresentados através da interface de utilizador.
Um platform event é identificado pelo sufixo de API Name ‘__e’. Por exemplo, WIT_ProcessExec__e.
PEs podem constituir uma maneira simples e ainda assim poderosa de ligar não só apps internas de Salesforce como também permitir troca de dados em tempo real com sistemas externos.
Arquitetura Event-Driven
A comunicação baseada em eventos funciona num modelo de publisher-subscriber, em que o sender transmite uma mensagem que pode ser capturada por um ou múltiplos listeners. Os eventos são enviados quer os receivers estejam ou não à escuta e os receivers não confirmam a recepção dos mesmos.
O diagrama seguinte ilustra a arquitetura de software baseada em eventos:
Os elementos que compõem este modelo são apresentados de seguida:
Event
É uma ocorrência de algo importante, por exemplo, a mudança de estado de um item ou de um processo.
Event message
A mensagem que contém dados com os detalhes acerca do evento.
Event producer
O publisher de uma event message.
Event channel
Canal de eventos através do qual o producer envia as event messages e os event consumers lêem essas messages. O canal é para um platform event e agrupa todas as event messages para esse platform event.
Event consumer
Um subscriber de um canal que recebe messages do mesmo.
Event bus
Serviço de comunicação e armazenamento que permite a transmissão de eventos usando o modelo publish-subscribe. O event bus permite a recepção de event messages a qualquer altura durante a janela de retenção.
Disponibilidade
- Os eventos podem ser publicados através de uma ou mais APIs (REST, SOAP, por exemplo);
- Apex suporta publicação de eventos;
- Triggers de Apex podem subscrever eventos;
- Eventos podem ser publicados declarativamente através do Process Builder e do Flow Builder;
Exemplo de Implementação
O exemplo seguinte apresenta uma implementação completa de um evento, desde a definição do object schema até à definição lógica de publicação e subscrição da APEX.
- Especificação do evento
Como mencionado anteriormente, um evento é de certa forma semelhante a um SObject e no qual podem ser adicionados alguns campos. Um evento é criado acedendo a Setup > Platform Events.
A configuração é iniciada com a atribuição de um nome ao evento e com a definição do Publish Behavior, i.e., quando é que numa transação o evento deve ser publicado [1].
De seguida, pode ser configurada o tipo de informação que se pretende guardar no evento, criando para o efeito campos customizados. Neste exemplo, os campos de texto Action e RecordId foram criados para permitirem a definição do nome de uma acção que deverá ser posteriomente executada sobre um determinado registo.
- Especificação da lógica de subscrição
Após criação e especificação do evento, poderá ser definida a lógica de subscrição em APEX para tratamento dos eventos. Neste exemplo, é criada a classe WIT_EventTrigger_Handler na qual é definida toda a lógica de processamento a executar quando o evento é disparado.
Como se pode verificar, o tratamento do objecto referente ao evento em APEX é semelhante a qualquer outro SObject.
Depois, é criado o trigger para a subscrição do novo evento e e aplicada a lógica de execução do método previamente apresentado.
Assim, de forma simples é definida uma solução bulk de eventos que permite processar todos os eventos WIT_ProcessExec__e publicados e para cada um deles executar uma acção sobre um registo previamente especificado.
Nota: Após criação do trigger, o mesmo fica visível no ecrã de definição do evento.
- Publicação do evento
Na perspectiva de lógica de publicação, pode-se seguir uma estratégia idêntica com a criação de uma classe que permita oferecer uma solução bulk de publicação de eventos.
Desta forma, sempre que necessária a publicação de algum(ns) evento(s), apenas é necessário invocar o novo método.
Considerações
A utilização de PEs pode ser considerada como uma maneira bastante prática a adoptar aquando do desenho de processos grandes e complexos permitindo a sua escalabilidade e evitando algumas típicas limitações.
Na implementação apresentada como exemplo, é demonstrado como um PE pode ser totalmente usado num processo interno de Salesforce, através da publicação e subscrição de eventos utilizando APEX.
Num cenário real é bastante comum enfrentarem-se vários desafios no desenho da solução:
- Processos de negócio de grande dimensão têm usualmente multiplas operações de DML combinadas com chamadas de API, em que a determinado momento no fluxo, callouts são executados, por exemplo, para obter dados externos;
- Muitas vezes, esse tipo de operações requerem/devem ser executadas assíncronamente, devido a complexidade, regras de negócio, disponibilidade da API externa, etc.;
- No topo desses pontos, é comum que esses processos sejam executados no mesmo contexto de execução de um batch;
- Portanto, quando processos de negócio são desenhados, é importante realçar:
- Operações DML não podem ser executadas antes de callouts, caso contrário isto irá resultar num erro 'You have uncommitted work pending. Please commit or rollback before calling out' [2;
- Future methods não podem ser executados em contexto de batch [3];
- Future methods não podem invocar outros future methods [3];
Conclusão
PEs podem então ser utilizados como uma solução a adoptar para os desafios mencionados anteriormente de uma forma simples mas ainda assim poderosa através de uma arquitectura de publicação/subscrição, permitindo a separação de acções complexas em mais simples, encadea-las e separar contextos de execução, resolvendo desta forma as limitações anteriormente referidas.
Referências
[2] - https://help.salesforce.com/articleView?id=000328873&type=1&mode=1
#Salesforce #PlatformEvents #worldIT