데이터 맵과 전문
주제 목차 · 이전: 거래 계약 개념 · 다음: CRUD 거래 연결과 검증
이 문서의 결과: 데이터 맵 네 종류와 요청·응답 전문 구조를 설명한다.
데이터 맵 네 종류
거래에서 주고받는 데이터는 묶음(맵) 단위로 다룹니다.
| 방향 | 타입 | 몇 건 | 화면에서 | 예 |
|---|---|---|---|---|
| 요청 | Row | 정확히 1건 | 검색 조건, 단건 폼 | 분류·제목 |
| 요청 | List | 0건 이상 | 그리드 여러 행 | 편집한 행 여러 개 |
| 응답 | Form | 1건 | 상세 폼 | 게시글 1건 |
| 응답 | Grid | 여러 건 | 목록 그리드 | 게시글 여러 건 |
BOD010의 LD01은 조건(Row)을 요청해 목록(Grid)을 받고, BOD012의 GD01은 ID(Row)를 요청해 상세(Form)를 받습니다.
세 곳에서 같은 이름이 나오는 이유
[화면 HTML] syn-datafield="Board"
[화면 JS] outputs: [{ type: 'Grid', dataFieldID: 'Board' }]
[.json 계약] Outputs: [{ Type: "Grid", ... }]
05. 화면 저작에서 이미 다룬 이름 일치 원칙이 여기서 실제로 검증됩니다. 이름이 어긋나면 거래는 성공하는데 화면이 비어 있는 상황이 됩니다. 초보자가 가장 자주 만나는 증상입니다.
요청·응답 전문 구조
클라이언트와 서버가 주고받는 전문은 헤더(설명)와 바디(정보)로 구성됩니다.
| 구성 | 담긴 정보 |
|---|---|
요청 헤더(global/system/interface/transaction) | 환경, 인증, 요청 시스템, 통신, 거래 업무 정보 |
요청 본문(payLoad) | 실제 데이터 맵 |
응답(message) | 성공/오류 상태와 코드 |
응답(result) | 실제 응답 데이터 맵 |
전문 필드 하나하나의 정의는 계약 중심 거래에서 확인합니다. 이 문서에서는 "왜 이런 구조가 필요한가"에 집중합니다. 요청마다 이 구조를 다 채우는 것은 화면 개발자가 아니라 syn.$w.transactionAction이 대신 처리합니다.
이것만 기억하세요
- 요청은 Row/List, 응답은 Form/Grid로 구분한다.
- 데이터 맵 이름 불일치가 "성공했는데 화면이 빈" 문제의 가장 흔한 원인이다.