Utilizați ID-uri de legare pentru a corela între declanșatori
Pentru călătorii repetabile bazate pe declanșare, un client poate repeta o călătorie fără a fi finalizat rularea anterioară. De exemplu, luați în considerare o călătorie care trimite confirmări de întâlnire și mementouri. Când o persoană se înregistrează pentru prima sa întâlnire, aceasta intră în călătorie și primește o confirmare. Ei vor continua să aștepte în călătorie până când vor primi un memento cu o zi înainte de programare. În acest timp, aceeași persoană s-ar putea înscrie pentru o a doua întâlnire. Participantul va începe aceeași călătorie a doua oară pentru a doua întâlnire. Cu alte cuvinte, aceeași persoană trece acum prin două cazuri ale aceleiași călătorii.
Într-o astfel de situație, dacă participantul la călătorie anulează una dintre întâlniri, ar trebui să părăsească doar călătoria asociată cu programarea anulată. De exemplu, dacă anulează prima programare, ar trebui să părăsească călătoria asociată cu prima programare, dar să continue călătoria asociată cu cea de-a doua întâlnire. Dacă utilizați ieșit din cutie Dataverse -evenimente bazate pe, atunci comportamentul este automat și nu este nevoie de altă acțiune. Cu toate acestea, dacă utilizați declanșatoare personalizate, trebuie să configurați declanșatorul pentru a identifica corect instanța specifică a călătoriei cu care declanșatorul trebuie să fie asociat.
Folosind bindingId atribut pentru a identifica în mod unic fiecare instanță a călătoriei
Fiecare declanșator personalizat are un opțional bindingId atribut care poate fi folosit pentru a lega declanșatorul de anumite instanțe ale unei călătorii. Cand bindingId atributul nu este prezent, declanșatorul va acționa asupra tuturor instanțelor călătoriei la care persoana respectivă participă. De exemplu, dacă persoana sa înregistrat pentru două întâlniri, dar anulează una și dacă declanșatorul anulat nu a folosit un bindingId, atunci acea persoană va ieși din ambele instanțe ale călătoriei. Dacă intenționați să utilizați declanșatoare în călătorii repetabile, este foarte recomandat să includeți a bindingId în declanşator.
Când declanșatorul care începe o călătorie conține a bindingId, acel ID este folosit pentru a identifica instanța de călătorie. Pentru a identifica instanța de călătorie, orice alt eveniment ar trebui să o folosească bindingId. Formatul pentru bindingId este după cum urmează:{entityType}/{entityId}. De exemplu, dacă evenimentul dvs. de început este o entitate de întâlnire numită Numirea confirmată și are un entityId de „123”, the bindingId va fi Appointment/123. Evenimentul dvs. de ieșire Numire anulată ar trebui să fie de același tip de entitate și să folosească același tip bindingId (Appointment/123) pentru a identifica în mod unic instanța de călătorie.
Dacă utilizați numai declanșatoare personalizate în călătorie, vă puteți baza pe șiruri unice pentru a identifica instanțele de călătorie.
Hinweis
Un declanșator personalizat va acționa în toate cazurile unei călătorii la care participă cineva dacă bindingId lipseste sau dacă legarea este pentru un alt tip de entitate.
Corelați între declanșatoare personalizate și evenimente ieșite din cutie sau evenimente de afaceri personalizate
Dacă doriți să utilizați o combinație de declanșatoare personalizate și evenimente de afaceri din fabrică sau personalizate, bindingId folosește formatare specială pentru a identifica în mod unic Dataverse masă și rând. De exemplu, călătoria dvs. ar putea începe cu evenimentul ieșit din cutie Oportunitate creată. Apoi puteți utiliza un declanșator personalizat numit Oportunitate Câștigată pentru evenimentul de ieșire. Declanșatorul personalizat Oportunitate Câștigată trebuie să conțină a bindingId care urmează modelul Oportunitate creată eveniment pentru a identifica în mod unic fiecare instanță.
Ori de câte ori o călătorie este începută printr-un eveniment de afaceri personalizat sau ieșit din cutie, fiecare instanță a călătoriei poate fi identificată în mod unic după model {entityType}/{unique row ID}. Acest model trebuie inclus în bindingId atributul oricărui declanșator personalizat să se coreleze între declanșatorii personalizați și evenimentele comerciale din fabrică sau personalizate.
În cazul Oportunitate Câștigată declanșator personalizat, bindingId ar putea fi:
- bindingId =
opportunity/{unique ID of the opportunity row}
Dacă declanșatoarele personalizate urmează bindingId model descris mai sus, acestea pot fi folosite pentru a identifica instanța exactă a călătoriei, chiar și atunci când sunt utilizate cu alte evenimente de afaceri. Cand bindingId este implementat, acționează asupra tuturor instanțelor călătoriei.
Hinweis
Legarea funcționează numai pentru aceleași tipuri de entități.
Cum se adaugă un bindingId la un declanșator personalizat
Puteți modifica bindingId atribut în fragment de cod pentru un declanșator personalizat.
Pentru a accesa fragment de cod pentru un declanșator personalizat existent:
- Mergi la Marketing în timp real > Logodnă > Declanșatoare.
- Selectați declanșatorul personalizat pe care doriți să-l adăugați bindingId la.
- Selectați Accesați fragment de cod.

- Copiați fragment și inserați-l în editorul de cod ales. Modificați bindingId atribut care urmează formatele menționate mai sus (un șir unic dacă îl utilizați numai cu declanșatoare personalizate sau
{table_name}/{unique row ID}atunci când se corelează între declanșatori personalizați și evenimente ieșite din cutie sau evenimente de afaceri personalizate).
Puteți urma aceiași pași pentru a adăuga un bindingId la crearea unui nou declanșator personalizat.
bindingId interpretare
The/ caracterul este rezervat. Se presupune întotdeauna că bindingId este într-o/ format separat și orice început sau final/ va fi sters. De asemenea, nu există/ în rezultat. Aplicația încearcă întotdeauna să o interpreteze în acest sens{entityType}/{entityId} Modă.
Exemple:
"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"}
Algoritm de comparație:
[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.
Exemple:
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
Feedback
Trimiteți și vizualizați feedback pentru