Java 확장을 8.x에서 9.x로 마이그레이션
Java가 지원되는 확장에만 마이그레이션이 필요할 수 있습니다. Java 확장의 마이그레이션은 ThingWorx 8.x에서 9.x로 업그레이드(9.x에서 9.x로의 업그레이드는 아님)하며 다음과 같은 경우에만 필요합니다.
• initializeEntity 및 cleanupEntity와 같은 수명 주기 이벤트를 구현한 경우
• 구현 내에서 로컬 상태를 유지하는 경우
• 다른 엔티티의 로컬 복사본(또는 하드 참조)가 있는 경우
ThingWorx 고가용성 클러스터링에서는 엔티티가 여러 서버에 있습니다. 이러한 정보는 서버 간에 동기화된 상태로 유지되어야 합니다. 변경이 발생하는 서버(변경 서버)와 변경이 동기화되는 서버(동기 서버)의 수명 주기는 약간 다릅니다. 변경 서버는 하나뿐이며, 클러스터의 모든 다른 서버는 동기 서버로 더티 엔티티를 다시 로드합니다. 변경 서버는 단순히 요청이 도달하는 서버이며, 특별한 구성 또는 상태가 없습니다.
새 확장 메타데이터 속성인
haCompatible이 추가되어 확장이 ThingWorx 고가용성 클러스터링과 호환되는지 여부를 확인할 수 있습니다. 자세한 내용은
ThingWorx 솔루션 패키징 및 배포 모범 사례 및
ThingWorx HA를 위한 플랫폼 설정을 참조하십시오.
수명 주기 API 변경
이제 ThingWorx 고가용성 클러스터링을 사용하려면 다음 수명 주기 API 메소드에 추가 매개 변수가 필요합니다. 변경 이유는 변경 서버와 동기 서버 간의 수명 주기 내 동작 차이 때문입니다. 변경 서버에서는 모든 논리를 수명 주기 이벤트에 대해 수행해야 합니다. 하지만 동기 서버에서는 이 논리의 하위 세트만 수행할 수 있습니다. 예를 들어, 초기화 동안 동기 서버에서 모든 상태를 설정할 이유가 없습니다. 상태는 공유되기 때문입니다.
ContextType 매개 변수를 사용하면 일부 논리의 발생 여부를 결정할 수 있습니다. ContextType이 NONE인 경우 이는 보조 작업이 아니며 모든 논리를 실행해야 함을 나타냅니다. ContextType을 서로 다른 동작을 트리거하는 STARTUP, SHUTDOWN, INSERT, UPDATE 또는 DELETE로 구분할 수도 있습니다.
이러한 변경으로 인해 컴파일 타임 오류가 생성됩니다. 단일 서버 수정의 경우 매개 변수를 메소드에 추가할 수 있으며 다른 변경이 필요하지 않습니다. 활성-활성 클러스터링과의 호환성을 위해 다음과 같이 변경합니다.
• initializeEntity()를 initializeEntity(contextType)로 복사합니다.
• cleanupEntity()를 cleanupEntity(contextType)로 복사합니다.
• initializeThing()를 initializeThing(contextType)로 복사합니다.
• startThing()를 startThing(contextType)로 복사합니다.
• processStartNotification()를 processStartNotification(contextType)로 복사합니다.
• stopThing()를 stopThing(contextType)로 복사합니다.
• cleanupThing()를 cleanupThing(contextType)로 복사합니다.
사물 엔티티의 아래 예에서 변경 서버가 초기화되면 계층 구조에서 전체 구성 테이블 업데이트가 수행되고 변경이 지속됩니다. 동기 서버에서 엔티티가 초기화되면 구성 테이블이 업데이트됩니다. 엔티티는 데이터베이스에 대해 이미 지속되고 있으므로 엔티티를 로드할 수 있습니다. 계층 구조를 탐색하거나 다른 논리를 수행할 필요가 없습니다.
public void initializeEntity(ContextType contextType) throws Exception {
_logger.trace("initializeEntity called on Thing {} with patch operation {} ", getName(), contextType);
if (!contextType.isSecondaryOperation()) {
updateConfigurationTableStructure(contextType, null,
ThingShapeUtilities.getConfigurationTableDataForInheritance(getThingTemplate(), getImplementedThingShapes()));
} else {
updateConfigurationTableStructure(contextType);
}
super.initializeEntity(contextType);
}
정리 작업에서는 동작이 유사합니다. 캐시 정보는 변경 서버에서 지워지지만 동기 서버에서는 상태가 공유되므로 지워지지 않습니다. 일반적으로 변경 서버에서 모든 작업을 수행하고, 동기 서버에서는 더 적은 작업을 수행합니다.
public void cleanupEntity(ContextType contextType) throws Exception {
super.cleanupEntity(contextType);
getInstanceShape().cleanup(contextType);
// reset cache
if (!contextType.isSecondaryOperation()) {
clearNonPersistentPropertiesFromCache();
clearLastPropertyValueCache();
}
if (isEnabled()) {
cleanupThing(contextType);
}
}
상태 유지
로컬 상태는 속성, 구성 테이블 또는 데이터 테이블에 없는 상태입니다. 서버 간에 사용할 수 있도록 로컬 상태를 공유 상태로 변경해야 합니다. 공유 상태는 Ignite 캐싱 레이어를 통해 달성됩니다. 확장의 경우 모든 상태를 속성 또는 구성 테이블에 저장하는 것이 좋습니다.
• 구성 테이블
구성 테이블은 데이터베이스에 저장되고 서버 간에 동기화됩니다. 따라서 서버 간 업데이트가 약간 지연됩니다. 구성 테이블은 모델 동기화의 일부이므로 동기화되면 동기 서버의 엔티티가 삭제되고 변경된 모델로 다시 생성됩니다. 따라서 전체 모델 업데이트보다 속성을 사용하는 것이 더 명확하고 효율적일 수 있습니다. 또한 지속 속성을 사용하여 재시작 사이에 상태 값을 저장할 수 있습니다.
• 속성
이제 모든 속성 값이 공유 상태로 저장됩니다. 이러한 값에 대한 업데이트는 캐시에 기록되면 서버 간에 즉시 수행됩니다. 지속 속성인 경우 성능을 위해 계속 캐시되고 데이터베이스에 기록되어 재시작 사이에 상태가 유지됩니다. 여러 사물 인스턴스 간에 상태 속성이 공통적이어야 하는 경우 상태 속성을 유지할 수 있는 데이터 사물을 만들 수 있습니다.
로컬 속성
속성에 대한 공유 상태를 사용해서는 안 되는 경우도 있습니다. 예를 들어, ConnectableThing에는 서버별로 연결 상태가 추적되는 isConnected 속성이 있습니다. ConnectableThings 연결 상태가 변경될 경우 각 서버에서 isConnected를 덮어쓰지 않도록 해야 합니다. 속성에 isLocalProperty 측면을 추가하면 이 로컬 상태가 달성될 수 있습니다. 이 측면은 지속이 아닌 속성에만 적용되며, 이 측면을 포함하는 지속 속성은 정상적으로 공유됩니다.
@ThingworxPropertyDefinition(
name ="isConnected",
description ="Flag indicating if connected or not",
baseType ="BOOLEAN",
aspects = {"isPersistent:false","isReadOnly:false","defaultValue:false","isLocalProperty:true"})
하드 참조 확인
분리는 다른 엔티티에 대한 하드 참조를 제거합니다. ThingWorx 고가용성 클러스터링에서 모델 동기화의 패치 적용 프로세스를 위해 시스템에서는 변경된 엔티티를 교환해야 합니다. 따라서 다른 엔티티에 대한 하드 참조를 캡슐화하는 엔티티가 있을 수 없습니다. 예를 들어 사물 수준에서 캐시된 사물 템플릿이 있는 경우 해당 템플릿이 변경되면 모든 서버에서 패치가 적용되어야 합니다. 이 템플릿에 대한 하드 참조가 있는 모든 사물은 중단됩니다. 따라서 모든 엔티티가 하드 참조에서 소프트 참조로 변경되어야 합니다. 참조가 필요하므로 플랫폼은 트리를 탐색해 참조를 가져옵니다.
예를 들어, 다음은 기본 사물 템플릿에 대한 참조가 있는 ThingTemplate 클래스입니다.
하드 참조 사용
// Parent thing template
privateThingTemplate _baseThingTemplate =null
...
@ThingworxExtensionApiMethod(since = {6,6})
publicThingTemplate getBaseThingTemplate() {
if(_baseThingTemplate ==null&& StringUtilities.isNonEmpty(getBaseThingTemplateName())) {
_baseThingTemplate = ThingTemplateManager.getInstance().getEntityDirect(getBaseThingTemplateName());
}
return_baseThingTemplate;
}
하드 참조를 _baseThingTemplate에 저장하므로 이로 인해 동기화 프로세스 패치 적용 시 문제가 발생합니다. 아래 예에서는 하드 참조가 소프트 참조로 분리되어 이름만 저장되고 필요한 경우 템플릿을 읽어들입니다.
//Note the hard reference is removed (local stored template _baseThingTemplate)
@ThingworxExtensionApiMethod(since = {6,6})
publicThingTemplate getBaseThingTemplate() {
ThingTemplate baseThingTemplate =null
if(StringUtilities.isNonEmpty(getBaseThingTemplateName())) {
baseThingTemplate = ThingTemplateManager.getInstance().getEntityDirect(getBaseThingTemplateName());
}
returnbaseThingTemplate;
}