Felsökning av SMS troubleshooting-sms

Problemet uppstod på ett eller flera konton

I så fall kan du tillämpa andra felsökningsprocedurer på varje konto separat. Det är bäst att inaktivera andra konton när du diagnostiserar ett konto för att minska nätverkstrafiken och antalet loggar.

Problemet uppstod inte när endast ett konto är aktivt vid något tillfälle

Du har en konflikt mellan konton. Som tidigare nämnts behandlar Adobe Campaign konton individuellt, men leverantören kan behandla dem som ett enda konto.

• Du använder olika kombinationer av inloggning/lösenord mellan alla dina konton.
  Du måste kontakta leverantören för att diagnostisera potentiella konflikter på deras sida.

• Vissa av de externa kontona delar samma kombination av inloggning och lösenord.
  Leverantören har inget sätt att avgöra från vilket externt konto de BIND PDU kommer från, så de behandlar alla anslutningar från flera konton som en enda. De kan ha cirkulerat MO och SR slumpmässigt över de två kontona, vilket kan orsaka problem.
  Om providern stöder flera korta koder för samma kombination av inloggning och lösenord måste du fråga var den korta koden ska placeras i BIND PDU. Observera att den här informationen måste placeras inuti BIND PDU, och inte i SUBMIT_SM, eftersom BIND PDU är den enda plats som tillåter att flerlägesobjekt dirigeras korrekt.
  Se avsnittet Information i varje typ av PDU ovan för att ta reda på vilket fält som är tillgängligt i BIND PDU, vanligtvis lägger du till den korta koden i address_range, men det kräver särskild support från providern. Kontakta dem för att få veta hur de förväntar sig att dirigera flera kortkoder oberoende av varandra.
  Adobe Campaign har stöd för hantering av flera korta koder på samma externa konto.

Undersök om anslutningsappen har ändrats nyligen och av vem (kontrollera Externa konton som en grupp).

select saccount, (sserver ||':'||sport) as serverPort, iextaccountid, CASE WHEN N0.iactive=1 THEN 'Yes' ELSE 'No' END as "(x) Enabled",

(select X1.sname from xtkoperator X1 where N0.icreatedbyid = X1.ioperatorid) as "Created By",

(select X1.sname from xtkoperator X1 where N0.imodifiedbyid = X1.ioperatorid) as "Last Modified By",

N0.slabel as "External Account", N0.tslastmodified as "LastModifiedDate"

from nmsextaccount N0 LEFT JOIN xtkoperator X0 ON (N0.icreatedbyid=X0.ioperatorid) order by 8 DESC LIMIT 50;

Undersök (i katalogen /postupgrade) om systemet uppgraderades och när

Undersök om några paket som påverkar SMS kan ha uppgraderats nyligen (https://experienceleague.adobe.com/var/log/dpkg.log?lang=sv).

Om problemet inträffar i en miljö med medelhög källkod måste du se till att leveransloggarna och de breda loggarna skapas och uppdateras på servern med mellanlagring. Om så inte är fallet är detta inte ett SMS-problem.

Om allt fungerar på mittservern och SMS-meddelanden skickas korrekt, men marknadsföringsinstansen inte uppdateras korrekt, kan du få ett problem med mellansynkronisering.

Om BIND PDU returnerar en command_status-kod som inte är noll ber du leverantören om mer information.

Kontrollera att nätverket är korrekt konfigurerat så att TCP-anslutningen kan göras till providern.

Be leverantören kontrollera att de har lagt till IP-adresserna till tillåtelselista i Adobe Campaign-instansen.

Kontrollera inställningarna för externt konto. Fråga leverantören vilket värde fälten har.

Om anslutningen lyckas men inte fungerar kontrollerar du avsnittet Problem med instabila anslutningar.

Om det är svårt att diagnostisera anslutningsproblem kan nätverksinhämtningen ge information. Se till att nätverksinhämtningen körs samtidigt medan problemet uppstår så att det kan analyseras effektivt. Du bör också notera exakt när problemet uppstår.

Anslutningen varar i mindre än 1 timme. Adobe Campaign Classic sändaranslutningar är ett undantag på grund av hur Adobe Campaign Classic MTA fungerar.

Providern skickar UNBIND PDUs.

enquire_link timeout, antingen på Adobe Campaign eller på leverantörssidan. I så fall kan ENQUIRE_LINK_RESP visas med en felkod som inte är noll.

Det finns många BIND PDUs. Det får inte finnas mer än ett fåtal under en dag, beroende på antalet anslutningar. Mer än 1 BIND PDU per timme ska vara varningar.

Instabila anslutningar är sällan rotorsaken, det beror ofta på ett annat problem som utlöser en frånkoppling. Att hitta rotorsaken är prioriteten.

Aktivera utförliga SMPP-spår. De måste se vad som händer när anslutningen startas om.

Om providern skickar BIND PDU kan något vara fel. Fråga din leverantör varför UNBING skickas.

Ibland är det enda sättet att se hur anslutningen stängs att ta en nätverksinhämtning.

Om providern stänger anslutningarna genom att skicka antingen en TCP FIN eller en TCP RST packet ber du leverantören om mer information.

Om providern stänger anslutningen efter att ha skickat ett rent fel som DELIVER_SM_RESP med en felkod måste de åtgärda sin koppling, annars förhindras andra typer av meddelanden från att skickas och MTA-begränsning aktiveras. Detta är särskilt viktigt i sändningsläge där stängning av anslutningen påverkar både MT och SR.

Kontrollera att anslutningen är stabil. En SMPP-anslutning bör vara kontinuerligt uppkopplad i minst en timme, med undantag för sändare på Adobe Campaign Classic. Se avsnittet Problem med instabila anslutningar.

Om du startar om MTA så att sändning av MT fungerar igen under en liten tidsperiod, har du antagligen strypning på grund av en instabil anslutning. Se avsnittet Problem med instabila anslutningar.

Kontrollera att den breda loggen finns och att den har rätt status med rätt datum. Annars kan det vara ett leveransproblem.

Kontrollera att MTA faktiskt behandlar meddelandet. Om så inte är fallet är det kanske inte ett SMS-problem.

Kontrollera att SMS-anslutningen är bunden till providerns utrustning. Be leverantören om feedback för att säkerställa att alla system kommunicerar på rätt sätt. Mer information om bindningsprocessen finns i BIND_TRANSMITTER och BIND_TRANSCEIVER PDU. Du kan behöva aktivera SMPP-spår för korrekt felsökning.

Kontrollera att SUBMIT_SM PDU innehåller rätt information när SMPP-spårningarna är aktiverade.

Kontrollera att providern svarar med ett SUBMIT_SM_RESP PDU med värdet OK (kod 0). Kontrollera att PDU:n kommer med en rimlig fördröjning: allt som är längre än en sekund måste diskuteras med leverantören, det kommer vanligtvis om mindre än 100 ms.

Om alla dessa steg fungerar kan du vara säker på att problemet ligger hos leverantören. De måste göra felsökningen på sin plattform.

Om det fungerar men flödet inte är konsekvent kan du försöka justera sändande fönster och sänka MT-flödet. Du måste arbeta med leverantören för att justera det. Adobe Campaign kan skicka meddelanden mycket snabbt så att det kan uppstå prestandaproblem på leverantörens utrustning.

Om dubbletter skickas med exakt 60 sekunders mellanrum är det antagligen ett problem på providersidan. De skickar inte SUBMIT_SM_RESP tillräckligt snabbt.

Om du ser många BIND/UNBIND har du en instabil anslutning. Se avsnittet Problem med instabila anslutningar för lösningar innan du försöker lösa problem med dubblettmeddelanden.

SMPP-spår måste vara aktiverade för att du ska kunna utföra någon typ av SR-felsökning.

Kontrollera att DELIVER_SM PDU kommer från providern och att den är korrekt formaterad.

Kontrollera att Adobe Campaign svarar med ett lyckat DELIVER_SM_RESP PDU i tid. I Adobe Campaign Classic garanterar detta att SR har infogats i providerMsgId tabellen för uppskjuten bearbetning av SMS-processen.

Kontrollera regex som rör extrahering av id och felbearbetning i det externa kontot ​. Du kan behöva validera dem mot innehållet DELIVER_SM PDUi .

Kontrollera att fel är korrekt etablerade i tabellen broadLogMsg .

Aktivera SMPP-spår under tester. Om du inte aktiverar TLS bör du göra en nätverksinhämtning när du felsöker MO för att kontrollera att PDU:er innehåller rätt information och är korrekt formaterade.

När du hämtar nätverkstrafik eller analyserar SMPP-spår, se till att du fångar in hela konversationen med MO och dess MT-svar om ett svar har konfigurerats.

Om flerlägesobjektet (DELIVER_SM PDU) inte visas i spårningarna är problemet på providersidan. De måste felsöka på sin plattform.

Om DELIVER_SM PDU visas kontrollerar du att den har bekräftats av Adobe Campaign med en DELIVER_SM_RESP PDU (kod 0). Denna RESP garanterar att all bearbetningslogik har använts av Adobe Campaign (autosvar och tillåt/blocklist). Om så inte är fallet söker du efter ett felmeddelande i SMS-processloggarna.

Om automatiska svar är aktiverade kontrollerar du att SUBMIT_SM har skickats till providern. Annars kommer det garanterat att hitta ett felmeddelande i SMS-processloggarna.

Om SUBMIT_SM MT PDU som innehåller svaret finns i spårningarna men SMS:et inte kommer till mobiltelefonen, måste du kontakta leverantören för hjälp med felsökning.

Kontrollera att telefonnummerformatet är exakt detsamma i karantäntabellen och i leveransloggen. Om så inte är fallet, gå till det här avsnittet om du har problem med plustexet för det internationella telefonnummerformatet.

Kontrollera korta koder. Undantag kan inträffa om den korta koden för mottagaren antingen är densamma som den är definierad i det externa kontot eller om den är tom (tom = valfri kortkod). Om bara en kort kod används för hela Adobe Campaign-instansen är det enklare att lämna alla short code-fält tomma.

Aktivera detaljerade SMPP-meddelanden när problemet uppstår. De flesta SMS-problem är omöjliga att lösa utan detta.

Om problemet är relaterat till SMS-trafik ska du kontakta leverantören först. Deras plattform passar bäst för effektiv diagnos av SMS-trafikproblem i realtid.

Ta med en kort men faktisk beskrivning av problemet.

Ta med en beskrivning av det förväntade resultatet.

Inkludera feedback från leverantören.

Inkludera relevanta loggar och/eller nätverksinhämtningar. Se till att du återskapar problemet under hämtningen när du gör hämtningar.

Om du inkluderar loggar, kalkeringar eller hämtningar pekar du exakt på platsen i filen när problemet uppstår.

Om du refererar till meddelanden, PDU:er eller loggar måste du tydligt ange deras tidsstämpel för att göra dem lättare att hitta.

Försök återskapa problemet i en testmiljö. Om du är osäker på en inställning kan du testa den i testmiljön och kontrollera resultatet med SMPP-spår. Det är vanligtvis bättre att rapportera problem som replikeras i testmiljöer än att direkt rapportera problem i produktionsmiljöer.

Inkludera alla ändringar eller justeringar som gjorts på plattformen. Inkludera också alla ändringar som leverantören kan ha gjort på sin sida.

Anslutningsproblem, men de detaljerade meddelandena visar inga BIND_RESP PDU.

Oförklarliga frånkopplingar utan felmeddelande, det vanliga beteendet för anslutningsappen när den upptäcker ett protokollfel på låg nivå.

Providern klagar över avbindnings-/frånkopplingsprocessen.

Kodningsproblem i valfria TLV-fält.

Trafiken misstänks vara blandad mellan olika anslutningar.

TLS aktiverat: TLS-trafik krypteras per definition så den kan inte fångas in.

Prestandaproblem: Loggar innehåller all information som behövs för att spåra prestandaproblem.

Timingproblem (retry timing, enquire_link period, begränsning av genomströmning osv.)

SR-parsning och -bearbetning: utförliga loggar ger mycket mer kontext och en bättre presentation.

MO-behandling (automatiska svar, karantän).

Fel som inte involverar faktisk SMPP-trafik: Förberedelse av leverans, API-problem för Message Center, arbetsflödesproblem osv.