신규 SAP PO를 도입하는 프로젝트에서는 별로 사용할일이 없는데 다른 EAI솔루션을 전환하는 프로젝트에서는 유용하게 사용할일이 많아지는것 같고 보통 PO의 Inbound Service Interface에서 Outbound Java Proxy를 호출하는 케이스를 많이 경험을 했었습니다.
특징
이클립스 기반인 NWA(SAP NetWeaver Developer Studio)에서 자바프록시 생성방법은 이전글을 참고하시면 될것 같은데 검색을 하시면 더 좋은 가이드가 많아서 그사이트를 참고하시면 도움이 되실것 같습니다.[PO 7.5] Creation JavaProxy in SAP Netweaver Developer Studio
자바프록시는 AS Java 릴리즈 6.4이상에서 자바 프록시 런타임을 설치할수 있다고 하며 동기자바프록시는 관련없지만 소스가 JDBC방식이고 타겟이 자바프록시 인경우 자바프록시를 중복호출이 되지않게 할 필요성이 있습니다.
예를 들어 JDBC Sender 채널의 폴링타임이 60초이고 설정된 조회쿼리에 계속 데이터가 존재한다면 불필요하게 자바프록시를 계속 호출하게 됩니다.
자바프록시를 구현할때는 ESR(Enterprise Services Repository), ID(Integration Directory)에서 정해진 틀에서 인터페이스 개발할때와 다르게 유연한 개발이 가능하여 여러방식으로 구현이 합니다. 레거시 DB연계를 할때는 NWA > Configuration > Infrastructure > Application Resources에서 JDBC드라이버를 등록 후 각 접속정보에 대한 JDBC custom DataSource를 생성하여 통합관리가 가능합니다. 그외 여러 장점들이 있는데 생각한대로 모든걸 구현이 가능할정도이죠.
하지만 자바 웹어플리케이션에서도 프레임웍이 있듯이 자바프록시도 정해진 표준과 프로젝트 내부가이드를 통해 개발이 진행이 되어야 효율적인 자바개발이 가능하며 이런부분들이 지켜지지 않는경우 오히려 독이 될수도 있으며 자바 Heap space부족, OOM(OutOfMemory) 등이 발생될수 있습니다.
그래서 제가 생각한 자바프록시를 개발할때 고려를 해야할부분들을 생각해보니 대용량, 익셉션, 트랜잭션처리 등이 있습니다.
대용량처리
DB나 FILE방식으로 대용량 처리 시 메모리를 늘리는건 한계가 있기때문에 로직에서 분할처리하는것을 권장하는 편입니다.예를 들어 PO에서 소스 DB의 테이블에서 조회한 데이터가 몇백만건이고 주기적으로 배치가 도는 인터페이스라고 했을경우 노드 하나에 부하를 주어 Node Down현상이 발생되어 다른 AP(Application Server)서버의 노드까지 영향을 줄수 있는 부분입니다. 그래서 신규인터페이스 개발하기 전에는 대략 발생 데이터 건수를 확인 후에 대용량인경우 Fetch Size를 지정하여 addBatch나 excuteBatch 등을 사용하여 처리하는게 효율적인것 같습니다.
전에는 자바프록시안에 ftp4j FTP관련 라이브러리를 사용하여 소스FTP서버에서 파일을 다운로드받는중에 OOM 발생된적이 있습니다. ftp4j.FTPClient.download java.lang.outofmemoryError: java heap space
원인은 대용량파일이지만 JVM관련 메모리를 높게 설정하게되면 처리가 가능할수도 있겠지만 하나의 인터페이스 때문에 PO의 여러 AP서버의 메모리를 설정하는건 효율적인지? 의심하게 됩니다. 파일 대용량같은경우 소스시스템에서 권장하는 사이즈에 맞게 분할업로드를 해주는게 좋을것 같습니다.
그리고 데이터나 파일이라는게 처음에는 사이즈가 작아도 운영중에 대용량이 될수 있부분이기도 하여 사전에 PO유입을 방지하기위해 사이즈 체크로직을 추가하여 일정사이즈를 초과하면 강제 Exception을 발생시키는 방법도 좋을것 같습니다.
트랜잭션, 익셉션 처리
보통 AllorNothing처리 10건중 1건이 에러가 발생되면 10건모두 롤백을 진행하며 AutoCommit처리는 10건중 에러가 발생된 건 이전꺼는 커밋이 되고 그 이후에는 롤백되거나 시스템에러가 발생되어 인터페이스가 에러처리가 됩니다. 지금 말씀드린 트랜잭션 처리는 PO의 ESR, ID의 일반적인 방식이며 자바프록시로 구현할경우 위의 트랜잭션 처리 뿐만아니라 try~ catch~ 나 Exception를 사용하여 여러건 처리시 중간에 에러가 발생되어도 계속 처리를 진행하게 할수 있으며 Runtime 에러를 발생시킬수 있게 유연하게 개발이 가능합니다.자바프록시는 DTR(Design Time Repository)를 사용하여 개발자간에 소스를 버젼관리를 할수 있는 용이함이 있으나 자바프록시마다 .EAR파일을 Export받아서 배포를 해야하는데 개수가 늘어나면 관리가 어려울수도 있을것 같습니다. 예를 들어 자바프록시 개발표준가이드가 없는 경우 수십개, 수백개 되는 자바프록시마다 중복된 라이브러리가 존재할수도 있어 비효율적으로 보일수도 있습니다. 그래서 공통으로 사용한 라이브러리를 .JAR파일로 생성을해서 자바프록시에서 참조가능한 경로에 임포트를 하면 좋겠지만 현재로서는 생성된 공통라이브러리를 자바프록시마다 넣주는 방법밖에 생각이 나지 않습니다.
그외 공통라이브러리에 로그처리, DB와 FTP 컨넥션 등 공통으로 처리할수 있는 부분들을 추가해두면 좋을것 같습니다. 이것외에 SAP PO의 자바프록시를 효율적으로 사용하는 방법은 더 있을것 같은데 이정도로만 정리하고 다음에 추가적인 내용이 확인되면 업데이트 해보겠습니다.
그리고 지속적으로 OOM이 발생되면 그 노드뿐만아니라 다른 AP서버의 노드까지 영향을 주는데 특정노드만 지정해서 다른 노드에 영향을 주지못하게 할수 없는지 궁금한데 혹시 아시는 분계시면 댓글 부탁드리겠습니다.
댓글 없음:
댓글 쓰기