Les på engelsk

Del via


Bruk bindings-ID-er til å samsvare på tvers av utløsere

For utløserbaserte, repeterbare reiser kan en kunde gjenta en reise uten å ha fullført den forrige kjøringen. Vurder for eksempel en reise som sender avtalebekreftelser og påminnelser. Når en person registrerer seg for sin første avtale, går de inn i reisen og mottar en bekreftelse. De fortsetter å vente i reisen til de mottar en påminnelse en dag før avtalen. I løpet av denne tiden kan samme person registrere seg for en ny avtale. Reisedeltakeren starter samme reise en gang til for den andre avtalen. Med andre ord går den samme personen nå gjennom to forekomster av samme reise.

Hvis reisedeltakeren i en slik situasjon annullerer en av avtalene, bør de bare avslutte reisen som er knyttet til den annullerte avtalen. Hvis de for eksempel avbryter den første avtalen, bør de avslutte reisen som er knyttet til den første avtalen, men fortsette reisen som er knyttet til den andre avtalen. Hvis du bruker med Dataverse-baserte standardhendelser, skjer virkemåten automatisk, og ingen annen handling er nødvendig. Hvis du bruker egendefinerte utløsere, må du imidlertid konfigurere utløseren til å identifisere den spesifikke forekomsten av reisen som utløseren må tilknyttes.

Bruk bindingId-attributtet til å unikt identifisere hver forekomst av reisen

Hver egendefinerte utløser har et valgfritt bindingId-attributt som kan brukes til å binde utløseren til bestemte forekomster av en reise. Når bindingId-attributtet ikke finnes, vil utløseren reagere på alle forekomster av reisen som personen deltar i. Hvis for eksempel personen har registrert seg for to avtaler, men annullerer én, og hvis den annullerte utløseren ikke brukte en bindingId, avslutter denne personen begge forekomstene av reisen. Hvis du har tenkt å bruke utløsere i repeterbare reiser, anbefales det sterkt at du inkluderer en bindingId i utløseren.

Når utløseren som starter en reise, inneholder en bindingId, brukes denne ID-en til å identifisere reiseforekomsten. For å identifisere reiseforekomsten bør alle andre hendelser bruke samme bindingId. Formatet for bindingId er som følger: {entityType}/{entityId}. Hvis starthendelsen for eksempel er en avtaleenhet som kalles Avtale bekreftet og den har en entityId på 123, er bindingId Appointment/123. Avslutningshendelsen Avtale annullert må være av samme enhetstype og bør bruke samme bindingId (Appointment/123) til å unikt identifisere reiseforekomsten.

Hvis du bare bruker egendefinerte utløsere i reisen, kan du være avhengig av unike strenger for å identifisere reiseforekomstene.

Obs!

En egendefinert utløser brukes på alle forekomster av en reise som noen deltar i, hvis bindingIdmangler, eller hvis bindingen gjelder en annen enhetstype.

Samsvar på tvers av egendefinerte utløsere og med standardhendelser eller egendefinerte forretningshendelser

Hvis du vil bruke en kombinasjon av egendefinerte utløsere og standard forretningshendelser eller egendefinerte forretningshendelser, bruker bindingId spesiell formatering for å unikt identifisere Dataverse-tabellen og -raden. Start for eksempel reisen med standardhendelsen Salgsmulighet opprettet. Du kan deretter bruke en egendefinert utløser kalt Salgsmulighet vunnet for avslutningshendelsen. Den egendefinerte utløseren Salgsmulighet vunnet må inneholde en bindingId som følger mønsteret for hendelsen Salgsmulighet opprettet for å unikt identifisere hver forekomst.

Når en hendelse startes av en standard eller tilpasset forretningshendelse, kan hver forekomst av reisen identifiseres unikt med mønsteret {entityType}/{unique row ID}. Dette mønsteret må inkluderes i bindingId-attributtet for eventuelle egendefinerte utløsere for å samsvare på tvers av egendefinerte utløsere og standard eller egendefinerte forretningshendelser.

Når det gjelder den egendefinerte utløseren Salgsmulighet vunnet, kan bindingId være følgende:

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

Hvis egendefinerte utløsere følger bindingId-mønsteret som er beskrevet ovenfor, kan de brukes til å identifisere den nøyaktige reiseforekomsten selv når den brukes med andre forretningshendelser. Når bindingId implementeres, brukes den på alle forekomster av reisen.

Obs!

Bindingen fungerer bare på tvers av de samme enhetstypene.

Slik legger du til en bindingId i en egendefinert utløser

Du kan endre bindingId-attributtet i kodesnutt for en egendefinert utløser.

Slik får du kodesnutten for en eksisterende egendefinert utløser:

  1. Gå til Customer Insights - Journeys>Engasjement>Utløsere.
  2. Velg den egendefinerte utløseren du vil legge til en bindingId i.
  3. Vel Gå til kodesnutt.

    Skjermbilde av Gå til kodesnutt.

  4. Kopier snutten og lim den inn i koderedigeringsprogrammet du velger. Endre bindingId-attributtet ved å følge formatene nevnt ovenfor (en unik streng hvis du bare bruker den med egendefinerte utløsere eller {table_name}/{unique row ID} når du samsvarer på tvers av egendefinerte utløsere og standardhendelser eller egendefinerte forretningshendelser).

Du kan følge de samme trinnene for å legge til en bindingId når du oppretter en ny egendefinert utløser.

bindingId-tolkning

Tegnet / er reservert. Det antas alltid at bindingId er i atskilt format med /, og at eventuelle foranstilte eller etterfølgende / er fjernet. Det finnes ingen / i resultatet. Appen prøver alltid å tolke den på denne {entityType}/{entityId}-måten.

Eksempler:

"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"}

Sammenligningsalgoritme:

[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. 

Eksempler:

Trigger event: "incident/000"
Resume event: "incident/000"
Result: Case 1 resume
Trigger event: "incident/000"
Resume event: "incident/001"
Result: Case 2 no resume
Trigger event: "incident/000"
Resume event: "opportunity/001"
Result: Case 3 resume
Trigger event: "incident/000"
Resume event: "opportunity/000"
Result: Case 3 resume
Trigger event: "incident/000"
Resume event: "random string"
Result: Case 3 resume
Trigger event: "random string"
Resume event: "random string"
Result: Case 1 resume
Trigger event: "random string 1"
Resume event: "random string 2"
Result: Case 2 no resume
Trigger event: "random string 2"
Resume event: ""
Result: Case 2 no resume
Trigger event: ""
Resume event: ""
Result: Case 0 resume
Trigger event: ""
Resume event: "incident/000"
Result: Case 0 resume
Trigger event: "incident/000"
Resume event: ""
Result: Case 3 resume