Utilizar IDs de enlace para correlacionar os acionadores

Artigo
01/30/2024

Para os percursos repetíveis baseados em acionadores, um cliente pode repetir um percurso sem ter concluído a execução anterior. Por exemplo, considere um percurso que envie confirmações de compromissos e lembretes. Quando uma pessoa se inscreve no seu primeiro compromisso, entra no percurso e recebe uma confirmação. Continuará a esperar no percurso até receber um lembrete um dia antes do compromisso. Durante este tempo, a mesma pessoa pode inscrever-se num segundo compromisso. O participante no percurso iniciará o mesmo percurso pela segunda vez no segundo compromisso. Por outras palavras, a mesma pessoa está agora a passar por duas instâncias no mesmo percurso.

Numa situação deste tipo, se o participante no percurso cancelar um dos compromissos, deve sair apenas do percurso associada ao compromisso cancelado. Por exemplo, se cancelar o primeiro compromisso, deve sair do percurso associado ao primeiro compromisso, mas continuar o percurso associado ao segundo compromisso. Se estiver a utilizar eventos baseados no Dataverse prontos a utilizar, o comportamento é automático e não é necessária nenhuma outra ação. No entanto, se estiver a utilizar acionadores personalizados, tem de configurar o acionador para identificar corretamente a instância específica do percurso ao qual o acionador tem de estar associado.

Utilizar o atributo bindingId para identificar de forma exclusiva cada instância do percurso

Cada acionador personalizado tem um atributo bindingId opcional que pode ser usado para vincular o acionador a instâncias específicas de um percurso. Quando o atributo bindingId não estiver presente, o acionador atuará em todas as instâncias do percurso em que a pessoa está a participar. Por exemplo, se a pessoa se registou para dois compromissos mas cancelar um, e se o acionador cancelado não utilizou bindingId, essa pessoa sairá de ambas as instâncias do percurso. Se pretende usar acionadores em percursos repetíveis, é altamente recomendável que inclua um bindingId no acionador.

Quando o acionador que inicia um percurso contém um bindingId, esse ID é utilizador para identificar a instância de percurso. Para identificar a instância de percurso, qualquer outro evento deve usar o mesmo bindingId. O formato para bindingId é o seguinte: {entityType}/{entityId}. Por exemplo, se o seu evento de início for uma entidade Compromisso denominada Compromisso Confirmado e tiver um entityId de “123,” bindingId seria Appointment/123. O seu evento de saída Compromisso Cancelado deve ser do mesmo tipo de entidade e deve usar o mesmo bindingId (Appointment/123) para identificar exclusivamente a instância do percurso.

Se só estiver a utilizar apenas acionadores personalizados no percurso, poderá confiar em cadeias exclusivas para identificar as instâncias do percurso.

Nota

Um acionador personalizado atuará em todas as instâncias de um percurso em que alguém está a participar se bindingId estiver em falta ou se a vinculação for para um tipo de entidade diferente.

Correlacionar em todos os acionadores personalizados e eventos prontos a utilizar ou eventos de negócios personalizados

Se pretende utilizar uma combinação de acionadores personalizados e eventos de negócio prontos a utilizar ou personalizados, bindingId utiliza formatação especial para identificar de forma exclusiva a tabela e a linha Dataverse. Por exemplo, o seu percurso pode começar com o evento pronto a utilizar Oportunidade Criada. Em seguida, pode usar um acionador personalizado denominado Oportunidade Ganha para o evento de saída. O acionador personalizado Oportunidade Ganha tem de conter um bindingId que segue o padrão do evento Oportunidade Criada para identificar de forma exclusiva cada instância.

Sempre que um percurso é iniciada por um evento de negócios pronto a utilizar ou personalizado, cada instância do percurso pode ser identificada de forma exclusiva pelo padrão {entityType}/{unique row ID}. Este padrão tem de ser incluído no atributo bindingId de qualquer acionador personalizado para correlacionar em todos os acionadores personalizados e eventos de negócio prontos a utilizar ou personalizados.

No caso do acionador personalizado Oportunidade Ganha, bindingId pode ser:

bindingId = opportunity/{unique ID of the opportunity row}

Se os acionadores personalizados seguirem o padrão bindingId acima descrito, poderão ser usados para identificar a instância de percurso exata, mesmo quando usados com outros eventos de negócio. Quando bindingId é implementado, atua em todas as instâncias do percurso.

Nota

A vinculação só funciona nos mesmos tipos de entidades.

Como adicionar um bindingId a um acionador personalizado

Pode modificar o atributo bindingId no fragmento de código para um acionador personalizado.

Para aceder ao fragmento de código para um acionador personalizado existente:

Aceda a Customer Insights - Journeys>Interação>Acionadores.
Selecione o acionador personalizado a que pretende adicionar um bindingId.
Selecione Ir para o fragmento de código.
Copie o fragmento e cole-a no seu editor de código de eleição. Modifique o atributo bindingId seguindo os formatos acima mencionados (uma cadeia exclusiva se estiver a usá-lo apenas com acionadores personalizados ou {table_name}/{unique row ID} quando estiver a correlacionar acionadores personalizados e eventos prontos a utilizar ou eventos de negócio personalizados).

Pode seguir os mesmos passos para adicionar um bindingId ao criar um novo acionador personalizado.

Interpretação do bindingId

O caráter / está reservado. Assume-se sempre que bindingId está num formato separado para / e qualquer / à esquerda ou à direita será removido. Além disso, não existe nenhum / no resultado. A aplicação tenta sempre interpretá-lo desta forma {entityType}/{entityId}.

Exemplos:

"A/B"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"A"
will be interpreted as 
{entityType = ""}/{entityId = "A"}

"A/B/C" 
will be interpreted as 
{entityType = "AB"}/{entityId = "C"}

""
will be interpreted as 
{entityType = ""}/{entityId = ""}

"A/B/"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"///A/B////"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

Algoritmo de comparação:

[Case 0] trigger has bindingId = "", meaning no restriction at all
    Always resume.
[Case 1] entityType matches, and entityId matches:
    Resume.
[Case 2] entityType matches, but entityId doesn't match:
    No resume.
[Case 3] entityType doesn't match trigger:
    It doesn't make sense to apply binding, so we fall back to what we have now and let it resume the journey instance.