Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Problembehebung bei Fahrten
Stellen Sie sicher, dass die Protokollierung aktiviert ist, damit Sie die Fehlerursache leichter identifizieren können. Weitere Informationen zur Protokollierung finden Sie unter Überwachung und Protokollierung und Journey-Ereignisse.
Eine ereignisbasierte Reise wird nicht ausgelöst, wenn eine PutEvents Anfrage verwendet wird
Problem und Lösung
-
Stellen Sie sicher, dass die konfigurierten Reiselimits nicht überschritten werden:
Maximale Anzahl der täglichen Nachrichten pro Endpunkt
Maximale Anzahl von Nachrichten, die ein Endpunkt von der Journey empfangen kann
Maximale Anzahl von Journey-Nachrichten pro Sekunde
Maximale Anzahl von Einträgen pro Endpunkt
-
Stellen Sie sicher, dass die aktive Anzahl der durch Ereignisse ausgelösten Fahrten den bereitgestellten Schwellenwert nicht überschreitet. Weitere Informationen finden Sie unter Kontingente.
-
Stellen Sie sicher, dass alle Komponenten der PutEventsAPIAnfrage vollständig sind, einschließlich der Ereigniskomponente und der Endpunktkomponente.
-
Stellen Sie sicher, dass sich die spezifische Reise in derselben Anwendung befindet wie die in der PutEvent Anfrage.
-
Stellen Sie sicher, dass das richtige Ereignis konfiguriert ist, um Ihre Journey zu aktivieren. Sie können diese Konfiguration in der Journey entry condition (Journey-Einstiegsbedingung) bestätigen.
-
Ereignisgesteuerte Journeys eignen sich nicht für Anwendungsfälle im Kontaktcenter, da die Nutzungsdauer für Wählvorgänge auf 3 Minuten begrenzt ist.
-
Sie können die folgende Beispielanforderung verwenden, um eine Fahrt zu aktivieren, indem Sie „TestEvent“ als Eingabebedingung verwenden.
aws pinpoint put-events --application-id 7149cbb8XXXXXXXX --events-request file://PutEvents.json file://PutEvents.json { "BatchItem": { "ExampleEndpointID": { "Endpoint": { "User": { "UserId": "10107" }, "ChannelType": "EMAIL", "Address": "johndoe@example.com" }, "Events": { "JourneyEvent": { "EventType": "TestEvent", "Timestamp": "2019-02-10T19:48:57+00:00" } } } } }
Alle Reiseteilnehmer durchlaufen während der geteilten Aktivität „Ja/Nein“ den Zweig „Nein“
Problem und Lösung
-
Dieser Fehler kann auftreten, wenn keine Wartezeit konfiguriert ist. Sendeereignisse werden sofort ausgewertet, was dazu führt, dass alle Teilnehmer in den Zweig „Nein“ verschoben werden.
-
Um diesen Fehler zu beheben, überprüfen Sie, ob nach der Zustandserfassung etwas Wartezeit konfiguriert ist.
-
-
Ja/Nein-Splits, die auf einem Ereigniskriterium basieren, und die folgenden benutzerdefinierten AWS Lambda -Aktivitäten haben eine implizite Wartezeit von 15 Minuten, bis die Ereignisse gesammelt und verarbeitet werden.
-
Ja/Nein-Splits auf der Grundlage eines Ereigniskriteriums und nachfolgende Kanalaktivitäten (SMS,EMAIL,PNS) haben eine Wartezeit von 1 Stunde, bis der Status der Zustellungsereignisse für Kanalnachrichtenzustellungen erfasst und verarbeitet wird.
-
Für Ja/Nein-Splits werden nur Standardereignisse unterstützt, die sich auf den Status der Kanalübermittlung beziehen.