사물 형태는 물리적 자산 그룹에서 공유되며 속성, 서비스, 이벤트 및 구독으로 표현되는 일련의 특성을 제공합니다. 사물 형태는 모델의 객체 간 관계를 설명하는 구성에 사용하기에 가장 적합합니다. 사물 형태는 하나 이상의 사물 템플릿에서 상속될 수 있는 포함된 속성과 비즈니스 로직을 쉽게 재사용할 수 있게 해 줍니다. ThingWorx에서 모델은 사물 템플릿이 하나 이상의 사물 형태를 구현하는 것을 허용합니다. 이는 다중 상속이 있는 C++의 클래스 정의와 비슷합니다. 서비스가 상위 객체 정의에서 재정의를 허용하도록 명시적으로 정의한 경우 사물 형태에서 상속된 서비스의 비즈니스 로직을 재정의할 수 있습니다.

사물 형태를 변경하면 변경 사항이 사물 형태를 구현하는 사물 템플릿 및 사물에 전파되므로 간단하게 모델을 유지 관리할 수 있습니다.

사물 형태에 대한 사용 사례는 동일한 ERP 시스템을 사용하는 여러 제품 라인이 있는 경우입니다. 회사에 주거용 잔디 트랙터를 제조하는 부문과 상용 농기계를 제조하는 부문의 두 비즈니스 단위가 있다고 가정합니다. 잔디 트랙터 및 농기계는 공통 데이터나 동작이 없습니다. 그러나 둘 모두에 추적할 수 있는 ERP 자산이 있으며, 동일한 CRM 시스템의 고객 및 서비스 티켓 시스템 정보가 있습니다. 물리적 자산으로 이러한 인터페이스를 한 번만 구현하기 위해 사물 형태에 비즈니스 로직을 삽입할 수 있습니다. 예를 들어, ERP 시스템의 관련 데이터를 사물 형태로 표현되는 ERP 커넥터 사물로 가져오는 방법을 구현할 수 있습니다. ERP 커넥터 사물에는 ERP 시스템에 도달하는 방법(예: IP 주소), 이를 인증하는 방법(예: 기술 사용자 사용) 및 요청 응답을 처리하는 방법을 아는 구성 데이터가 있을 수 있습니다. ERP 커넥터 사물에서 서비스를 사용하여 요청 응답 기능을 구현해야 합니다. 그런 다음 응용 프로그램에 대해 사물 형태에서 요청 데이터를 가져오는 특정 함수를 정의할 수 있습니다. 사물 형태에는 속성(예: 위치 및 ERP 자산 ID)으로 표현되는 기본 데이터와 자산 관련 데이터를 가져오는 서비스(예: 내 열린 작업 요청서 가져오기, 내 작업 요청 내역 가져오기, 내 고객 권한 가져오기)가 있어야 합니다. 그러면 잔디 트랙터 및 농기계에 대한 사물 템플릿이 사물 형태의 기능을 상속할 수 있으며, 사물 형태에 캡슐화된 비즈니스 로직을 통해 ERP 데이터에 액세스할 수 있습니다.

확장자로 생성된 사물 형태는 ThingWorx Composer에서 생성된 것과 유사합니다. 사물 형태는 동일한 속성, 구성 매개 변수, 서비스 등을 통해 사물을 생성하는 데 사용되는 기본 템플릿입니다. Composer에서 사물 형태를 생성하는 것과 확장 프레임워크 내에서 생성하는 것의 차이는 서비스에 사용되는 언어와 해당 서비스의 표시 유형입니다.

Composer 템플릿:

Extension SDK 템플릿: