앞 절에서 설명한 필요조건은 기술 지원의 판단과 문제의 심각성에 따라 변경될 수 있습니다. 또한 사용자가 그러한 필요조건들을 준수하는 것이 정보 모델러에 대한 지원 확보에 중요합니다.
Java 클래스 파일을 소스 코드로 리버스엔지니어링할 수 있는 도구들을 쉽게 접할 수 있습니다. 그러나 소스 코드 디컴파일링은 법적으로 금지되어 있습니다. PTC는 디컴파일된 소스 코드를 변경하거나 기존 클래스 파일을 대체하는 방식으로 생성된 클래스 파일을 지원하지 않습니다.
기술 지원 부서에서 고객의 커스터마이징을 지원하기 위해서는 커스터마이징에 다음과 같은 언어들이 사용되어야 합니다.
커스터마이징 구현 시 특정 기능을 활성화하는 데 다른 프로그래밍 언어가 필요한 경우가 많습니다. 이는 기술적으로는 가능하지만, 기술 지원 부서에서는 발송된 Windchill 개발 제품 사용에 대해 제한적인 지원만을 제공합니다. 이런 기타 언어를 설치하거나 익히는 추가 절차 없이 기술 지원 부서에서 고객이 겪고 있는 문제를 재현할 수 있도록 하는 책임은 고객에게 있습니다. 지원되지 않는 커스터마이징의 예는 다음과 같습니다.
해당 소스 코드가 Windchill Customization 설치 시 제공되는 경우 기존 클래스를 수정할 수 있습니다. 대부분의 경우 리소스 번들에만 수정이 적용됩니다. 대규모 소스 파일이 고객에게 제공된 경우, 정보 모델러(IM) 개발자는 합리적인 범위내의 소규모 수정으로 국한시켜야 합니다. 소스 로직을 완전히 이해하는 사람이 코드를 조작해야 합니다. 원본 코드에 위배되는 변경을 가했을 때는 극히 제한된 지원만을 받을 수 있습니다. 또한 소스 파일에 주석을 달아서 어떤 변경이 있었는지를 명시해야 합니다.
예를 들어, 사용자가 WTExplorerFrame 클래스에 메뉴를 더하거나 삭제하고자 합니다. 이 작업은 손쉽게 할 수 있으며 지원받을 수 있는 커스터마이징입니다. 그러나 만약 소스 코드의 많은 부분이 수정되어 문서 탐색기 클라이언트의 로직이 완전히 바뀐 경우에는 기술 지원을 제공할 수 없습니다.
기술적 측면에서 볼 때, Windchill 코드베이스의 모든 클래스 파일을 커스터마이징 소스 코드로 쓰는 것이 가능하긴 하지만 Windchill 클래스 사용에는 몇 가지 제약이 있습니다. 클래스 사용에는 해당 클래스의 필드나 메소드에 대한 액세스 또는 클래스의 인스턴스 생성이 포함됩니다.
클래스를 사용하려면 클래스가 JavaDoc에 정의되어 있어야 합니다. 모든 클래스의 JavaDoc에는 Supported API 필드가 있습니다. 클래스가 커스터마이징 내에서 사용할 수 있도록 지원되려면 이 엔트리가 true여야 합니다. 클래스의 필드나 메소드가 사용되는 경우, 이 필드나 메소드의 Supported API 엔트리는 false여야 합니다. Supported API 엔트리 필드나 메소드가 없지만 클래스 자체가 지원되는 API인 경우에는 해당 필드나 메소드도 지원됩니다.
클래스 확장은 클래스 사용의 예외적인 경우입니다. 또한 지원되는 클래스 확장을 만들려면 JavaDoc에서 필드 Extendable: true로 상위 클래스의 확장 가능성을 표시해야 합니다. 이 확장된 클래스에도 Windchill 클래스 사용에 설명된 필요조건이 적용됩니다.
HTML 사용자 인터페이스의 사용 편의성을 높이기 위해 JavaScript를 사용할 수 있습니다. 기술 지원 부서에서는 복잡한 질의에 대한 해결책은 제공하지 않습니다. 다만, 오류가 Windchill 쪽에서 발생하는 경우 JavaScript와 Windchill 충돌을 조사하게 됩니다.