아래 내용은 'Script collection reusable artifact in SAP Cloud Integration'글을 보고 재 정리한 글이며 생성한 여러 리소스(Groovy,Java script와 jar파일)를 하나의 스크립트 컬렉션에 추가하여 두개이상의 통합Flow에 사용할수 있다는것을 이해하게 되었던것 같습니다.
예제를 구현하는 순서는
- 패키지에 스크립트 컬렉션을 생성
- 생성한 컬렉션에 스크립트를 생성하거나 업로드
- 두개의 통합flow를 생성
- 두개의 flow에 하나의 컬렉션을 참조탭에서 추가
- 통합 프로세스의 스크립트 단계에 추가
- 배포
생성한 스크립트 컬렉션과 통합플로우는 동일한 패키지에 존재하여야 서로 참조사용이 한데 각 플로우 별로 로컬로 스크립트도 생성도 가능합니다.
스크립트 컬렉션의 장점은
두개이상의 통합flow에 중복된 리소스를 방지하며 이로인해 메모리를 줄이고 유지보수나 재사용면에서도 좋은것 같다고 이해가 되는데 어느 댓글내용의 예를 보면
하나의 스크립트 컬렉션에 공통 .jar파일의 클래스를 참조하는 두개의 Groovy A,B라는 스크립트를 포함 후 이 컬렉션을 두개의 iFlow A에 Groovy A를, iFlow B에 Groovy B를에 추가하는경우
둘중에 Groovy에서 변경이 발생되어 스크립트 컬렉션을 재배포 하게되면 iFlow A에 영향을 있다고 말하는 부분에 대해서는 사용 시 주의가 필요할수도 있을것 같습니다.
기존 PO에서 하나의 공통적인 UDF(User Defined Functions)나 자바매핑 등을 많은 인터페이스에서 사용하는 할때 공통으로 생성한 오브젝트를 변경할때 해당 고통오브젝트를 사용하고 있는 인터페이스들의 영향도에 생각해봐야되는 부분도 존재합니다.
그래서 위 스크립트 컬렉션 같은경우도 동일하게 재사용 측면에는 좋으나 관리측면에서는 인터페이스 방식이나 업무적인 부분에 따라 고민이 필요할수도 있을것 같습니다.
예를들어 처음 설계시 송,수신 연계시스템만 다르고 동일한 로직이라면 공통 리소스를 관리하는것도 좋을것 같은데 개별 인터페이스 별로 대응(변경)이 필요한 부분이라면 로컬 리소스로 관리되는것도 좋을것 같습니다.
이전에 작성된 관련 글입니다.
댓글 없음:
댓글 쓰기