Integrera med externa system external-systems

På den här sidan visas de olika säkerhetsutkast som Journey Optimizer ger när ett externt system integreras, liksom de bästa sätten: hur man optimerar skyddet för det externa systemet med API:t för appning, hur man konfigurerar tidsgränsen för resan och hur försök fungerar igen.

Med Journey Optimizer kan du konfigurera anslutningar till externa system via anpassade datakällor och anpassade åtgärder. På så sätt kan du till exempel berika dina resor med data från ett externt bokningssystem eller skicka meddelanden med ett tredjepartssystem som Epsilon eller Facebook.

När du integrerar ett externt system kan du stöta på flera problem, systemet kan vara långsamt, det kan sluta svara eller så kanske det inte kan hantera en stor volym. Journey Optimizer erbjuder flera skyddsräcken för att skydda datorn mot överbelastning.

Alla externa system har olika prestanda. Du måste anpassa konfigurationen efter dina användningsfall.

När Journey Optimizer gör ett anrop till ett externt API körs de tekniska garantierna enligt följande:

API:er för begränsning och begränsning capping

Om att cappa och strypa API:er

När du konfigurerar en datakälla eller en åtgärd upprättar du en anslutning till ett system för att antingen hämta ytterligare information som ska användas under dina resor eller skicka meddelanden eller API-anrop.

Journeys API:er har stöd för upp till 5 000 händelser per sekund, men vissa externa system eller API har kanske inte samma genomströmning. Om du vill förhindra att dessa system överbelastas kan du använda API:erna Capping och Throttling för att begränsa antalet händelser som skickas per sekund.

Varje gång ett API-anrop utförs via resor, skickas det via API-motorn. Om gränsvärdet i API:t nås, avvisas anropet antingen om du använder API:t för begränsning, eller köas i upp till 6 timmar och behandlas så snart som möjligt i den ordning som de togs emot om du använder API:t för begränsning.

Anta till exempel att du har definierat en begränsning på 200 anrop per sekund för det externa systemet. Ditt system anropas av en anpassad åtgärd på tio olika resor. Om en resa tar emot 300 samtal per sekund används de 200 tillgängliga kortplatserna och de 100 återstående kortplatserna tas bort eller köas. Eftersom den högsta nivån har överskridits kommer de övriga nio resorna inte att ha några platser kvar. Denna granularitet hjälper till att skydda det externa systemet från överbelastning och krascher.

Mer information om hur du arbetar med API:erna finns i följande avsnitt:

En detaljerad beskrivning av API:erna finns i dokumentationen för Adobe Journey Optimizer API:er

Datakällor och kapacitet för anpassade åtgärder capacity

För externa datakällor är det maximala antalet anrop per sekund begränsat till 15. Om den här gränsen överskrids, ignoreras eller köas eventuella ytterligare anrop beroende på vilket API som används. Det är möjligt att öka denna gräns för privata externa datakällor genom att kontakta Adobe för att inkludera slutpunkten i tillåtelselista, men detta är inte ett alternativ för offentliga externa datakällor. * Lär dig konfigurera datakällor.

För anpassade åtgärder måste du utvärdera kapaciteten för ditt externa API. Om Journey Optimizer till exempel skickar 1 000 samtal per sekund och ditt system bara kan hantera 200 samtal per sekund, måste du definiera en begränsning eller begränsning så att systemet inte blir mättat. Lär dig hur du konfigurerar åtgärder

Slutpunkter med långsam svarstid response-time

När en slutpunkt har en svarstid på mer än 0,75 sekunder dirigeras dess anpassade åtgärdsanrop via en dedikerad långsam anpassad åtgärdstjänst i stället för standardtjänsten.

Den här tjänsten för långsam anpassad åtgärd tillämpar en begränsning på 150 000 anrop var 30:e sekund. Gränsen används med ett skjutfönster som kan börja när som helst under en 30-sekundersperiod. När fönstret är fullt avvisas ytterligare anrop med spärrfel. Systemet väntar inte på nästa fasta intervall, men börjar kryssa omedelbart efter att tröskelvärdet på 30 sekunder har uppnåtts.

Eftersom långsamma slutpunkter kan orsaka fördröjningar för alla åtgärder i kön i pipeline, bör du inte konfigurera anpassade åtgärder med slutpunkter som har långsamma svarstider. Vidarebefordra sådana åtgärder till den långsamma tjänsten för att skydda den övergripande systemprestandan och förhindra ytterligare latens för andra anpassade åtgärder.

Timeout och försök igen timeout

Om begränsnings- eller begränsningsregeln är uppfylld tillämpas timeout-regeln.

Under varje resa kan du definiera en tidsgräns. Detta gör att du kan ange en maximal varaktighet när du anropar ett externt system. Tidsgränsen har konfigurerats i egenskaperna för en resa. Se den här sidan.

Den här tidsgränsen är global för alla externa anrop (externa API-anrop i anpassade åtgärder och anpassade datakällor). Som standard är den inställd på 30 sekunder.

Under den angivna tidsgränsen försöker Journey Optimizer anropa det externa systemet. Efter det första anropet kan högst tre försök utföras tills tidsgränsen för timeout har nåtts. Antalet försök kan inte ändras.

Varje nytt försök använder en kortplats. Om du har ett tak på 100 samtal per sekund och vart och ett av dina samtal kräver två försök, kommer hastigheten att sänkas till 30 samtal per sekund (varje samtal använder 3 platser: det första samtalet och två försök).

Tidsgränsvärdet beror på användningsfallet. Om du snabbt vill skicka ditt meddelande, till exempel när klienten kommer in i butiken, vill du inte ange en lång tidsgräns. Ju längre tidsgränsen är, desto fler objekt placeras i kö. Detta kan påverka prestandan avsevärt. If Journey Optimizer performs 1000 calls per seconds, keeping 5 or 15 seconds of data can quickly overwhelm the system.

Let’s take an example for a timeout of 5 seconds.

Frågor och svar faq

You will find below Frequently Asked Questions about integrating Journey Optimizer with external systems.

Need more details? Use the feedback options at the bottom of this page to raise your question, or connect with Adobe Journey Optimizer community.