플러그인을 구현할 때 개체를 캐시하거나, 백그라운드에서 가져오거나, 복제하는 등 특정 방법을 적용할 수 있습니다. 이러한 방법을 따르면 플러그인의 성능을 개선하고, 동시 실행 문제를 방지하고, Orchestrator 클라이언트의 응답성을 높일 수 있습니다.

개체 캐시

플러그인은 원격 서비스와 상호 작용할 수 있으며, 이러한 상호 작용은 서비스 쪽의 원격 개체를 나타내는 로컬 개체에 의해 제공됩니다. 플러그인의 성능 및 Orchestrator UI의 응답성을 높이려면 원격 서비스에서 매번 가져오는 대신 로컬 개체를 캐시하면 됩니다. 이 경우 모든 플러그인 클라이언트에 하나의 캐시를 사용하거나, 플러그인 사용자당 하나의 캐시를 사용하거나, 타사 서비스 사용자당 하나의 캐시를 사용하는 등 캐시 범위를 고려할 수 있습니다. 구현된 캐싱 메커니즘은 개체를 찾아서 무효화하기 위해 플러그인 인터페이스에 통합됩니다.

백그라운드에서 개체 가져오기

플러그인 인벤토리에 대용량 개체 목록을 표시해야 하지만 이러한 개체를 신속하게 검색할 방법이 없는 경우 백그라운드에서 개체를 가져올 수 있습니다. 예를 들어 fakeloaded의 두 가지 상태로 개체를 유지하여 백그라운드에서 개체를 가져올 수 있습니다. fake 개체는 생성하기가 매우 쉽고 인벤토리에 표시해야 하는 최소한의 정보(예: 이름 및 ID)를 제공한다고 가정해 보겠습니다. 이 경우 항상 fake 개체를 반환할 수 있으며, 실제로 모든 정보(실제 개체)가 필요한 경우 사용 중인 엔티티 또는 플러그인에서 load 메서드를 자동으로 호출하여 실제 개체를 가져올 수 있습니다. 사용 중인 엔티티의 작업을 예측하기 위해 fake 개체가 반환된 후 자동으로 시작하도록 개체 로드 프로세스를 구성할 수도 있습니다.

동시 실행 문제를 방지하기 위해 개체 복제

플러그인에 캐시를 사용하는 경우 개체를 복제해야 합니다. 요청하는 모든 엔티티에 항상 동일한 개체 인스턴스를 반환하는 캐시를 사용할 경우 원치 않는 결과가 발생할 수 있습니다. 예를 들어 엔티티 A는 개체 O를 요청하여 해당 특성과 함께 인벤토리에 개체를 표시합니다. 이와 동시에 엔티티 B는 개체 O를 요청하고 엔티티 A는 개체 O의 특성을 변경하는 워크플로를 실행합니다. 이 실행이 끝나면 워크플로에서 개체의 update 메서드를 호출하여 서버 쪽의 개체를 업데이트합니다. 엔티티 A와 엔티티 B가 개체 O의 동일한 인스턴스를 가져온 경우 엔티티 A는 변경 내용이 서버 쪽에 커밋되기 이전에도 엔티티 B가 수행한 모든 변경 내용을 인벤토리에 표시합니다. 정상적으로 실행되면 문제가 없지만 실행에 실패한 경우 엔티티 A에 대한 개체 O의 특성이 되돌려지지 않습니다. 이 경우 캐시(플러그인의 find 작업)에서 항상 동일한 인스턴스 대신 개체의 복제본을 반환한다면 사용 중인 각 엔티티에서 자체 복사본을 표시하고 수정하므로 적어도 Orchestrator 내에서의 동시 실행 문제를 방지할 수 있습니다.

다른 엔티티에 변경 내용 알림

캐시와 개체 복제를 동시에 사용하는 경우 문제가 발생할 수 있습니다. 가장 큰 문제는, 사용 중인 엔티티에서 표시하는 개체가 해당 개체에 사용 가능한 최신 버전이 아닐 수 있다는 점입니다. 예를 들어 엔티티에서 인벤토리를 표시하고 개체가 한 번 로드되었지만 이와 동시에 다른 엔티티가 일부 개체를 변경 중인 경우 첫 번째 엔티티에는 변경 내용이 표시되지 않습니다. 이 문제를 방지하기 위해 Orchestrator 플러그인 API에서 PluginWatcherIPluginPublisher 메서드를 사용하여 Orchestrator 클라이언트의 다른 인스턴스에서 변경 내용을 볼 수 있도록 일부 항목이 변경되었음을 알릴 수 있습니다. 이는 Orchestrator 클라이언트의 고유한 인스턴스, 즉 인벤토리 내 한 개체의 변경 내용이 인벤토리의 다른 개체에 영향을 주고 이러한 개체에 알림을 제공해야 하는 경우에도 적용됩니다. 알림을 주로 사용하는 작업으로는, 개체 또는 개체의 일부 속성이 인벤토리에 표시될 때 이러한 개체를 추가, 업데이트 및 삭제하는 작업이 포함됩니다.

언제든지 모든 개체를 찾을 수 있도록 설정

유형 및 ID만으로 개체를 찾을 수 있도록 IPluginFactory 인터페이스의 find 메서드를 구현해야 합니다. find 메서드는 Orchestrator를 다시 시작하고 워크플로를 재개하는 즉시 호출될 수 있습니다.

쿼리 서비스 시뮬레이션(없는 경우)

Orchestrator 클라이언트에서 특정한 경우 일부 개체를 쿼리하거나, 해당 개체를 트리 대신 목록 또는 테이블 등으로 표시해야 할 수 있습니다. 이는 플러그인에서 언제든지 일부 개체 집합을 쿼리할 수 있어야 함을 의미합니다. 타사 기술에서 쿼리 서비스를 제공하는 경우 이 서비스를 적용하고 사용해야 합니다. 그렇지 않으면 복잡성이 커지거나 솔루션 성능이 저하됨에도 불구하고 쿼리 서비스를 시뮬레이션할 수 있어야 합니다.

메서드 찾기에서 런타임 예외를 반환해서는 안 됨

플러그인 내에 검색을 구현하는 IPluginFactory 인터페이스의 메서드는 제어되거나 제어되지 않는 런타임 예외를 발생시켜서는 안 됩니다. 이는 워크플로가 실행 중일 때 비정상적인 유효성 검사 오류 실패를 초래할 수 있습니다. 예를 들어 워크플로의 두 노드 사이에서 첫 번째 노드의 출력이 두 번째 노드의 입력인 경우 find 메서드가 호출됩니다. 이때 런타임 예외로 인해 개체를 찾을 수 없는 경우에는 Orchestrator 클라이언트에서 유효성 검사 오류 외에 다른 정보를 얻을 수 없습니다. 로그 파일 내에서 얻을 수 있는 정보의 양은 플러그인이 예외를 기록하는 방식에 따라 달라집니다.