본문으로 건너뛰기

요청흐름 이해

주제 목차 · 이전: 개념과 용어 · 다음: 도입 범위 판단

이 문서의 결과: 조회 버튼 클릭 한 번이 데이터베이스까지 갔다가 돌아오는 경로를 순서대로 설명한다.

요청 한 건의 여행​

[사용자] 조회 버튼 클릭
|
v
[화면 JS] syn.$w.transactionAction('LD01') 호출
| 화면의 입력값을 모아 요청 전문 구성
v
[transact 모듈] BOD010.json 계약 확인
| - 요청이 계약의 Inputs 정의와 맞는가?
| - 인증이 필요한가? (Authorize)
| - GlobalID 부여, 거래 로그 기록
v
[dbclient 모듈] BOD010.xml 의 LD01 SQL 실행
|
v
[transact 모듈] 결과를 Outputs 정의대로 변환
|
v
[화면 JS] 응답을 그리드/폼 컨트롤에 표시

각 단계에서 확인할 것​

단계확인 지점문제가 생기면
화면 → transact요청이 서버에 도착했는가브라우저 개발자 도구 네트워크 탭
transact 계약 검증계약의 Inputs와 실제 요청이 일치하는가거래 이력의 오류 코드
dbclient 실행SQL이 정상 실행됐는가dbclient 로그, SQL 문법
transact 응답과 화면 표시출력의 형식·순서와 컨트롤 매핑이 맞는가입출력 연결 규칙 대조

이 표는 10. 테스트와 디버깅에서 실제 진단 절차로 이어집니다.

저장 위치 찾아보기​

실제 예제(handstack 저장소)에서 BOD 게시판 요청이 지나는 파일을 직접 찾아보면 다음과 같습니다.

지나는 곳실제 파일
화면contracts/wwwroot/HDS/BOD/BOD010.html, BOD010.js
거래 계약contracts/transact/HDS/BOD/BOD010.json
SQL 계약contracts/dbclient/HDS/BOD/BOD010.xml

GitHub의 BOD010.html부터 열어 세 파일을 나란히 비교해 보십시오.

자주 하는 오해​

"HTTP 상태 200이면 성공 아닌가요?" 아닙니다. 통신은 성공(200)했지만 거래가 실패할 수 있습니다. 응답 본문의 message.responseStatus, acknowledge 값으로 실제 성공 여부를 판단합니다. 전문 구조는 계약 중심 거래에서 확인합니다.

"거래가 성공했는데 화면이 비어 있어요." 거래 성공과 화면 표시는 별개입니다. 응답에 실제 행이 있는지 확인한 다음, HTML과 JS의 출력 컨트롤 이름 및 계약의 출력 형식·순서를 대조하세요. 증상별 문제 해결을 참고합니다.

이것만 기억하세요​

  1. 요청은 화면 → transact → dbclient(또는 function) → transact → 화면 순으로 흐른다.
  2. 각 단계마다 확인할 근거(네트워크, 로그, 이력)가 다르다.
  3. 200과 성공은 다르다.