개요

모든 서비스에서 중요한 고려 사항은 기능 수행에 필요한 상태를 관리할지 여부와 그 방법은 매우 중요합니다. 이 문서에서는 Vantiq 플랫폼이 제공하는 서비스 상태 관리 지원 기능과 그 활용 사례를 살펴보겠습니다.

관련된 문서

상태 저장 서비스에 대한 직접적인 경험을 얻을 수 있습니다. 상태 저장 서비스 튜토리얼 그리고 협력을 통해 협업 소개   고급 협업 튜토리얼. 이러한 기술이 어떻게 적용되는지에 대해서도 읽을 수 있습니다. GenAI 에이전트.

무국적 서비스

상태 비저장 서비스는 작동 과정에서 메모리에 상태를 저장하지 않습니다. 즉, 서비스에서 조작하는 모든 상태는 애플리케이션 데이터 모델에 하나 이상의 리소스 유형을 통해 리소스 인스턴스로 저장되어야 합니다. 서비스는 영구 데이터 모델에 대한 모든 동시 액세스를 관리할 책임이 있습니다. 관련 섹션을 참조하세요. 지속적인 상태 관리 자세한 내용은 다음과 같습니다. 이 옵션은 가장 간단한 것처럼 보일 수 있지만, 가장 기본적인 서비스 외에는 일반적으로 권장되지 않습니다. 특히 영구 상태를 관리하기로 선택한 경우, 서비스의 확장성(또는 확장 불가능성)을 신중하게 고려해야 합니다.

상태 저장 서비스

상태 저장 서비스는 작업의 일부로 관리할 메모리 내 상태(하나 이상의 유형으로 정의됨)를 선언합니다. 상태는 메모리에 저장되므로 리소스 인스턴스 액세스와 관련된 오버헤드 없이 이벤트 처리 또는 프로시저 실행 중에 사용할 수 있습니다. 상태 저장 서비스는 두 가지 데이터 액세스 패턴을 지원합니다. 글로벌   분할 된 여기에 표시된대로 :

VAIL을 사용하여 상태 저장 서비스를 선언할 수 없습니다. 이를 위해서는 다음을 사용해야 합니다. 서비스 빌더 위에 표시된대로.

주어진 상태 저장 서비스는 필요에 따라 이러한 접근 방식 중 하나 또는 둘 다를 사용할 수 있습니다. 이 메모리 내 상태에 대한 모든 동시 액세스를 관리하는 것은 서비스의 책임입니다. 관련 섹션을 참조하십시오. 메모리 내 상태 관리 자세한 내용은.

글로벌 상태

서비스에 전역 상태가 있는 경우, 런타임에 해당 서비스의 모든 인스턴스와 연결된 이 상태의 단일 사본이 존재합니다. 이 상태의 정확한 위치는 정의되어 있지 않지만, 시스템은 사본이 하나만 존재하도록 보장합니다. 전역 상태의 구조는 전역 상태 선언을 통해 정의됩니다. 유형. 이 유형의 속성은 다음과 같이 사용할 수 있습니다. 암묵적으로 정의된 변수.

이러한 상태 변수는 "전역"으로 선언된 프로시저에서만 액세스할 수 있습니다. 절차 선언). 서비스에 글로벌 상태만 있는 경우 이를 글로벌 서비스라고 하며 모든 프로시저는 암묵적으로 글로벌로 선언됩니다.

분할된 상태

서비스에 분할된 상태가 있는 경우, 데이터는 여러 파티션에 분산됩니다. 데이터 분할의 목적은 해당 상태를 동시에 처리할 수 있도록 하는 것입니다. 이 모델은 분산 데이터베이스에서 사용하는 모델과 동일합니다. 서비스 상태를 분할하면 Vantiq 클러스터 구성원 간에 상태를 나누고 각 파티션에 독립적으로 액세스할 수 있습니다. 전역 상태와 마찬가지로, 시스템은 분할된 상태에 액세스해야 하는 프로시저가 대상 파티션과 연결된 인스턴스에서 실행되도록 적절하게 라우팅되도록 합니다. 전역 상태와 달리, 분할된 상태는 두 가지 액세스 패턴을 지원합니다.

• 단일 파티션 - 단일 파티션 프로시저를 호출할 때마다 정확히 하나의 파티션에서 실행됩니다. 어떤 파티션이 실행될지는 제공된 "파티셔닝 키"에 따라 결정되며, 이는 관례적으로 프로시저의 초기 매개변수. 이 키는 일반적으로 파티션 내의 특정 값에 액세스하는 데에도 사용됩니다(참조 인메모리 상태 관리 상세 사항은).
• 다중 파티션 - 다중 파티션 프로시저의 각 호출은 다음을 실행합니다. 모든 파티션의 (잠재적으로 동시에). 이러한 절차는 일반적으로 초기화 또는 데이터 전송과 같은 다양한 정리 작업을 수행하는 데 사용됩니다. 메모리 내 상태)에 지속적 상태직접 실행하면 처리 블록을 통해 점진적으로 처리할 수 있는 일련의 결과가 반환됩니다.

분할된 상태의 구조는 분할된 상태의 선언에 의해 정의됩니다. 유형. 이 유형의 속성은 다음과 같이 사용할 수 있습니다. 암묵적으로 정의된 변수. 이러한 상태 변수는 단일 또는 다중 파티션으로 선언된 프로시저에서만 액세스할 수 있습니다. 절차 선언). 서비스에 분할된 상태만 있는 경우 해당 서비스의 모든 프로시저는 암묵적으로 단일 파티션으로 선언됩니다.

무국적 절차

때로는 상태 접근이 필요 없는 프로시저를 상태 저장 서비스의 일부로 정의하는 것이 유용합니다. 이렇게 하면 프로시저 사용이 간소화되고 서비스 상태와 관계없이 사용할 수 있는 "유틸리티" 프로시저를 생성할 수 있습니다. 이는 다음을 사용하여 수행됩니다. 무국적 절차 수정자 절차를 정의할 때.

상태 초기화

선언된 상태 유형의 모든 속성(전역 및 분할 모두)에는 선언된 유형에 따라 값이 암묵적으로 할당됩니다.

• Object – 빈 Object 예.
• 사용자 정의 유형 - 빈 Object 예.
• Map – 다음을 사용하여 생성된 인스턴스 동시.맵().
• Value – 다음을 사용하여 생성된 인스턴스 동시 값().
• Integer – 가치 0.
• Real – 가치 0.0.
• 기타 모든 VAIL Scalar – 값 null.

속성 생성을 넘어 사용자 지정 초기화를 수행하기 위해 상태 저장 서비스는 전역 상태와 분할 상태 모두에 대한 초기화자를 가질 수 있습니다. 이러한 초기화자는 다음과 같은 특징을 가진 "잘 알려진" 프로시저입니다.

• 그들은 고정된 이름을 가지고 있습니다 – initializeGlobalState   initializePartitionedState. 각각의 동작은 서비스 상태가 초기화되는 경우에만 허용됩니다.
• 그들은해야합니다 PRIVATE 절차.
• 매개변수가 없어야 합니다.
• 초기화 프로그램은 명시적인 상태 접근 제한자를 요구하지 않습니다. 만약 상태 접근 제한자가 제공되는 경우, 전역 초기화 프로그램은 "global"로, 분할 초기화 프로그램은 "multi partition"으로 표시되어야 합니다.
• 이는 시스템에 의해 암묵적으로 호출될 수 있습니다. 지원 명시적으로 호출되어야 합니다.

시스템은 연관된 상태를 생성하거나 재생성해야 할 때마다 초기화 프로그램을 자동으로 호출합니다. 예를 들어, 분할된 상태 유형이 변경되어 분할된 상태가 무효화되면 시스템은 해당 상태를 재생성하고 분할된 초기화 프로그램을 실행합니다.

예정된 절차

상태 저장 서비스는 다음을 선언할 수 있습니다. 예약 리소스 인스턴스의 상태를 유지하거나 계산 중인 통계를 재설정하는 등 주기적인 백그라운드 작업을 수행하는 데 도움이 되는 프로시저입니다. 이는 프로시저 선언의 일부로 스케줄링 간격을 지정하여 수행됩니다. 지원되는 최소 간격은 다음과 같습니다. 1 minute 그리고 최소 증가량은 1 minute. 예약된 프로시저의 실행은 정렬됩니다. 즉, 모든 호출은 매시 정각에 시작하여 거기에서 오프셋됩니다(예: 10분 간격은 0, 10, 20, 30,…을 의미하고 15분 간격은 0, 15, 30,…을 의미함).

예정된 절차에는 실행 시간 제한이 적용되지 않습니다. 그러나 다음 것 절차의 호출은 다음까지 발생하지 않습니다. current 호출이 완료됩니다. 예를 들어, 10분마다 실행되도록 예약된 프로시저가 완료까지 11분이 걸리면 0, 20, 40, 0 등의 순서로 실행됩니다. 이는 중복 실행을 방지하기 위한 것입니다. 이는 스케줄러가 프로시저를 호출할 때만 적용됩니다. 예약된 프로시저가 다른 컨텍스트에서 호출되는 경우, 표준 제어가 적용됩니다.

서비스 복제

상태 저장 서비스는 관리하는 상태에 대한 내결함성을 제공하기 위해 "복제"될 수 있습니다. 이는 클러스터의 두 개 이상의 멤버에 쓰기 작업을 복제함으로써 수행됩니다. 이렇게 하면 한 멤버에 장애가 발생하더라도 나머지 멤버를 통해 동일한 데이터 사본을 사용할 수 있습니다. 복제는 투명하게 이루어지며 읽기 의미 체계에 영향을 미치지 않습니다. 주어진 쓰기 작업은 모든 대상에 성공적으로 복제될 때까지 완료된 것으로 간주되지 않습니다. 데이터를 읽는 사람은 읽기 요청 이전에 완료된 쓰기 작업의 영향을 볼 수 있습니다.

데이터의 "복제본" 수는 서비스의 "복제 계수"에 따라 결정됩니다. 복제 계수(RF)가 1(기본값)이면 데이터 인스턴스(기본 인스턴스)가 하나뿐이므로 서비스가 복제되지 않음을 의미합니다. 값이 2 이상이면 여러 클러스터 멤버에 저장된 데이터 사본이 여러 개 있음을 나타냅니다. 장애가 발생하면 시스템은 장애가 해결될 때까지 데이터의 보조 사본 중 하나를 사용하도록 자동으로 전환합니다. 이 전에 다른 장애가 발생하면 시스템은 다른 데이터 사본이 있다고 가정하고 다시 전환을 시도합니다. 일반적으로 시스템은 데이터 손실 없이 (RF-1) 동시 장애에서 복구할 수 있습니다.

서비스의 유효 RF는 해당 서비스가 실행 중인 클러스터의 크기에 따라 제한됩니다. 예를 들어, 멤버가 3명인 클러스터에서 복제된 서비스의 유효 RF는 3을 초과할 수 없습니다(더 높게 설정하더라도).

RF를 다음보다 큰 값으로 설정할 이유는 거의 없습니다. 2. RF의 2 모든 클러스터 장애의 99.95%에서 서비스 상태가 유지되도록 합니다. 중요한 것은 클러스터의 롤링 재시작(예: 새 버전의 Vantiq 플랫폼 설치 시)에도 상태가 유지된다는 것입니다. 이 시점을 넘어서면 추가 오버헤드는 일반적으로 이로 인한 이점을 상쇄하지 못합니다. 예를 들어, RF를 2에서 3으로 높이면 복제 중 장애 발생 가능성이 두 배로 증가하고 처리량이 가장 느린 복제본 수준으로 제한됩니다.

시스템은 복제 사용을 최대한 투명하게 만들려고 노력합니다. 하지만 몇 가지 "모범 사례"를 염두에 두어야 합니다.

• 다음과 같이 입력된 상태 속성만 Map or Value 복제됩니다. 다른 유형의 속성이 존재할 수 있지만, 실패 시 해당 값은 손실됩니다.
• 상태 속성에 "직접 할당"한 결과는 복제될 수 없습니다. 따라서 상태 초기화 프로그램 외부에서는 이러한 작업을 피해야 합니다. 예를 들어, 상태 속성에서 모든 키를 제거하려면 Map 예를 들어 다음을 사용해야 합니다. myMap.clear() 하지 myMap = Concurrent.Map().

협력

Vantiq 서비스가 이벤트나 프로시저 호출에서 발생한 데이터를 상태에 기록하여 사용자에게 제공하는 것은 확실히 가능하지만 서비스가 데이터를 사용하여 중요한 상황을 인식하고 조치를 취하는 경우 훨씬 더 강력합니다. 동작 결과적으로, 이러한 동작에는 GenAI 에이전트(또는 다른 서비스)가 서로, 사용자와 정보를 교환하거나 여러 사용자의 동작을 조정하는 작업이 포함될 수 있습니다. 몇 가지 예를 들면 다음과 같습니다.

• 서비스에서 기계 고장을 감지할 수 있지만, 수리 작업에는 기계를 실제로 수리할 수 있는 기술 전문가와의 협력이 필요합니다. 서비스는 상황에 맞는 제안 및 권장 사항과 기계 상태에 대한 시의적절한 정보를 제공할 수 있지만, 수리 시간과 비용을 최소화하기 위해서는 기술 전문가의 전문 지식이 필수적입니다.
• 카지노에서 고객을 모니터링하는 애플리케이션에서 우수 고객을 "경쟁"하고 충성도를 높이는 데 있어 플로어 매니저는 핵심적인 협력자입니다. 플로어 매니저는 고객을 직접 확인하고 제안된 경쟁 상품이 고객에게 호평을 받을지 여부를 쉽게 판단할 수 있습니다. 플로어 매니저가 고유한 문제점을 발견하는 경우, 애플리케이션에서 생성된 제안을 재정의하여 고객의 경험을 최적화할 수 있습니다.
• 환자의 생명 통계를 모니터링하는 담당자는 해당 환자의 치료에 대한 권장 사항을 제시할 수 있지만, 해당 권장 사항이 효과적인지 확인하기 위해 의사와 다른 분야(예: 약물 상호 작용)를 전문으로 하는 담당자와 협력해야 합니다.

이 모든 경우에서 협업 활동은 특정 애플리케이션 특정 "엔터티"에 대한 정보를 포함하며, 비교적 장기간에 걸쳐 이루어질 수 있습니다. Vantiq는 실시간 비즈니스 애플리케이션 서비스와 사용자 간의 협업, 그리고 애플리케이션 사용자 간의 협업 개발 및 운영을 간소화하는 광범위한 기능을 제공합니다.

협업 상태 속성

서비스가 협업을 관리할 것이라고 결정했다면 첫 번째 단계는 서비스의 정의입니다. 협업 상태 속성. 이들은에서 발견됩니다 주 정부 의 섹션 구현 탭 여기에 표시된 대로 서비스 빌더에서:

엔터티 및 협력자 역할

역할은 협업에서 각 참여자의 책임을 식별하는 데 사용됩니다. 두 가지 역할이 있습니다.

• 엔터티 역할 – 각 활동의 영향을 받는 도메인 모델 엔터티를 나타내는 객체에 바인딩됩니다. 관례적으로 엔터티 역할은 협업 실행의 영향을 받는 엔터티를 나타냅니다. 런타임 시 객체는 협업이 실행되는 실제 엔터티 인스턴스(즉, 엔터티)를 식별하는 엔터티 역할에 바인딩됩니다.
• 협력자 역할 – 각 활동 실행을 담당하는 실제 사용자에게 바인딩됩니다. 각 협업자 역할은 해당 역할에 할당된 사용자의 책임 집합을 해당 역할이 참여하는 활동의 형태로 암묵적으로 식별합니다.

엔티티 역할과 협업자 역할은 모두 협업을 관리하는 서비스에 의해 정의됩니다. 역할이 정의되면 해당 서비스의 모든 이벤트 핸들러에서 해당 역할을 사용할 수 있습니다.

엔터티를 사용하여 협업 설정

협업과 관련된 작업을 수행할 때 서비스가 먼저 해야 할 일 중 하나는 "설정"입니다. 어느 협업 인스턴스가 사용해야 합니다. 일반적인 방법 중 하나는 엔터티의 ID로 시작하여 이를 "외래 키"로 사용하여 올바른 협업 인스턴스를 찾거나 새 인스턴스를 만드는 것입니다. 이 작업은 다음을 사용하여 프로그래밍 방식으로 수행할 수 있습니다. 엔터티 역할 절차 또는 협업 구축 시각적 이벤트 핸들러의 활동 패턴입니다. 이러한 방식으로 엔터티를 사용할 경우, 현재 서비스에서 생성된 협업 인스턴스만 고려됩니다. 다른 협업은 무시됩니다. 더 공식적으로 말하자면, 각 서비스는 자신이 관리하는 협업을 "소유"하고 엔터티 역할은 정의하는 서비스로 "범위가 지정"된다고 합니다.

이름이 지정된 대화

중개인 협업에 참여하는 사용자는 협업 인스턴스의 일부로 대화 상태를 관리할 수 있어야 합니다. 이러한 이유로 각 협업 인스턴스에는 해당 인스턴스의 기본 대화가 있습니다. 협업 ID서비스가 두 개 이상의 대화에 참여해야 하는 경우 사용자는 추가 대화 이름을 선언할 수 있습니다. 이러한 대화 이름은 다음에서 사용할 수 있습니다. ActiveCollabsStartConversation 순서시각적 이벤트 핸들러에서 제출프롬프트, 답변질문   GenAI 흐름 이러한 대화에 참여하도록 활동 패턴을 구성할 수 있습니다. 또한 다음을 호출할 때도 사용할 수 있습니다. GenAI 절차.

대화 상태 수명 주기는 대화가 생성된 협업 인스턴스에 해당합니다. 새 협업이 열리면 시스템은 참조된 대화를 시작합니다. 대화 기억 서비스. 협업이 데이터베이스에 기록되면 시스템은 현재 대화 상태를 함께 기록합니다. 협업이 데이터베이스에서 로드되면 시스템은 필요한 경우 대화 상태를 재설정합니다. 협업이 종료되면 시스템은 대화를 종료합니다. 대화 기억 서비스를 제공하고 닫힌 인스턴스에서 모든 대화의 최종 상태를 기록합니다.

쓰기 빈도

협업은 서비스 상태 내에서 완전히 업데이트되고 관리됩니다. 하지만 장기 실행 협업의 경우, 서비스 상태가 너무 커지지 않도록 일정 간격으로 결과를 데이터베이스에 저장하는 것이 유용할 수 있습니다. 결과를 유지하는 것은 이전 협업의 감사 로그 역할도 할 수 있습니다. 쓰기 빈도는 서비스가 메모리 내 협업 상태를 데이터베이스에 유지하는 간격을 결정합니다. 기본적으로 서비스는 다음 주기마다 협업 상태를 유지합니다. 5 분.

협업 관리

서비스 상태

협업 역할 또는 대화를 정의하면 협업 서비스 상태 및 협업 관리 절차가 생성됩니다(다음 중 하나를 사용). 협업 관리 VEH의 활동 패턴도 이를 트리거합니다. 협업 상태는 두 개의 분할된 상태 속성으로 관리됩니다.

• ActiveCollabs (Map[문자열, ArsCollaboration]) – 협업 ID에서 연관된 협업 인스턴스로의 매핑입니다.
• CollabIdsByEntity (맵[문자열, 문자열]) – 엔터티 ID에서 해당 협업 ID로의 매핑(사용됨) 협력 설립)

협업 인스턴스에는 다음과 같은 속성이 있습니다.

• id – 협업의 고유 식별자입니다. 고유 ID는 협업이 처음 생성될 때 시스템에서 할당합니다. 변수 collaborationId 모든 작업에 대한 구성 매개변수로 사용할 수 있습니다.
• name – 협업의 이름(기본적으로 이벤트 핸들러 생성의 이름이 됨).
• 지위 – 문자열 값 중 하나로 표현되는 협업의 현재 상태: 활동적인, 완료, 실패한.
• 엔티티 – 엔터티 역할과 현재 엔터티 역할에 할당된 객체를 식별하는 객체입니다. 키는 엔터티 역할 이름이고 값은 역할의 현재 할당입니다.
• 공동 작업자 – 현재 협업 역할과 각 역할에 할당된 사용자를 식별하는 객체입니다. 키는 협업자 역할 이름이고 값은 역할의 현재 할당입니다. collaborators 속성은 참여 협업자의 현재 스냅샷을 나타냅니다. 참여자는 협업 실행 과정에서 변경될 수 있습니다.
• 대화 – 활성 대화를 식별하는 객체입니다. 키는 대화 "이름"이고 값은 다음 속성을 가진 객체입니다.
  • id – 대화 ID
  • 상태 – 대화의 현재 상태
  • 속성 – 대화의 속성
• 결과 – 여러 활동에서 집계된 결과입니다. 예를 들어, 위치 추적 활동은 도착한 사용자 목록과 추적된 다른 모든 사용자의 현재 위치 목록을 저장합니다.

안내

서비스 상태 외에도 다음과 같은 협업 관리 절차가 서비스에 추가되었습니다.

모든 경우에 해당 절차는 현재 서비스가 "소유한" 협업 인스턴스에서만 작동합니다.

공공 절차

• ActiveCollabsCloseAll() – 메모리에 있는 모든 협업을 데이터베이스에 유지하고 모든 활성 협업(메모리에 없었던 협업 포함)의 상태를 즉시 업데이트합니다. 완료.
• ActiveCollabsGetActive(): system.collaborations ARRAY – 모든 활성 협업 인스턴스를 반환합니다. 여기에는 현재 캐시에 없는 영구 인스턴스도 포함됩니다.
• ActiveCollabsGetById(collaborationId String REQUIRED, resultType String, allowInactive Boolean): Any – 주어진 ID로 지정된 협업을 가져옵니다. 해당 협업이 없으면 "null"을 반환합니다. 기본적으로 전체 협업 인스턴스를 반환합니다. 결과 유형 매개변수를 사용하여 특정 협업 속성을 요청할 수 있습니다. 비활성 협업 인스턴스를 요청하는 것은 오류입니다. 비활성 허용 가  true.
• ActiveCollabsUpdateStatus(collaborationId String REQUIRED, status String REQUIRED) – 협업 상태를 지정된 값으로 업데이트합니다. 이는 다음 중 하나여야 합니다. 완료 or 실패한.
• ActiveCollabsWriteAll() – 메모리에 있는 각 협업을 데이터베이스에 저장합니다. 쓰기 프로시저는 5분마다 자동으로 실행되도록 예약됩니다. 업데이트 쓰기 빈도 서비스는 쓰기 프로시저가 실행되는 간격을 수정합니다.

개인 절차

• ActiveCollabsGenerateId(): String – 새로운 협업 ID를 생성합니다.
• ActiveCollabsGetByEntityId(entityId String REQUIRED, entityRoleName String REQUIRED): system.collaborations – 지정된 엔터티와 연관된 활성 협업 인스턴스를 반환합니다. null 존재하지 않는 경우.
• ActiveCollabsGetCached(activeOnly Boolean DEFAULT true): system.collaborations ARRAY – 서비스가 현재 메모리에 캐시한 모든 협업 인스턴스를 반환합니다. 기본적으로 활성 인스턴스만 반환합니다( 활성 전용 가  false).
• ActiveCollabsGetConversation(collaborationId String REQUIRED, conversationName String): String – 지정된 협업 인스턴스에서 명명된 대화의 ID를 반환합니다. 이름이 지정되지 않으면 "기본" 대화를 반환합니다.
• ActiveCollabsGetOrCreate(collaborationId String REQUIRED, collaborationName String): Object – 주어진 ID로 지정된 협업을 가져오고, 없으면 새로 생성합니다. 반환값은 다음 속성을 가진 객체입니다.
  • 협업 – 연관된 활성 협업 인스턴스입니다.
  • isNew – 협업 인스턴스가 생성되었으면 "true", 그렇지 않으면 "false"입니다.
• ActiveCollabsGetOrCreateForEntity(entityId String REQUIRED, entityRoleName String REQUIRED, entity Object REQUIRED, initialCollaboration Object): Object – 지정된 엔터티와 연결된 활성 협업 인스턴스를 반환하고, 해당 인스턴스가 없으면 새로 생성합니다. 반환 값은 다음 속성을 가진 객체입니다.
  • 협업 – 연관된 활성 협업 인스턴스입니다.
  • isNew – 협업 인스턴스가 생성되었으면 "true", 그렇지 않으면 "false"입니다.
• ActiveCollabsSetEntity(collaborationId String REQUIRED, entityId String REQUIRED, entityRoleName String REQUIRED, entity Object REQUIRED) – 지정된 ID를 가진 협업에서 주어진 엔터티 값을 설정합니다. 업데이트된 협업을 반환합니다.
• ActiveCollabsStartConversation(collaborationId String REQUIRED, conversationName String, conversationProperties Object, collaborationName String): String – 지정된 ID로 협업에서 명명된 대화를 시작/계속합니다("아무것도 지정하지 않으면 기본값"). 협업이 현재 존재하지 않으면 생성됩니다. 대화의 ID를 반환합니다.

API 마이그레이션 참고 사항:

이전 API 포함 ActiveCollabsGetAll 처럼 행동한다고 ​​가정되었습니다 ActiveCollabsGetActive, 하지만 그러지 않았습니다. 해당 절차는 여전히 사용 가능하지만 더 이상 사용되지 않으며 비공개로 전환되었습니다. 다음 중 하나로 마이그레이션하세요. ActiveCollabsGetActive or ActiveCollabsGetCached 다음 릴리스 이전에.

이전 API는 다음과 같은 "동작" 선택을 직접 노출했습니다. 협업 구축 활동 패턴이 매우 혼란스러웠습니다. 업데이트된 API는 엄격한 "getter"를 제공하며, null 인스턴스가 발견되지 않으면 getOrCreate 변형으로, 아무것도 발견되지 않으면 새로운 협업을 생성합니다. 이는 두 가지 모두에서 제공됩니다. ById   ByEntity 변형(협업 ID 또는 엔티티 ID로 시작할 수 있음). 이전에는 엔티티 기반 버전이 각 작업별로 독립적으로 생성되었습니다. 이러한 변형은 제거되었으며, 해당 변형에 대한 모든 호출을 업데이트해야 합니다.

엔터티 역할 절차

기본 협업 관리 절차는 주로 협업을 직접 관리하는 데 중점을 둡니다. 따라서 대부분의 절차는 사용자가 운영할 특정 협업의 ID를 가지고 있다고 가정합니다. 경우에 따라 서비스가 연결된 엔터티 ID를 통해 활성 협업에 액세스하는 것이 더 편리할 수 있습니다. 이러한 액세스 방식을 지원하기 위해 IDE는 정의된 각 엔터티 역할에 대해 다음 절차를 생성하는 옵션을 제공합니다.

• ${entityRoleName}Activate(entityId String REQUIRED, entity ${entityType} REQUIRED, collaborationName String): String – "${roleName}" 엔터티 역할의 지정된 인스턴스에 대한 협업을 활성화합니다. 활성 협업의 ID를 반환합니다.
• ${entityRoleName}Close(entityId String REQUIRED, asFailure Boolean) – ${roleName} 인스턴스와 관련된 활성 협업을 닫습니다.
• ${entityRoleName}GetActive(forAllUsers Boolean DEFAULT false): Object Sequence – "${roleName}" 엔터티 역할과 연결된 현재 활성화된 모든 협업에 대한 세부 정보를 반환합니다. 반환된 Object 인스턴스는 다음과 같은 속성을 갖습니다.
  • collaborationId – 활성 ${roleName}을 관리하는 데 사용되는 협업의 ID입니다.
  • 엔터티 - 활성 ${roleName}과 연관된 현재 값입니다.
• ${entityRoleName}UpdateActive(entityId String REQUIRED, entity ${entityType} REQUIRED) – 활성 협업에서 지정된 "${roleName}" 엔터티 역할 인스턴스를 업데이트합니다(존재하는 경우).

이러한 절차의 생성은 여기에 표시된 대로 생성 대화 상자에서 기어 아이콘을 클릭하여 선택한 엔터티 역할에 대해 수행할 수 있습니다.