SMPP 연결 확인 validate-smpp-connection
다음은 SMPP 연결이 올바른지 확인하는 몇 가지 확인란입니다.
시작하기 전에 확인해야 할 사항 check-go-live
시작하기 전에 아래 검사 목록과 함께 SMPP 설정이 올바른지 확인하십시오.
외부 계정 충돌 확인 sms-external-accounts-check
SMS 외부 계정이 남아 있지 않은지 확인하십시오. 잠재적인 충돌을 제거하기 위해 테스트 계정을 삭제합니다.
외부 계정에 다른 인스턴스가 연결되어 있지 않은지 확인하십시오. 특히 프리프로덕션 환경이 프로덕션 외부 계정에 연결되지 않도록 합니다.
동일한 Campaign 인스턴스에 동일한 공급자에 연결하는 계정이 여러 개 있어야 하는 경우 공급자에게 문의하여 이러한 계정이 실제로 연결을 구분하는지 확인하십시오. 동일한 로그인을 사용하는 계정이 여러 개 있으면 추가 구성이 필요합니다.
활성화된 모든 SMS 외부 계정에 전용 프로세스 설정이 활성화되어 있는지 확인합니다. 동일한 인스턴스에서 두 종류의 계정(전용 프로세스가 있는 경우와 없는 경우)을 혼합할 수 없습니다.
실제 테스트를 수행합니다. real-test
다른 모바일에서 몇 가지 SMS를 전송해 보십시오.
모든 종류의 문자가 포함된 SMS 보내기
GSM 또는 ASCII 이외 문자로 SMS를 전송해야 하는 경우 최대한 다양한 문자로 일부 메시지를 보내십시오. 사용자 지정 문자 매핑 테이블을 설정하는 경우 가능한 모든 데이터 코딩 값에 대해 하나 이상의 SMS를 전송하십시오.
SR이 제대로 처리되었는지 확인
SMS는 게재 로그에 수신된 것으로 표시되어야 합니다. 게재 로그는 성공해야 하며 다음과 같습니다. "SR yourProvider stat=DELIVRD err=000|#MESSAGE#".
"SMSC 구현 이름" 필드를 제대로 설정했는지 확인하십시오. 프로덕션 환경에서는 게재 로그에 "SR 일반"이(가) 포함되어서는 안 됩니다.
MO가 처리되었는지 확인
모든 자동 회신 키워드에 대해 몇 가지 SMS를 보내고 회신이 빠르은지 확인합니다(몇 초 이내).
MO가 nms:inSms 데이터베이스에 삽입되었는지 확인하십시오. 사용자 지정 TLV가 있는 경우 올바른 형식의 TLV도 올바르게 삽입되었는지 확인하십시오.
Campaign이 DELIVER_SM_RESP(command_status=0)에 성공하여 답글을 남긴다는 로그를 확인하십시오.
부하 테스트 수행
이는 메시지를 많이 보내거나 실시간 메시지를 사용하는 경우에 특히 중요합니다.
최소 5초 동안 100%에서 연결을 로드하는 테스트를 수행합니다. 공급자가 테스트용 가짜 계정에 연결할 수 없는 경우 실제 메시지를 보내야 합니다. 이를 위한 방법은 자세한 SMPP 메시지가 활성화된 상태에서 충분히 큰 첫 번째 전달을 자세히 모니터링하는 것입니다.
전송할 최소 메시지 수는 다음과 같이 계산할 수 있습니다.
최대 MT 처리량 * 총 송신기/송수신기 연결 수 * 5
게재가 완료되면 다음 사항을 확인합니다.
- 모든 메시지가 전송되었는지(반드시 수신되지는 않음) 확인
- 공급자가 정상적인 작동이라고 명시하지 않는 한 command_status가 0x00000000이 아닌 절대 제로 PDU가 있어야 합니다.
- 전체 전달 프로세스 동안 연결이 절대적으로 안정적이어야 합니다(BIND PDU 없음).
- 모든 메시지에 SR이 있고 올바르게 처리되었는지 확인합니다(SR이 제대로 처리되었는지 확인 참조). 작은 백분율에 오류가 있는 경우 Campaign 측에서 전송 또는 처리 중 오류가 아닌 실제 SR 반환 오류인지 확인하십시오.
- 성능을 잘 모르는 경우 특히 PDU와 해당 RESP 간에 지연이 적절한지 확인하십시오. 지연 시간이 500ms를 초과할 경우 높은 처리량에 문제가 될 수 있습니다. 해당 지연을 사용하여 전송 창 수식을 확인합니다(자세한 내용은 전송 창 설정 참조)
PDU 확인 pdu
PDU의 형식이 올바른지 확인합니다.
바인딩
BIND_* PDU가 올바르게 전송되었는지 확인합니다. 가장 중요한 것은 공급자가 항상 성공적인 BIND_*_RESP PDU를 반환한다는 것입니다(command_status = 0).
BIND_* PDU가 너무 많지 않은지 확인합니다. 너무 많으면 연결이 불안정하다는 것을 나타낼 수 있습니다. 자세한 내용은 아래의 불안정한 연결 문제 해결 섹션을 참조하십시오.
INQUIRE_LINK
연결이 유휴 상태일 때 ENQUIRE_LINK PDU가 정기적으로 교환되는지 확인합니다.
SUBMIT_SM / DELIVER_SM
메시지를 보낸 다음, 로그에서 해당 SUBMIT_SM, SUBMIT_SM_RESP, DELIVER_SM 및 DELIVER_SM_RESP PDU를 검색합니다.
SUBMIT_SM PDU 사용:
- data_coding이 올바른지 확인합니다(기본적으로 0).
- short_message가 올바르게 인코딩되었는지 확인합니다. 여러 인코딩을 지원하는 16진수 변환기를 사용하여 디코딩해 봅니다(일부 온라인 사용 가능).
- 긴 메시지에 message_payload를 사용하는 경우 콘텐츠가 short_message 필드가 아닌 선택적 필드에 있는지 확인합니다.
SUBMIT_SM_RESP PDU 사용:
- 성공했는지 확인합니다(command_status = 0).
- 본문 뒤에 '0' 바이트가 오는 올바른 형식의 ID를 포함하는지 확인하십시오.
DELIVER_SM PDU 사용:
- 16진수 short_message 필드를 디코딩합니다(온라인 도구 있음).
- SR에 있는 ID의 추출 정규 표현식에서 정의된 정규 표현식이 정확히 하나의 캡처 그룹을 반환하고 메시지에 있는 전체 ID를 캡처하는지 정규 표현식 검사 도구로 확인합니다.
- 추출된 ID가 SUBMIT_SM_RESP의 ID와 일치하는지 확인합니다.
- SR에서 상태의 추출 정규 표현식에 정의된 정규 표현식이 통계 필드의 내용을 반환하는지 확인합니다.
- SR의 오류 추출 정규 표현식에 정의된 정규 표현식이 오류 필드의 내용을 반환하는지 확인합니다.
DELIVER_SM_RESP PDU 사용:
- DELIVER_SM PDU를 받은 후 (일반적으로 1초 미만) 빠르게 전송되었는지 확인합니다.
- 성공했는지 확인합니다(command_status = 0).
공급자와의 라이브 테스트 sms-live-test
시작하기 전에 가장 좋은 방법은 양쪽 모두 실행 중에 로그를 보고 공급자와 함께 라이브 테스트를 하는 것입니다.
자세한 SMPP 추적 비활성화 sms-disable-smpp
모든 검사가 완료되면 마지막으로 수행할 작업은 너무 많은 로그를 생성하지 않도록 자세한 SMPP 추적을 비활성화하는 것입니다.
SMS 문제 해결 sms-troubleshooting
일반 문제 해결 절차 sms-general-troubleshooting
SMS 커넥터에는 SMPP 공급자, Adobe 및 사용자의 3개 엔티티가 포함됩니다.
기본 SMS 전문가는 SMPP 공급자이므로 모든 SMS 트래픽 관련 문제(연결 문제, 메시지 손실, 인코딩 문제, 국가별 규칙 등)에 포함되어야 합니다.
전용 프로세스 활성화 sms-dedicated-process
이전 (MTA 기반) 커넥터 (전용 프로세스가 비활성화됨)에 문제가 있는 경우 전용 프로세스 커넥터로 마이그레이션하는 것이 좋습니다. 훨씬 더 나은 성능을 발휘하고, 더 안정적이며, 로그에서 훨씬 더 나은 피드백을 제공합니다.
서로 다른 외부 계정 간의 충돌 sms-conflict-external-accounts
인스턴스에 여러 SMS 외부 계정이 있는 경우 계정 간의 충돌로 인한 문제가 아닌지 확인합니다.
문제를 일으키는 외부 계정을 격리하려면 다음을 수행하십시오.
- 모든 외부 계정 비활성화
- 하나의 외부 계정 활성화
- 문제를 재현해 보십시오.
- 해당 단일 계정에 문제가 나타나지 않으면 비활성화하고 다음 계정의 2단계로 다시 시작하십시오. 모든 계정을 개별적으로 확인한 후에는 두 가지 가능한 시나리오가 있습니다.
하나 이상의 계정에 문제가 발생했습니다
이 경우 각 계정에서 다른 문제 해결 절차를 개별적으로 적용할 수 있습니다. 네트워크 트래픽과 로그 양을 줄이기 위해 계정을 진단하는 동안 다른 계정을 비활성화하는 것이 가장 좋습니다.
언제든지 하나의 계정만 활성화해도 문제가 나타나지 않습니다
계정 간에 충돌이 있습니다. Adobe Campaign은 계정을 개별적으로 처리하지만 공급자는 이를 단일 계정으로 처리할 수 있습니다.
모든 계정 간에 다른 로그인/암호 조합을 사용하고 있습니다
공급자에게 문의하여 잠재적인 충돌 가능성을 진단해야 합니다.
일부 외부 계정이 동일한 로그인/암호 조합을 공유합니다
공급자는 BIND PDU가 어느 외부 계정에서 오는지 알 수 없으므로 여러 계정의 모든 연결을 단일 연결로 취급하므로 MO 및 SR을 2개의 계정에 대해 임의로 라우팅하여 외관상 무작위 문제를 일으킬 수 있습니다.
공급자가 동일한 로그인/암호 조합에 대해 여러 짧은 코드를 지원하는 경우 BIND PDU에 해당 짧은 코드를 넣을 위치를 요청해야 합니다. BIND PDU가 라우팅 MO를 올바르게 허용하는 유일한 위치이기 때문에 이 정보는 SUBMIT_SM이 아닌 BIND PDU 내에 배치해야 합니다.
BIND PDU에서 사용할 수 있는 필드를 알려면 위의 각 종류의 PDU에 있는 정보 섹션을 참조하세요. 일반적으로 address_range에 짧은 코드를 넣지만 이를 위해서는 공급자의 특별한 지원이 필요합니다. 여러 짧은 코드를 독립적으로 라우팅하는 방법에 대해 알아보려면 관리자에게 문의하십시오.
Adobe Campaign은 동일한 외부 계정에서 여러 짧은 코드 처리를 지원하므로 종종 모든 트래픽에 대해 단일 계정을 사용하는 것도 잘 작동합니다.
외부 계정 작동이 중지되었습니다. sms-external-account-not-working
일반적으로 SMPP 연결은 시간이 지남에 따라 매우 안정적인 경향이 있으며, 올바르게 구성되면 계속 작동해야 합니다.
- 커넥터가 최근에 변경되었는지 여부 및 해당 사용자에 의해 변경되었는지 여부를 조사합니다(그룹으로 외부 계정 확인).
- 시스템이 업그레이드되었는지 여부와 시기를 조사합니다.
- SMS에 영향을 주는 패키지가 최근에 업그레이드되었는지 확인합니다.
이러한 검사 중 근본 원인이 없는 경우 공급자에게 문의하십시오. 공급자가 플랫폼을 업데이트할 때 커넥터가 약간 다르게 작동하는 경우가 있습니다. 이렇게 하면 미세 조정된 설정이 손상되어 회귀가 발생할 수 있습니다.
공급자와 계속 연락하는 것이 좋으며, 그들은 종종 사전에 주요 변경 사항을 전달합니다.
중간 소싱(호스팅) 문제 sms-issue-hosted
- 중간 소싱 환경에서 문제가 발생하는 경우 중간 소싱 서버에서 게재 및 브로드로그가 올바르게 생성 및 업데이트되었는지 확인하십시오. 그렇지 않으면 이 문제는 SMS 문제가 아닙니다.
- 중간 연산자 이름이 소문자로 엄격하게 설정되어 있는지 확인하십시오. 그렇지 않으면 게재가 보류 중 상태로 유지됩니다.
- 모든 것이 중간 서버에서 작동하고 SMS가 제대로 전송되지만 마케팅 인스턴스가 제대로 업데이트되지 않으면 중간 동기화 문제가 발생합니다.
공급자에 연결할 때 문제 발생 sms-issue-connection
- BIND PDU가 0이 아닌 command_status 코드를 반환하거나(오류가 있음을 의미함) BIND_RESP PDU가 없으면 공급자에게 이 문제가 발생하는 이유를 문의하십시오.
- 공급자에 TCP 연결을 수행할 수 있도록 네트워크가 올바르게 구성되었는지 확인합니다.
- 공급자에게 Adobe Campaign 인스턴스의 IP 주소를 올바르게 허용했는지 확인하도록 요청합니다(대부분의 공급자가 이를 요구함).
- 외부 계정 설정을 확인합니다. 일부 필드의 값이 확실하지 않은 경우 공급자에게 문의하십시오.
- 연결이 성공했지만 불안정한 경우 연결이 불안정한 문제를 확인하십시오. 아래 섹션.
- 연결 문제를 진단하기 어려운 경우 네트워크 캡처를 통해 많은 정보를 얻을 수 있습니다. 네트워크 캡처가 동시에 실행되면서 문제가 나타나므로 효율적으로 분석할 수 있어야 합니다. 또한 문제가 나타나는 정확한 시간을 알아야 네트워크 캡처에서 문제를 더 쉽게 찾을 수 있습니다.
연결이 불안정한 문제 unstable-connections
불안정한 연결을 진단하는 방법:
다음 중 하나라도 발생하면 연결이 불안정한 것으로 간주됩니다.
- 연결은 1시간 미만 동안 지속됩니다.
- SMS 프로세스를 다시 시작하면 일시적으로 "문제 해결"됩니다. 즉, 연결이 불안정하면 제한이 트리거되고 SMS 프로세스가 다시 시작되면 제한이 지워지며 근본 원인이 발견될 때까지 다시 발생합니다.
- 공급자가 바인딩 해제 PDU를 보냅니다. 공급자는 정상 작동 시 바인딩 해제 PDU를 전송해서는 안 됩니다.
- enquire_link 시간이 캠페인 쪽 또는 공급자 쪽에서 초과되었습니다. 이 경우 ENQUIRE_LINK_RESP에 0이 아닌 오류 코드가 표시될 수도 있고 표시되지 않을 수도 있습니다.
- 많은 BIND PDU가 있습니다. 하루에 많이는 없어야 합니다(연결 수에 따라 다름). 시간당 및 연결당 1개 이상의 BIND PDU에 경고 메시지가 표시되어야 합니다.
연결 안정성 문제를 해결하는 방법:
- 불안정한 연결은 근본 원인이 되는 경우가 드물며, 어떤 식으로든 연결 해제를 트리거하는 다른 문제의 결과인 경우가 많습니다. 근본 원인을 찾는 것이 우선입니다.
- 자세한 SMPP 추적을 활성화합니다. 연결이 다시 시작될 때 발생하는 상황을 사용자가 확인해야 합니다.
- 공급자가 UNBIND PDU를 전송하는 경우 잘못된 작업을 할 수 있습니다. 그들에게 왜 UNBIND를 전송하는지 물어보면 아마도 근본 원인으로 이어질 것입니다.
- 네트워크 캡처를 사용하는 것이 연결이 어떻게 닫혀 있는지 확인할 수 있는 유일한 방법인 경우가 있습니다.
- 공급자가 연결을 닫으면(TCP FIN 또는 TCP RST 패킷 전송) 그 이유를 물어보십시오. 이것이 문제의 근본 원인을 말해 줄 것이다.
- 공급자가 클린 오류를 보낸 후 연결을 닫으면(예: 오류 코드가 있는 DELIVER_SM_RESP) 다른 종류의 메시지가 전송되지 않고 MTA 제한을 트리거하므로 해당 커넥터를 수정해야 합니다. 이는 연결을 종료하는 것이 MT 및 SR 모두에 영향을 미치는 송수신기 모드에서 특히 중요하다.
- 시간 초과(BIND 시간 초과, SUBMIT_SM 시간 초과)가 있는 경우 Campaign에서 해당 공급자에 대해 메시지를 너무 빨리 보낼 수 있습니다. 최대 MT 처리량 설정을 낮추고 이 문제가 해결되었는지 확인해 보십시오.
MT(일반 사용자에게 전송된 SMS)를 전송할 때 문제 발생
- 연결이 안정적인지 확인합니다. SMPP 연결은 최소 1시간 동안 지속적으로 유지되어야 합니다. 위의 "불안정한 연결 문제" 섹션을 참조하십시오.
- SMS 프로세스를 다시 시작하면 전송 MT가 짧은 시간 동안 다시 작동하는 경우 연결이 불안정하여 전송률이 저하될 수 있습니다. 위의 "불안정한 연결 문제" 섹션을 참조하십시오.
- 브로드 로그가 있고 날짜가 맞는 올바른 상태인지 확인하십시오. 그렇지 않은 경우 SMS 문제가 아니라 게재 문제 또는 게재 준비 문제입니다(이 문서의 범위를 벗어남).
- SMS 커넥터가 실제로 공급자의 장비와 연결되어 있는지 확인합니다. 공급자에게 피드백을 요청하여 모든 시스템이 제대로 통신하고 있는지 확인하십시오. 바인드 프로세스에 대한 정보는 BIND_TRANSMITTER 및 BIND_TRANSCEIVER PDUs 를 참조하십시오. 적절한 문제 해결을 위해 SMPP 추적을 활성화해야 할 수 있습니다.
- SMPP 추적이 활성화된 상태에서 SUBMIT_SM PDU에 올바른 정보가 포함되어 있는지 확인합니다(위의 설명서 참조).
- 공급자가 "OK" 값(코드 0)으로 SUBMIT_SM_RESP PDU에 응답하는지 확인합니다. PDU가 적절한 지연 시간에 도착하는지 확인하십시오. 1초 이상 걸리는 것은 의심스러운 것이므로 공급자와 논의해야 하며 일반적으로 100ms 이내에 도착합니다.
- 이 모든 단계가 작동하면 문제가 공급자 측에 있다고 확신할 수 있습니다. 플랫폼에서 문제 해결을 수행해야 합니다.
- 작동하지만 처리량이 일치하지 않으면 전송 창을 조정하고 MT 처리량을 낮춰 보십시오. 이를 조정하려면 공급자와 협력해야 합니다. Campaign은 매우 신속하게 메시지를 보낼 수 있으므로 공급자의 장비에 성능 문제가 발생할 수 있습니다.
MT가 중복됩니다(동일한 SMS가 한 행에 여러 번 전송됨)
재시도로 인해 중복이 발생하는 경우가 많습니다. 메시지를 다시 시도할 때 중복이 있는 것이 정상이므로 다시 시도의 근본 원인을 제거하는 데 노력을 집중해야 합니다.
- 정확히 60초 간격으로(또는 기타 의심되는 "정규" 기간) 전송된 중복이 표시되면 공급자 측의 문제일 수 있으므로 SUBMIT_SM_RESP를 충분히 빠르게 전송하지 않습니다.
- BIND/UNBIND가 많이 표시되면 연결이 불안정합니다. 연결이 불안정한 문제 섹션에서 해결 방법을 확인한 후 중복 메시지 문제를 해결하십시오.
- 잠시 후 모든 SUBMIT_SM PDU에 일치하는 SUBMIT_SM_RESP가 있는지 확인합니다. 그렇지 않거나 SUBMIT_SM_RESP가 너무 느리면 공급자 측에서 문제가 발생합니다.
재시도 시 중복의 양 완화:
- 전송 창을 낮춥니다. 전송 창은 SUBMIT_SM_RESP 지연을 처리할 수 있을 만큼 커야 하지만 너무 크지는 않습니다. 이 값은 창이 가득 찬 상태에서 오류가 발생할 경우 복제할 수 있는 최대 메시지 수를 나타냅니다.
SR(게재 영수증) 처리 시 문제
- 모든 종류의 SR 문제 해결을 수행하려면 SMPP 추적을 활성화해야 합니다.
- DELIVER_SM PDU가 공급자로부터 왔으며 형식이 올바른지 확인합니다.
- Campaign이 적시에 성공적인 DELIVER_SM_RESP PDU에 응답하는지 확인하십시오. 따라서 SMS 프로세스에서 지연된 처리를 위해 SR이 providerMsgStatus 테이블에 삽입되도록 합니다.
DELIVER_SM PDU가 정상적으로 승인되지 않으면 다음 몇 가지를 확인해야 합니다.
- 외부 계정에서 ID 추출 및 오류 처리와 관련된 정규 표현식을 확인합니다. DELIVER_SM PDU의 콘텐츠에 대해 유효성을 검사해야 할 수 있습니다.
- broadLogMsg 테이블에서 오류가 제대로 프로비저닝되었는지 확인합니다(Campaign 설명서에서 이에 대해 자세히 설명).
ACC 확장 SMPP 커넥터에서 DELIVER_SM PDU가 확인되었지만 broadLog가 제대로 업데이트되지 않은 경우 위의 MT, SR 및 broadlog 항목 일치 섹션에 설명된 ID 조정 프로세스를 확인하십시오.
일부 잘못된 SR이 여전히 공급자의 버퍼에 있지만 모든 것을 수정한 경우 "잘못된 ID 승인 수" 옵션을 사용하여 건너뛸 수 있습니다. 이 값은 주의하여 사용하고 버퍼가 정리 된 후 가능한 한 빨리 0으로 재설정해야 합니다.
SR 처리가 느리면 BroadLogMsg 테이블에서 가장 일반적인 상태 메시지를 확인합니다.
일부 SR만 수신되지만 전체가 수신되는 것은 아닌 경우 테스트 시스템과 같이 다른 시스템이 공급자의 계정에 연결되지 않는지 확인합니다. SR은 모든 연결에서 라우팅될 수 있으므로 그 중 일부는 다른 시스템으로 라우팅될 수 있습니다. 공급자는 계정에 연결된 다른 시스템이 있는 위치를 찾는 데 도움이 될 수 있습니다.
MO 처리 시 문제(및 격리/자동 회신)
- 테스트 중 SMPP 추적을 활성화합니다. TLS를 활성화하지 않는 경우에는 MO 문제 해결 시 네트워크 캡처를 수행하여 PDU에 올바른 정보가 포함되어 있고 형식이 제대로 지정되어 있는지 확인하는 것이 좋습니다.
- 네트워크 트래픽을 캡처하거나 SMPP 추적을 분석할 때 MO 및 해당 응답 MT(응답이 구성된 경우)와의 전체 대화를 캡처해야 합니다.
- MO(DELIVER_SM PDU)가 추적에 표시되지 않으면 공급자 측에 문제가 있음을 확신할 수 있습니다. 플랫폼에서 문제 해결을 수행해야 합니다.
- DELIVER_SM PDU가 표시되면 Campaign에서 DELIVER_SM_RESP PDU(코드 0)가 성공했는지 확인합니다. 이 RESP는 Campaign에서 모든 처리 논리를 적용(자동 회신 및 격리)했음을 보장합니다. 그렇지 않은 경우 SMS 프로세스 로그에서 오류 메시지를 검색합니다.
- 자동 회신이 활성화된 경우 SUBMIT_SM이 공급자에게 전송되었는지 확인합니다. 그렇지 않은 경우 SMS 프로세스 로그에서 오류 메시지를 찾을 수 있습니다.
- 응답이 들어 있는 SUBMIT_SM MT PDU가 추적에서 발견되었지만 SMS가 휴대폰에 도달하지 않은 경우 문제가 공급자 쪽에 있을 수 있으므로 공급자에게 문제 해결에 대한 지원을 요청해야 합니다.
게재를 준비하는 동안 격리된 수신자(자동 회신 기능에 의해 격리됨)를 제외하지 않는 문제
- 검역표와 배송 로그에서 전화번호 형식이 정확히 동일한지 확인합니다. 국제 전화 번호 형식의 더하기 접두사에 문제가 있는 경우 위의 "전체 전화 번호 보내기" 설정을 참조하십시오.
- 짧은 코드 확인: 수신자의 짧은 코드가 외부 계정에 정의된 것과 동일하거나 비어 있는 경우(비어 있음 = 임의의 짧은 코드) 제외가 발생합니다. 전체 Campaign 인스턴스에 하나의 짧은 코드만 사용하는 경우 모든 "짧은 코드" 필드를 비워 두는 것이 더 쉽습니다.
인코딩 문제 sms-encoding-issues
SMS에서 인코딩 문제가 자주 발생합니다. 다음은 몇 가지 기본 단계입니다.
1단계: 공급자에게 연락하기
공급자는 SMS 작동 방식을 알고 있는 전문가입니다. 그들에게 연락하여 무엇이 잘못되었는지 알아보십시오. 문제가 자신의 책임인지 Campaign의 책임인지 여부를 알려줄 수 있어야 합니다. Campaign에 문제가 있는 경우 잘못된 필드를 정확하게 알려 줄 수 있으므로 많은 도움이 됩니다.
2단계: 메시지에 있는 내용 파악
메시지에 포함된 내용을 알아야 합니다. 그 문장은 쉽게 들릴지 모르지만 그렇지 않다. 유니코드는 Campaign에서 유사 문자를 모두 처리할 수 없을 만큼 많은 변형을 허용합니다.
가장 일반적인 문제 소스는 워드 프로세서에서 복사하여 붙여 넣기, 일반적인 문자를 유형적으로 올바른 버전으로 변경: 공백은 줄바꿈하지 않는 공백으로, 큰따옴표는 여는 따옴표와 닫는 따옴표로, 빼기 기호는 다양한 종류의 하이픈으로 변경되었습니다 …
테스트할 때 메시지를 복사하여 붙여넣지 말고 항상 인터페이스에 직접 입력하십시오.
16진수로 겁먹지 마세요. 16진수는 낯설고 부자연스러워 보이지만 매우 독특한 품질을 가지고 있습니다. 유사한 문자들 간의 차이점을 알 수 있습니다. 소문자 L, 대문자 I, O, 0, 모든 다른 유형의 따옴표, 비 라틴어 인코딩 또는 심지어 다른 유형의 공백도 모두 동일하게 보일 수 있습니다 (또는 전혀 표시되지 않을 수도 있음). 16진수는 모든 것을 보여주며 사물을 비교하는 데 도움이 됩니다.
유니코드를 16진수로 변환하려면 온라인 도구를 사용합니다.
티켓을 열 때 공급자와 Campaign 지원 여부에 관계없이 인코딩 문제에 대해 입력한 내용과 표시되는 내용에 대한 16진수 버전을 포함합니다.
3단계: 보낼 내용 파악
사용할 인코딩을 결정하고 해당 문자 테이블을 온라인으로 검색합니다. 전송하려는 문자를 대상 코드 페이지에서 실제로 사용할 수 있는지 확인합니다. data_coding 필드가 올바르고 사용자와 공급자가 예상하는 것과 일치하는지 확인하십시오.
4단계: 실제로 보낸 내용 파악
공급자에게 보내는 바이트를 정확히 확인하려면 커넥터의 디버그 출력이 필요합니다. 인코딩 문제는 SUBMIT_SM PDU에 나타나므로 캡처해야 합니다. 로그에서 쉽게 찾을 수 있는 고유한 메시지를 보냅니다.
테스트할 때 다른 종류의 특수 문자를 보내는 것을 주저하지 마십시오. 예를 들어, GSM7 인코딩에는 16진수 형식으로 매우 고유한 확장 문자가 있으므로 다른 인코딩에 나타나지 않으므로 쉽게 찾을 수 있습니다.
성능 문제 sms-performance-issues
MT를 보내는 동안 성능 문제
- 외부 계정의 처리량 및 지연 섹션에 있는 모든 설정이 올바른지, 공급자가 허용한 설정과 일치하는지 확인하십시오.
- 다시 시도가 없는지 확인합니다.
- 공급자의 인프라가 포화 상태가 아닌지 확인합니다. RESP PDU에서 RMSGQFUL 또는 RTHROTTLED 오류를 확인합니다.
- serverConf 설정을 확인합니다. 기본값으로 시작하여 매개 변수를 천천히 하나씩 늘립니다.
- 로드 중에 SMS 프로세스가 항상 다시 시작되지 않는지 확인하십시오. 이 경우 serverConf 파일에서 maxSMSMemoryMb, maxProcessMemoryAlertMb 및 maxProcessMemoryWarningMb을(를) 늘려야 할 수 있습니다.
SR을 받는 동안 성능 문제
공급자가 측면에서 버퍼 오버로드에 대해 불평하는 경우 Campaign이 SR을 충분히 빨리 받지 못하기 때문일 수 있습니다.
- 인스턴스 데이터베이스가 오버로드되지 않았는지 확인하십시오. SR 처리는 데이터베이스 성능에 매우 의존합니다.
- 공급자에게 DELIVER_SM의 전송 창을 늘려 달라고 요청합니다. serverConf의 batchUpdateSize 설정만큼 큰 것이 좋습니다.
SMS 문제에 대해 통신할 때 포함할 요소
SMS 문제(Adobe Campaign에 대한 지원 티켓을 열거나 SMS 공급자에게 보내는 지원 티켓 또는 문제와 관련된 모든 종류의 커뮤니케이션 등)에 대한 지원을 요청할 때마다 다음 정보를 적어도 포함해야 제대로 된 자격을 갖출 수 있습니다. 제대로 된 문제는 문제를 더 빨리 해결하는 데 핵심이 되기 때문에 상황을 이해하고 의미 있는 정보를 주기 위해 조금 더 시간을 투자하면 효율성이 크게 도약할 것이다.
- 문제가 표시되는 동안 자세한 SMPP 메시지를 활성화합니다. 대부분의 SMS 문제는 이 없이는 사실상 해결이 불가능합니다.
- 문제가 SMS 트래픽과 관련된 경우 먼저 공급자에게 문의하십시오. SMS 트래픽 문제를 실시간으로 효율적으로 진단하기 위해 가장 잘 알고 있는 플랫폼입니다.
- 문제에 대한 간략하지만 사실적인 설명을 포함하십시오.
- 예상 결과에 대한 설명을 포함합니다.
- 공급자의 모든 피드백을 포함합니다.
- 관련 로그 및/또는 네트워크 캡처를 포함합니다. 캡처를 할 때는 캡처 중에 문제를 재현해야 합니다. 그렇지 않으면 무용지물이 됩니다.
- 로그, 추적 또는 캡처를 포함하는 경우 문제가 나타날 때의 파일의 정확한 위치와 작업 중인 예제의 정확한 위치를 정확하게 파악합니다. 캡처나 추적은 보기에는 크고 지루할 수 있으므로 그 안에서 정보를 찾는 데 도움이 되는 모든 것이 도움이 됩니다.
- 메시지, PDU 또는 로그를 참조하는 경우 다른 사람이 쉽게 찾을 수 있도록 타임스탬프를 명확하게 기술하십시오.
- 테스트 환경에서 문제를 재현해 보십시오. 설정이 확실하지 않은 경우 테스트 환경에서 테스트하고 SMPP 추적으로 결과를 확인합니다. 일반적으로 프로덕션 환경에서 문제를 직접 보고하는 것보다 테스트 환경에서 복제된 문제를 보고하는 것이 좋습니다.
- 플랫폼에서 수행되는 모든 변경 사항 또는 변경 사항을 포함합니다. 사소한 변경 사항도 큰 영향을 미칠 수 있습니다. 또한 공급자가 측면에서 수행했을 수 있는 모든 변경 사항을 포함합니다.
네트워크 캡처는 언제 유용합니까?
네트워크 캡처가 항상 필요한 것은 아닙니다. 대부분의 경우 자세한 SMPP 메시지로 충분합니다. 다음은 네트워크 캡처를 수행할 가치가 있는지 확인하는 데 도움이 되는 몇 가지 지침입니다.
- 연결 문제가 발생하지만 자세한 메시지에 BIND_RESP PDU가 표시되지 않습니다.
- 오류 메시지가 없는 원인 불명의 연결 해제(낮은 수준의 프로토콜 오류를 감지할 때 커넥터의 작동).
- 공급자가 바인딩 해제/연결 해제 프로세스에 대해 불만을 토로합니다.
- 선택적 TLV 필드에 인코딩 문제가 있습니다.
- 서로 다른 연결 사이에 트래픽이 혼재되어 있는 것으로 의심됩니다.
다른 모든 상황에서는 먼저 자세한 정보 SMPP 메시지를 분석하고 자세한 정보 로그에 정보가 누락된 것이 분명한 경우에만 네트워크 캡처를 요청하십시오.
네트워크 캡처가 소용없는 경우는 언제입니까?
네트워크 트래픽을 캡처하는 것이 소용없거나 시간 낭비인 경우도 있습니다. 다음은 가장 일반적인 상황입니다.
- TLS 활성화됨: 정의에 따라 TLS 트래픽은 암호화되므로 캡처할 수 없습니다.
- 성능 문제: 로그에는 성능 문제를 추적하는 데 필요한 모든 정보가 포함되어 있습니다.
- 시간 문제(재시도 시간, enquire_link 기간, 처리량 제한 등)
- SR 구문 분석 및 처리: 세부 정보 로그는 훨씬 더 많은 컨텍스트와 더 나은 프레젠테이션을 제공합니다.
- MO 처리(자동 회신, 격리).
- 실제 SMPP 트래픽을 포함하지 않는 오류: 게재 준비, 메시지 센터 API 문제, 워크플로우 문제 등…