자판기 API 이벤트: 지연 및 중복 업데이트를 처리하여 판매량 중복 계산 방지
웨이미 인사이트 / 데이터 통합
동일한 이벤트를 두 번 수신했다고 해서 판매가 두 건으로 발생해서는 안 됩니다.
자판기 데이터를 자체 보고 시스템에 연결하기 전에 거래 식별 정보, 이벤트 발생 시점 및 대조 방법을 정의하십시오.
신원
이 업데이트는 어떤 거래를 설명하는 것입니까?
주문하다
그 사건은 언제 발생했고, 언제 도착했습니까?
화해
누락되거나 일관성이 없는 기록은 어떻게 찾아낼 수 있을까요?
보고서로 이벤트를 가져오기 전에 데이터 계약 및 업데이트 규칙에 동의하십시오. 메시지 전달과 비즈니스 활동은 서로 다른 집계 방식입니다.
01 / 구매자 참고 사항
먼저 제공업체의 실제 행사 계약서를 살펴보세요.
판매 플랫폼은 이벤트 알림, 정기 보고서 또는 조회 인터페이스를 제공할 수 있습니다. 제안된 서비스가 지원하는 기능을 확인하고 관련 문서를 확보하십시오. API가 있다고 해서 웹훅, 주문 보장 또는 완전한 이력 피드가 포함된다고 가정하지 마십시오.
어떤 비즈니스 이벤트가 가능한지, 그리고 각 이벤트가 무엇을 의미하는지 문의하십시오. 주문 생성, 결제 승인, 실물 배송 및 최종 결제는 서로 다른 단계를 나타냅니다. 보고 시스템은 각 단계를 별도의 판매로 계산해서는 안 됩니다.
이 가이드는 통합 설계 시 고려해야 할 사항들을 제시합니다. 특정 WEIMI 플랫폼이 여기에 설명된 이벤트 필드나 전달 보장을 제공한다고 주장하는 것은 아닙니다. 해당 플랫폼을 기반으로 구축하기 전에 실제 인터페이스를 반드시 확인하십시오.
02 / 구매자 참고 사항
비즈니스 기록에 안정적인 거래 식별 정보를 사용하십시오.
수신 시스템은 동일한 거래에 대한 업데이트를 연결하는 신뢰할 수 있는 참조가 필요합니다. 소스에서 고유한 거래 식별자를 제공하는지, 그리고 그 고유성이 어떻게 보장되는지 문의하십시오. 캐비닛 ID와 로컬 시퀀스를 사용하는 경우 전역적으로 고유한 참조와는 다른 처리 방식이 필요할 수 있습니다.
인터페이스에서 이벤트 식별자를 제공하는 경우, 해당 식별자를 별도로 관리해야 합니다. 하나의 트랜잭션에 여러 이벤트가 속할 수 있으며, 반복적인 전달은 동일한 이벤트를 나타낼 수 있습니다. 통합 팀은 샘플 값을 추측하는 대신 실제 계약 내용을 바탕으로 데이터베이스 규칙을 정의해야 합니다.
제품명, 가격, 타임스탬프만을 고유한 구매 키로 간주하여 위험성을 평가하지 않고 사용하는 것은 위험합니다. 두 고객이 거의 동시에 동일한 제품을 동일한 가격에 구매할 수 있습니다. 이러한 경우, 편리한 근사치를 사용하면 정상적인 거래가 혼합되거나 중복 구매가 발생할 수 있습니다.
03 / 구매자 참고 사항
이벤트 시간과 수신 시간을 구분하세요
업데이트는 해당 업데이트에서 설명하는 비즈니스 작업보다 늦게 도착할 수 있습니다. 인터페이스에서 제공하는 관련 타임스탬프와 시스템이 메시지를 수신한 시간을 기록하십시오. 보고서가 여러 위치에서 해석 가능하도록 명시적인 시간대 처리를 사용하십시오.
구매 발생 시점을 나타내는 지표인 경우, 업데이트가 지연될 경우 자동으로 현재 시간대의 새로운 판매로 보고되어서는 안 됩니다. 보고 규칙과 지연된 데이터가 이전 기간에 미치는 영향을 명확히 정의해야 합니다.
보고서에 필요한 시간 정보가 제공되지 않는 경우, 해당 제한 사항을 명시하십시오. 증거 없이 영수증 시간표를 정확한 고객 구매 시간으로 표시하지 마십시오. 정확한 보고는 제공된 필드의 의미를 정확히 이해하는 것에서 시작됩니다.
04 / 구매자 참고 사항
계약에 따라 반복적인 업데이트를 처리합니다.
일부 인터페이스는 알림을 재발송하거나 이전 쿼리에서 이미 확인한 레코드를 반환할 수 있습니다. 수신 시스템은 동일한 비즈니스 활동이 두 번 계산되는 것을 방지하기 위해 문서화된 ID 및 상태 규칙을 사용해야 합니다. 모든 메시지를 새로운 메시지로 간주하기보다는 공급자의 동작을 확인하십시오.
가상의 거래 T42의 경우, 완료된 업데이트를 두 번 수신하더라도 두 메시지가 동일한 이벤트 또는 상태를 나타내는 경우 비즈니스 관점에서는 완료된 거래가 하나만 남아 있어야 합니다. 구현 시에는 전달 문제 조사를 위해 필요한 진단 정보를 충분히 보존해야 합니다.
중복된 항목을 무시하는 것과 이후의 수정 사항을 무시하는 것을 혼동해서는 안 됩니다. 후속의 유효한 업데이트는 거래 결과를 변경하거나 관련 조정 사항을 추가할 수 있습니다. 통합 시스템은 적절한 기록을 유지하면서 변경 사항을 적용하는 명확한 방법을 마련해야 합니다.
05 / 구매자 참고 사항
도착 순서가 더 강력한 증거를 덮어버리도록 내버려 두지 마십시오.
업데이트 내용을 해석할 때는 제공업체에서 정의한 순서 정보 또는 상태 규칙을 사용해야 할 수 있습니다. 주문이 보장되는지, 시스템에서 수정 사항을 어떻게 표시하는지 문의하십시오. 이러한 세부 정보가 없으면 초기 단계의 메시지가 늦게 전달되어 완료된 거래가 다시 보류 중인 것처럼 보일 수 있습니다.
통합 팀과 함께 상태 전환 검토를 수행하십시오. 허용된 전환, 해결되지 않은 상태, 그리고 기록이 일치하지 않을 경우 권한의 출처를 파악하십시오. 숫자가 더 큰 상태이거나 나중에 도착한 상태가 항상 올바르다는 일반적인 규칙을 만들지 마십시오.
API에 모호성을 해결하는 데 필요한 정보가 부족한 경우, 조정 또는 지원팀으로 전달하십시오. 대시보드의 총합을 맞추기 위해 불확실한 기록을 강제로 성공 범주에 포함시켜서는 안 됩니다.
06 / 구매자 참고 사항
실시간 영상과 함께 화해를 구축하세요
실시간 피드를 통해 운영팀은 신속하게 대응할 수 있으며, 주기적인 비교를 통해 누락되거나 일관성이 없는 기록을 식별할 수 있습니다. 대조 작업에 사용할 수 있는 소스 보고서 또는 과거 쿼리가 무엇인지, 그리고 해당 범위가 이벤트 스트림과 어떻게 관련되는지 문의하십시오.
일관된 기간과 정의를 비교하십시오. 기계 판매 보고서, 지급 보고서 및 은행 정산서는 서로 다른 단계 또는 금액을 나타낼 수 있습니다. 모든 합계가 즉시 일치해야 한다고 가정하기보다는 관련 참조 자료와 문서화된 규칙을 통해 이를 조정하십시오.
공급업체가 허용한 테스트 환경을 사용하여 중복 배송, 도착 지연, 업데이트 누락 및 승인된 수정 사항을 테스트하십시오. 개발 예제에서 실제 고객 및 결제 데이터는 필요하지 않은 경우 사용하지 마십시오. 승인 결과는 올바른 비즈니스 결과와 메시지 수신 성공을 보여야 합니다.
서로 다른 의미를 지닌 세 개의 기록
수신 메시지
시스템 내 정보 전달 1회를 나타냅니다 .
메시지 하나가 곧 새로운 판매로 이어진다 고 생각하지 마십시오 .
거래 기록
나타냄: 비즈니스 거래의 현재 해석된 상태.
필요사항: 안정적인 ID와 문서화된 업데이트 규칙.
조정 결과
의미: 합의된 범위 내에서 정의된 기록들을 비교한 것.
필요사항: 일관된 시기, 금액 및 상태 정의.
실질적인 답변
주문하기 전에 물어볼 만한 질문들
웹훅 전송은 제품이 배송되었음을 증명하는 것인가요?
문서화된 사건이 해당 결과를 구체적으로 나타내고 기본 시스템이 그 증거를 뒷받침하는 경우에만 해당됩니다. 사건 정의를 참조하십시오.
API 응답 횟수를 계산에 포함시켜 매출을 산출할 수 있나요?
기록을 이해하지 않고는 정확한 답변을 드릴 수 없습니다. 답변에는 반복적인 업데이트, 판매 이외의 이벤트 또는 하나의 거래에 대한 여러 기록이 포함될 수 있습니다.
늦게 도착한 데이터는 폐기해야 할까요?
자동으로 처리되지는 않습니다. 합의된 보고 및 수정 규칙을 적용하여 지연된 활동이 정확하게 처리되도록 하십시오.
다음 단계
대시보드를 구축하기 전에 데이터 계약을 검토하세요.
WEIMI에 보고 요구사항 및 통합 아키텍처를 공유하십시오. 제안된 플랫폼에서 사용 가능한 식별자, 이벤트 의미 및 조정 옵션을 확인하십시오.
장비 살펴보기 → 요구사항을 논의해 주세요 →