대체로 SAP PO만 개발했던 사람으로서 CPI는 비슷하지만 다른부분들이 더 많은것 같고 앞으로 CPI와 PO는 어떻게 다르고 CPI를 어떠한 방향으로 알아야할지 생각을 해보는 내용입니다.
"솔직히 도움되는 내용은 없으면 만약 PO를 오랫동안 하셨던 분이라면 깨끗하게 이전에 개발했던 방식은 잊고 새로운 마음으로 CPI를 해보시는걸 권장드리고 싶습니다."
아직 페이지의 내용을 다 보고 이해한건 아니지만 같은 뱃속에서 태어난것 같은데 이렇게다 서로 다른건지 ㅎ
Comprehensive SAP CPI Guide for Standards & Best Practices 웹페이지를 보면 자세하게 정리되어있습니다. 이내용에서 제가 이해한 내용에 대해서만 간략하게 정리를 했습니다.
개발환경
SAP CPI의 개발환경은 자바기반의 이클립스(플러그인)와 웹에서 구동되는 SAP자체 브라우저 기반 플랫폼을 제공해주는데 SAP 로드맵에 따르면 이클립스 기반 툴은 곧? 폐기된다고 나와있고 권장하는 CPI개발은 웹에서 진행하는걸 권장하는것 같습니다.
"이클립스 기반의 NWDS는 어떻게 되는걸까요?"
오브젝트
CPI의 오브젝트 타입에서는 PO에서 익숙하게 보았던 오브젝트와 네이밍룰도 보이는데요. 보통 국내에서는 고객사마다 각 각 다른 네이밍룰로 설계가 되서 각 오브젝트에 대한 의미를 알면 좋을것 같습니다.
- Custom Package Name: 국가별 업종별 내용을 보면 PO의 SLD의 소프트웨어 컴포넌트와 비슷해보기이기도 합니다.
- iFlow: PO에서도 볼수 있는 오브젝트인데 기억나는건 인터페이스 흐름을 시각적으로 볼수 있는 단순했던 화면이였는데 실제 개발할때 거의 사용을 안했던 기능이였습니다. (CPI에서는 많이 사용되는걸까요?)
- ContentModifier:
- Script: 복잡한 플로우를 처리하는?(매핑에 복잡한 로직을 처리하는 PO의 자바매핑이나 UDF같은 기능인걸까요?)
- MessageMapping:
- Sender:
- Receiver:
- ValueMaping: PO에서는 사용하면 유용할것 같은 기능인데 개발하면서 거의 사용안했던 기능이였습니다.(CPI에서는 자주 사용할일이 생겼으면 좋겠네요)
- Communication Channel:
- Local Process Flow: 이것도 PO의 자바매핑이나 UDF와 비슷한 기능인것 같습니다.
CPI의 IFLOW 제가 알고 있는 개념과 다르게 스탭별로 처리되는 인티그레이션 플로우를 나타내는것 같은데 인터페이스나 업무적으로 식별할수 있는 오브젝트인것 같고 재사용,검색 등에도 사용되는 올바른 통합 레이아웃 설계를 위해 중요한것 같습니다. 뭔가 팁코 디자이너 툴과 nwBPM에서 보았던 화면가 비슷할것 같기도 합니다.
아이플로우에 가이드 라인의 몇가지 내용을 보면 복잡한 로직에 대한 모듈화, 흐름에 대한 단계는 10으로 제한하고, 유지보수를 용이, 불필요한 메시지는 지워야하는 등 이부분은 웹메서드의 개발 로직가도 비슷한 부분이 있는데 차이는 웹메서드는 위에서 아래로 CPI는 왼쪽에서 오른쪽 방향이라고 합니다.
CPI에서는 자바스크립트를 사용할수 있다고 들은것 같은데 그외 Groovy스크립트를 사용하는것이 좋다고 하는데 구루비는 자바와 비슷하다고 합니다. CPI의 큰기능으로 코드의 재사용성을 얘기하는데 기존 SAP PI/PO에서는 서로 다른 소프트웨어 구성버젼에서의 재사용성보다 더 좋다고 보여지고 있습니다.
오브젝트 버젼관리
CPI에서는 아래내용을 보면 개발자가 동시개발 진행할때 뭔가 PO와는 다른것 같은데요.
"For Version, enter WIP to indicate that the package is work in progress(중략)Once the edit is done, then save the paceage as a version"
PO에서는 여러사용자가 한 오브젝트에 접근을 하는경우 한사람의 편집중이면 다른 사람이 수정을 못하는 상태가 되고 편집을 누르면 편집중인 사람에 대한 아이디가 나오는데 CPI어떻게 동시개발할때 실제로 버젼관리가 어떻게 되는지 궁금하기도 합니니다.
어댑터
FILE, JMS, REST는 익숙한 어댑터인데 CPI의 REST에서는 페이징처리나 ODATA(Open Data Protocol) API라고 나오는데 URL에 쿼링을 할수 있도록 표준을 정해놓은 방식이라고 합니다. 그외 AS2, SF 어댑터 등 생소한 어댑터도 있는데 CPI에서도 PO의 효율적인 메시지 처리방법처럼 불필요한 데이터 차단, 대용량 파일에 대한 별도 처리 등처럼 비슷한 부분도 보이는데 처리지연이나 성능을 위한 메모리 확보 등에 대해서는 SAP에 노드와 메모리를 늘려달라고 요청할수 있다고 보이는데 PO에서의 이런부분들에 대해서는 BC쪽에 요청했었는데 특이합니다.
그리고 실패된 메시지에 대해 자동으로 재시도 할수 없고 로드맵에는 있지만 QoS나 EO를 지원하지 않는다고 설명합니다.
이관방식
CPI의 이관방식에 대해서는 기존에 PO에서도 많이 사용되었던 Export and Import, CTS+가 있고 생소한 MTAR Download, Transport Management Servicce가 있는데 이중에 고객사에서 CTS+를 사용하는경우 이 방식을 권장한다고 보입니다.
사용자 역할
기존 국내 큰규모의 PO프로젝트에서는 설계나 운영이관하는 컨설턴트, 개발하고 품질이관하는 개발자 권한 아니면 SI나 SM으로 별도의 사용자 롤로 지정되었는데요. 대체로 이렇게 두 역할로 나눠지고 작은 규모의 프로젝트에서는 대체로 모든 권한을 갖고 진행을 했었습니다. CPI를 진행하는 사용자별로 어떻게 역할이 나눠질지 궁금하기도 합니다.
모니터링
이전 PO에서 SAP의 지원을 받는경우 모니터링 화면이나 메시지, 로그를 보낼때도 있었는데 CPI는 클라우드 환경이라 빠르게 이슈나 오류부분들에 대해 지원을 받을수 있을것 같네요. CPI에서도 모니터링 기능을 지원한다고 하고 아이플로우의 로깅설정에 활성화 시킬수 있는것으로 보여집니다.
이제까지 정리한 내용들은 아래 링크된 페이지의 아직 작은 일부분의 내용들이며 관심있으시다면 전체 내용을 보시는것도 좋으실것 같은데요.(내용 정리하신분 정말 대단하신듯) 국내에는 이제 CPI프로젝트가 진행중에 있다는 곳도 들려오는것 같은데 외국은 이미 진행완성형으로 보입니다.
PO를 하신다면 같이 보시면 좋을것 같습니다.
댓글 없음:
댓글 쓰기