Perfluorodecalin

Eclipse를 사용해 Thingworx Extension 개발하기

12 min read

How to develop custom extension in Thingworx Platform using Eclipse

Thingworx에서 개발하다 보면 추가 기능들에 대한 구체적이고 다양한 요구사항이 들어오고는 한다.
Thingworx Custom Extension을 개발하기 위한 Eclipse 세팅 방법을 설명하고, 커스텀 Extension 개발과 관련된 견해와 사설들을 뒤에서 좀 풀어보고자 한다.

일단 각설하고 전체적인 개발 순서를 먼저 알아보겠다.

Thingworx Custom Extension 개발 절차

  1. Eclipse에서 개발환경을 구축해야하므로, Eclipse를 설치한다.
  2. Eclipse Plugin for Thingworx Extensions를 버전에 맞게 다운로드 한다.
  3. Eclipse에 Plugin을 설치한다.
  4. Thingworx Extensions SDK를 버전에 맞게 다운로드한다.
  5. Thingworx Extensions SDK를 지정하여 Thingworx Extension 프로젝트를 생성한다.
  6. 생성하고자 하는 Entity를 지정하여 Extension을 개발 및 테스팅한다.
  7. 개발이 완료되면 패키지 버전 등의 메타데이터를 수정하고 빌드한다.
  8. 빌드된 Extension을 Thingworx에 Import하여 사용한다.

이클립스 설치에 대한건 건너뛰고, 실질적인 플러그인 설치와 SDK 세팅에 대해 알아보려 한다.
일반적으로 플러그인과 SDK의 버전은 혹시라도 문제가 발생하지 않도록 왠만하면 타겟 Thingworx의 버전을 맞춰주는 편이다.
Thingworx는 Composer 기능만 쓰면 차이가 드라마틱해보이지는 않지만 OOTB 내부적인 동작방식은 버전별로 차이가 있는지, 개발자 도구로 클라이언트단의 Mashup과 Event 등의 객체를 이리저리 써보려 할때 차이점을 꽤 느꼈다. 그 밖에도 버전별로 Fixed Issues in ThingWorx Platform 목록이 꽤 나오는걸 봐서라도 타겟버전 맞춰주자.

Eclipse Plugin for Thingworx Extensions 다운로드

PTC Support에서 버전에 맞는 Thingworx Release그룹을 선택하여 Eclipse Plugin for Thingworx Extensions zip 파일을 다운로드 받아 압축을 해제한다.

Eclipse에 Plugin 설치

Eclipse 실행 후 Help > Install New Software...메뉴를 선택하여 설치 창을 띄운다.

Add를 눌러 Add Repository화면에서 Local...을 클릭하여 이전 단계에서 다운로드 한 thingworx-eclipse-plugin-{version}.zip파일을 선택한다. (Group items by category 옵션 체크 해제)

ThingWorx Extension Builder을 선택하고 설치한 뒤 Eclipse를 재시작 한다. (설치 과정에서 신뢰나 동의 여부 물어볼 수도 있는데 전부 Accept 하여 넘긴다.)
설치 여부는 Help > Installation Details에서 ThingWorx Extension Builder가 추가되어있는 것으로 확인할 수 있다.

Thingworx Extensions SDK 다운로드

PTC Support에서 버전에 맞는 Thingworx Release그룹을 선택하여 Thingworx Extensions SDK zip 파일을 다운로드 받는다.

Thingworx Extension 프로젝트 생성

File > New > Project...를 선택하여 프로젝트 설치 창을 띄운다.
Thingworx를 검색하여 Thingworx 폴더를 확장하고 ThingWorx Extension Project를 선택한 후 Next를 클릭한다.

프로젝트 이름을 입력하고 Browse...를 눌러 이전 단계에서 다운받은 SDK를 선택한다.

⚠️ 본 글에서는 빌드 프레임워크는 Ant로 지정하겠다.


Vendor 이름, 패키지 버전 등을 수정할 수 있다. Finish를 클릭해 프로젝트를 생성한다.

Entity 생성

엔티티 생성을 위해서는 ThingWorx메뉴를 선택해 생성하고자 하는 엔티티 타입을 선택한다.

생성하고자 하는 위치를 선택하고, 엔티티 이름을 입력한다.
Finish를 클릭해 엔티티 생성을 완료한다.

Widget 생성

ThingWorx메뉴를 선택해 New Widget을 선택해 위젯 생성 창을 띄운다.
위젯 생성 창에서 새로운 위젯을 추가할 프로젝트를 선택 후 위젯 이름을 입력하여 Finish를 클릭해 위젯을 생성한다.

/ui 폴더 내부에 새로운 위젯 폴더가 생성되고, 위젯의 CSS, JS 파일이 함께 생성된다.

Extension 빌드

Extension 빌드는 Gradle, Ant 두가지 방식중 하나를 선택할 수 있고 프로젝트 생성시에 지정해야한다.
선택한 빌드 방식에 따라 빌드 방법이 달라진다.

Gradle Build

build.gradle를 우클릭 하고 Run As > Gradle Build를 선택하여 빌드한다.

And Build

build-extension.xml 을 우클릭 하고 Run As > Ant Build를 선택하여 빌드한다.

빌드 결과물

프로젝트 내의 build > distributions 경로 내부에 빌드된 Extension zip 파일이 생성된다.
빌드된 Extension zip 파일은 ThingWorx에 Import가 가능하다.
혹시 경로가 안보이는 경우에는, 프로젝트 새로고침(F5)이나 프로젝트 우클릭해서 디스크에서 다시 로드하기 등을 해보자.

그럼에도 불구하고 빌드 결과물이 보이지 않는 경우는 다시 빌드해보고, 빌드 에러난 경우에는 빌드 콘솔에서 Build Fail이 떠있을거니 확인해보자.
Extension 프로젝트에서는 내용물이 없는 필요없는 폴더라고 기본적으로 생성되는 폴더를 막 지우면 빌드 시에 해당 폴더를 찾지 못해 에러가 날 수 있다. 기본적으로 생성되는 폴더는 그냥 놔두는 편이 좋다.

기존에 개발된 Extension 프로젝트를 Load 하기

Thingworx Plugin이 설치된 상태에서 Extension을 로드해야한다.
프로젝트가 Thingworx Extension 프로젝트로 잘 열리는 경우는 그대로 그 환경에서 소스를 수정하거나 빌드하여 사용해도 된다.
다만 환경이 달라서 프로젝트가 열리지 않는 경우가 있는데 이 때는 아래의 절차대로 수행해보자.

  1. 프로젝트 파일 내의 .settings, build, .classpath, .project 폴더 및 파일을 제거한다.
  2. File > Import Projects from File System or Archive를 선택한다.
  3. Import 화면에서 Directory...를 클릭하여 프로젝트 루트폴더를 선택하고 Finish를 클릭한다.
  4. Project Explorer탭 상에서 프로젝트를 우클릭하여 Properties창을 띄우고 Project Nature을 메뉴에서 Add... 버튼을 클릭한다.
  5. ThingWorx를 검색하여 ThingWorx Extension Project Nature을 추가한 뒤 Apply and Close 버튼을 클릭하여 적용한다.
  6. 다시 Properties 창을 띄우면 Builders에 ThingWorx Extension Project Builder가 추가되어있고, 좌측 리스트에 ThingWorx Extension에 대한 설정 메뉴가 추가된 것을 확인할 수 있다.
  7. 좌측 리스트에서 ThingWorx Extension 메뉴로 진입하면, SDK Location is invalid 라고 되어있을 텐데 Browse...를 클릭하여 SDK를 지정하고 Package Version을 기입하여 환경 설정을 완료한다.

Custom Extension들을 개발해오며

사실 Custom Extension 개발을 남발하지 않는 것이 편하다..

어떤 기능이든 Thingworx 내에서 서비스적으로 구현 하거나, PTC에서 오피셜 하게 제공되는 Mail Extension같은 Extension들을 받아서 Import 해서 사용하는것이 PTC Technical Service를 받기도 수월할 뿐더러 유지보수 관점에서는 편리하지만(문제가 있으면 PTC TS로 넘기면 되니까!)
서비스적으로 구현해도 프로세스 복잡도가 지나치게 올라가서 기능 추적이 힘들고 유지보수가 너무 나빠지거나 외부 라이브러리가 필요한 경우 등등의 경우가 있을 수 있고,
이 경우 Custom Extension을 개발함으로써 해결이 쉬워지는 문제들은 분명히 있다.
장단점을 잘 저울질 해서 선택하길 바란다.

Custom Extension 개발 시에는 Technical Service나 Support쪽에 바랄 수 있는게 한정되어있음을 고려하자

당연하게도 Custom Extension에 대한 오너쉽은 개발한 쪽에 있기 때문에 개발과 테스트 중에 발생하는 문제들은 TS에 문의하면 서로 좀 난감하다. 코드리뷰 부탁하는 느낌이랄까..
애초에 TS쪽에서도 Custom 쪽은 문제해결이 힘들 수 있다고 밑밥을 까시는 편이기도 한 것 같고..
TS 쪽 입장을 이해하기 위해 노력해보자면, 고객사 외부에서 개발해서 TS쪽에 수월하게 개발중인 Extension 소스 제공이 가능하고 TS쪽에서도 문제 재현이 가능하면 그나마 다행인데 사용중인 Thingworx 자체도 많은 Custom이 이미 적용되어있어 기능이 연쇄적이라 재현이 힘들거나, TS에서는 문제 현상 재현이 안될 수도 있다. 또는 고객사 요구사항이라 보안 이슈가 있을 수도 있기 때문에 TS쪽에 소스 제공이 불가능 할 수도 있다. 이렇게 되면 TS는 더더욱 Custom Extension 문제를 봐주기 힘들어진다.
사실 PTC TS 쪽 뿐만이 아니라 같은 그룹의 개발자 간에도 Extension 개선 및 트러블슈팅을 위해 다시 프로젝트를 열어봤을 때 히스토리를 몰라서 난해한 경우들이 발생한다.
그렇기에 개인적인 경험으로는 단일 Extension의 기능 복잡도를 너무 많이 끌어올리지 않는게 유지보수 측면으로나, 트러블 슈팅 난이도를 줄이는 측면에서 좋은 것 같다.

그래프 뷰