v7 v8

SMS 문제 해결

서로 다른 외부 계정 간의 충돌

인스턴스에 여러 SMS 외부 계정이 있는 경우 외부 계정 간의 충돌로 인한 문제가 아닌지 확인해야 합니다.

Adobe Campaign은 외부 계정을 관련 없는 엔티티로 취급합니다.

계정이 여러 개인 경우 다음 절차에 따라 문제를 일으키는 외부 계정을 격리합니다.

  1. 모든 외부 계정을 비활성화합니다.
  2. 하나의 외부 계정을 활성화합니다.
  3. 문제를 재현해 보십시오.
  4. 초기 문제가 항상 나타나지 않는다면, 결론을 내리기 전에 적당량의 시도를 한다.
  5. 해당 단일 계정에 문제가 나타나지 않으면 비활성화하고 다음 계정의 2단계로 다시 시작하십시오.

모든 계정을 개별적으로 확인한 결과 다음과 같은 2가지 시나리오가 있습니다.

  • 하나 또는 여러 계정에서 문제가 발생했습니다

    이 경우 각 계정에서 다른 문제 해결 절차를 개별적으로 적용할 수 있습니다. 네트워크 트래픽과 로그 수를 줄이기 위해 계정을 진단하는 동안 다른 계정을 비활성화하는 것이 가장 좋습니다.

  • 한 번에 하나의 계정만 활성 상태일 때는 문제가 나타나지 않았습니다

    계정 간에 충돌이 있습니다. 앞에서 언급했듯이 Adobe Campaign은 계정을 개별적으로 처리하지만 공급자는 이를 단일 계정으로 처리할 수 있습니다.

    • 모든 계정 간에 서로 다른 로그인/암호 조합을 사용하고 있습니다.
      제공자 측에서 발생할 수 있는 충돌을 진단하려면 제공자에게 연락해야 합니다.

    • 일부 외부 계정은 동일한 로그인/암호 조합을 공유합니다.
      공급자는 어떤 외부 계정 BIND PDU 에서 오는지 알 수 있는 방법이 없으므로 여러 계정의 모든 연결을 단일 연결로 취급합니다. 두 계정에서 MO 및 SR을 임의로 라우팅하여 문제가 발생했을 수 있습니다.
      공급자가 동일한 로그인/암호 조합에 대해 여러 짧은 코드를 지원하는 경우 공급자에게 해당 짧은 코드를 BIND PDU. 이 정보는 BIND PDU, 및 에는 없음 SUBMIT_SM, 이후 BIND PDU 은 MO 라우팅을 올바르게 허용하는 유일한 위치입니다.
      다음을 참조하십시오. 각 유형의 PDU에 있는 정보 위의 섹션에서 사용할 수 있는 필드를 알아봅니다. BIND PDU, 일반적으로 짧은 코드를에 추가합니다. address_range, 그러나 공급자의 특별한 지원이 필요합니다. 여러 짧은 코드를 독립적으로 라우팅하는 방법에 대해 알아보려면 관리자에게 문의하십시오.
      Adobe Campaign은 동일한 외부 계정에서 여러 짧은 코드 처리를 지원합니다.

일반 외부 계정 문제

  • 커넥터가 최근에 변경되었는지 여부와 해당 사용자에 의해 변경되었는지 여부를 조사합니다(그룹으로 외부 계정 확인).

    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;

  • (/postupgrade%20%EB%94%94%EB%A0%89%ED%86%A0%EB%A6%AC%EC%97%90%EC%84%9C?lang=ko) 시스템이 업그레이드되었는지 여부와 시기를 조사합니다.

  • SMS에 영향을 주는 패키지가 최근에 업그레이드되었는지 여부를 조사합니다(/var/log/dpkg.log?lang=ko).

중간 소싱(호스팅) 문제

  • 중간 소싱 환경에서 문제가 발생하는 경우 중간 소싱 서버에서 게재 및 광범위한 로그가 올바르게 생성 및 업데이트되었는지 확인하십시오. 그렇지 않은 경우 SMS 문제가 아닙니다.

  • 모든 것이 미드 서버에서 작동하고 SMS가 제대로 전송되지만 마케팅 인스턴스가 제대로 업데이트되지 않으면 중간 동기화 문제가 발생할 수 있습니다.

공급자에 연결할 때 발생하는 문제

  • BIND PDU 에서 0 command_status 이 아닌 코드를 반환하는 경우 공급자에게 자세한 정보를 요청합니다.

  • TCP 연결이 공급자에게 이루어질 수 있도록 네트워크가 올바르게 구성되었는지 확인합니다.

  • 공급자에게 Adobe Campaign 인스턴스의 허용 목록에 IP를 제대로 추가했는지 확인하도록 요청합니다.

  • 외부 계정​설정을 확인합니다. 공급자에게 필드의 값을 물어보십시오.

  • 연결이 성공했지만 불안정한 경우 불안정한 연결 문제 섹션.

  • 연결 문제를 진단하기 어려운 경우 네트워크 캡처를 통해 정보를 제공할 수 있습니다. 네트워크 캡처가 동시에 실행되면서 문제를 효율적으로 분석할 수 있는지 확인합니다. 문제가 나타나는 정확한 시간도 확인해야 합니다.

연결이 불안정한 문제

다음 중 하나라도 발생하면 연결이 불안정한 것으로 간주됩니다.

  • 연결은 1시간 미만 동안 지속됩니다. Adobe Campaign Classic 송신기 연결은 Adobe Campaign Classic MTA의 작동 방식으로 인해 예외입니다.

  • 공급자가 다음을 전송함 UNBIND PDUs.

  • enquire_link Adobe Campaign 측이나 공급자 측에서 시간이 초과됩니다. 다음을 볼 수 있습니다. ENQUIRE_LINK_RESP 이 경우 0이 아닌 오류 코드가 표시됩니다.

  • 많음 BIND PDUs. 연결 수에 따라 하루에 몇 개 이상 있지 않아야 합니다. 시간당 1개 이상의 BIND PDU에 경고가 표시되어야 합니다.

연결 안정성 문제를 해결하는 방법:

  • 불안정한 연결은 근본 원인이 되는 경우가 드물며, 종종 연결 해제를 트리거하는 다른 문제의 결과이기도 합니다. 근본 원인을 찾는 것이 우선입니다.

  • 자세한 SMPP 추적을 활성화합니다. 연결이 다시 시작될 때 발생하는 상황을 사용자가 확인해야 합니다.

  • 공급자가 다음을 전송하는 경우 BIND PDUs, 문제가 있을 수 있습니다. 공급자에게 이유를 물어보십시오. UNBING 이(가) 전송됩니다.

  • 네트워크 캡처를 사용하는 것이 연결이 어떻게 닫혀 있는지 확인할 수 있는 유일한 방법인 경우가 있습니다.

  • 공급자가 다음 중 하나를 전송하여 연결을 닫는 경우: TCP FIN 또는 TCP RST packet공급자에게 자세한 정보를 문의하십시오.

  • 공급자가 다음과 같은 클린 오류를 보낸 후 연결을 닫는 경우 DELIVER_SM_RESP 오류 코드를 사용하면 다른 종류의 메시지가 전송되지 않고 MTA 제한을 트리거하는 커넥터를 수정해야 합니다. 이는 연결을 종료하는 것이 MT 및 SR 모두에 영향을 미치는 송수신기 모드에서 특히 중요하다.

MT(일반 사용자에게 전송된 SMS)를 전송할 때 문제 발생

  • 연결이 안정적인지 확인합니다. SMPP 연결은 Adobe Campaign Classic의 송신기를 제외하고 최소 1시간 동안 지속적으로 유지되어야 합니다. 섹션 보기 불안정한 연결 문제.

  • MTA를 다시 시작하면 MT를 다시 보내는 데 시간이 조금 걸리는 경우 연결이 불안정하여 전송률이 저하될 수 있습니다. 섹션 보기 불안정한 연결 문제.

  • 브로드 로그가 있고 날짜가 맞는 올바른 상태인지 확인하십시오. 그렇지 않은 경우 게재 또는 게재 준비 문제일 수 있습니다.

  • MTA가 실제로 메시지를 처리하는지 확인합니다. 그렇지 않은 경우 SMS 문제가 아닐 수 있습니다.

  • SMS 커넥터가 실제로 공급자의 장비와 연결되어 있는지 확인합니다. 공급자에게 피드백을 요청하여 모든 시스템이 제대로 통신하고 있는지 확인하십시오. 다음을 참조하십시오 BIND_TRANSMITTER 및 BIND_TRANSCEIVER PDUs 를 참조하십시오. 적절한 문제 해결을 위해 SMPP 추적을 활성화해야 할 수 있습니다.

  • SMPP 추적이 활성화된 상태에서 SUBMIT_SM PDU 에 올바른 정보가 포함되어 있습니다.

  • 공급자가 다음으로 응답하는지 확인합니다. SUBMIT_SM_RESP PDU "OK" 값(코드 0)이 있는 경우 PDU가 적절한 지연 시간 내에 도착하는지 확인하십시오. 1초 이상의 시간은 공급업체와 상담해야 하며 일반적으로 100ms 이내에 도착합니다.

  • 이 모든 단계가 작동하면 문제가 공급자 측에 있다고 확신할 수 있습니다. 해당 플랫폼에서 문제 해결을 수행해야 합니다.

  • 작동하지만 처리량이 일치하지 않으면 전송 창을 조정하고 MT 처리량을 낮춰 보십시오. 이를 조정하려면 공급자와 협력해야 합니다. Adobe Campaign은 매우 신속하게 메시지를 보낼 수 있으므로 공급자의 장비에 성능 문제가 발생할 수 있습니다.

MT가 중복됩니다(동일한 SMS가 한 행에 여러 번 전송됨)

재시도로 인해 중복이 발생하는 경우가 많습니다. 메시지를 다시 시도할 때 중복이 있는 것이 정상입니다. 대신 다시 시도의 근본 원인을 제거해야 합니다.

  • 정확히 60초 간격으로 전송된 중복이 표시되면 공급자측의 문제일 수 있으므로 은(는) 전송되지 않습니다 SUBMIT_SM_RESP 빨리!

  • 많이 보시면 BIND/UNBIND, 연결이 불안정합니다. 다음을 참조하십시오.불안정한 연결 문제 섹션 을 참조하십시오.

재시도 시 중복 항목 수 감소:

  • 전송 창을 낮춥니다. 전송 기간은 대기 시간을 감당 SUBMIT_SM_RESP 할 수 있을 만큼 커야 합니다. 이 값은 창이 꽉 찼을 때 오류가 발생할 경우 복제할 수 있는 최대 메시지 수를 나타냅니다.

SR(배달 영수증) 처리 시 문제

  • 모든 종류의 SR 문제 해결을 수행하려면 SMPP 추적을 활성화해야 합니다.

  • 다음을 확인하십시오. DELIVER_SM PDU 은(는) 공급자로부터 발생하며 형식이 잘 지켜집니다.

  • Adobe Campaign이 성공적으로 회신했는지 확인 DELIVER_SM_RESP PDU 적시에. Adobe Campaign Classic에서 이렇게 하면 SR이 providerMsgId SMS 프로세스에서 지연된 처리에 대한 테이블입니다.

다음과 같은 경우 DELIVER_SM PDU 이(가) 정상적으로 승인되지 않은 경우 다음을 확인해야 합니다.

  • 에서 ID 추출 및 오류 처리와 관련된 정규 표현식 확인 외부 계정. 의 DELIVER_SM PDU컨텐츠에 대해 유효성을 검사해야 할 수도 있습니다.

  • 테이블에 오류가 제대로 프로비저닝되어 broadLogMsg 있는지 확인합니다.

다음과 같은 경우 DELIVER_SM PDU Adobe Campaign Classic 확장 SMPP 커넥터가 을 확인했지만 broadLog가 제대로 업데이트되지 않았습니다. 섹션에 설명된 ID 조정 프로세스를 확인하십시오 일치하는 MT, SR 및 broadlog 항목.

일부 잘못된 SR이 여전히 공급자의 버퍼에 있지만 모든 것을 수정한 경우 "잘못된 ID 승인 수" 옵션을 사용하여 건너뛸 수 있습니다. 이 값은 주의하여 사용하고 버퍼가 정리 된 후 가능한 한 빨리 0으로 재설정해야 합니다.

MO 처리 시 문제(및 블랙리스트/자동 회신)

  • 테스트 중에 SMPP 추적을 활성화합니다. TLS를 사용하도록 설정하지 않으면 MO 문제를 해결할 때 네트워크 캡처를 수행하여 PDU에 올바른 정보가 포함되어 있고 형식이 올바른지 확인해야 합니다.

  • 네트워크 트래픽을 캡처하거나 SMPP 추적을 분석할 때 회신이 구성된 경우 MO 및 해당 회신 MT와의 전체 대화를 캡처해야 합니다.

  • MO인 경우 (DELIVER_SM PDU)가 추적에 표시되지 않습니다. 공급자 측에서 문제가 발생합니다. 플랫폼에서 문제 해결을 수행해야 합니다.

  • 다음과 같은 경우 DELIVER_SM PDU 가 나타나면 Adobe Campaign에서 정상적으로 승인되었는지 확인합니다. DELIVER_SM_RESP PDU (코드 0). 이 RESP는 모든 처리 논리가 Adobe Campaign(자동 회신 및 허용/차단 목록)에 의해 적용되었음을 보장합니다. 그렇지 않은 경우 SMS 프로세스 로그에서 오류 메시지를 검색합니다.

  • 자동 회신이 활성화되어 있으면 SUBMIT_SM 이(가) 공급자에게 전송되었습니다. 그렇지 않은 경우 SMS 프로세스 로그에서 오류 메시지를 찾을 수 있습니다.

  • 다음과 같은 경우 SUBMIT_SM MT PDU 응답이 들어 있는 것은 추적에서 발견되지만 SMS가 휴대 전화에 도착하지 않으면 서비스 제공업체에 연락하여 문제 해결에 도움을 받아야 합니다.

게재를 준비하는 동안 격리된 수신자(자동 회신 기능에 의해 격리됨)를 제외하지 않는 문제

  • 검역표와 배송 로그에서 전화번호 형식이 정확히 동일한지 확인합니다. 그렇지 않은 경우 다음을 참조하십시오. 섹션 국제 전화 번호 형식의 더하기 접두사에 문제가 있는 경우.

  • 짧은 코드를 확인합니다. 수신자의 짧은 코드가 외부 계정에 정의된 것과 동일하거나 비어 있는 경우(비어 있는 경우 = 모든 짧은 코드) 제외가 발생할 수 있습니다. 전체 Adobe Campaign 인스턴스에 대해 하나의 짧은 코드만 사용되는 경우 모든 코드를 더 쉽게 남길 수 있습니다 짧은 코드 필드가 비어 있습니다.

인코딩 문제

1단계: 공급자에게 문의

그들에게 연락하여 무엇이 문제인지 알아보십시오. 그들은 문제가 그들 편인지 Adobe Campaign 편인지 알려줄 수 있어야 합니다. Adobe Campaign에 문제가 있는 경우 잘못된 필드를 정확하게 알려 줄 수 있습니다.

2단계: 메시지 내용 파악

유니코드는 유사 문자에 대해 많은 변형을 허용하며 Adobe Campaign은 이러한 변형을 모두 처리할 수 없습니다.

가장 일반적인 문제 원인은 워드 프로세서에서 복사하여 붙여넣는 것으로, 일반적인 문자를 유형적으로 올바른 버전으로 변경합니다. 공백은 줄바꿈하지 않는 공백으로, 큰따옴표는 여는 따옴표와 닫는 따옴표로, 빼기 기호는 다양한 종류의 하이픈으로 변경되었습니다.

테스트할 때 메시지를 복사하여 붙여넣지 말고 항상 인터페이스에 직접 입력하십시오.

16진수를 사용하면 유사한 문자의 차이점을 알 수 있습니다. 소문자 L, 대문자 I, O, 0, 모든 다른 유형의 따옴표, 비 라틴어 인코딩 또는 심지어 다른 유형의 공백은 모두 동일하게 보이거나 전혀 표시되지 않을 수 있습니다.

유니코드를 16진수로 변환하려면 유니코드 코드 변환기 웹 사이트입니다. 텍스트를 입력하고 전화 번호와 같은 PII가 없는지 확인한 다음 전환. 맨 아래(UTF-32 영역)에 16진수 값이 표시됩니다.

인코딩 문제에 대한 티켓을 열 때 공급자든 아니든 Adobe 고객 지원 센터는 항상 사용자가 입력하는 내용과 표시되는 내용의 16진수 버전을 포함합니다.

3단계: 보낼 내용 파악

사용할 인코딩을 결정하고 해당 문자 테이블을 온라인으로 검색합니다. 전송하려는 문자를 대상 코드 페이지에서 실제로 사용할 수 있는지 확인합니다. 다음을 확인하십시오. data_coding 필드는 올바르며 사용자와 공급자가 예상하는 것과 일치합니다.

4단계: 실제로 보낸 내용 파악

공급자에게 보내는 바이트를 정확히 확인하려면 커넥터의 디버그 출력이 필요합니다. 인코딩 문제가에 표시됨 SUBMIT_SM PDUs. 따라서 반드시 캡처하십시오. 로그에서 쉽게 찾을 수 있는 고유한 메시지를 보냅니다.

테스트할 때 다른 종류의 특수 문자를 보냅니다. 예를 들어, GSM7 인코딩에는 16진수 형식으로 매우 구별되는 확장 문자가 있으며 다른 인코딩에는 나타나지 않으므로 쉽게 찾을 수 있습니다.

SMS 문제에 대해 통신할 때 포함할 요소

Adobe Campaign, SMS 공급자에 대한 지원 티켓을 열거나 문제에 대한 모든 종류의 커뮤니케이션에 관계없이 SMS 문제에 대한 지원을 요청할 때마다 다음 정보를 포함하여 제대로 작동하는지 확인해야 합니다. 제대로 검증된 문제는 문제를 더 빨리 해결하는 데 핵심이 됩니다.

  • 자세한 SMPP 메시지 활성화 문제가 나타날 때. 대부분의 SMS 문제는 이 없이 해결할 수 없습니다.

  • 문제가 SMS 트래픽과 관련된 경우 먼저 공급자에게 문의하십시오. 이 플랫폼은 SMS 트래픽 문제를 실시간으로 효율적으로 진단하는 데 가장 적합합니다.

  • 문제에 대한 간략하지만 사실적인 설명을 포함하십시오.

  • 예상 결과에 대한 설명을 포함합니다.

  • 공급자의 피드백을 포함합니다.

  • 관련 로그 및/또는 네트워크 캡처를 포함합니다. 캡처를 수행할 때 캡처 중에 문제를 재현해야 합니다.

  • 로그, 추적 또는 캡처를 포함하는 경우 문제가 나타날 때 파일에서 정확한 위치를 찾아냅니다.

  • 메시지, PDU 또는 로그를 참조하는 경우 해당 타임스탬프를 쉽게 찾을 수 있도록 명확하게 기술하십시오.

  • 테스트 환경에서 문제를 재현해 보십시오. 설정이 확실하지 않은 경우 테스트 환경에서 테스트하고 SMPP 추적으로 결과를 확인합니다. 일반적으로 프로덕션 환경에서 문제를 직접 보고하는 것보다 테스트 환경에서 복제된 문제를 보고하는 것이 좋습니다.

  • 플랫폼에서 변경된 사항이나 조정을 포함합니다. 또한 공급자가 자신의 측에서 수행했을 수 있는 변경 사항을 포함합니다.

네트워크 캡처

네트워크 캡처가 항상 필요한 것은 아닙니다. 일반적으로 자세한 SMPP 메시지만 있으면 됩니다. 다음은 네트워크 캡처가 필요한지 여부를 결정하는 데 도움이 되는 몇 가지 지침입니다.

  • 연결 문제가 발생하지만 자세한 메시지가 표시되지 않습니다. BIND_RESP PDU.

  • 오류 메시지가 없는 원인 불명의 연결 해제, 낮은 수준의 프로토콜 오류를 감지할 때 커넥터의 일반적인 동작.

  • 공급자가 바인딩 해제/연결 해제 프로세스에 대해 불만을 토로합니다.

  • 선택적 TLV 필드의 인코딩 문제

  • 서로 다른 연결 사이에 트래픽이 혼재되어 있는 것으로 의심됩니다.

다른 모든 상황에서는 먼저 자세한 정보 SMPP 메시지를 분석하고 자세한 정보 로그에 정보가 누락된 경우에만 네트워크 캡처를 요청하십시오.

경우에 따라 네트워크 트래픽을 캡처할 필요가 없습니다. 다음은 가장 일반적인 상황입니다.

  • TLS 활성화됨: 정의에 따라 TLS 트래픽은 암호화되므로 캡처할 수 없습니다.

  • 성능 문제: 로그에는 성능 문제를 추적하는 데 필요한 모든 정보가 포함되어 있습니다.

  • 시간 문제 (retry timing, enquire_link 기간, 처리량 제한 등)

  • SR 구문 분석 및 처리: 세부 정보 로그는 훨씬 더 많은 컨텍스트와 더 나은 프레젠테이션을 제공합니다.

  • MO 처리(자동 회신, 격리).

  • 실제 SMPP 트래픽을 포함하지 않는 오류: 게재 준비, 메시지 센터 API 문제, 워크플로우 문제 등

SMPP 추적 활성화

새 커넥터가 추적을 통한 확장 로깅을 지원합니다. SMPP. 추적은 표준 출력이 아닌 MTA 로그에 출력됩니다.

외부 계정당 활성화(기본 방법)

  1. 다음에서 외부 계정, 확인 로그 파일에서 자세한 SMPP 추적 활성화.
  2. 서버가 외부 계정을 다시 로드할 수 있도록 10분 정도 기다립니다.

이제 활성화되어야 합니다.

구성에서 활성화

다음에서 config-instance.xml 파일에서 다음 매개 변수를 설정합니다.

<mta>
  <child extraArgs="-tracefilter:SMPP"/>
</mta>
<sms args="-tracefilter:SMPP"/>

컨테이너의 열린 연결 수 확인

컨테이너에 열려 있는 연결 수를 확인하려면 다음 명령을 사용합니다.

(for pid in $(ss -neopts  | sed -n 's/^.*:3600[ \t].*users:(([0-9A-Za-z"]*,pid=\([0-9]*\),.*$/\1/p' | sort ); do  cat /proc/$pid/cmdline; echo  " $pid" ;done;) | uniq --count

지정된 포트에 대해 열린 연결 수가 나열됩니다. 여기서는 포트 3600을 사용합니다.

결과는 다음과 같아야 합니다.

4 nlserversms -noconsole -tracefile:sms@INSTANCE_NAME -instance:INSTANCE_NAME -detach 15180
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 1838
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 24025
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 24029
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 29088
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 30390

sms 프로세스에 대해 열린 연결 4개 및 하위 5개가 있는 mta 하위 항목당 2개.

이 페이지에서는