기술 저장소

스튜디오나 통합서버 기능을 디버깅 하는데 JeusServerLog (jlog)를 주로 사용한다. 그런데 문제는 스튜디오는 개발자 수만큼 여러개인데 통합서버는 하나이다 보니 jlog 가 뒤죽박죽 섞여있어서 내 스튜디오서 발생한 action의 로그를 찾기가 힘들다. 이럴때 다음의 설정으로 간단하게 내 스튜디오만의 jlog를 확인할 수 있다. 통합서버 설정파일인 PfmDevSvr.xml 의 내용중 다음부분을 수정하여 준다. PRIVATE_LOG 의 value는 YES로 변경PRIVATE_LOG_IP의 value에 로그 확인을 원하는 스튜디오 pc의 IP를 입력한다. , 를 구분자로 여러개 IP를 넣는 것도 가능PRIVATE_LOG_DIR의 value 폴더는 생성해줘야한다. 설정 수정 후 JEUS를 재기동하면 ..

Proframe studio를 이용해서 개발할 때 리소스가 오랜기간 많이 쌓이게 되면 리소스 저장, 리소스 히스토리 검색 속도가 느려진다. 해당 기능과 연관된 테이블에 데이터가 많이 쌓여서 생기는 현상인데 해당 테이블은 DEV_HISTORY, DEV_HISTORY_CONTENTS 이다.날짜가 많이 지난 DEV_HISTORY의 데이터는 삭제해주고 DEV_HISTORY_CONTENTS의 경우 HISTORY_ID를 이용해 정리를 해줘야한다. 수동이 아닌 자동으로 리소스 정리를 하기 위해서는 통합서버 설정파일에서 RESOURCE_HISTORY_MANAGEMENT, HISTORY_DAY_RANGE, HISTORY_ROW_NUM_RANGE 값을 조정하여 설정할 수 있다. ex>==> 자원 History 관리를 사용..

Proframe 4c, 5c 에서 제공하는 기능중 File IO를 사용할 때 주의할 점이 있다. File IO 의 Read Buffer는 최대길이가 10240 (10kb) 로 고정되어 있다. 때문에 File IO 구조체를 만들때 총 길이가 10240을 이상일 경우 한번에 데이터를 못읽는 경우가 생긴다.그리고 그 다음번 데이터를 읽을때 다음 전문의 시작부분이 아니라 소실된 데이터 부분부터 시작하기 때문에 담기는 데이터가 꼬이게 된다. File IO의 Read Buffer 의 최대길이는 엔진소스에서 설정되기 때문에 해당 부분 변경을 위해서는 패치가 필요하기 때문에부득이한 케이스를 제외하고는 AP 개발시에 사용하는 File IO 구조체의 총길이를 10240 미만으로 가져가야 한다. 왜 이렇게 만들어놨을까 궁금..

Batch 업무는 특성상 배치 실행여부를 확인하기 위해 반환값에 의존할 수 밖에 없는데 Proframe에서는 Batch Jop information을 지원하여 조금 더 수월하게 배치 실행 정보를 확인 할 수 있다. 배치 실행 정보는 PFM_BATCH_JOB 테이블에 기록되는데, 기본적인 status, 시간, 배치모듈 정보 외에도 다음의 API를 사용하여 배치 성공과 실패에 대한 추가적인 정보를 기입 할 수 있다. 배치 성공시:PfmBatchSuccessJobTable pfmBatchSuccessJobTable;strcpy( pfmBatchSuccessJobTable.job_last_key, "100" );pfmBatchSuccessJobTable.job_nrm_cnt = 30;strcpy( pfmBatc..