장점

시스템을 자동으로 채우고 업데이트하기 위해 학생 정보 시스템 통합을 사용하여 Blackboard Learn에 데이터를 전달할 경우의 주요 이점은 다음과 같습니다.

  • 코스 및 사용자 데이터 관리를 Blackboard 서버에 대한 명령줄 접근 권한이 필요 없는 한 명 이상의 관리자에게 위임할 수 있습니다.
  • 한 LMS(학습 관리 시스템)에서 다른 LMS로 데이터를 빠르고 효율적으로 전송할 수 있습니다.

시작하기 전에

하나 이상의 학생 정보 시스템 통합을 생성하기 전에 Blackboard Learn에서 어떤 소스의 어떤 데이터를 어떤 형식으로 사용하여 시스템을 채울지를 계획하는 데 모든 이해관계자가 참여하도록 해야 합니다. 커뮤니케이션은 학생 정보 시스템에서 Blackboard Learn으로만 이루어지므로 각 코스, 사용자 및 사용자 역할에 대한 모든 데이터는 정의된 후 Blackboard에 설명되어야 합니다. 또한 모든 사용자는 Blackboard에서 자신을 고유하게 식별하는 데 필요한 자격 증명을 보유하고 있어야 합니다.

코스, 사용자 및 등록 데이터를 수집하는 프로세스는 반복됩니다. 개인이 교육기관에 들어오고 나감에 따라 코스가 생성되고 등록이 변경되므로 Blackboard 내의 데이터도 변경되어야 합니다. 데이터를 수집하고 로드하는 빈도는 교육기관 정책에 의해 결정됩니다. 시스템에 정보를 제공하는 데이터 소스는 Blackboard 관리자에게 데이터를 제공하기 위해 반복 가능한 절차를 설정해야 합니다.

교육기관은 비즈니스 규칙에 대한 동의를 기반으로 이미 강력한 프로세스를 갖추고 있을 수 있습니다. 이 경우, 광범위한 계획은 필요하지 않을 수 있지만 Blackboard에 필요한 정보 요구 사항과 완료해야 할 작업 순서 및 빈도에 대해 이해하고 있어야 합니다. 교육기관에서 자동화된 프로세스를 막 실행하기 시작했거나 변경하고 있는 경우 시작하기 전에 사용할 수 있는 비즈니스 규칙 및 정보를 갖추고 있으려면 보다 심층적인 계획이 필요합니다.


사용자, 코스 및 등록에 대한 필수 정보

통합을 생성하려면 사용자, 코스 및 등록에 대한 다음 정보를 Blackboard에 제공해야 합니다. 계획에서 처음으로 수행해야 하는 작업은 각 데이터 조각의 소스를 식별하는 것입니다.

필수 정보
객체요소
사용자(사람)개인 고유 식별자

로그인 식별자

비밀번호(Blackboard 접근용)

이름

별명(선택 사항)

이메일 주소

교육기관 내 역할

코스코스 고유 식별자

코스 식별자

코스명

코스 콘텐츠의 소스(선택 사항)

등록코스에 연계된 사용자 집합

코스 내 사용자 역할


인증 방법 결정

각 사용자의 로그인 식별자 및 비밀번호를 수집하십시오. Blackboard의 기본 인증 시스템 또는 교육기관의 인증 시스템을 사용할 수 있습니다.

  • Blackboard의 기본 인증 시스템을 사용하는 경우 로그인 식별자 및 비밀번호는 수집된 사용자 데이터에 속하게 됩니다. 로그인 식별자 및 비밀번호는 각 사용자에게 배포되어야 합니다.
  • 교육기관 인증 시스템의 로그인 식별자 및 비밀번호를 사용하는 경우 로그인 식별자를 수집하고 각 사용자에 대해 임의 비밀번호를 생성하십시오. 그러면 사용자가 교육기관 인증 시스템에서 인증됩니다.

데이터 소스 정의

Vista처럼 LMS 내에서 모든 데이터 정보를 수집할 수 있지만 교육기관이 수집하고 유지 관리하는 공식적인 교육기관 데이터를 사용하는 것이 훨씬 좋습니다. 이 교육기관 데이터는 서로 다른 데이터 소스에서 오게 될 수 있습니다. 데이터 소스 유형 및 이 소스에서 수집할 수 있는 데이터 유형은 교육기관에서 이미 설정되어 있거나 아직 결정되지 않았을 수 있습니다. 어떤 경우든 통합을 생성하려면 데이터 추출 방법 및 데이터 소스에 대해 동의해야 합니다.

모든 교육기관은 서로 다르게 설정되어 있지만, 필요한 정보를 찾기 위해 이동할 수 있는 몇 가지 공통된 위치가 있습니다.

  • 학생 정보 시스템: 이름, 주소, 연락처 정보, 학년 또는 졸업 날짜와 같은 학생 정보를 위한 저장소입니다.
  • 학적 담당 부서: 코스 카탈로그 정보를 비롯해 코스 이름, 설명 및 섹션 정보, 등록 정보가 있습니다.
  • 인적 자원 담당 부서 또는 HRMS(인적 자원 관리 시스템): 교사, 직원, 부교수 및 조교 등 교육기관에 있는 모든 사람을 설명하는 정보가 있습니다.
  • 학교 안내 책자 서비스(인명별 전화번호부): 직원 및 부서별 전화번호, 이메일 주소 및 사무실 주소를 조회합니다. 이 안내 책자는 LMS에 대한 정보의 소스가 될 수 있습니다.
  • IT 부서 또는 컴퓨터 서비스: LDAP 서비스와 같이 사용자 인증을 위한 방법을 설정합니다. 이메일 주소 및 로그인 자격 증명을 생성할 수 있습니다.

상충되는 데이터 해결

데이터를 여러 데이터 소스에서 수집하는 경우 상충되는 데이터 요소가 생길 수 있습니다. 이러한 상충을 해결하는 정책을 갖추고 있어야 시스템에서 어떤 소스를 사용할지 파악할 수 있습니다. 예를 들어, HRMS에서 사용자에게 이메일 주소를 요청하고 학적 담당 부서에서도 이메일 주소를 요청할 수 있습니다. 사용자가 교육기관 내에서 두 가지 다른 역할을 수행하는 경우(예: 학생이자 조교인 경우 또는 직원이자 부교수인 경우) 상충되는 이메일 주소가 생길 수 있습니다. 이렇게 두 이메일 주소가 서로 다를 경우 어떤 소스를 우선 적용할지를 결정해야 합니다.

상충되는 데이터 요소의 또 다른 예로는 학적 담당 부서 및 학생 정보 시스템이 학생의 이메일 주소를 각각 보유하는 경우가 있습니다. 교육기관의 안내 책자 서비스에도 각 사용자의 이메일 주소가 보관될 수 있습니다. 이 상충 문제를 해결하는 한 가지 방법은 하나의 소스를 선택하여 다른 소스보다 우선 적용되도록 하는 것입니다. 다른 솔루션은 사용자가 Blackboard 내에서 이메일 주소를 설정하도록 허용하는 것입니다.

통합을 생성하기 위해서는 상충되는 데이터 요소가 생길 수 있는 위치를 식별하고 상충 문제를 해결해야 합니다.


데이터 로드 순서

시스템에서 사용자, 코스 및 등록을 생성할 때 필요로 하는 모든 정보가 필요하지만, 데이터는 서로 다른 소스에서 올 수 있기 때문에 Blackboard에 특정한 순서로 로드되어야 합니다. 코스 및 사용자 정보를 먼저 로드해야 하는데, 이는 등록이 이러한 정보에 따라 결정되기 때문입니다. 데이터 로드 순서는 다음과 같습니다.

  1. 사용자
  2. 코스
  3. 등록

사용자, 코스 및 등록 생성에 대한 구체적인 내용이 아래 섹션에 설명되어 있습니다.


사용자 생성

  • EXTERNAL_PERSON_KEY. 이 요소는 데이터베이스 내의 사용자를 식별하는 데 사용됩니다. 이 키는 표시되지 않지만, 여기에 개인 식별 데이터, 이름, 주민등록번호 또는 생년월일이 포함되어 있어서는 안 됩니다. 개인의 데이터가 변경되기 때문입니다. 결혼, 이혼 또는 개명하거나 주민등록번호가 변경되는 사람도 있습니다. 개인 식별 데이터를 넣지 않아야 변경 시 문제를 방지할 수 있습니다. 이 키는 64자를 초과할 수 없습니다. 실수로 학생 데이터가 다른 학생에게 노출될 수 있는 위험이 있으므로 이 키를 재사용해서는 안 됩니다. 이 키는 학생에게 발급된 후 다시 발급되어서는 안 됩니다. EXTERNAL_PERSON_KEY를 재발급하면 한 사용자의 정보가 다른 사용자에게 표시될 수 있는 위험이 있습니다. 따라서 이 키를 매우 큰 키 공간의 일부로 사용하는 것이 좋습니다. 아직 적절한 식별자가 없는 경우 이러한 키를 구성하는 좋은 방법은 학생별로 임의의 16~20자리 16진수 숫자를 생성하는 것입니다. 높은 가변성과 임의 배포를 통해 데이터베이스가 균형 있는 인덱스를 구축하도록 허용할 수 있습니다.
  • USER_ID. USER_ID는 경우에 따라 네트워크 ID, 사용자명 또는 로그인 이름이라고도 합니다. 이 요소는 비밀번호와 함께 LMS에서 사용자를 인증할 때 사용됩니다. 중앙 인증 시스템이 없는 경우 Blackboard를 인증 시스템으로 사용할 수 있습니다. 이 경우 Blackboard 관리자는 각 사용자의 USER_ID와 비밀번호를 생성해야 합니다. Blackboard에서 지원하는 프로토콜을 사용하는 중앙 인증 시스템을 사용하는 경우 해당 시스템으로 Blackboard 사용자를 인증하는 것이 좋습니다. 이 경우 EXTERNAL_PERSON_KEY에 연결되어 있는 USER_ID 목록을 모아 Blackboard에 로드해야 합니다. 이는 Blackboard에 대한 권한 부여 역할도 합니다.
  • FIRSTNAME, LASTNAME, NICKNAME. 이러한 요소는 학생의 ID가 Blackboard 내에서 표시되는 방식을 결정합니다. 가능한 경우 이름 데이터의 소스를 Blackboard에 전달하기 전에 이름을 구성 요소로 분할하십시오. 이 이름은 교육기관에서 공식 기록(예: 성적 증명서, 미국 국세청 W2 양식 또는 식별 카드)에 사용하는 공식 이름일 수 있습니다. 모든 사람이 공식 이름으로 불리지는 않으며 별명으로 불리는 사람도 있습니다. Blackboard는 NICKNAME 데이터 요소로 별명을 지정하는 기능(선택 사항)을 제공합니다. FIRSTNAME 대신 NICKNAME의 콘텐츠를 표시하도록 LMS를 구성하십시오. 가장 좋은 방법은 별명의 수집 및 저장을 공식화하고 중앙에서 처리하는 것입니다.
  • EMAIL. 이메일 주소는 사용자와 커뮤니케이션할 때 필요합니다.
    • Blackboard는 한 사람당 하나의 이메일 주소를 지원합니다. 사용자에게 이메일 주소가 여러 개 있는 경우 여러 데이터 소스에서 데이터를 수집하면 상충 문제가 발생할 수 있습니다. 이는 일반적으로 사용자가 교육기관 내에서 두 가지 이상의 역할을 보유한 경우(예: 학생이자 조교인 경우 또는 직원이자 부교수인 경우) 발생할 수 있습니다. 이 사용자에 대해 하나의 이메일만 선택해야 합니다.
    • Blackboard 내에서 공식 이메일 주소가 아닌 이메일 주소를 사용하려는 교수자가 있을 수 있으며, 소셜 이메일 주소와 코스 작업용 이메일 주소를 구분하려는 학생이 있을 수도 있습니다. 이를 가능하게 하려면 사용자가 Blackboard 내에서 이메일 주소를 업데이트할 수 있어야 합니다. 학생이 이메일 주소를 업데이트할 수 있을지 여부는 교육기관에서 결정할 수 있습니다. 사용자가 이메일 주소를 변경하고 나면 공식 소스에서 이 주소를 다시 업데이트할 수 없습니다. 사용자는 Blackboard 내에서 이메일 주소를 최신 상태로 유지해야 합니다. 사용자가 자신의 공식 기록을 업데이트하는 것을 잊어버릴 경우 이메일 커뮤니케이션이 잘못된 주소로 전달될 수 있는 위험이 있습니다.
  • INSTITUTION_ROLE. 이 요소는 교육기관 내 사용자 역할을 나타냅니다. 이 요소는 코스 내 사용자 역할이 아니라 교육기관 내 사용자 역할을 식별하기 위한 방법입니다. INSTITUTION_ROLE에 따라 Blackboard에서 사용자에게 표시되는 항목이 결정됩니다. 이 역할은 어떤 사용자가 애플리케이션 내에서 상승된 권한을 갖게 될지를 지정할 때도 사용됩니다. 교육기관 내 사용자 역할에 따라 사용자에게 서로 다른 포털 페이지 보기를 제공할 필요가 없는 경우에는 INSTITUTION_ROLE 데이터 요소를 'none'으로 설정할 수 있습니다.
  • SYSTEM_ROLE. 이 요소는 Blackboard 내 사용자 역할을 나타냅니다. 이 역할에 따라 Blackboard 측을 관리하는 기능이 부여됩니다. 이러한 기능으로는 시스템 관리, 코스 생성 및 코스 콘텐츠 관리 등이 있습니다. 'NONE' 역할은 시스템 관리 또는 코스 생성 권한을 제공하지 않으며, 가장 일반적으로 할당되는 역할입니다.

코스 생성

  • EXTERNAL_COURSE_KEY. 이 요소는 코스를 고유하게 식별합니다. 모든 Blackboard 사용자에게 표시되는 것은 아닙니다. 가장 좋은 방법은 이러한 데이터 요소를 쉽게 정렬하고 조작하기 위해 서식을 지정하는 것입니다. 수년간(데이터 보존 기간) 코스를 고유하게 설명하는 여러 데이터 요소를 수집해야 합니다. 학적 담당 부서에서는 적어도 지정된 학기 동안 코스를 고유하게 식별하는 번호를 유지하는 경우가 많습니다. 예를 들어, 2012년 가을 학기 동안 고유 코스 번호가 12345인 화학 301 코스를 수강하는 경우 EXTERNAL_COURSE_KEY의 값으로 2012_fall_12345_CH_301을 선택할 수 있습니다. 가능한 경우 EXTERNAL_COURSE_KEY의 모든 요소, 특히 부서 및 날짜를 동일한 길이로 설정하면 더 좋습니다. 학기는 달을 나타내는 숫자인 1, 6, 9로 나타낼 수 있습니다. 일부 타사 빌딩 블록에서는 필드가 동일한 길이일 것을 요구합니다. 이는 특히 날짜 정보의 경우 그렇습니다. 앞에서 설명한 예에서는 개별 데이터 요소를 데이터 구분 기호인 밑줄('_')로 일관되게 구분했습니다.
  • COURSE_ID. 이 요소는 코스를 정렬할 때 포털 모듈에 사용됩니다. 이 요소는 코스가 생성된 후에는 변경할 수 없습니다. 이 키는 사용자에게 표시되므로 사용자가 알아보기 쉬운 정보를 포함해야 합니다. 일반적으로 이 키는 정렬을 위해 연도 및 학기를 포함해야 합니다. 또한 부서, 코스 번호, 고유 식별자도 포함해야 합니다. 예를 들어, COURSE_ID는 2010_9_12345_CHEM_301과 같습니다. 일관된 데이터 구분 기호인 밑줄을 사용하는 것이 좋습니다. 기본적으로 '나의 코스' 포털 모듈은 COURSE_ID를 기준으로 코스를 정렬하는데, 이 기능은 코스 목록이 긴 경우 매우 중요합니다.
  • COURSE_NAME. 이 요소는 코스를 설명하는 어느 것이든 될 수 있습니다. 이 요소는 고유하지 않아도 되며, 데이터를 로드 시 변경되거나 교수자에 의해 변경될 수 있습니다. 일부 빌딩 블록은 COURSE_NAME을 기준으로 정렬됩니다.
  • TEMPLATE_COURSE_KEY. TEMPLATE_COURSE_KEY(선택 사항)는 콘텐츠와 함께 준비된 기존 코스의 이름을 나타냅니다. 일부 조직은 표준화된 콘텐츠가 있는 코스를 제공해야 하며, 이는 TEMPLATE_COURSE_KEY를 사용하여 가능합니다. 이 콘텐츠로는 파일, 설문 조사, 퀴즈, 공지 사항 및 교수자 등이 있습니다. 템플릿 코스는 코스를 생성하기 전에 완료해야 합니다. 콘텐츠는 코스를 생성할 때 새 코스에 복사됩니다. 코스를 생성한 후에 템플릿 코스를 변경해도 이전에 생성해 놓은 코스는 영향을 받지 않습니다. 템플릿 코스는 템플릿을 기반으로 새 코스를 생성하기 전에 해당하는 최종 양식 안에 있어야 합니다. 템플릿 코스에 대해 표준화된 명명 규칙을 선택하십시오. 예를 들어, 뒤에 밑줄과 몇 개의 다른 식별자가 오는 '템플릿'이 있는 모든 템플릿 코스를 시작할 수 있습니다.

등록 생성

등록이란 코스에 사용자를 할당하고 코스 내 사용자 역할(예: 학생 또는 교수자)을 정의하는 것입니다.

  • EXTERNAL_COURSE_KEY. 이 요소는 코스 데이터의 고유 키입니다.
  • EXTERNAL_PERSON_KEY. 이 요소는 사용자 데이터의 고유 키입니다. 이러한 키는 먼저 정의해야 특정한 등록 기록을 처리할 수 있습니다.
  • ROLE. ROLE 데이터 요소는 코스 내 사용자 역할을 정의합니다.

데이터 레이블 및 서식 지정

모든 데이터 소스를 식별하고, 상충 해결 규칙을 설정하고, 소스에서 모든 데이터 요소를 수집한 후에는 데이터 집합을 하나의 작업으로 처리할 수 있도록 DSK(데이터 소스 키)라는 데이터에 몇 가지 레이블을 생성해야 합니다. 또한 선택한 통합 유형별로 데이터를 올바르게 인식하고 처리할 수 있도록 데이터에 서식이 지정되어 있는지 확인해야 합니다.

데이터 소스 키 생성

데이터 소스 키는 각 기록을 개별적으로 처리하는 대신 하나의 작업으로 데이터 집합을 처리할 수 있도록 데이터 집합에 지정할 수 있는 레이블입니다. 여러 데이터 소스 키를 생성하고 이를 사용하여 Blackboard에서 데이터를 로드하고 처리할 수 있습니다.

가장 좋은 방법은 유사한 항목을 모두 함께 로드할 수 있도록 데이터 소스 키를 설계하는 것입니다. 사용자를 하나의 데이터 소스 키에 배치하고, 각 학기의 코스를 또 다른 데이터 소스 키에 배치하십시오. 이렇게 하면 사용자에게 영향을 주지 않으면서 하나의 명령으로 한 학기 분량의 코스를 효율적으로 조작할 수 있습니다. 동일한 사유에 대해 각 학기의 등록을 고유한 데이터 소스 키에 로드하십시오.

연도, 학기, 소스 및 데이터 유형을 사용하여 DATA_SRC_KEY 이름을 작성하십시오. 예를 들어, 2011년 가을 코스에는 2011_fall_SIS_courses라는 레이블을 지정할 수 있습니다.

데이터 소스 키에 대해 자세히 알아보기

데이터 서식 지정

학생 정보 시스템 통합 빌딩 블록이 각 요소를 인식하고 알맞게 처리할 수 있도록 데이터에 서식을 지정해야 합니다. 모든 데이터 요소는 해당 유형과 관련하여 식별되어야 합니다. XML(Extensible Markup Language)은 데이터를 설명하는 간단하고 자세하며 일반화된 방법을 제공합니다. XML 형식은 선택하는 통합 유형에 따라 약간 다릅니다.


추가적인 계획 정보

학생 정보 시스템 통합을 계획할 때 어떤 통합 유형을 생성할지를 결정하고 교육기관 정책 및 요구 사항에 따라 다른 결정을 내려야 합니다.

통합 유형

사용할 수 있는 통합 유형은 6가지이며, 데이터 형식은 선택하는 유형에 따라 약간 다릅니다. 시스템이 보유할 수 있는 통합 개수에는 제한이 없습니다. 하나의 시스템에 다양한 통합 유형을 보유할 수 있긴 하지만, 이러한 경우는 일반적이지는 않습니다.

  • IMS Enterprise 1.1
  • IMS Enterprise 1.1 - Vista
  • IMS 학습 정보 서비스
  • 스냅샷 플랫 파일
  • 스냅샷 XML
  • Grades Journey

각 통합 유형의 데이터 매핑에 대해 자세히 알아보려면 학생 정보 시스템 통합 생성 및 수정을 참조하십시오.

IMS 학습 정보 서비스에 대한 SSHA 비밀번호 암호화

권한 부여는 Sungard Banner에서 사용한 방법을 기반으로 합니다. 필드 매핑에서 암호화 유형을 SSHA로 설정하면 앞에 {SSHA}가 붙습니다(아직 없는 경우). SSHA 접두사가 설정 및 삽입될 뿐만 아니라 pwencryptiontype도 다음 예에 표시된 것과 같이 설정 및 삽입됩니다.

<userid useridtype="SCTID" pwencryptiontype="SSHA" password="{SSHA}OMMjWPR+6fM/iQ+ZvpWHEVGxoAEFT0JUQUE4Qz==">N00013021</userid>

커뮤니케이션 중단에 대한 계획

학생 정보 시스템과 Blackboard 간에 커뮤니케이션 문제가 발생하는 경우 중단을 처리할 방법을 계획해야 합니다. GUI에서 데이터를 통합에 수동으로 업로드할 수 있습니다. 시스템을 원활하게 실행하고 시스템 데이터를 최신 상태로 유지하려면 시스템 트리거 및 백업을 설정해야 합니다.

통합 상태 설정

Blackboard는 테스트 상태에서 새 통합을 시작할 것을 권장합니다. 이 상태를 선택하면 통합을 적용하기 전에 통합을 시험하여 일어날 수 있는 문제를 해결할 수 있습니다. 테스트가 완료되면 상태를 비활성 또는 활성으로 설정하십시오. 비활성 상태에서는 요청을 처리하거나 데이터베이스에서 데이터를 업데이트하지 않습니다. 활성 상태에서 시스템은 요청을 처리하고 데이터베이스에서 데이터를 업데이트하며 사용자에게 표시됩니다.

또한 Blackboard는 프로덕션에 릴리즈하기 전에 스테이징 또는 테스트 환경에서 이러한 통합을 생성할 것을 권장합니다.

로깅

통합 생성 시 로그 상세 표시 수준을 설정하면 선택된 통합에 대해 시스템에서 유지되는 로깅의 범위와 유형이 정해집니다. 로그는 오류 유형, 통합 및 기간 등을 활용하는 고급 검색 방법을 사용하여 필터링할 수 있습니다.

고급 구성

학습 객체 유형 및 SIS 시스템의 객체 유형은 일대일 목록에 매핑되어 있습니다. 각 객체 유형에서 삽입, 업데이트 및 삭제를 어떻게 처리할지 선택합니다.

자세히 알아보기

학습 정보 서비스 사양 입문서

학습 정보 서비스