본문 바로가기

프로젝트/장애인 PT 플랫폼, PTFD20

DELETE , UPDATE 쿼리 관련 동시성 문제 문제점 : 상품을 작성하던 중 PAGIGNG 혹은 조회 과정에서 글이 삭제 되거나 , 수정되었을 때는 어떻게 진행할지에 대한 의견이 나왔다. 단순히 상품, 전체 만을 조회 할 때는 글이 삭제 수정되는 것만으로 그칠 수 있는 문제지만 후에 해당 상품을 구매하는 경우에는 구매 도중 글을 삭제하거나 취소할 수 있다는 문제까지 유발 될 것으로 예측되어 해당 부분에 대한 고민을 생각했다. 생각한 해결방안 : 각 요청시마다 검사 너무 많은 요청과 잦은 검사가 필요하게 된다. 또한 DATA의 문제를 BACKEND단에서 모두 검증하는 방식이, DATA는 DB영역에서 관리하고 서비스는 BACKEND 영역에서 관리하는 분리에 대한 개념에서 벗어났다고 느꼈다. 낙관적 LOCK(S-LOCK) 구매 과정에서, 특히 DB의 VE.. 2024. 3. 30.
결제 과정 완료 기존, 결제를 원하는 상품을 즉시 구매하는 형태로 구현하려 하였으나, 기술이 아닌 정책상의 문제(개인 사업자 만이 사용 가능, 사용자의 카드정보를 개인이 보유 금지)로. 이를 해결할 방안을 찾게 되었다. 해당 과정을 진행하며 주의했던 점 1. 결제 검증 결제 자체는 open api호출 만으로 쉽게 진행할 수 있다.( 앞서 상기한 정책상 이유로, test channel만 가능) 하지만 증권사 시스템을 분석하며, 결제 등의 프로세스에서 가장 중요한 것은 검증이라는 생각을 했다. front단이 전송한 결제 정보가, 사실과 다를 수도 있다는 가정을 하며 검증을 진행하였다. 2. front, backend 단의 분리 사용자의 카드 정보를 backend 단에서 보유할 수 없다. 이러한 이유로 front 단에서 어쩔.. 2024. 2. 27.
프로젝트 TEST public void SavePaymentInfo(String paymentid, String status, String paytime, String ordername, int totalamount) { OffsetDateTime offsetDateTime = OffsetDateTime.parse(paytime); Timestamp requestedAtTimestamp = Timestamp.from(offsetDateTime.toInstant()); Payment payment = new Payment( paymentid,status,requestedAtTimestamp,ordername,totalamount ) ; paymentRepository.save(payment) ; } 해당 내용을 TEST 하.. 2024. 2. 25.
SERVICE/CONTROLLER단 분할, 그에 따른 비동기적 형태 변경 이전 목표에 따라 , 1. TOKEN을 매 요청마다 생성(POSTONE 측의 TOKEN이, 굉장히 자주 만료된다) 2. SERVICE와 CONTROLLER단, 그리고 내부적인 역할 분담을 진행하겠다. @Service @NoArgsConstructor @Slf4j public class AccessTokenService { private final WebClient webClient = WebClient.builder().baseUrl("https://api.portone.io").build(); private final ObjectMapper objectMapper = new ObjectMapper(); public Mono GetToken() { PortoneTokenRequest portoneToke.. 2024. 2. 23.
FRONT에서의 결제 + 결제 정보 저장 현재까지 수 없이 고민한 내용은, 결제를 어떻게 진행 할 것인가 였다. 모든 결제를 BACKEND단에서 진행하자니, 많은 정책상의 문제. 그리고 또 결제가 정상적으로 진행 되었는지 사용자에게 친화적이지 않다는 문제가 있었다. 그렇다고 FRONTEND단에서만 사용하자니, 금액에 대한 관리가 우리 서버에서 전혀 진행할 수 없는 형태가 된다. POINT만을 사용하는 결제는, 결제의 기본이 남에게 확인을 받아야한다는 것을 고려했을때, 결제가 아닐 수 도 있다. 현재 그러므로 회의끝에 내린 결론은 웹하드처럼, 포인트를 구매해서(FRONT단에서) 이 포인트로 상품을 사자! 이를 위해 , 기존에 PURCHASEJSV2로 두었던 JS단에서 가장 먼저 구매 내역을 저장하게 하였다 . @Table(name = "Payme.. 2024. 2. 22.
Portone을 활용한 수기 결제(백엔드 단에 전 권한 이임) @RestController @RequiredArgsConstructor @Slf4j public class HandWritePayController { private final WebClient webClient = WebClient.builder().baseUrl("https://api.portone.io").build(); private final String mytoken = @PostMapping("/handwritepay") public Mono HandWritePay() { MethodDto handwritemethod = new MethodDto( new CardDto (new CredentialDTO("testcard", 2026, 11) )); PaymentAmount amount = .. 2024. 2. 21.
PORTONE활용 결제부, 상품 관련 DB 추가. 상품관련 DB는 2가지 분야에서 사용될 것이다. 1. 주문을 넣는 단(프론트 단)에서, 현재 남은 상품에 따라 해당 상품을 주문할 수도, 혹은 불가능 할 수 있다. 2. 결제확인까지 완료된 이후에, 남은 상품을 변경한다. (현재 프론트 단과는 협업이 필요하기 때문에, 일단 2번을 먼저 진행하도록 하겠다) 상품 DB 추가, 결제에 따른 상품 변경 DBeaver를 활용해서, 매우 간단하게 상품의 목록을 구현하였다. 그 이후엔, 이미 생성한 product table을 mapping 하였다 @Table(name = "Product") @Entity @Getter @Setter @NoArgsConstructor @AllArgsConstructor public class Product { //getter sette.. 2024. 2. 18.
PortOne을 활용한 간단 결제단 구축 결제 정보가 요청된다. test channel이기 때문에, 금액 상관 없이 결제가 가능하다. 이와 같이, 결제가 생성된다. 고려할점 - 현재 매우매우 간단하게 제공된 툴로 JS단에서 결제를 구성했다. 이런 간단한 수준만의 결제는 결과 적으론 의미가 있을 수 있어도, 프로젝트 측면에선 의미가 약하다고 판단. 빌링키 조회 API를 활용하여 REST API로 백에게 전 권한을 위임하여 통신하는 방식으로 변경해야겠다고 생각했다. @RestController @Slf4j public class PaymentController { private final WebClient webClient; public PaymentController(WebClient.Builder webClientBuilder) { this.w.. 2024. 2. 11.
PortOne을 활용한 결제 프로그램 구축 증권 계열 it업무를 분석하며 , HTS의 결제 과정에 대해서도 분석했다. 어떠한 결제, 입금, 출금, 송금이더라도, 그 기본적인 틀이 모두 동일함을 알 수 있었다 . 1. 결제 2. 실질적인 결제 (금융권은 이 작업을 직접 진행하지만, 증권계열의 한국 거래소와의 통신을 같은 맥락으로 보았다) *결제를 직접 진행할 수 있는 기관 : (여기서 결제 프로그램을 증권,금융사는 OPEN API로 하진 않기 때문에 추가적인 일들이 필요하다) 3-1. 결제 성공시, 결제에 따른 상품 변경 반영 3-2. 결제 성공시, 결제 내역 저장 (금융 , 증권사는 OPEN API를 사용하지 않기 때문에 계좌정보 확인들도 직접 진행한다) 3-3. 결제 실패시, 모든 내역 취소 4. 응답 물품을 구매하는 프로그램의 전반적인 프로세.. 2024. 2. 11.
OPEN API를 사용할때 주의점 OPEN API를 사용하여 OPEN API를 사용자에게 전달할 때, 주의점이 존재한다. 일단, 내가 생각하고 있는 자동매매의 흐름은 다음과 같다 . 1. 사용자가 TYPE A, B,C를 매수 매도에 대해 설정한다(DEFAULT값이 있을 것이다.) 2. 해당 TYPE에 따라서, 프로그램에서 매수 매도 한다 . 3. 이 매수 매도 정보를 DB에 저장한다. 그렇다면, 해당 매수 매도 정보를 OPEN API에서 받아와서 사용자에게 제출해야할까? 이는 그렇지 않다. 아는 동기형 이 진행했던 프로젝트 내용을 확인해보고 물어보았다. 해당 형의 프로젝트는 서비스 프로젝트로써, 사용자가 영화를 확인하고 마음에 드는 영화를 모아놓는 형태이다. 내가 생각하기엔, 모든 영화를 OPEN API에서 받아와서 DB에 저장하고, 그.. 2024. 1. 29.

티스토리툴바