오자마자 팀즈 문제로 팀즈 캐시 다시 삭제했는데
아무래도 계정명 변경 문제로 팀즈는 쭉 이렇게 캐시 삭제를 해야 할 것 같은 불안함이 생겼다.
이후 rest api생성을 진행하는데
소비자 키와 소비자 암호를 받아서 여기에 저장하지만
실제로는 이렇게 하면 안되는 것을 알고 있고
현재 테스트용 org의 키이기도 하며
이 페이지 접근 가능자는 회사 내부 인원들이고
블로그에는 키, 암호를 제외하고 올릴 예정이라
일단 이렇게 진행하기로 했다.
(키 들어있던 위치로 삭제하고 올렸다)
Rest api 요청을 위해서 A org의 class를 만들어야 했는데
어차피 Read 기능만 필요했기 때문에 부담없이 할 수 있었고
다른 기능 또한 크게 어렵지 않아 보였다.
중간에 with sharing pmd 경고가 나와서 지우면 또 없다고 뭐라고 하는 상황이었는데
위니가 without sharing을 해보라고 해서 했더니 문제를 해결할 수 있었다.
뭔가 api가 생성된 것 같기는 한데
다른 곳에서 어떻게 접근할 수 있는지 조금 의문이 들었고
postman을 사용해 작성한 데이터는 받아볼 수 있었지만
뭔가 아쉬움이 들었다.
데이터를 보내기 전 일단 postman을 통해서 params를 어떻게 주고 받을 수 있는지 먼저 테스트했다.
postman에 존재하는 params를 이용했는데
처음에는 주소창에 수동으로 값을 입력했지만 getUrl같은 기능이 작동하지 않았기 때문에 포기했고
그 뒤로는 params값을 받아오는 작업을 진행했다.
System.RestContext.request로 정보를 불러오는 것 까지는 진행했지만
params에 접근하는 방법이 어려웠는데 알고보니 .params로 바로 연결이 가능했다.
그 위에 header로 감싸져 있었기 때문에 header 내부에 있는 줄 알고
계속 빙빙 돌며 제대로 접근을 하지 못했던 것이었다.
params의 값을 성공적으로 받아온 다음
내부 값에 접근하는 법을 알아보니 .get(’id’)형태로 매칭되는 값을 가져올 수 있었고
id=a,b,c,d,e,f 형태로 보낸 경우 가져온 값을 split(’,’)으로 분할해 배열로 가져올 수 있었다.
드디어 제대로 된 값을 가져와서 where id in :id로 진행하니
내가 원하는 아이디만 지정해서 요청이 가능했다.
요청에서 Id, Name, Stock__c 필드를 가져올 수 있는 것을 확인했고
params를 통해 체크박스로 원하는 값만 리로딩 할 수 있는 rest api를 만들었으니
이제 B org에서 A org에 소통하는 것만 남았다.
소통 전 받아온 값들을 어떻게 처리할지 고민하다가
lwc 구상을 적용해서 만들려고 lwc 페이지 이름을 완성한 순간!(Inventory Consolidation)
생각해보니 여기서 받은 데이터를 띄우는 것은 의미가 없고
실제로 수정, 삭제, 생성이 된 product2의 필드를 가져오는게 의미가 있기 때문에
해당 데이터를 바탕으로 수정, 삭제, 생성을 하는 조건문을 작성하기로 했다.
중간에 동기간에 대화를 하다가
최근 수정 시간이 1시간이 넘게 차이나는 데이터는 굳이 받을 필요가 없지 않냐는 이야기가 나왔고
이게 실제 데이터라면 효율이 10배 이상 좋아질 것 같은 좋은 아이디어라고 생각했다.
회사에서 치킨을 주문해서 같이 먹고
insert, delete, update를 처리했다.
중간에 타입이 맞지 않아서 답답했던 일들이 많았는데
아래와 같은 처리들로 타입을 변환해서 어찌저찌 처리했고
Object a = 3처럼 object가 아니지만 Object로 감싸져 있는 경우
비교문에서는 자동으로 최소단위로 벗겨지지만
그 외에는 처리를 해야 한다고 해서 아래와 같은 처리들을 진행했다.
for(Product2 bPureData : bPureDatas){
List<Object> mixedList = new List<Object> {bPureData.Id,bPureData.Stock__c,bPureData.ProductParentId__c};
bDatas.put(bPureData.ProductParentId__c, mixedList);
}
----------------------------------------------------------------
for (Object obj : results) {
Map<String, Object> record = (Map<String, Object>) obj;
String name = (String) record.get('Name');
String id = (String) record.get('Id');
Integer stock = (Integer) record.get('Stock__c');
Object bData = bDatas.get(id);
List<Object> mixedList = (List<Object>) bData;
----------------------------------------------------------------
List<Object> mixedList = (List<Object>) bDatas.get(key);
String bId = (String) mixedList[0];
현재 처리 과정은 완료했지만 실제 적용이 되는지를 모르기 때문에
아래와 같이 실제 처리는 주석처리하고 list로 모아둔 update, delete, insert를 확인해보기로 했다.
System.debug('this is bDatas(have to be null) - '+bDatas);
System.debug('insertList');
System.debug(insertList);
System.debug('deleteList');
System.debug(deleteList);
System.debug('updateList');
System.debug(updateList);
// insert(insertList);
// delete(insertList);
// update(updateList);
a에서 3키 체인, 4키 홀더의 수량을 10으로 바꾸고 T자 키링과 레더 벨트를 지우고
저녁으로 먹었던 순살만 공격과 콜라를 추가했다.
예상대로면 각 list에 2,2,2개의 데이터가 들어있어야 하는데
조금 더 확실하도록 마우스패드와 팔찌의 수량을 10으로 증가시키고 펜슬 캡을 삭제해
update4 delete3 insert2로 각각 2, 3, 4개의 list를 보유해야 한다.
실제로 데이터를 실행해보니 삭제 처리 메서드에서는 bDatas를 제거하지 않아서
3개의 bDatas list, 2개의 insert list, 3개의 delete list, 4개의 update list를 볼 수 있었다.
그 후 실제 dml 요청까지 진행해보니
3개의 dml이 날아가는 것을 볼 수 있었고
실제로 데이터 또한 동일하게 됨을 볼 수 있었다.
최종적으로 확인한 결과 제대로 작동하는 것을 볼 수 있었고
이렇게 한 것으로 과제 최소조건은 달성했고
버튼에만 넣어줘도 된다는 말을 들었는데
여기서 이제 보안, pmd, 주석, 테스트코드 등을 신경써주고
추가적인 Org들을 생산해 페이지를 관리하며
A, C, D, E(가죽, 목재, 철제, 유리 공방) 페이지 4개를 LWC에서 출력하는 방향으로 하려고 한다.
각 작업은 15분간격으로 00 15 30 45분마다 자동 트리거를 사용하고
LWC 버튼 등은 4개를 고려만 해두고
B 먼저 작동하게 완료한 다음 해당 포맷을 그대로 3개 더 진행하면 될 것 같다.
(1).백준 18005번 Even or Odd?는 연속된 1~ 100경 사이의 숫자 중
n개의 연속된 숫자의 합이 짝수인지 홀수인지 둘 모두가 될 수 있는지를 묻는 문제였다.
규칙을 보면 1개의 경우 고르는 것에 따라 홀, 짝이 갈리고
2개의 경우 짝+홀로 무조건 홀수가 되며
3개의 경우에도 고르는 것에 따라 홀, 짝이 갈리고
4개의 경우에는 뭘 고르든 홀,짝,홀,짝으로 짝이 되게 된다.
이런 내용을 확인하고 %4를 통해 0,1,2,3에 맞는 조건으로 배치했다.
조건이 100경까지라고 하지만
실제 입력되는 연속되는 숫자의 갯수는 10억 이하였기 때문에
간단하게 Number type으로 받고 % 처리를 통해 해결했지만
100경이 연속된 숫자의 갯수라면 BigInt를 사용해야 했다.
const input = 12
if(input % 4 === 0){
console.log(2)
}
else if(input % 2 === 1){
console.log(0)
}
else{
console.log(1)
}
'회고' 카테고리의 다른 글
[수습일지] - 46 (0) | 2023.05.11 |
---|---|
[수습일지] - 45 (0) | 2023.05.10 |
[수습일지] - 43 (0) | 2023.05.08 |
[수습일지] - 42(주말) (0) | 2023.05.07 |
[수습일지] - 41(주말) (0) | 2023.05.06 |