Delen via


Binding-id's gebruiken om te correleren tussen triggers

Voor op triggers gebaseerde, herhaalbare reizen kan een klant een reis herhalen zonder de vorige run te hebben voltooid. Denk bijvoorbeeld aan een reis waarbij afspraakbevestigingen en -herinneringen worden verzonden. Wanneer een persoon zich inschrijft voor zijn eerste afspraak, gaat hij de reis in en ontvangt hij een bevestiging. De persoon blijft in de reis wachten tot hij een dag voor de afspraak een herinnering ontvangt. Gedurende deze periode kan dezelfde persoon zich inschrijven voor een tweede afspraak. De reisdeelnemer begint een tweede keer aan dezelfde reis voor de tweede afspraak. Met andere woorden, dezelfde persoon doorloopt nu twee gevallen van dezelfde reis.

In een dergelijke situatie, als de reisdeelnemer een van de afspraken annuleert, moet hij alleen de reis verlaten die bij de geannuleerde afspraak hoort. Als hij de eerste afspraak annuleert, moet hij bijvoorbeeld de reis verlaten die is gekoppeld aan de eerste afspraak, maar doorgaan met de reis die bij de tweede afspraak hoort. Als u kant-en-klare Dataverse-gebeurtenissen gebruikt, is het gedrag automatisch en is er geen andere actie nodig. Als u aangepaste triggers gebruikt, moet u de trigger echter configureren om het specifieke exemplaar van de reis te identificeren waaraan de trigger moet worden gekoppeld.

Het kenmerk bindingId gebruiken om elk exemplaar van de reis uniek te identificeren

Elke aangepaste trigger heeft een optioneel kenmerk bindId dat kan worden gebruikt om de trigger te binden aan specifieke exemplaren van een reis. Wanneer het kenmerk bindingId niet aanwezig is, werkt de trigger op alle exemplaren van de reis waaraan de persoon deelneemt. Als de persoon zich bijvoorbeeld heeft geregistreerd voor twee afspraken, maar er een annuleert, en de geannuleerde trigger geen bindingId heeft gebruikt, verlaat die persoon beide exemplaren van de reis. Als u triggers wilt gebruiken in herhaalbare trajecten, wordt u ten zeerste aangeraden een bindingId in de trigger op te nemen.

Wanneer de trigger waarmee een reis wordt gestart een bindingId bevat, wordt die id gebruikt om het reisexemplaar te identificeren. Om het reisexemplaar te identificeren, moet elke andere gebeurtenis dezelfde bindingId gebruiken. De indeling van de bindingId is als volgt: {entityType}/{entityId}. Als uw startgebeurtenis bijvoorbeeld een entiteit Afspraak met de naam Afspraak bevestigd is en deze de entityId 123 heeft, is de bindingId Appointment/123. Uw afsluitgebeurtenis Afspraak geannuleerd moet van hetzelfde entiteitstype zijn en dezelfde bindingId (Appointment/123) gebruiken om het reisexemplaar uniek te identificeren.

Als u tijdens de reis alleen aangepaste triggers gebruikt, kunt u vertrouwen op unieke tekenreeksen om de reisexemplaren te identificeren.

Notitie

Een aangepaste trigger werkt op alle exemplaren van een reis waaraan iemand deelneemt als de bindingId ontbreekt of als de binding voor een ander entiteitstype is.

Correleren tussen aangepaste triggers en kant-en-klare gebeurtenissen of aangepaste zakelijke gebeurtenissen

Als u een combinatie van aangepaste triggers en kant-en-klare of aangepaste zakelijke gebeurtenissen wilt gebruiken, gebruikt bindingId speciale opmaak om de Dataverse-tabel en -rij op unieke wijze te identificeren. Uw reis kan bijvoorbeeld beginnen met de kant-en-klare gebeurtenis Verkoopkans gemaakt. U kunt dan een aangepaste trigger met de naam Verkoopkans binnengehaald gebruiken voor de afsluitgebeurtenis. De aangepaste trigger Verkoopkans binnengehaald moet een bindingId bevatten die het patroon van de gebeurtenis Verkoopkans gemaakt volgt om elk exemplaar uniek te identificeren.

Wanneer een reis wordt gestart door een kant-en-klare of aangepaste zakelijke gebeurtenis, kan elk exemplaar van de reis uniek worden geïdentificeerd door het patroon {entityType}/{unique row ID}. Dit patroon moet worden opgenomen in het kenmerk bindingId van een aangepaste trigger om te correleren tussen aangepaste triggers en kant-en-klare of aangepaste zakelijke gebeurtenissen.

In het geval van de aangepaste trigger Verkoopkans binnengehaald kan de bindingId zijn:

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

Als aangepaste triggers het hierboven beschreven patroon bindingId volgen, kunnen ze worden gebruikt om het exacte reisexemplaar te identificeren, zelfs wanneer ze worden gebruikt met andere zakelijke gebeurtenissen. Wanneer hjet kenmerk bindingId wordt geïmplementeerd, werkt deze op alle instanties van de reis.

Notitie

De binding werkt alleen voor dezelfde entiteitstypen.

Een bindingId toevoegen aan een aangepaste trigger

U kunt het kenmerk bindingId in het codefragment wijzigen voor een aangepaste trigger.

Ga als volgt te werk om het codefragment voor een bestaande aangepaste trigger te openen:

  1. Ga naar Customer Insights - Journeys>Interactie>Triggers.
  2. Selecteer de aangepaste trigger waaraan u een bindingId wilt toevoegen.
  3. Selecteer Ga naar codefragment.

    Schemafbeelding van Ga naar codefragment.

  4. Kopieer het fragment en plak dit in de code-editor van uw keuze. Wijzig het kenmerk bindingId volgens de hierboven genoemde indelingen (een unieke tekenreeks als u deze alleen gebruikt met aangepaste triggers of {table_name}/{unique row ID} bij het correleren tussen aangepaste triggers en kant-en-klare gebeurtenissen of aangepaste zakelijke gebeurtenissen).

U kunt dezelfde stappen volgen om een bindingId toe te voegen wanneer u een nieuwe aangepaste trigger maakt.

Interpretatie van bindingId

Het teken / is gereserveerd. Er wordt altijd van uitgegaan dat de bindingId een door een / gescheiden indeling heeft en dat alle /-tekens aan het begin of einde worden verwijderd. Het resultaat bevat ook geen /. De app probeert het altijd op deze {entityType}/{entityId}-manier te interpreteren.

Voorbeelden:

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

Vergelijkingsalgoritme:

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

Voorbeelden:

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