MDB, DEX, API: 자판기 프로젝트에 필요한 인터페이스는 무엇일까요?

01 / 구매자 참고 사항

약어가 아니라 직무 내용부터 시작하세요.

모바일 앱 개발을 계획하는 사업자는 이메일에서 MDB, DEX, API를 요청할 수 있습니다. 이는 합리적인 출발점이지만, 이러한 용어들이 서로 대체 가능한 옵션을 나타내는 것은 아닙니다. 결제 단말기 연결, 감사 기록 ​​다운로드, 외부 애플리케이션의 판매 요청 허용은 각각 다른 작업입니다. 기기가 이러한 작업 중 하나만 지원하고 나머지는 프로젝트 요구 사항에 맞게 지원하지 않을 수도 있습니다.

실질적인 첫 단계는 고객 여정을 그림으로 나타내는 것입니다. 고객이 상품을 선택하고, 서비스 담당자가 구매를 승인하고, 담당자가 배송을 시도하고, 최종적으로 고객과 배송 담당자에게 전달되는 과정을 그려보세요. 각 단계에 대한 담당 조직을 명시하십시오. 이렇게 하면 인터페이스 관련 약어 목록을 길게 나열하는 것보다 누락된 연결 고리를 더 빨리 파악할 수 있습니다.

02 / 구매자 참고 사항

MDB: 기기와 결제 주변기기

MDB(멀티드롭버스)는 자판기 컨트롤러와 결제 단말기 등의 호환 주변기기 간의 통신을 의미합니다. 이는 범용 클라우드 서비스의 명칭이 아닙니다. 따라서 장비가 MDB와 호환된다는 사실만으로 모바일 애플리케이션이 모든 기능을 직접 제어할 수 있다는 것을 의미하지는 않습니다.

구매 시에는 컨트롤러 모델, 리더기 모델, 펌웨어 버전 및 지원되는 작동 모드를 기록하십시오. 그런 다음 실제 조합에 대한 증빙 자료를 요청하십시오. 구매 성공 여부뿐만 아니라 승인 거절, 선택 취소, 판매 실패 또한 중요합니다. 통합 시스템은 단순히 결제 요청을 수락하는 것이 아니라 실제 거래의 결과를 처리해야 합니다.

커넥터가 일치한다는 사실만으로 충분한 증거로 간주해서는 안 됩니다. 전기적, 프로토콜 및 소프트웨어 요구사항은 인터페이스 검토에 포함되어야 합니다. 설치 및 전기 점검은 문서화된 장비 지침을 따라야 하며 자격을 갖춘 담당자가 수행해야 합니다. 이 문서는 배선 안내서가 아닙니다.

03 / 구매자 참고 사항

DEX: 앱 명령 채널이 아닌 감사 정보

DEX는 자판기 감사 정보를 전송하는 데 사용됩니다. 구현 방식에 따라 해당 정보에는 총 판매액, 선택 데이터 및 기타 기기 기록이 포함될 수 있습니다. DEX가 있다고 해서 앱이 제품을 예약하거나, 가격을 변경하거나, 요청에 따라 제품을 내놓을 수 있는 것은 아닙니다.

제안된 구성에서 대표 파일과 각 필드에 대한 설명을 요청하십시오. 카운터가 누적 방식인지 보고 기간을 기준으로 하는지, 선택 항목이 제품에 어떻게 매핑되는지, 컨트롤러 또는 제품 레이아웃이 변경될 때 어떤 일이 발생하는지 명확히 하십시오. 이러한 정의가 없으면 기술적으로 성공적인 가져오기라도 잘못된 보고서를 생성할 수 있습니다.

유용한 인수 검증 절차는 문서화된 테스트 거래를 수행하고, 감사 결과를 수집하고, 변경 사항을 대조하는 것입니다. 먼저 시작 값을 기록하십시오. 누적 카운터를 단순히 파일이 오늘 검색되었다는 이유만으로 당일 매출액으로 해석해서는 안 됩니다.

04 / 구매자 참고 사항

API: 실제 계약을 검사하세요

API는 애플리케이션 프로그래밍 인터페이스를 의미합니다. 이는 소프트웨어 간의 상호 작용 방식을 설명하지만, 특정 공급업체가 제공하는 기능에 대해서는 자세히 알려주지 않습니다. 어떤 API는 판매 보고서를 제공할 수도 있고, 다른 API는 특정 기계 명령을 지원할 수도 있습니다. 따라서 브로셔에 있는 'API'라는 단어만으로는 이러한 기능 범위를 추측해서는 안 됩니다.

개발 작업을 할당하기 전에 문서를 숙지하십시오. 지원되는 작업, 인증 방법, 권한, 응답 필드, 오류 상태 및 버전 정책을 파악하십시오. 결과물이 이벤트로 푸시되는지 아니면 요청해야 하는지, 그리고 테스트 환경이 마련되어 있는지 확인하십시오. 상업적 접근 권한 및 지원 책임은 기술적 타당성과 별도로 확인하십시오.

앱 중심 프로젝트의 경우, 시스템이 이미 작업을 완료한 후 요청 시간이 초과될 경우 어떻게 처리할지 합의해야 합니다. 일부 시스템에서는 상태 확인 없이 명령을 반복 실행하면 두 번째 작업이 발생할 수 있습니다. 통합 설계에서는 고유한 트랜잭션 참조, 중복 처리 및 복구를 명시적으로 정의해야 합니다. 이는 특정 시스템에 대한 주장이 아니라 검증해야 할 요구 사항입니다.

05 / 구매자 참고 사항

실제 구매 대화를 위한 인터페이스 워크시트

비즈니스 활동, 송신 시스템, 수신 시스템, 필요한 증빙 자료의 네 가지 열을 사용하세요. 예를 들어, 가상의 사무 프로젝트는 다음과 같은 세 개의 행으로 구성될 수 있습니다. 선택한 결제 서비스를 통해 구매 승인, 문서화된 제어 인터페이스를 통해 특정 품목 요청, 합의된 보고 피드를 통해 완료된 판매 내역 대조. 이 예시는 계획 모델일 뿐이며, 모든 제품이 이러한 인터페이스를 제공한다는 것을 의미하는 것은 아닙니다.

각 행 아래에 실패 사례를 추가하세요. 보고서 피드가 지연될 경우 고객은 여전히 ​​제품을 받을 수 있나요? 승인은 성공했지만 출고가 실패할 경우 어떤 시스템에서 예외 기록을 생성하나요? 앱을 사용할 수 없는 경우 기기는 다른 승인된 구매 경로를 제공하거나 사용 불가 메시지를 표시하나요? 각 답변에는 담당자가 필요합니다.

마지막으로, 프로토콜 문서, 샘플 메시지, 샘플 감사 파일, 그리고 제안된 구성에 대한 전체 과정 시연 녹화 영상 등 정확한 증거를 첨부하십시오. "지원됨"으로 표시된 체크리스트보다는 어떤 필드가 도착하고 어떤 물리적 결과를 나타내는지 보여주는 테스트 영상이 훨씬 더 유용합니다.

06 / 구매자 참고 사항

출처 및 한계

MDB와 DEX의 기능적 차이점은 다음과 같습니다. Vending Market Watch의 DEX 및 MDB 개요 해당 기사는 2008년에 발표되었으며, 기기나 판독기의 최신 호환성 증거가 아닌 배경 정보를 제공합니다.

구매 결정을 내릴 때는 최신 제조업체 문서와 프로젝트별 테스트 결과를 활용하십시오. 이 가이드는 모든 WEIMI 구성에 MDB, DEX 또는 명령 API가 포함된다고 주장하지 않습니다. 관련 구성 및 통합 범위를 검토할 수 있도록 아키텍처와 필요한 운영 체제를 공유해 주십시오.