다음 가이드라인은 WebSphere® InterChange Server에 사용되는 통합 아티팩트의 개발을 지원하기 위해 만들어진 것입니다. 이 가이드라인을 준수하여 WebSphere InterChange Server 아티팩트를 손쉽게 WebSphere Process Server로 이주할 수 있습니다.
당연한 사항이지만 통합 솔루션은 WebSphere InterChange Server에서 제공하는 프로그래밍 모델 및 아키텍처를 준수해야 합니다. WebSphere InterChange Server는 실시간 자동화 프로세스 통합 솔루션에 최적화되어 있습니다. 또한 WebSphere InterChange Server에 있는 각 통합 구성요소는 아키텍처 안에서 올바르게 정의된 역할을 수행합니다. 이 모델에서 크게 벗어나는 경우 WebSphere Process Server의 적합한 아티팩트로 컨텐츠를 이주하는 작업은 더욱 어려워집니다.
나중에 이주 프로젝트를 크게 성공할 수 있게 하는 또 다른 우수 사례는 시스템 디자인을 문서화하는 것입니다. 기능상의 디자인 및 서비스 요구사항의 품질, 프로젝트 간에 공유되는 아티팩트의 독립성 그리고, 배치 동안에 발생하는 디자인 결정을 포함하여 통합 아키텍처 및 디자인을 캡처하십시오. 이 작업은 이주 중의 시스템 분석을 지원하며 재작업 노력을 최소화합니다.
아티팩트 정의를 작성, 구성 및 수정하려면 반드시 제공된 개발 도구만을 사용해야 합니다. 아티팩트 메타데이터의 수동 조작(예: XML 파일의 직접 편집)은 이주할 아티팩트를 손상시킬 수도 있으므로 피해야 합니다.
아티팩트에 대한 제품 문서에 출력된 API만 사용하십시오. 이러한 API는 WebSphere InterChange Server 개발 안내서에 자세히 설명되어 있습니다. 많은 경우에 호환성 API는 WebSphere Process Server에서 제공되며 여기에는 출력된 API만 포함됩니다. WebSphere InterChange Server에는 개발자가 사용하려는 여러 내부 인터페이스가 있지만, 인터페이스가 계속 지원될 것으로 확신할 수는 없습니다.
맵과 협업 템플리트에서 비즈니스 로직 및 변환 규칙을 디자인할 때 활동 편집기 도구를 최대한 활용하십시오. 이 경우 비즈니스 로직은 새 아티팩트로 더욱 쉽게 변환될 수 있는 메타데이터를 통해 기술됩니다. 도구에서 재사용하려는 오퍼레이션의 경우 가능하면 활동 편집기의 "내 콜렉션" 기능을 사용하십시오. WebSphere InterChange Server의 클래스 경로에 Java 아카이브(*.jar) 파일로 포함된 필드 개발 공통 코드 유틸리티 라이브러리는 수동으로 이주해야 하므로 사용하지 않는 것이 좋습니다.
개발해야 하는 Java 코드 스니펫에서 해당 코드는 가능한 단순하고 작게 작성하는 것이 좋습니다. Java 코드에서 정교화 수준은 기본 평가, 오퍼레이션, 계산, 데이터 형식화, 유형 변환 등과 관련된 스크립팅 순서로 유지되어야 합니다. 좀 더 폭넓고 정교한 응용프로그램 로직이 필요하면 WebSphere Application Server에서 실행되는 EJB를 사용하여 로직을 캡슐화하는 것이 좋습니다. 그런 다음 웹 서비스 호출을 사용하여 해당 EJB를 WebSphere InterChange Server에서 호출하십시오. 개별적으로 이주해야 하는 써드파티 또는 외부 라이브러리보다는 표준 JDK 라이브러리를 사용하십시오. 또한 단일 코드 스니펫 안에 있는 관련된 모든 로직을 수집하고 연결 및 트랜잭션 컨텍스트가 다중 코드 스니펫에 걸쳐 있는 로직은 사용하지 마십시오. 예를 들어, 데이터베이스 오퍼레이션의 경우 연결 확보, 트랜잭션 시작 및 종료, 연결 릴리스 등과 관련된 코드는 하나의 코드 스니펫으로 되어야 합니다.
일반적으로 EIS(Enterprise Information System)와 소통하도록 작성된 코드는 맵 또는 협업 템플리트가 아니라 어댑터 안에 위치해야 합니다. 이것은 일반적으로 아키텍처 디자인에 대한 우수 사례에 해당됩니다. 또한 코드 안에서 연결 관리 및 가능한 JNI(Java Native Interface) 구현과 같은 써드파티 라이브러리 및 관련 고려사항에 대한 전제조건을 생략하는 데 도움을 줍니다.
적합한 예외 핸들을 사용하여 가능한 안전하게 코드를 작성하십시오. 또한 현재 J2SE 환경에서 실행되는 코드라 하더라도 해당 코드를 J2EE 응용프로그램 서버 환경에서 실행할 수 있게 호환되도록 작성하십시오. 정적 변수, 스레드 출력 및 디스크 I/O 금지 등과 같은 J2EE 개발 규칙을 준수하십시오. 이러한 규칙은 일반적으로 준수할 최상의 우수 사례이지만 이식성에 적합해야 합니다.
나중의 이식성을 최대화하려면 협업 템플리트 또는 맵 안의 Java 스니펫 노드에 걸쳐 데이터베이스 트랜잭션을 활성화하지 마십시오. 예를 들어, 연결 확보, 트랜잭션 시작 및 종료, 연결 릴리스 등과 관련된 코드는 하나의 코드 스니펫으로 되어야 합니다.
비즈니스 오브젝트의 개발에 대한 기본 고려사항은 아티팩트 구성을 위해 제공된 도구만 사용하는 것, 명시적 데이터 유형 사용 및 데이터 속성의 길이 사용, 문서화된 API만 활용 등입니다.
WebSphere Process Server 안의 비즈니스 오브젝트는 SDO(Service Data Object)에 기반하며 SDO는 강력한 유형의 데이터 속성을 사용합니다. WebSphere InterChange Server 및 어댑터의 비즈니스 오브젝트의 경우 데이터 속성은 강력한 유형이 아니며 사용자는 때때로 비문자열 데이터 속성에 대해 문자열 데이터 유형을 지정하기도 합니다. WebSphere Process Server의 문제를 방지하려면 데이터 유형의 스펙에서 명시적이어야 합니다.
WebSphere Process Server 안의 비즈니스 오브젝트는 구성요소 간에 전달될 때 런타임 시 직렬화될 수도 있기 때문에, 데이터 속성에 대해 필요한 길이로 명시하여 시스템 자원의 사용을 최소화하는 것이 중요합니다. 예를 들어, 문자열 속성에 최대 255 문자 길이는 사용하지 마십시오. 또한 현재 기본값이 255 문자인 길이 속성에 0을 지정하지 마십시오. 속성에 필요한 정확한 길이를 지정하십시오.
XSD NCName 규칙은 WebSphere Process Server의 비즈니스 오브젝트 속성 이름에 적용되므로 비즈니스 오브젝트 속성의 이름에 공백이나 ":"을 사용하지 마십시오. 공백 또는 ":"을 갖는 비즈니스 오브젝트 속성 이름은 WebSphere Process Server에서 올바르지 않습니다. 이주하기 전에 비즈니스 오브젝트 속성의 이름을 바꾸십시오.
비즈니스 오브젝트에서 배열을 사용하는 경우 맵 및 관계에서 배열에 색인화할 때 배열의 순서에 의존할 수는 없습니다. 이 경우 WebSphere Process Server로 이주되는 생성은 색인 순서를 보장하지 않으며 특히 항목이 삭제되었을 때 그러합니다.
앞서 설명한 바와 같이 비즈니스 오브젝트 정의를 편집하는데 Business Object Designer 도구만을 사용하고 통합 아티팩트 내부의 비즈니스 오브젝트용으로 출력된 API만을 사용해야 합니다.
앞에서 설명했던 여러 가이드라인은 협업 템플리트의 개발에 적용됩니다.
프로세스를 메타데이터로 적절하게 설명하려면 협업 템플리트의 작성 및 수정에 항상 Process Designer 도구를 사용하고 메타데이터 파일을 직접 편집하지는 마십시오. 가능하면 활동 편집기 도구에서 메타데이터를 최대한으로 사용하여 필요한 로직을 설명하십시오.
이주에 필요할 수도 있는 수동 재작업을 최소화하려면 협업 템플리트 안의 문서화된 API만 사용하십시오. 정적 변수는 사용하지 마십시오. 대신 비정적 변수 및 협업 특성을 사용하여 비즈니스 로직의 요구사항을 해결하십시오. Java 스니펫에서 Java 규정자 final, transient 및 native를 사용하지 마십시오. 이러한 규정자는 협업 템플리트 이주의 결과인 BPEL Java 스니펫에 강제 적용될 수 없습니다.
나중의 이식성을 최대화하려면 사용자 정의 데이터베이스 연결 풀에 명시적 연결 릴리스 호출 및 명시적 트랜잭션 묶음(예: 명시적 확약 및 명시적 롤백)을 사용하지 마십시오. 대신 컨테이너 관리 암시적 연결 정리 및 암시적 트랜잭션 묶음을 활용하십시오. 또한 협업 템플리트 안의 Java 스니펫 노드에 걸쳐 시스템 연결 및 트랜잭션을 활성화하지 마십시오. 이 사항은 사용자 정의 데이터베이스 연결 풀뿐만 아니라 외부 시스템에 대한 모든 연결에도 적용됩니다. 이미 설명한 바와 같이 외부 EIS를 사용한 오퍼레이션은 어댑터에서 관리되어야 하며 데이터베이스 오퍼레이션과 관련된 코드는 하나의 코드 스니펫 안에 포함되어야만 합니다. 이것은 BPEL 비즈니스 프로세스 구성요소로 렌더링될 때 인터럽트 가능한 플로우로, 선택적으로 배치될 수 있는 협업 안에 필요할 수도 있습니다. 이 경우에 프로세스는 활동 간에 전달되는 상태 및 글로벌 변수 정보만 갖는 몇몇 개별적인 트랜잭션으로 구성될 수 있습니다. 임의의 시스템 연결에 대한 컨텍스트 또는 해당 프로세스 트랜잭션을 확장하는 관련 트랜잭션은 손실됩니다.
협업 템플리트 특성 이름에는 특수 문자를 사용하지 마십시오. 특수 문자는 해당 문자가 이주되는 BPEL 특성 이름에 올바르지 않습니다. 이주에 의해 생성되는 BPEL에서 구문 오류를 피하려면 이주하기 전에 특성의 이름을 바꿔 특수 문자를 제거하십시오.
"this"를 사용하는 변수를 참조하지 마십시오. 예를 들어, "this.inputBusObj" 대신 "inputBusObj"를 사용하십시오.
시나리오 범위의 변수 대신 클래스 레벨 범위의 변수를 사용하십시오. 시나리오 범위는 이주 시에 앞으로 진행되지 않습니다.
Java 스니펫에 선언된 모든 변수를 기본값으로 초기화하십시오. 예를 들어, "Object myObject = null;"과 같이 초기화하십시오. 이주 전에 선언되는 동안 모든 변수가 초기화되는지 확인하십시오.
협업 템플리트의 사용자 수정 가능 섹션에 Java import 문이 없는지 확인하십시오. 협업 템플리트의 정의에서 import 필드를 사용하여 Java 패키지를 가져오도록 지정하십시오.
협업 템플리트에 대해 앞에서 설명했던 여러 가이드라인은 맵에도 적용됩니다.
맵이 메타데이터로 적절하게 설명되려면 맵의 작성 및 수정에 항상 Map Designer 도구를 사용하고 메타데이터 파일을 직접 편집하지는 마십시오. 가능하면 활동 편집기 도구에서 메타데이터를 최대한으로 사용하여 필요한 로직을 설명하십시오.
맵에서 하위 비즈니스 오브젝트를 참조할 때 해당 하위 비즈니스 오브젝트에 대해 하위 맵을 사용하십시오.
Java 코드를 SET에서 "value"로 사용하지 마십시오. 해당 코드는 WebSphere Process Server에 올바르지 않기 때문입니다. 대신 상수를 사용하십시오. 예를 들어, 설정 값이 "xml version=" + "1.0" + " encoding=" + "UTF-8"인 경우 이 값은 WebSphere Process Server에서 유효하지 않습니다. 이 경우에는 이주하기 전에 해당 값을 "xml version=1.0 encoding=UTF-8"로 변경하십시오.
이주에 필요할 수도 있는 수동 재작업을 최소화하려면 협업 템플리트 안의 문서화된 API만 사용하십시오. 정적 변수는 사용하지 마십시오. 대신 비정적 변수 및 협업 특성을 사용하여 비즈니스 로직의 요구사항을 해결하십시오. Java 스니펫에서 Java 규정자 final, transient 및 native를 사용하지 마십시오.
비즈니스 오브젝트에서 배열을 사용하는 경우 맵에서 배열로 색인화할 때 배열 순서에 의존할 수는 없습니다. 이 경우 WebSphere Process Server로 이주되는 생성은 색인 순서를 보장하지 않으며 특히 항목이 삭제되었을 때 그러합니다.
나중의 이식성을 최대화하려면 사용자 정의 데이터베이스 연결 풀에 명시적 연결 릴리스 호출 및 명시적 트랜잭션 묶음(예: 명시적 확약 및 명시적 롤백)을 사용하지 마십시오. 대신 컨테이너 관리 암시적 연결 정리 및 암시적 트랜잭션 묶음을 활용하십시오. 또한 변환 노드 경계에 걸쳐 Java 스니펫 코드에서 시스템 연결 및 트랜잭션을 활성화하지 마십시오. 이 사항은 사용자 정의 데이터베이스 연결 풀뿐만 아니라 외부 시스템에 대한 모든 연결에도 적용됩니다. 이미 설명한 바와 같이 외부 EIS를 사용한 오퍼레이션은 어댑터에서 관리되어야 하며 데이터베이스 오퍼레이션과 관련된 코드는 하나의 코드 스니펫 안에 포함되어야만 합니다.
관계의 경우 관계 정의는 WebSphere Process Server에서 사용하도록 이주될 수 있으며 관계 테이블 스키마 및 인스턴스 데이터는 WebSphere Process Server에서 재사용될 수 있고 또한 WebSphere InterChange Server 및 WebSphere Process Server 간에 동시에 공유됩니다.
관계에 대한 핵심 고려사항은 관련 구성요소를 구성하도록 제공된 도구만 사용하는 것, 통합 아티팩트 내부의 관계용으로 출력된 API만 사용하는 것입니다.
Relationship Designer 도구만을 사용하여 관계 정의를 편집해야 합니다. 또한 WebSphere InterChange Server만 관계 스키마를 구성하도록 허용하십시오. 이 스키마는 관계 정의 배치 시 자동으로 생성됩니다. 데이터베이스 도구 또는 SQL 스크립트를 사용하여 관계 테이블 스키마를 직접 변경하지 마십시오.
또한 관계 테이블 스키마 안의 관계 인스턴스 데이터를 직접 수정하려면 Relationship Designer에서 제공하는 기능을 사용하십시오.
앞서 설명한 바와 같이 통합 아티팩트 안의 관계용으로 출력된 API만 사용해야 합니다.