다음 예에서는 다양한 사용 사례를 충족하는 멤버십 데이터 피드의 구성을 보여줍니다. 이러한 예에서는 사용 사례를 충족하는 데 필요한 가장 간단한 데이터 피드를 사용합니다. 멤버십 기록을 생성하는 데 사용할 수 있는 MEMBERSHIP 피드 헤더는 더 있습니다. 교육기관의 정보 시스템과 학적 담당자의 요구 사항 및 계획을 분석하면 데이터 및 멤버십의 수명 주기 목표를 충족하며 Learn을 적절히 채우는 데 필요한 데이터의 상세 수준을 결정하는 데 도움이 됩니다.
해당 예는 통합 구성 UI의 기본 Learn 설정을 기반으로 합니다. 이러한 구성 요소를 변경하면 해당 예의 결과가 변경됩니다. 이러한 설정에 대한 설명은 학생 정보 시스템 프레임워크 개요에서 확인할 수 있습니다. 또한 달리 언급된 내용이 없는 한, 통합은 모든 수신 데이터에 동일한 데이터 소스를 사용하도록 구성되어 있다고 가정합니다.
병합된 코스에서의 멤버십에 대한 참고 사항
병합된 코스에서 멤버십을 생성할 때 다음 기준을 따르면 성공적으로 생성할 수 있습니다.
- 학생 정보 시스템의 안내를 따릅니다. 멤버십은 학생 정보 시스템당 하나로 유지되어야 합니다. 상위 코스에 모든 멤버십을 강제로 적용하지 마십시오.
- 멤버십은 병합된 코스에서 두 개 이상의 하위 코스에 없을 수도 있습니다. SP12에서는 병합된 코스의 등록 관리를 지원하기 위해 코스 멤버십에 대한 새로운 필드 매핑(교차 목록 등록 이동)을 도입했습니다. 이 필드 매핑을 적용하면 멤버십 및 연결된 데이터/콘텐츠가 현재 코스에서 새로운 하위 코스로 이동됩니다(다음 사용 예시 참조).
- '교차 목록 등록 이동'을 사용하는 경우에는 먼저 하나의 하위 코스에서 멤버십을 비활성화한 후에 다른 하위 코스에서 멤버십을 생성해야 합니다. 교육기관에서 학생이 두 개 이상의 코스 인스턴스에 등록할 수 있는 광범위한 코스 등록 정책을 허용하는 경우에는 추가 멤버십 요청에서 통합 오류가 발생합니다. 예를 들어 Math100에 하위 코스가 3개(Math100.1, Math100.2, Math100.3) 있고 학생이 등록 기간 중에 Math100.2와 Math100.3을 옵션으로 선택하는 경우 먼저 처리되는 하위 멤버십에 따라 Learn에서 처리 시 둘 중 하나에 오류가 발생합니다.
멤버십 데이터에 대하여
멤버십 데이터는 관리자가 아닌 역할을 가진 사용자의 코스 또는 조직에 대한 접근 권한을 결정하는 기본 정보 집합입니다.
작업
데이터는 Learn에 제공한 이후 업데이트, 제거 또는 수정할 수 있으므로 관리자는 가장 간단한 데이터 집합으로 시작한 뒤 교육기관의 데이터 요구 사항이 변경됨에 따라 데이터를 확대할 수 있습니다.
스냅숏 플랫 파일의 데이터 관리
학생 정보 시스템 프레임워크에서는 Learn 시스템에서 제공하는 URL 집합 및 UI 피드 업로드를 통해 스냅숏 플랫 파일의 데이터 피드 업로드를 지원합니다.
학생 정보 시스템 통합 UI의 시스템 관리자 데이터 통합에서 사용할 수 있는 통합 메뉴를 통해 HTTP 정보에 접근하고 피드 파일을 업로드하십시오.
두 경우 모두 데이터 작업의 동작은 선택한 작업 유형 및 통합 구성에 따라 진행됩니다. 피드의 데이터가 '해석'되는 방식은 선택한 데이터 작업 유형에 따라 결정되며, 각 URL에서는 원하는 통합 목표를 충족하기 위해 서로 다른 결과를 제공합니다.
작업 | 설명 |
---|---|
저장 | 이 작업 유형을 사용하면 피드 파일에 포함된 데이터가 통합에서 소유하는 모든 데이터 소스에서 저장 또는 업데이트됩니다(구성 설정에 따라). 데이터 '소유권' 및 데이터 소스에 대한 내용은 학생 정보 시스템 프레임워크 개요에서 참조하십시오. |
새로 고침 완료 | 이 작업을 수행하면 데이터 피드에 포함된 데이터가 저장 또는 업데이트되는 동시에, 통합과 연결된 데이터 피드에 포함되어 있지 않은 데이터가 모든 데이터 소스에서 비활성화됩니다. |
삭제 | 이 작업을 수행하면 통합과 연결된 데이터 피드에 포함된 기록이 통합 설정에 따라 모든 데이터 소스에서 비활성화됩니다. |
데이터 소스 기준 새로 고침 완료 | SP12에 도입된 이 작업을 선택하면 통합이 구성된 데이터 소스하고만 연결된 데이터가 전체적으로 새로 고쳐집니다. 이 작업을 수행하면 데이터를 새로 고치기 위해 명령줄 스냅숏 프로세스가 더 면밀히 에뮬레이트됩니다. |
멤버십 작업과 연결된 객체는 다음과 같습니다.
객체 | 작업 |
---|---|
멤버십 | 저장, 새로 고침 완료, 삭제, 데이터 소스 기준 새로 고침 완료 |
조직과 코스에서는 멤버십 관리를 위해 동일한 패턴을 공유하지만, 서로 다른 헤더를 필요로 합니다. 이 점은 해당하는 경우 언급되지만, 예에서는 계속 코스 멤버십 관리를 집중적으로 살펴봅니다.
제공된 예에서는 스냅숏 프레임워크의 UI인 피드 파일 업로드 기능을 사용합니다. 다른 명령줄/프로그래밍 작업을 자동화하거나 사용하는 방법을 자세히 알아보려면 스냅숏 플랫 파일 자동화를 참조하십시오.
데이터 소스 키에 대한 미리 알림
모든 데이터 객체는 해당 데이터 집합을 그룹화하기 위해 데이터 소스 키를 변경하는 기능을 지원하며, 연결된 데이터 소스를 변경하는 데 사용될 수 있습니다.
이는 프레임워크 기반 데이터 피드에서 필수 필드가 아니며, 달리 언급된 내용이 없는 한 제공된 예에서는 통합이 단일 데이터 소스를 사용하도록 구성되었다고 가정합니다. SP12에는 새 데이터 소스를 지정하는 것과 별개로 데이터 피드에서 데이터 소스를 지정하는 기능이 도입되었습니다. 데이터 소스 키 관리 및 멤버십 기록의 데이터 소스를 변경하는 방법에 관한 섹션을 참조하십시오.
필드 매핑에 대한 참고 사항
필드 매핑을 사용하면 Learn에 저장되기 전에 수신 데이터를 변경할 수 있습니다. 이 기능을 사용하면 저장된 데이터를 완벽하게 제어할 수 있으며, 제공된 학생 정보 시스템 데이터가 충분하지 않은 경우 Learn용 규칙을 충족할 수 있습니다(예: 적합한 멤버십 이름 항목을 생성하는 경우). 멤버십 객체 필드에 적용되면 연결된 스크립트가 멤버십 기록별로 실행되어 Learn에 저장되기 전에 데이터를 변경하거나 제공합니다. 필드 매핑에 대한 자세한 설명은 스냅숏 플랫 파일의 사용자 지정 필드 매핑에 나와 있습니다.
멤버십 작업 예시
상위 수준에서 모든 멤버십 데이터 작업에 적용될 수 있는 세 가지 학생 정보 시스템 통합의 데이터 피드 패턴을 확인할 수 있으며, 어떤 패턴을 선택할지는 제공할 수 있는 데이터에 따라 달라집니다.
- 단일 피드 파일을 사용하여 기록을 비활성화(삭제)하는 것과는 별개인 프로세스를 활용하여 기록을 저장 및 업데이트(저장)할 수 있습니다.
- 단일 피드 파일을 사용하여 기록을 저장, 업데이트 및 비활성화(새로 고침 완료)할 수 있습니다.
- 파일 조합을 사용하여 하나의 조합으로 저장하고, 또 다른 조합으로 비활성화할 수 있습니다.
마지막으로, 학생 정보 시스템 피드 패턴은 아니지만 알아두면 유용한 사항은 UI에서 사용할 수 있는 데이터 소스 관리 도구를 활용하면 DSK만을 기반으로 하여 비활성화 및 제거할 수도 있다는 점입니다. 이러한 방식으로 학생 정보 시스템에서 제공한 데이터를 관리할 때는 매우 신중해야 합니다. 이는 학생 정보 시스템을 통해 제공된 적이 없거나 더 이상 제공되지 않는 데이터 또는 테스트 작업의 결과인 데이터를 제거할 때 매우 유용합니다.
기본 사항: 멤버십
모든 멤버십에는 설정을 위한 기본 정보 집합이 필요합니다. 이 정보는 스냅숏 플랫 파일의 데이터 형식 및 스냅숏 플랫 파일의 헤더 설명에 자세히 설명되어 있습니다.
현재 UI 배치 도구를 사용 중인 경우 학생 정보 시스템 프레임워크를 사용하고 학생 정보 시스템 프레임워크의 UI 업로드 기능 및 최소 멤버십 데이터를 사용하도록 전환하면 데이터 수집 프로세스를 변경하지 않고도 데이터 업로드를 더 잘 기록 및 보고할 수 있습니다.
데이터 요약
Learn에서 멤버십 계정을 생성하는 데 필요한 최소 데이터 집합 또는 헤더는 다음과 같이 구성됩니다.
- EXTERNAL_COURSE_KEY - 이 멤버십 기록의 고유 식별자입니다. 조직의 경우에는 EXTERNAL_ORGANIZATION_KEY입니다.
- NEW_DATA_SOURCE_KEY - 이 기록의 데이터 집합에 대한 고유 식별자입니다.
참고: 이는 피드에서 또는 통합 구성을 통해 제공됩니다. - EXTERNAL_PERSON_KEY - 멤버십이 적용되는 사용자의 ID입니다.
통합 구성에 따라 학생 정보 시스템 프레임워크에서는 필수가 아닌 필드에 기본값을 제공하거나 그러한 필드를 무시합니다. 멤버십 피드에 대해 필수 항목이 아닌 세 개의 유용한 필드는 AVAILABLE_IND, ROW_STATUS 및 ROLE입니다. 이와 관련된 내용은 다음 사용 사례에서 다룰 예정입니다.
이러한 헤더는 각각 스냅숏 플랫 파일의 헤더 설명에 자세히 설명되어 있습니다.
멤버십 정보 추가하기
멤버십 정보를 추가하는 사용 사례로는 두 가지가 있습니다. 첫 번째는 멤버십 정보 STORE 작업을 실행하여 데이터 피드에 표시되는 바와 같이 기록이 추가 또는 업데이트되도록 하는 것입니다. 두 번째는 Learn에 이미 표시되어 있는 멤버십 정보에 REFRESH 작업을 수행하여 데이터 파일에 표시되는 바와 같이 기록이 생성되거나 기존 기록이 업데이트되는 동시에 멤버십 데이터 파일에 표시되어 있지 않은 기존의 Learn 기록이 비활성화되도록 하는 것입니다.
저장 작업 예시
예 1: 멤버십 생성하기
기존 계정에 영향을 주지 않고 멤버십을 Learn에 추가하고자 합니다. 통합은 모든 수신 데이터에 동일한 데이터 소스를 사용하도록 구성되어 있습니다.
전제 조건
멤버십 작업에 성공하려면 코스 및 사용자가 있어야 합니다.
최소 데이터 피드 요구 사항
EXTERNAL_COURSE_KEY
EXTERNAL_PERSON_KEY
해결책
시스템에 추가하려는 멤버십별 필수 헤더 및 연결된 데이터가 포함된 memberships.txt 데이터 파일을 생성하십시오. 예:
EXTERNAL_COURSE_KEY|EXTERNAL_PERSON_KEY
testcourse1|testPerson1
testcourse1|testPerson2
testcourse2|testPerson3
STORE 작업을 사용하여 멤버십 데이터 유형을 통해 UI로 이 파일을 업로드하십시오. 멤버십 계정이 생성되고 시스템 관리자의 멤버십 도구를 통해 해당 계정을 검색할 수 있습니다.
사후 조건
testcourse1의 멤버십이 EXTERNAL_PERSON_KEY로 testPerson1, testPerson2을 사용하는 개인에 대해 생성되었으며 testcourse2의 멤버십이 testperson3에 대해 생성되었습니다.
예 2: 멤버십 업데이트하기
멤버십 계정을 생성했는데 이를 변경해야 합니다. 예를 들어 위의 예에서는 testPerson3이 testcourse1을 위한 것이어야 했는데 testcourse2에 추가되었습니다.
데이터 피드인 testcourse1|testPerson3을 올바르게 변경하는 동안 이전 testcourse2 멤버십은 비활성화될 때까지 유효하게 유지됩니다. 이 작업은 ROW_STATUS 헤더 요소를 추가하여 단일 피드에서 완료될 수 있습니다.
전제 조건
코스 및 개인 기록이 Learn에 있어야 합니다.
비활성화에 대한 기록이 Learn에 이미 있어야 합니다.
해결책
생성/업데이트 또는 비활성화하려는 멤버십별 필수 헤더 및 연결된 데이터가 포함된 membership.txt 데이터 파일을 생성하십시오. 예:
EXTERNAL_COURSE_KEY|EXTERNAL_PERSON_KEY|ROW_STATUS
testcourse2|testPerson3|disabled
testcourse1|testPerson3|enabled
STORE 작업은 파일에 포함된 데이터에 대해서만 작동하기 때문에 멤버십 기록을 이전에 제출한 데이터는 영향을 받지 않으며, 기록을 비활성화하려면 STORE 작업에 명시적인 데이터 조작이 필요합니다.
STORE 작업을 사용하여 멤버십 데이터 유형을 통해 UI로 이 파일을 업로드하십시오. 파일의 멤버십 기록이 업데이트됩니다.
사후 조건
testPerson3에 대한 멤버십 기록은 testcourse1에서 멤버십을 생성하고 활성화하는 동안 testPerson3에 대한 testcourse2 멤버십을 명시적으로 비활성화하도록 업데이트됩니다.
이전에 생성한 멤버십 기록은 영향을 받지 않습니다.
멤버십: 새로 고침 완료 작업
COMPLETE REFRESH 작업은 STORE 작업과 다르게 작동합니다. COMPLETE REFRESH 작업에서는 새 기록을 저장하거나 기존 기록을 업데이트하거나 데이터 파일에 없는 기록을 Learn에서 비활성화하는 등 통합에서 소유하는 Learn의 기록과 피드 파일의 데이터를 비교하는 두 가지 작업을 수행합니다.
예: 새로 고침 완료
Learn에 있어야 하는 코스 멤버십의 전체 스냅숏이 학생 정보 시스템에서 제공하는 데이터에 포함됩니다. 이 데이터에는 추가할 멤버십 기록, 업데이트할 멤버십 기록이 포함되며 구성에 따라 적절히 처리되어야 하는 이전 COMPLETE REFRESH 작업(비활성화 또는 제거)이 수행된 이후에 제거된 기록이 제외됩니다.
전제 조건
코스 및 개인 기록이 Learn에 있어야 합니다.
최소 데이터 피드 요구 사항
EXTERNAL_COURSE_KEY
EXTERNAL_PERSON_KEY
해결책
첫 번째 멤버십 저장 작업의 데이터부터 testcourse1에서 testPerson3에 대한 올바른 멤버십을 추가하고 testcourse2에서 testPerson3에 대한 잘못된 멤버십을 제거하여 COMPLETE REFRESH 작업이 파일에 없는 모든 기록을 암시적으로 비활성화하는 것처럼 위에 표시된 여러 STORE 작업과 비슷한 결과를 제공하십시오.
EXTERNAL_COURSE_KEY|EXTERNAL_PERSON_KEY
testcourse1|testPerson1
testcourse1|testPerson2
testcourse1|testPerson3
이 통합을 통해 다른 멤버십 기록이 관리되는 경우 해당 기록은 위의 데이터 피드에 없기 때문에 비활성화 또는 제거됩니다.
사후 조건
testcourse1|testPerson1 및 testcourse1|testPerson2에 대한 멤버십 기록이 유지 및 업데이트됩니다.
testcourse1|testPerson3에 대한 멤버십 기록이 Learn에 추가됩니다.
testcourse2|testPerson3에 대한 멤버십 기록은 데이터 피드에 포함되어 있지 않기 때문에 통합 구성에 따라 비활성화된 것으로 표시되거나 제거를 위해 준비됩니다.
멤버십: 데이터 소스 기준 새로 고침 완료 작업
COMPLETE REFRESH BY DATA SOURCE 작업에서는 통합의 데이터 소스하고만 연결된 데이터에만 COMPLETE REFRESH 작업을 수행합니다.
예: 데이터 소스 기준 새로 고침 완료
Learn에 대한 접근 권한이 있어야 하는 PERSON의 전체 스냅샷이 학생 정보 시스템에서 제공하는 데이터에 포함됩니다. 이 데이터에는 추가할 PERSON 기록, 업데이트할 PERSON 기록 및 구성에 따라 적절히 처리되어야 하는 이전 REFRESH 작업(비활성화 또는 제거)이 수행된 이후에 제거된 기록이 포함됩니다. 또한 이 새로 고침에 포함되는 모든 데이터는 통합에 정의된 것과 동일한 데이터 소스를 사용하여 지정되며, 이 데이터 소스 키와 관련된 데이터만 영향을 받도록 하려고 합니다.
전제 조건
코스 및 개인 기록이 Learn에 있어야 합니다.
최소 데이터 피드 요구 사항
EXTERNAL_COURSE_KEY
EXTERNAL_PERSON_KEY
해결책
마지막 저장 작업의 데이터를 사용하여 testcourse1에서 testPerson3에 대한 새로운 멤버십을 추가하고 데이터 피드에서 testcourse2|testPerson3을 제거하십시오.
EXTERNAL_COURSE_KEY|EXTERNAL_PERSON_KEY
testcourse1|testPerson1
testcourse1|testPerson2
testcourse1|testPerson3
사후 조건
testcourse1|testPerson1 및 testcourse1|testPerson2에 대한 멤버십 기록이 유지 및 업데이트됩니다.
testcourse1|testPerson3에 대한 멤버십 기록이 업데이트되고 Learn에 추가됩니다.
testcourse2|testPerson3에 대한 멤버십 기록은 데이터 피드에 포함되어 있지 않기 때문에 통합 구성에 따라 비활성화된 것으로 표시되거나 제거를 위해 준비됩니다.
이 통합을 통해 다른 멤버십 기록이 관리되는 경우 해당 기록은 통합에서 지정한 것과 동일한 데이터 소스를 갖고 있지 않는 한, 위의 데이터 피드에 없다는 이유로 비활성화 또는 제거되지 않습니다.
멤버십 사용 가능성
멤버십 사용 가능성 설정을 사용하면 Learn의 계정을 학생에게 표시하거나(사용 가능) 표시하지 않도록(사용 불가능) 설정할 수 있습니다. 이는 멤버십을 비활성화하는 것과는 다릅니다. 즉, 멤버십을 모든 사용자가 사용할 수 없게 설정할 뿐만 아니라 UI를 통한 멤버십 관리와 같은 추가 작업에도 사용할 수 없음을 의미합니다. 이 데이터 피드 헤더를 추가해도 멤버십 기록을 생성하기 위해 위에서 설명한 STORE, COMPLETE REFRESH, COMPLETE REFRESH BY DATA SOURCE 작업을 사용하는 데는 영향이 가지 않습니다.
AVAILABILITY 설정이 데이터 피드에서 제공되지 않은 경우에는 기본 통합 설정에 따라 객체가 생성/업데이트 작업에서 사용할 수 있도록 설정됩니다.
예: 멤버십 계정 사용 가능성
학생 정보 시스템에서는 Learn 접근 사용 가능성을 컨트롤하며, 데이터 피드는 사용자가 Learn에 대한 접근 권한을 지니고 있고 관리자가 PERSON 생성/업데이트 작업에서 이 접근 설정을 컨트롤하려는 경우 컨트롤할 사용자에 대한 사용 가능성 설정을 나타냅니다.
전제 조건
코스 및 개인 기록이 Learn에 있어야 합니다.
최소 데이터 피드 요구 사항
EXTERNAL_COURSE_KEY
EXTERNAL_PERSON_KEY
AVAILABILITY_IND
해결책
AVAILABLE_IND 헤더를 데이터 피드에 추가하고 사용 가능한 경우 단일 문자 Y를, 사용 불가능한 경우 단일 문자 N을 입력하십시오.
EXTERNAL_COURSE_KEY|EXTERNAL_PERSON_KEY|AVAILABLE_IND
testcourse1|testPerson1|Y
testcourse1|testPerson2|Y
testcourse1|testPerson3|Y
testcourse2|testPerson3|N
사후 조건
저장
testcourse1 및 testcourse2에 대한 멤버십 기록만 현재의 사용 가능성 상태로 생성되거나 업데이트됩니다.
새로 고침 완료 작업
testcourse1 및 testcourse2에 대한 멤버십 기록이 현재의 사용 가능성 상태로 생성되거나 업데이트됩니다. 다른 모든 기록은 위의 데이터 피드에 없기 때문에 비활성화되거나 제거를 위해 표시됩니다.
데이터 소스 기준 새로 고침 완료
testcourse1 및 testcourse2에 대한 멤버십 기록이 현재의 사용 가능성 상태로 생성되거나 업데이트됩니다. 다른 통합을 통해 다른 멤버십 기록이 관리되는 경우 해당 기록은 통합에서 지정한 것과 동일한 데이터 소스를 갖고 있지 않는 한, 위의 데이터 피드에 없다는 이유로 비활성화 또는 제거되지 않습니다. COMPLETE REFRESH BY DATA SOURCE 작업은 통합 데이터 소스의 기록에 대해서만 작동합니다.
멤버십 기록 비활성화하기
Learn에서 멤버십 기록을 비활성화하면 모든 사용자가 코스 기록에 접근할 수 없게 되며(비활성화된 상태는 사용 가능성 설정을 재정의함) UI 작업을 수행할 때도 기록에 접근할 수 없게 됩니다(예: UI를 통해 비활성화된 멤버십을 관리할 수 없음). 또한 Learn에서 기록을 제거하려면 먼저 해당 기록을 비활성화해야 합니다.
기록을 비활성화하고 후속 제거를 수행하면 Learn에서 해당 기록에 대한 모든 참조가 제거됩니다. 비활성화된 기록을 제거하는 작업은 업무 및 법적 관례에 따라 지정된 기간 이후에만 수행하는 것이 좋습니다. 그렇지 않으면 활동을 기록해야 할 수 있습니다.
기록을 비활성화할 때는 REFRESH 작업에서 피드 데이터 제외를 통해 비활성화하거나 피드 헤더인 ROW_STATUS를 사용하여 비활성화할 수 있습니다.
REFRESH 작업을 사용하는 이전 멤버십 작업에서는 제외를 통해 비활성화하는 경우를 보여주며, 다음 사례 및 예에서는 ROW_STATUS를 사용하여 비활성화하는 경우를 보여줍니다.
예: 멤버십 기록 비활성화하기
정책에 따르면 5년 후에는 Learn에서 코스를 완전히 제거해야 합니다(표시 여부만 제한하며 멤버십을 사용할 수 없게 설정하는 것과는 다름). STORE 작업을 사용 중인 경우 멤버십을 제거하려면 ROW_STATUS 헤더를 사용하여 멤버십을 명시적으로 비활성화해야 합니다. 이는 학생 정보 시스템 피드의 범위를 벗어나는 수동 작업에도 유용합니다.
전제 조건
코스 및 개인 기록이 Learn에 있어야 합니다.
최소 데이터 피드 요구 사항
EXTERNAL_COURSE_KEY
EXTERNAL_PERSON_KEY
ROW_STATUS
해결책
ROW_STATUS 헤더를 데이터 피드에 추가하고 활성화된 경우 ENABLED를, 비활성화된 경우 DISABLED를 입력하십시오.
EXTERNAL_COURSE_KEY|EXTERNAL_PERSON_KEY|ROW_STATUS
testcourse1|testPerson1|enabled
testcourse1|testPerson2|enabled
testcourse1|testPerson3|enabled
testcourse2|testPerson3|disabled
사후 조건
저장
데이터 피드에 포함된 멤버십 기록만 ROW_STATUS가 명시적으로 업데이트된 상태로 생성되거나 업데이트됩니다.
새로 고침 완료
데이터 피드에 포함된 멤버십 기록이 ROW_STATUS가 명시적으로 업데이트된 상태로 생성되거나 업데이트됩니다. 다른 모든 기록은 데이터 피드에 없기 때문에 비활성화되거나 제거를 위해 표시됩니다.
데이터 소스 기준 새로 고침 완료
데이터 피드에 포함된 멤버십 기록이 ROW_STATUS가 명시적으로 업데이트된 상태로 생성되거나 업데이트됩니다. 다른 통합을 통해 다른 멤버십 기록이 관리되는 경우 해당 기록은 통합에서 지정한 것과 동일한 데이터 소스를 갖고 있지 않는 한, 위의 데이터 피드에 없다는 이유로 비활성화 또는 제거되지 않습니다. COMPLETE REFRESH BY DATA SOURCE 작업은 통합 데이터 소스와 일치하는 기록에 대해서만 작동합니다.
SP12의 새로운 기능
예: 교차 목록 등록 이동
병합된 코스를 사용할 경우 멤버십(등록) 처리에 몇 가지 제약이 있습니다. 특히, 사용자는 두 개 이상의 병합된 코스에서 동시에 활성화된 멤버십을 보유할 수 없습니다.
특정한 교차 목록 시나리오에서 사용자가 교차 목록(병합됨) 집합의 course_child1에 이미 등록되어 있으면 학생 정보 시스템에서는 일반적으로 course_child2에 대한 사용자 등록을 실행할 수 없습니다. Move Cross-Listed Enrollment 필드는 학생 정보 시스템 통합에서 다른 경우 유효한 모든 등록이 교차 목록 제한 때문에 차단되지 않아야 한다고 가정하도록 통합에 대한 컨트롤을 설정합니다. 이는 위의 course_child2/course_child1 참조에 따라 course_child1에 대한 등록이 course_child1에서 course_child2로 이동됨을 의미합니다.
교차 목록 등록 관리를 위한 필드 매핑은 각 통합 인스턴스의 '고급 구성'을 통해 사용할 수 있습니다. 이는 '등록' 객체 필드 매핑의 일환으로, '교차 목록 등록 이동'이라고 합니다.
'교차 목록 등록 이동'에서는 항상 '참'을 반환하는 내부 기본 스크립트 호출을 사용합니다. 이 동작을 변경하려면 일부 또는 모든 상황에서 참이 아닌 다른 결과를 반환하는 스크립트를 제공해야 합니다. 예를 들어 단순히 거짓을 반환하는 스크립트를 보유하거나 멤버십의 코스 ID가 조건부로 일부 패턴 등을 충족하는 경우에만 거짓을 반환한 스크립트를 보유할 수 있습니다. 자세히 알아보려면 사용자 지정 필드 매핑 예시를 참조하십시오.
기본적으로 이 매핑은 통합 유형에 대한 피드의 일환으로 '직접' 설정되지 않습니다. 즉, 스냅샷 플랫 파일에는 이에 대한 열이 없으며, IMS/Vista 등에는 이에 대한 XML 노드가 없습니다. 따라서 이 필드에 대한 '데이터' 예가 없습니다.
완전한 예시
위의 헤더를 하나의 파일로 결합하면 대부분의 사용 사례를 한 번에 다룰 수 있습니다.
전제 조건
템플릿 복사 작업에 성공하려면 testmembership8을 이전에 생성하지 않았어야 합니다.
EXTERNAL_COURSE_KEY|EXTERNAL_PERSON_KEY|AVAILABLE_IND|ROW_STATUS
testcourse1|testPerson1|Y|enabled
testcourse1|testPerson2|Y|enabled
testcourse1|testPerson3|Y|enabled
testcourse2|testPerson3|N|disabled
사후 조건
저장
데이터 피드에 포함된 멤버십 기록만 AVAILABILITY 및 ROW_STATUS가 다음과 같이 명시적으로 업데이트된 상태로 생성되거나 업데이트됩니다.
모든 멤버십의 사용 가능성이 예(Y)로 설정되어 있습니다(아니요(N)로 설정된 testcourse2|testPerson3 제외).
testcourse1에 대한 멤버십은 '활성화됨'으로 설정되고, testcourse2|testPerson3에 대한 멤버십은 '비활성화됨'으로 설정됩니다.
새로 고침 완료
저장 작업과 동일한 결과가 나오며, 관리되는 다른 모든 기록은 데이터 피드에 없기 때문에 비활성화되거나 제거를 위해 표시됩니다.
데이터 소스 기준 새로 고침 완료
저장 작업과 동일한 결과가 나오며, 다른 통합을 통해 다른 멤버십 기록이 관리되는 경우 해당 기록은 통합에서 지정한 것과 동일한 데이터 소스를 갖고 있지 않는 한, 위의 데이터 피드에 없다는 이유로 비활성화 또는 제거되지 않습니다. COMPLETE REFRESH BY DATA SOURCE 작업은 통합 데이터 소스의 기록에 대해서만 작동합니다.