서비스 만들기, 구현 및 테스트
사물 서비스는 사물이 수행할 수 있는 기능입니다. 서비스는 ThingWorx Platform 및 매쉬업에서 내부적으로 사용되며 적절한 액세스 권한을 가진 모든 외부 소스에서 연결될 수 있습니다. 다음 ThingWorx 엔티티에 대해서만 서비스를 정의할 수 있습니다.
• 사물
• 사물 템플릿
• 사물 형태
• 리소스
• 인증자
서비스는 JavaScript, SQL 또는 Java를 통해 구현됩니다.
 |
Java는 확장에만 사용할 수 있습니다.
|
서비스는 URL, REST 클라이언트 솔루션 또는 ThingWorx의 다른 서비스를 통해 호출될 수 있습니다.
프로젝트 요구사항에 맞게 ThingWorx에서 해당 모델에 대한 사용자 정의 서비스를 만듭니다.
서비스 만들기 및 구현에 대한 모범 사례
서비스를 만들고 구현할 때 다음 모범 사례를 사용합니다.
• 서비스에 대한 이름 규약을 정의합니다. 다음 사항을 유념하십시오.
◦ 서비스에 논리적이고 의미 있는 이름 및 설명을 제공합니다.
◦ 서비스 전체에 표준 명칭을 사용합니다. 예를 들어, 서비스 이름 앞에 동사와 서비스에 대한 설명을 포함합니다. 다음은 동사의 몇 가지 예입니다.
|
동사
|
설명
|
|---|---|
|
가져오기
|
데이터베이스에서 값을 읽어들입니다.
|
|
설정
|
데이터베이스 엔트리의 값을 설정합니다.
|
|
질의
|
데이터베이스에서 레코드 그룹을 반환합니다.
|
|
추가
|
데이터베이스에 기록을 추가합니다.
|
|
업데이트
|
데이터베이스에서 기록을 업데이트합니다.
|
|
삭제
|
데이터베이스에서 기록을 삭제합니다.
|
|
유효성 검사
|
데이터베이스에서 기록의 유효성을 검사합니다.
|
|
제거
|
데이터베이스에서 기록을 제거합니다.
|
|
작성
|
데이터베이스에서 일련의 기록을 만듭니다.
|
|
가져오기
|
데이터를 데이터베이스로 가져옵니다.
|
|
내보내기
|
데이터베이스에서 데이터를 내보냅니다.
|
|
구문 분석
|
데이터를 구문 분석합니다.
|
예: 기록 데이터를 읽어들이는 서비스에는 History 대신 getHistory가 권장되는 이름입니다.
◦ 모호한 이름은 사용하지 마십시오.
◦ 가능한 경우 긴 서비스 이름을 사용하지 않도록 합니다.
자세한 내용은 이름 지정 엔티티 단원을 참조하십시오.
• 공통 속성 및 서비스를 가능하면 사물 형태인 단일 엔티티로 그룹화합니다.
• 가능한 경우 사물 형태에서 서비스를 구현합니다.
|
|
사물 형태를 사용하여 속성 및 서비스를 정의하는 것이 좋습니다. 사물 템플릿에 속성과 서비스를 정의하면 해당 정의를 사물 형태로 이동하기가 어렵습니다.
|
• 사용자 인터페이스, 비즈니스 로직 및 데이터 검색과 같은 다양한 레이어에 대한 서비스를 설계합니다. 서로 다른 레이어의 서비스는 책임이 서로 다릅니다. 다음 이미지는 다양한 레이어의 책임에 대한 예를 제공합니다.
• 서비스를 작성하는 동안 ThingWorx 코드 조각 라이브러리에서 사용 가능한 코드 조각을 재사용해 보십시오. 코드 조각을 사용하는 방법을 모르는 경우 서비스에서 해당 코드 조각을 사용하기 전에 테스트합니다.
• 출력을 JSON으로 설정하여 서비스를 생성하는 동안 다음 사항에 유의하십시오.
◦ 속성의 값이 null 또는 undefined인 경우 결과에 속성이 반환되지 않습니다.
예를 들면, 다음과 같습니다.
var test = {
test1: "aaa",
test2: 123,
test3: null,
test4: undefined
};
var result = test;
test1: "aaa",
test2: 123,
test3: null,
test4: undefined
};
var result = test;
출력: {"test1": "aaa", "test2": 123}
◦ 속성이 JSON 객체이고 null로 설정된 경우 결과에 반환됩니다.
예를 들면, 다음과 같습니다.
var test = {
test1: "aaa",
test2: 123,
test3: null,
test4: undefined,
"line_categories": [ null ]
};
var result = test;
test1: "aaa",
test2: 123,
test3: null,
test4: undefined,
"line_categories": [ null ]
};
var result = test;
출력: {"test1": "aaa", "test2": 123, "line_categories": [ null ]}
• 서비스를 완료하는 데 시간이 오래 걸리는 경우 사용자가 서비스를 동시에 여러 번 트리거할 수 없는지 확인합니다.
• 서비스가 매쉬업의 이벤트 트리거를 기반으로 하는 경우 ServiceInvokeCompleted 이벤트를 사용하여 솔루션의 데이터 흐름을 허용합니다.
• 매쉬업의 데이터를 새로 고치려면 자동 새로 고침 위젯 또는 GetProperties 서비스를 사용하는 것이 좋습니다.
매쉬업이 GetProperties 서비스를 사용하고 브라우저가 WebSocket을 지원하는 경우 브라우저는 서버에서 업데이트된 속성의 값을 실시간으로 자동으로 받습니다. 이 경우 자동 새로 고침 함수를 사용할 필요가 없습니다. 이 기능은 서비스 속성 패널에서 새 값을 이용할 수 있을 때 자동 업데이트 확인란을 선택한 경우에만 사용할 수 있습니다.
자동 새로 고침 함수를 사용 중인 경우 시스템에 부담을 주지 않기 위해 자동 새로 고침 함수를 최소 15초로 설정하는 것이 좋습니다.
| | 서버측 지연 서비스는 다른 서비스 차단을 유발할 수 있으므로 사용하지 마십시오. 이로 인해 솔루션이 충돌할 수 있습니다. |
• 런타임에 간단하게 변환하려는 경우 서비스 대신 표현식 위젯을 사용하는 것이 좋습니다.
예를 들어, 온도를 °C로 표시하고 사용자가 온도를 °F로 볼 수 있게 하려면 표현식 위젯을 사용합니다.
• 최종 사용자에게 오류가 발생할 가능성을 방지하기 위해 코드에 검사 기능을 추가합니다.
예를 들어, 코드에 두 개의 입력 매개 변수가 실행되어야 하는 경우 서비스가 실행될 때 이러한 입력 매개 변수가 null이 아닌지 확인하는 검사를 만듭니다.
• 솔루션이 로컬리제이션되고 UI 요소에 서비스 결과에 따라 동적으로 변경되는 텍스트가 있는 경우 매쉬업에 표시될 서비스의 텍스트 값을 하드 코딩하지 않아야 합니다. 이는 텍스트를 반환하는 서비스의 결과를 로컬리제이션해야 하기 때문입니다. 이렇게 하면 나중에 UI 텍스트를 유지하고 수정하기가 더 쉬워집니다.
• 사용자 정의 서비스를 만들 때 이 서비스를 호출할 수 있는 권한이 필요한 사용자 또는 사용자 그룹을 결정합니다. 자세한 내용은 표시 유형 및 권한을 사용하여 ThingWorx Platform에 작성된 솔루션 보안을 참조하십시오.
• 서비스를 실행하면 고스트 엔티티가 작성될 수 있습니다. 고스트 엔티티는 ThingWorx Composer가 아닌 코드/스크립팅을 통해 동적으로 작성됩니다. 고스트 엔티티를 작성하는 것은 좋지 않은 방법입니다. 자세한 내용은 고스트 엔티티 생성 및 삭제를 참조하십시오.
• ThingWorx Platform의 기본 스크립트 시간 제한 설정은 30초입니다. 스크립트가 기본 설정보다 길게 실행되면 ThingWorx Platform에서 실행을 종료합니다. ThingWorx 관리자는 platform-settings.json 파일의 기본 설정 섹션에서 스크립트 제한 시간을 구성할 수 있습니다.
서비스 테스트를 위한 모범 사례
서비스를 테스트할 때 다음 모범 사례를 사용합니다.
• 서비스를 빌드할 때 점진적으로 테스트합니다. 적절한 경우 스크립트 로거 메시지를 사용합니다.
| | 무한 루프가 있는 서비스는 ThingWorx 서버를 중단시킬 수 있습니다. |
• 서비스를 테스트하는 동안 로그에서 오류 메시지를 확인합니다. 이는 구독 서비스에 특히 유용합니다. 다음 로그 파일이 유용합니다.
◦ ErrorLog.log – 오류에 대한 자세한 스택 추적을 제공합니다.
◦ ScriptErrorLog.log – 서비스 컨텍스트 정보(스택 오류 줄 번호)를 제공합니다.
LoggingSubsystem 하위 시스템의 구성 탭에서 스크립트 스택 추적 사용 확인란을 선택한 경우에만 이 파일에 오류가 기록됩니다.
| | 위 파일은 ThingworxStorage/logs 폴더에서 사용할 수 있습니다. 이러한 파일을 읽으려면 ThingWorx 서버에 액세스해야 합니다. |
• 서비스가 매쉬업에서 호출되면 Composer 및 매쉬업에서 해당 서비스를 테스트합니다.
• 서비스를 실행하는 데 사용자 입력이 필요한 경우 유효성 검사기 함수를 사용할 수 있습니다.
• 브라우저에서 사용할 수 있는 개발자 도구를 사용하여 서비스 결과를 검사합니다. 이는 매쉬업에서 실행되는 서비스 시퀀스를 디버깅하려는 경우에 유용합니다. 이 도구는 서비스 결과를 해당 실행의 컨텍스트에서 표시합니다.
팁
• 서비스를 검색하려면 편집 모드에서 엔티티를 열지 마십시오. 엔티티 이름 왼쪽에 있는 미리 보기 링크를 사용하여 보기 모드에서 엔티티를 엽니다.
기타 고려 사항
• 보안 - 보안을 강화하려면 서비스 재정의를 사용하여 ThingWorx Platform에서 사용 가능한 중요 서비스에 대한 권한을 거부합니다.
• 업데이트 - 좋은 코딩 방법을 사용하고 대형 모놀리식 서비스는 만들지 마십시오.
• 동시성 패턴 - ThingWorx 사물 서비스는 응용 프로그램 엔진에 의해 분리되어 실행되지 않습니다. 따라서 한 서비스에서 수행된 사물 모델 속성 변경은 동시에 실행 중인 모든 다른 서비스에 즉시 표시됩니다. 두 서비스가 동일한 속성을 동시에 쓰려고 시도하는 경우 두 쓰기 작업이 모두 수행됩니다. 속성 값은 마지막으로 실행된 상태에 관계없이 처리되며 쓰기 작업이 서버로 제출된 순서와 다를 수 있습니다. 실제로 ThingWorx Platform 내 대부분의 데이터 및 리소스에 대한 동시 액세스는 마지막 쓰기 우선 방식으로 동작합니다. 응용 프로그램 개발자와 설계자는 응용 프로그램을 작성할 때 이러한 동작을 고려해야 합니다.