Oracle Student Learning Implementation Guide, Release 3.1.3

Release 3.1.3

E21072-04

Contents

List of Figures

List of Tables

Title and Copyright Information

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

1 Overview

2 OSL Data Objects

- 2.1 Department Data

- 2.1.1 Schools and Institutions

- 2.1.2 Calendars

- 2.1.3 Curriculum Frameworks

- 2.1.4 Grade Sets

- 2.2 School Data

- 2.2.1 Calendars

- 2.2.2 School Curriculum

- 2.2.3 Courses

- 2.2.4 Offerings

- 2.2.5 Class

- 2.2.6 Grade Sets

3 User Provisioning

- 3.1 OSL and LDAP Attributes

- 3.2 User Roles

- 3.2.1 LT Admin Roles

- 3.2.2 LT Roles

4 Integration with Source Systems

- 4.1 Integration through DLS

- 4.1.1 Longitudinal and Partial Data

5 Default Content Integration

- 5.1 OSL Content

- 5.1.1 OSL Content Use Cases

- 5.2 General Content

- 5.2.1 General Content Use Cases

- 5.2.2 Default Content Implementation (DCI)

- 5.2.2.1 Overview

- 5.2.2.2 Security Model

- 5.2.2.3 DCI Metadata Model

- 5.2.2.4 DCI User Accounts

6 Configuration Options

- 6.1 List of Values

- 6.1.1 Updating LOVs

- 6.2 Resource Bundles

- 6.2.1 Deploying Updated Resource Bundles

- 6.3 Preferences

- 6.3.1 Site-Specific Preferences

- 6.3.2 User-Specific Preferences

- 6.3.3 User-Modifiable Preferences

- 6.4 Technical Configuration Properties

7 Functional Setup and Maintenance

- 7.1 Setup Sequence

- 7.1.1 Seed Data

- 7.1.2 Create Calendars, Curriculum Frameworks and Grade Sets

- 7.1.2.1 Special Note about Curriculum Context

- 7.1.3 Create Schools

- 7.1.4 Make Curricula Available to Schools

- 7.1.4.1 Institution Groups

- 7.1.5 Adopt Calendars, Curriculum, and Grade Sets

- 7.1.6 Load People and Their Roles and Relationships

- 7.1.7 Create School Grade Sets

- 7.1.8 Create School Courses and Course Tags

- 7.1.9 Create School Offerings

- 7.1.10 Create School Classes and Enrolments

- 7.1.11 Set Preferences

- 7.2 Setup Summary

A List of Values (LOVs)

- A.1 LOVs Matrix

B Property Files

- B.1 Property Files

C Preferences Matrix

- C.1 Preferences Matrix

D Default Content Integration

- D.1 Prerequisites

- D.2 Configuring Content Server

- D.2.1 OSL Content Users

- D.2.2 Additional Configuration Variables

- D.2.3 Content Security

- D.2.4 Override Configuration Variables

- D.3 Component Deployment

- D.3.1 Custom Components Deployment

- D.3.2 Standard Components Deployment

- D.4 UCM Schema Setup

- D.4.1 Create Table

- D.4.2 Create View

- D.5 Custom Metadata

- D.6 Add Profile Options

- D.7 Advanced Search Design

- D.8 Rules

- D.9 Roles/Groups/Permissions

- D.10 DCI Configuration Assistant

- D.11 Inbound Refinery Setup

- D.11.1 File Formats Wizard (Content Server)

- D.11.2 Inbound Refinery Conversion Options (Content Server)

- D.11.3 Conversion Listing (Inbound Refinery)

- D.11.4 Additional Renditions (Inbound Refinery)

- D.12 Using Content Server in Non-English Environments

E Oracle Internet Directory (OID) Setup for Default Content Integration

- E.1 Prerequisites

- E.2 Configuring OID

- E.2.1 Command to execute Idiff files

- E.2.2 Create Tree

- E.2.3 Create Groups

- E.2.4 Create School Groups

- E.2.5 Assign Members to Groups

- E.2.6 Configure OID Provider for UCM with Group DN

List of Figures

- 1-1 High-Level Overview of OSL

- 2-1 OSL Reference Data

- 6-1 Preference tab

- 6-2 Edit Preference page

- 6-3 Search and Select Users page

- 6-4 Search for Users

- 6-5 Edit User Preference Value

- 6-6 Updated Preference Value

- 6-7 LT User Preference Dialog

- 7-1 Functional Setup and Maintenance Tasks

- 7-2 LT Class Selector Dialog

List of Tables

- 2-1 Sample Calendar Dates

- 3-1 LT Admin Roles

- 3-2 LT Roles

- 4-1 Data Integration Issues and Considerations

- 5-1 OSL Content Use Cases

- 5-2 General Content Use Cases

- 5-3 General Content Categories

- 7-1 LT Institution Attributes

- 7-2 Setup Summary

- A-1 LOVs Matrix

- B-1 List of property files

- C-1 List of preferences

- D-1 Users definition

- D-2 List of configuration variables

- D-3 School

- D-4 Scope

- D-5 Visibility

- D-6 YesNo

- D-7 Creating Views

- D-8 List of metadata

- D-9 Creating Roles, Groups, and Permissions

- D-10 Configuration property

- E-1 Environment variables

- E-2 List of variables

- E-3 Mapping of different accounts to OSL Group

Oracle® Student Learning

Implementation Guide

Release 3.1.3

E21072-04

January 2012

Oracle Student Learning Implementation Guide, Release 3.1.3

E21072-04

Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Preface

This preface includes the following topics:

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

Audience

This document is describes and discusses the functional/business setup options and considerations in implementing the Oracle Student Learning (OSL).

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

For more information, see the following documents in the Oracle Student Learning documentation set:

- Oracle Student Learning (OSL) Installation and Deployment Guide

- Oracle Student Learning (OSL) Learning Tool Admin User's Guide

- Oracle Student Learning (OSL) Learning Tool Customization Guide

- Oracle Student Learning (OSL) Learning Tool User's Guide

- Oracle Student Learning (OSL) Programmer's Guide

- Oracle Student Learning (OSL) Release Notes

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

The script content on this page is for navigation purposes only and does not alter the content in any way.

1 Overview

Figure 1-1 provides a high-level overview of Oracle Student Learning (OSL).

Figure 1-1 High-Level Overview of OSL

The centerpiece of OSL is the Learning and Teaching Tool (LT). It is the application that is synonymous with OSL from a student, teacher, and parent perspective.

It is recommended that some form of Business Intelligence is applied to provide a range of reports and analytics. Oracle Business Intelligence Enterprise Edition (OBIEE) is pre-integrated with OSL to provide this functionality without the need for any bespoke integration effort. OSL also ships with some OBIEE dashboards that are accessed, in context, directly from the LT.

Content management is required to support some use-cases within the Learning Tool. OSL is pre-integrated with Oracle Universal Content Management (UCM) to provide this functionalityFoot 1 .

The LT cannot function without necessary "reference data". For related information, see Chapter 2. The OSL Learning Tool Administration user interface (LTAdmin) use to maintain this data (except for users, see Chapter 3. However, it is expected that much of this data would be maintained through integration with third-party source systems through the Data Loading Services (DLS), see Chapter 4.

Footnote Legend
Footnote 1:  As OSL 3.1.3 is de-coupled from the Content Management System (CMS), it may be deployed with a (non-Oracle) third-party CMS. Integration with a third-party CMS and the subsequent support, is the responsibility of the implementation party.

2 OSL Data Objects

Data that is maintained within OSL are categorized as:

- Reference Data
This is data that is non-changing (subject to minor amendments), which is entered once at initiation of the system and at periodic intervals (start of new school year or semester) by functional administrators. This data may be maintained through automated processes (using the Data Loading Services) or through the LT Admin user interface or some balance of both.

- Transactional Data
This is data that is managed and accumulated with the LT by students, teachers, and parents. This is mostly a data that pertains to learning activities, student work, and assessments.

This documentation focuses on reference data. Figure 2-1 provides a summary of OSL reference data and its interdependencies. For information on users, see Chapter 3.

Figure 2-1 OSL Reference Data

2.1 Department Data

Within OSL, certain reference data is common to the entire enterprise (also known as "The Department") and other reference data is applicable only to a school within the enterprise. OSL 3.1.3 does not support multiple departments, but "departmental data" must be "adopted" by the schools, that is the school users will only see the data that is applicable to their school.

2.1.1 Schools and Institutions

Schools exist as institutions within OSL. Non-school institutions may also be created to allow schools to be organized into hierarchies, and schools can also be organized into groups (institution groups). Ultimately, all schools are related back to the root Department, which is itself a special type of institution that is seeded during installation and cannot be removed. There can be only one Department.

2.1.2 Calendars

Calendars are essentially the "years" (calendar years, not to be confused with grade levels also known as year levels), which exist as objects in OSL. It is also possible to (optionally) define sub-calendars (for example, Semesters). Calendars (years) must be defined because, ultimately, school classes must be related back to a calendar (for example, 2010 classes versus 2011 classes).

Calendars are defined as data objects to enable different calendar dates for different parts of the world. For example:

Table 2-1 Sample Calendar Dates

Calendar Date

Start Date

End Date

Description

2010

01 Jan 2010

31 Dec 2010

Southern Hemisphere

2010-11

01 Aug 2010

31 Jul 2011

Northern Hemisphere

2011

01 Jan 2011

31 Dec 2011

Southern Hemisphere

2011-12

01 Aug 2011

31 Jul 2011

Northern Hemisphere

It is possible to define multiple overlapping calendars. As calendars must be adopted by schools, it is possible to have, for example, some schools following a southern hemisphere calendar, while others follow a northern hemisphere calendar.

2.1.3 Curriculum Frameworks

Curriculum Frameworks are complex data objects within OSL. They are pivotal to much of the functionality provided by OSL. This is one key differentiators between OSL and other K-12 applications, which typically only define curriculum as metadata attributes. Curriculum is explained in greater detail in the “Implementation and Adoption” training.

2.1.4 Grade Sets

Grade sets are called "Graded Proficiency Sets" in the LT Admin. They define the set of grades (such as A+ to F or High-Med-Low) that a teacher can apply as an assessment of student work.

2.2 School Data

The enterprise (or Department) reference data must be adopted, and extended upon, by schools so that the school users will only see the data that is applicable to their school.

2.2.1 Calendars

A school adopts those calendar(s) defined by the Department that are applicable to the school. In a typical implementation we would expect all schools to adopt all department calendars (years).

A school may (optionally) extend an adopted calendar by adding in their own (unique to the school) sub-calendar, but this non-typical and serves little purpose.

2.2.2 School Curriculum

A school adopts those curriculum framework(s) defined by the Department that are applicable to the school (and have been made available to the school). The curriculum framework is also adopted in the context of a calendar (year). For example, the school may choose to adopt the "State Curriculum" in 2010 and then adopt the "National Curriculum" in 2011. It is also possible (and usual) for a school to adopt several curricula in any given calendar.

2.2.3 Courses

Schools define their own set of courses (such as Grade 8 Mathematics, Grade 12 Physics, Grade 1 General Studies). Unlike the previously mentioned objects, courses are not defined centrally and adopted, therefore schools are free to implement courses in any way that is appropriate to the school. It is very common for schools to run "alternative" courses that may cross multiple grade levels and disciplines (such as "Middle School Communications"), that is there are no "standard" course definitions for schools.

2.2.4 Offerings

A school must "offer" a Course in the context of a School Curriculum. For example: "Grade 8 Mathematics" may be offered against the "State Curriculum" in 2010; then it may be offered against the "National Curriculum" in the following year.

2.2.5 Class

A class represents the grouping of students and teachers that undertake a particular course of study. Classes are tied to Offerings. Typically, there are many classes per offering (such as "Mathematics 8A", "Mathematics 8B", and so on) with each class normally having anywhere between 25-50 students with one teacher. OSL allows for multiple teachers of a class. Classes are mandatory because all learning tasks are ultimately tied back to a class.

2.2.6 Grade Sets

Typically, schools simply adopt the applicable grade sets defined by the Department. However, schools may (optionally) define their own grade sets (unique to school).

The script content on this page is for navigation purposes only and does not alter the content in any way.

3 User Provisioning

The provisioning of users in the Oracle Student Learning (OSL) environment is primarily a technical concern. However, there is some overlap between user provisioning and functional administration. It is important that a functional administrator has a clear understanding of the provisioning process.

The Learning Tool (LT) can be deployed as a standalone application. However, a completely functional OSL environment requires integration with a content management system. As an enterprise application, OSL is typically deployed in a broader environment as part of the K-12 enterprise solution for learning and teaching. This could include other components such as portal, collaboration and communication tools, school administration systems, and so on.

It is for these reasons that:

- OSL requires external identity management (LDAP)

- Single sign-on (SSO) is a highly recommended component

- Users are not maintained in LT Admin

For information on integrating a content management system, see Chapter 5.

3.1 OSL and LDAP Attributes

Configuring LDAP and SSO to work with OSL is not within the scope of this guide. However, it is important to understand the relationship that the LDAP attributes have with OSL.

- OSL Party Identifier
A user in OSL must have a Party Identifier that corresponds to the SSO id held in the LDAP directory. The Party Identifier should be a non-changing attribute that cannot be inferred from the user's name or other attributes. A State assigned number is an excellent candidate for the Party Identifier, whereas a personal email address is a poor candidate.

- LDAP User Groups
A user must belong to a group in the LDAP directory corresponding to the user's role(s) in OSL. The default implementation of the LDAP groups are a direct mapping to the OSL roles as specified in Section 3.2 and articulated in the OSL Installation and Deployment Guide.

Regardless of the mechanism that is used to provision the users, ultimately users must be:

- added to the OSL database with their correct Party Identifier

- added to the LDAP directory with their correct Group assignments

3.2 User Roles

Users must be provisioned into OSL with an appropriate role. Users can have multiple roles. There are some roles that are used for two purposes.

3.2.1 LT Admin Roles

There are two types of administration roles: Department and School. Department roles are enterprise-wide, whereas School roles are in relation only to a specific school.

Table 3-1 LT Admin Roles

Role

Relationship

Department Administrator

Assign user roles, maintain Institutions, and preferences

Department Curriculum Administrator

Maintain Calendar, Curriculum Frameworks, and Graded Proficiency Sets

School Administrator

Assign user roles and maintain school-based preferences

School Curriculum Administrator

Maintain school curriculum, graded proficiency sets, courses, offerings, classes, and enrollments

3.2.2 LT Roles

A person may be defined as a STUDENT, TEACHER, or PARENT within the LT. The role definition is inferred through the person's relationships as specified in the table below.

Table 3-2 LT Roles

Role

Relationship

STUDENT

Requires a current "student" relationship to a school

TEACHERFoot 1

Requires a current "teacher" relationship to a school

PARENT

Requires a current "parental" relationship to a student

Footnote 1 Any person defined in OSL as a "Teacher", which is typically inclusive of school principals and other support staff such as teacher's aides.

The script content on this page is for navigation purposes only and does not alter the content in any way.

4 Integration with Source Systems

Integration with source systems extends to those elements of reference data identified in Figure 2 on page 7 of Chapter 2, "OSL Data Objects"Foot 1 . The integration mechanism is a technical concern that is outside of the scope of this guide. However, because it is possible to maintain this data through either the LTAdmin user interface or through automated integration with source systems, the functional administrators of an OSL environment must be very clear about the correct protocols and procedures for the administration of reference data.It should be noted that, as a general rule, reference data objects in OSL contain external identifier attributes that facilitate integration through the DLS (and SIF). These external identifiers are not exposed through the LTAdmin UI.

4.1 Integration through DLS

Data Loading Services (DLS) extend to all reference data objects. This makes it possible to maintain all reference data through automated processes and completely by-pass the need to use the LTAdmin user interface. In practice, it is very likely that there will be certain elements of data that are either simply not available in any source system (or in a data-centric format) or impractical to maintain in this manner.

To reduce the administrative burden and limit the likelihood of data (mis)entry issues, it is preferable to automate as much of the reference data maintenance as possible. Specific integration requirements may vary, the following table provides a summary of issues and considerations.

Table 4-1 Data Integration Issues and Considerations

Classification

Data Object

Issues/Considerations

Department

Schools

As schools are usually only ever created once, and as the creation of a school in the LTAdmin user interface is fairly simple, there is an argument to suggest that it may be simpler (for a small implementation) to maintain the list of schools manually in the user interface (UI).

However, as most other data will reference schools (especially the user provisioning process) it becomes problematic if schools are not maintained through integration with a source system.

Department

Curriculum Framework

Curriculum Frameworks are unlikely to exist in data-centric format (to level of detail needed by OSL). Furthermore, only a few Curriculum Frameworks are ever defined (maybe once a decade) so it is generally less effort to maintain manually through the LTAdmin (Department Curriculum Administrator).

NOTE: The majority of the effort is usually in the thinking needed to "translate" curriculum into a data-centric model.

Department

Calendar

Minimal effort is required to maintain calendars (setup once), however, some consideration might be given to automating the load of calendars to facilitate the adoption of calendars by schools.

Department

Grade Sets

Typically, Grade Sets do not exist in data-centric format. Only a few Grade Sets are ever defined and they are not onerous to enter and maintain manually through LTAdmin (Department Curriculum Administrator).

School

Calendar, School Curriculum, and Grade Sets

This would be part of the integration flow related to the creation of schools. Typically we would expect an annual process to automate the adoption of:

- the upcoming calendar year

- curricula that will be in operation in the school in the upcoming year

- grade sets that will be active in the school in the upcoming year

The creation of school-based sub-calendars and grade sets is not recommended, as this only serves to add administrative burden at the school level for no real benefit.

School

Courses, Offerings, and Classes

Typically, this data is maintained in (different) local school-based systems (often home-grown) or in spread-sheets (or not at all) in smaller schools.

Automated integration with source systems is preferred as it would save ongoing administrative overhead in schools.

The biggest challenge is to provide K-12 business-centric consultancy to assist with standardizing (human) business processes.

4.1.1 Longitudinal and Partial Data

It should be highlighted that OSL maintains a complete longitudinal record of data to a level of detail that often does not exist in current systems. Many source systems only hold current data (for example, to which Grade a student belongs) or partial data (for example, a listing of Course with no reference to which Curriculum they are offered against). Dealing with source data issues is usually the biggest challenge in any implementation yet is often not given the due consideration it deserves during implementation planning.

Footnote Legend
Footnote 1: User provisioning is documented separately in Chapter 3, "User Provisioning".

5 Default Content Integration

There are some different cases where students, teachers, and/or parents need to consume and/or interact with content through the OSL LT. The LT includes APIs that allow an implementation of OSL to build integration with a third-party Content Management System (CMS), to support these use cases. However, as content management is a significant part of LT functionality, OSL provides a default pre-integration with Oracle Universal Content Management (UCM).

5.1 OSL Content

"OSL Content" is content that is managed and controlled by OSL. This content is only accessible to OSL users through OSL. It is content that only has meaning in the context of OSL. OSL content includes files and in-line audio recording that are attached to:

- Learning Items (lessons and activities);

- Observations (comments about students); and

- Student Submissions (work completed by students).

The preconfiguration for OSL Content is a technical consideration that is outside the scope of this guide. For more information, see Chapter 6 of Oracle Student Learning Installation and Deployment Guide.

5.1.1 OSL Content Use Cases

The OSL Content Use Cases are summarized in the following table.

Table 5-1 OSL Content Use Cases

OSL Content Use Case

Description

Open file

This is where the student, parent, or teacher wishes to open a file that has been attached to an OSL objects listed above. In this case, the attachment behaves as a normal browser link and is handled by the browser on the client. So, for example, if the attachment is an MS Word document: a user on Windows XP using Internet Explorer, may find the document open directly in the browser; Whereas a user on Windows 7 using Google Chrome, may find that the document is automatically downloaded.

Open audio file

This is where the student, parent or teacher wishes to open an in-line audio recording that has been attached to an OSL objects listed above. In this case, the LT displays a Java applet that plays back the audio recording (JRE required).

Attach file

This is where the student, parent, or teacher wishes to attach a file to an OSL objects listed above. In this case, the user selects a local file using the standard operating system's file-browser dialog.

Record in-line audio

This is where the student, parent or teacher wishes to attach an in-line audio recording to an OSL objects listed above. In this case, the LT displays a Java applet that is used to record the audio (JRE required).

Remove Attachment

This is where the student, parent, or teacher wishes to remove a file or in-line recording from an OSL objects listed above.

Upload OSL Content

This is where the student, parent, or teacher wishes to upload a file to an OSL objects listed above. In this case, the user clicks the Upload tab in the RichDataEditor and selects a file using the file-browser dialog. A file is uploaded and displayed along with the rich data text.

5.2 General Content

"General Content" is content that is managed and controlled outside of the context of OSL. The interaction of OSL with General Content includes:

- References (hyperlinks) to and images embedded from General content within

- Learning Items (lessons and activities);

- Observations (comments about students); and

- Student Submissions (work completed by students).

- Exporting (publishing) Learning Items (lessons and activities) from OSL into General Content

- Importing (retrieving) Learning Items (lessons and activities) from General Content into OSL

As OSL has no control over this content, it is very much the decision of the specific implementation as to how to configure their CMS for General Content usage.

5.2.1 General Content Use Cases

From an OSL perspective, the use cases listed in the following table must be supported.

Table 5-2 General Content Use Cases

General Content Use Case

Description

Open resource

This is where the student, parent, or teacher wishes to open a reference has been attached to an OSL Learning Item, Observation, or Submission. In this case, the reference behaves as a normal browser link and is handled by the browser on the client. So, for example, if the attachment is an MS Word document: a user on Windows XP using Internet Explorer, may find the document open directly in the browser; Whereas a user on Windows 7 using Google Chrome, may find that the document is automatically downloaded.

A variation is where the reference is an image that the user chooses to display within the (html) text rather than as a hyperlink.

Find resource

Scenario 1

Where the student, parent, or teacher wishes to find:

- a resource to reference (hyperlink); or

- an image to display

within the (html) text of an OSL Learning Item, Observation or Submission.

Scenario 2

Where the teacher wishes to find a previously exported Learning Item to import into a lesson plan.

Upload resource

Where the teacher wishes to export a Learning Item from OSL into the CMS.

Associate context

This is invoked after the "Find resource" use case. In this case, the OSL context (which object in OSL is referencing the content item) is returned to the CMS.

Disassociate context

The reverse of the "Associate context" use case. This is where the user has removed a content reference in OSL.

5.2.2 Default Content Implementation (DCI)

The configuration of General Content is outside the scope of OSL. However, this release provides a default implementation of Oracle UCM 11g for General Content. DCI configurations have been designed to support generic requirements of K-12 education and may be easily and quickly applied. The configuration of the DCIs described in Appendix D.

5.2.2.1 Overview

The DCI provides a simple and effective security and metadata model that makes it easy for administrators, teachers, students, and parents to use the content system. As the DCI is a configuration of Oracle UCM 11g (not a customization) it is possible to modify the DCI configurations (for example, extend the metadata attributes, introduce additional profiles, and so on) to meet specific requirements.From the administrator, teacher, student, and parent perspective, the DCI provides content in two "scopes", Public and School. Public content is accessible to all users of the system, whereas School content is only accessible to members of the school.Administrators can publish any content (files) as "Endorsed" meaning that when a person performs a general search for content he/she will find all endorsed content (Public and School) matching the search term.The DCI provides a simplified "check-in" screen that makes it very easy for administrators and teacher to add files into the content system. Teachers may add both Public and School content but are not able to "endorse" the content (the endorsement must be made by an administrator). Teachers can direct other users (students, parents, teachers, and administrators).

5.2.2.2 Security Model

General content is stored in the default ("Public") security group. Access to documents is controlled through "Document Accounts".

All access to General content from within the OSL LT are performed as the logged-in user.

General content fits one "categories" specified in the following table.

Table 5-3 General Content Categories

Category

Description

Document Account

Metadata

Public

To enable sharing of documents across schools at the grass-roots level. Only teachers and administrators (school or department) can upload documents of this category. The documents are accessible to all users (students, teachers, and parents) but not searchable. Should a teacher wish to make a document searchable, s/he should ask an administrator to update the document Department (Endorsed).

PUBLIC

Scope=Public

Visibility=All

Endorsed=FALSE

Searchable=FALSE

Department

Endorsed

To enable the department to publish endorsed documents. Only department administrators can upload documents of this category. The documents are available to and searchable by all users.

ENDORSED/DEPARTMENT

Scope=Public

Visibility=All

Endorsed=TRUE

Searchable=TRUE

School

Endorsed

To enable schools to publish endorsed documents to all members of the school. Only school administrators can upload documents of this category. The documents are available to, and searchable by, all members of the school.

ENDORSED/SCHOOL/SchoolID

Scope=[School Name]

Visibility=All

Endorsed=TRUE

Searchable=TRUE

School

Unendorsed

To enable sharing of documents within a school at the grass-roots level. Only teachers and school administrators can upload documents of this category (to their own school). The documents are accessible to, and searchable by, all members of the school (students, teachers and parents).

UNENDORSED/SCHOOL/SchoolID

Scope=[School Name]

Visibility=All

Endorsed=FALSE

Searchable=TRUE

School

Teacher-only

Same as School (Unendorsed), except that the documents are only accessible to teachers and administrators of the school.

UNENDORSED/SCHOOL/SchoolID

Scope=[School Name]

Visibility=Teachers

Endorsed=FALSE

Searchable=TRUE

5.2.2.3 DCI Metadata Model

The following metadata attributes, in addition to mandatory system metadata elements, are associated with General content resources:

- Scope

- Visibility

- Endorsed

- Searchable

- Tags

- OSL Framework Item ID

- OSL Outcome ID

5.2.2.4 DCI User Accounts

To ensure that students, parents, and teachers can access the correct content categories, they must be allocated with appropriate Document Accounts. The allocation is based on their role(s) as mapped to groups specified in the LDAP directory.

Since DCI security extends to schools, some additional configuration of Oracle Internet Directory (OID) is required for the DCI. This is described in Appendix E.

The script content on this page is for navigation purposes only and does not alter the content in any way.

6 Configuration Options

In addition to the reference data that is expected to be loaded into the system, there are some other configurations that can be made to OSL. These fall into the following categories:

6.1 List of Values

There are two types of List of Values (LOVs) – those which can be customized and those which cannot. If a LOV can be customized, therefore either:

- some seeded values can be removed or end-dated; and/or

- additional values can be added.

Regardless of whether the LOV can be customized or not, the Description (that is displayed to users) of any LOV and any value can always be changed.

The complete set of LOVs is listed in Appendix A.

6.1.1 Updating LOVs

The LOVs are seeded at the installation of OSL and cannot be updated by an administrator in the LTAdmin UI. The LOVs must be updated by a technical administrator using the DLS. The process for updating the LOVs through DLS is outside the scope of this guide and is described in the OSL Programmer's Guide.

6.2 Resource Bundles

The text labels, error messages, icon sets, and images that appear everywhere throughout the LT (that is all of the visual elements of the LT) are controlled by "resource bundles". The resource bundles are a set of name-value pairs that the UI uses to interpret the values rendered in the UI.

For example:

DEFAULT.DATE.FORMAT=dd MMM yyyy

Specifies the dates are displayed like "17 Sep 2010" by default in the LT.

If this was changed to

DEFAULT.DATE.FORMAT=mm/dd/yyyy

Then the dates would be displayed like "09/17/2010" by default.

The resource bundles are contained (as embedded files) in Appendix B. The OSL Learning Tool Customization Guide describes the location of each image and label across OSL.

6.2.1 Deploying Updated Resource Bundles

Like LOVs, Resource Bundles are seeded at the installation of OSL and cannot be updated by an LTAdmin user through the UI. Updated Resource Bundles must be deployed (onto the web server) by a technical administrator. The process for deploying resource bundles is outside the scope of this guide and is described in Oracle Student Learning Installation and Deployment Guide.

6.3 Preferences

Unlike LOVs and Resource bundles, "preferences" are set through the UI. Preferences are used to control specific behaviors of the LT, for example whether teachers are able to hide feedback (assessment) from their students or not.

The complete set of preferences is listed in Appendix C.

Some preferences are site-specific, which means that they apply to the enterprise as a whole. For example: OSL_PARENT_ACCESS_TO_DISCUSSIONS, which controls whether parents can access discussion posts, is site-specific and so applies to all parents.

Other preferences are user-specific, which means that they apply to individuals. For example: OSL_STUDENT_WORKSPACE, which controls which UI (Advanced, Intermediate or Basic) is presented to each student, is user-specific and can be set differently for different students.

Furthermore, some user-specific preferences may also be controlled by the users themselves (user-modifiable). For example: OSL_STUDENT_WORKSPACE_BACKGROUND_IMAGE, which controls which background image is presented on a student's UI, is user-modifiable and so can be controlled by the student him/herself.

6.3.1 Site-Specific Preferences

Site-specific preferences can be set by Department Administrators onlyFoot 1  through the LTAdmin UI as follows:

1. Select the Preference tab.

2. Enter a search term and click the Search button (if no search term is entered then all preferences will be returned).

Figure 6-1 Preference tab

3. Select a preference (by clicking on the row) and click the Edit icon.

Figure 6-2 Edit Preference page

4. Change the Site Value as required and click the Save and Return button (or alternatively, click Cancel to make no change).

6.3.2 User-Specific Preferences

User-specific preferences can be set by both the Department and School Administrators. However, only Department Administrators can change the default value of the preference (which applies where the preference has not been specified for a given user). The preferences are set through the LTAdmin UI as follows:

1. Select the Preference tab.

2. Enter a search term and click the Search button.

3. Select a preference and click the Edit icon.

4. Since this is a user-specific preference, a dialog is presented that enables the administrator to (optionally) select the users' for whom the preference will be set. If the Department Administrator wishes to set the default value, then proceed to the next step. If, instead, the School (or Department) Administrator wishes to set the preference value for some specific users, then proceed to step 7.

Figure 6-3 Search and Select Users page

5. Do not perform a search, just click the OK button.

6. Change the Site Value as required and proceed to the last step.

7. Enter some search terms and click the Search button.

Figure 6-4 Search for Users

8. Select the desired users and click the OK button

9. Select the users (from the bottom half of the screen) whose preference values are to be set/changed and click the Edit icon.

Figure 6-5 Edit User Preference Value

10. Set the preference value for the selected users and click the OK button. Notice how the Preference Value column is updated.

Figure 6-6 Updated Preference Value

11. Click the Save and Return button.

6.3.3 User-Modifiable Preferences

Some user-specific preferences can also be modified by the user. That means that the user can set the preference directly from the LT. Figure 6-7 illustrates the User Preferences dialog that is presented to in the teacher LT UI.

Figure 6-7 LT User Preference Dialog

6.4 Technical Configuration Properties

The technical configuration of OSL is described in the Oracle Student Learning Installation and Deployment Guide and, in the main, has no bearing on feature functionality. However, there is a configurable property called osl.lt.web.enable.FrameworkDataCaching that determines whether Curriculum Framework data is cached in the web layer.

Functional administrators must be aware that if this property is enabled, then any changes made to a Curriculum Framework (by a Department Curriculum Administrator in the LT Admin UI or through Data Loading Services) do not take effect until after a restart of the OSL LT application.

Footnote Legend
Footnote 1: School Administrators are able to view site-specific preferences

The script content on this page is for navigation purposes only and does not alter the content in any way.

7 Functional Setup and Maintenance

Before students, teacher, and parents can start using the LT, all of the reference data must be loaded and preferences must be set appropriately. Note that:

- The majority of these tasks occur at initialization.

- Some/all of the tasks must be revisited periodically, typically at the start of each new school year.

- User data (roles and relationships, and class enrolments) are the only elements of reference data that need to be regularly updated.

Regardless of the extent to which automated processes are used, the sequence of the tasks must be properly thought out and planned. In Figure 7-1, all of the functional setup and maintenance tasks are laid out in a flowchart to indicate the interdependencies between them.

Figure 7-1 Functional Setup and Maintenance Tasks

The instructions on how to perform each of the setup tasks using the LTAdmin are described in the Oracle Student Learning Learning Tool Admin User's Guide Release.

7.1 Setup Sequence

This section outlines the steps that need to be followed, post installation and configuration of OSL, to get the first school users accessing the LT.

7.1.1 Seed Data

When OSL is first installed, it is seeded with the root Department (Institution) and some (technical) users to enable the underlying technical processes (data loading, content integrations, and so on).

The name of the root Department is set by the initialization script that is run as part of the installation of OSL and is exposed to Department Administrators only (in the LTAdmin UI). The Department Administrator cannot change the name of the root Department through the LTAdmin UI as required.

The only other question regarding seeded data is whether it is intended to manually set Preferences, create Schools, Curriculum Frameworks and Calendars before loading any production users. If this is the case, then an initial Department Administrator user must be loaded through DLS before the integration with the source system.

7.1.2 Create Calendars, Curriculum Frameworks and Grade Sets

The sequence in which these objects are created or loaded is of no consequence. The objects may even be created after loading the schools and people. However, these objects must be created so they can be "adopted" by schools (and it is usually simpler to adopt calendars, curricula, and grade sets at the instantiation of the school).

These data objects are essentially "fixed". Curriculum Frameworks typically have a life span of several years.

7.1.2.1 Special Note about Curriculum Context

The OSL Learning Tool Admin User's Guide describes how to create a Curriculum Framework. This includes some sections that describe the management of "Contexts" (specifically sections: 5.3.8 Managing Department and School Contexts; 6.2.3 Adopting Contexts for a Framework Item; and 6.2.4 Removing Contexts for a Framework Item).

Curriculum Contexts are legacy items that will not be supported in the future and, therefore, should not be implemented in any new deployments of OSL.

7.1.3 Create Schools

Institutions (schools) may be created manually using the LTAdmin UI but, in practical terms, this is really only an option for pilots or very small implementations.

As is the case with People, there are certain legacy attributes that will be discontinued in the future, as listed in Table 7-1 below.

Table 7-1 LT Institution Attributes

Institution Attribute

Description

Institution Name

Required

Institution Type

Required - LOV: OSL_ INSTITUTION_TYPE (such as Primary)

Parent Institution

Required

External Identifier

Optional - used to match Institution to source system entity

External System Identifier

Optional - specifies the source system

List Of Phone Numbers

Legacy - Compound Object

List Of Addresses

Legacy - Compound Object

List Of Email Addresses

Legacy - Compound Object

7.1.4 Make Curricula Available to Schools

The Curriculum Frameworks (created in Section 7.1.2, "Create Calendars, Curriculum Frameworks and Grade Sets") must be made available to schools (so that they can be later adopted). Making curricula available is actually part of the Curriculum Framework creation process; that is whenever a school is created, the curriculum frameworks must be modified so that the new school can be added. This is typically a process that would be automated as part of on-boarding a new school or curriculum (which would normally happen after a school year in preparation for the following year).

7.1.4.1 Institution Groups

Institution groups are used to streamline the process of availing Curriculum Frameworks to schools. For example, a "Special Developmental" Curriculum Framework would be made available to a "Special Developmental School" Institution Group.

Whenever a new "Special Developmental" school is created, it only needs to be assigned to the group. Conversely, if a new "Special Developmental" Curriculum Framework is created, it only needs to have the group assigned to it (rather than all of the Special Developmental schools).

7.1.5 Adopt Calendars, Curriculum, and Grade Sets

The "adoption" of calendars, curricula, and grade sets by schools may be performed manually in the LTAdmin UI by a School Curriculum Administrator, but this places an administrative burden on schools. It is therefore recommended that the process is automated as part of the instantiation of a school (that is part of create school workflow). This is typically a process that would be automated as part of an annual "roll-over" process – that is after each school year.

7.1.6 Load People and Their Roles and Relationships

After the Institutions have been loaded, it is then possible to assign people to them. It is this assignment (relationship) that determines the person's roleFoot 1  (as outlined in Section 3.2, "User Roles"). In OSL, relationships are never (and cannot be) deleted. Changing relationships are managed through start-dates and end-dates.

It is not technically necessary to create the people-institution (and people-people) relationships as part of the same process by which users are loaded (provisioned). Therefore, it is possible to load people without any relationships (or role assignments) much earlier in the process and add the relationships later. It is also possible to manually assign the relationships in the LTAdmin UI. Notwithstanding this, it is expected that relationships would typically be loaded as part of the user provisioning process.

Loading people and their roles and relationships is an ongoing process. Typically, in a production system, we would expect this to occur through a publish-subscribe or routine batch process, so that updates occur in near real time or with a maximum latency of 24 hours.

7.1.7 Create School Grade Sets

While it is possible for schools to create their own Grade Sets, it is more typical (and recommended) that schools adopt Grade Sets from the Department. School Grade Sets can be created at any time (even in production).

7.1.8 Create School Courses and Course Tags

School Courses can only be created after the school has been created and must be created before the school Offering. The definition of a Course is very simple, it includes a (unique to school) Name (50 Char) and Code (15 Char).

School Courses may only be deleted where there is no dependent data (that is Offerings) but are more typically end-dated when they are no longer active. School courses only need to be created once, as they are then re-offered from one year to the next. Typically, there would be a review of courses after each year, where a few minor changes might be made (a new course created, an old course retired or a course renamed).

Tags should be applied to courses so that the classes (which ultimately hang off the courses) can be navigated in the LT, as illustrated in Figure 7-2.

Figure 7-2 LT Class Selector Dialog

7.1.9 Create School Offerings

Offerings can only be created after the school Courses have been created and the school has adopted both the Curriculum and Calendar (since an Offering is tied to a Course, Curriculum, and Calendar).

Offerings must be created before Classes can be created. The definition of an Offering is very simple, it includes a (unique to school calendar) Name (50 Char) and Code (15 Char).

School Offerings may only be deleted where there is no dependent data (that is Classes). Offering start-date and end-dated must fall within the associated school calendar.

The creation of school offerings typically occurs after each year (or semester) in preparation for the following year.

7.1.10 Create School Classes and Enrolments

The ultimate object for creation is the School Class. A School Class is tied to an Offering. The definition of a Class is very simple, it includes a (unique to Offering) Title (80 Char).

School Classes may only be deleted where there is no dependent data (that is Enrolments or Learning Items that have been added by the teacher in the LT). Class start-date and end-dated must fall within the associated offering's start and end dates.

The creation of school classes typically occurs after each semester in preparation for the following semester. However, there are often last minute changes that are made to classes (new classes added, classes merged, or removed and so on) that can occur even after the new semester has begun.

Students and Teachers are enrolled into classes with a specified start-date and end-date, to cater for instances where a student (or teacher) may arrive or leave mid semester. Changes to class enrolments occur quite frequently during the normal course of a semester.

Occasionally, a user is mistakenly enrolled in a class, in which case the user's enrolment can be deleted, but only if there are no Learning Items that have been added to the class by an assigned teachers. After this point, Student and Teacher enrolments in the class may only be end-dated.

7.1.11 Set Preferences

Preferences can be set at any stage (even in production), and preferences may even be loaded through DLS (as may be the case for the student workspace). But, it is expected that most preferences will be set manually in the LTAdmin UI by a Department Administrator. It should be performed before UAT.

7.2 Setup Summary

The previous section outlines the sequence through which the functional setup tasks need to occur to ready an OSL environment for use by students, teacher, and parents. The following table summarizes all of these tasks including their dependencies and expected frequencies.

Table 7-2 Setup Summary

Data Object

Dependencies

Frequency

Comment

Method

Calendar

Department

initial, annual

Set calendars at setup. Simple task performed manually in the UI. Possible to create calendars many years in advance, but likely to create calendars for upcoming years as required.

Dept Curric Admin

DLS

Curriculum Framework

Department

initial as required

Curriculum Frameworks are “fixed”. New Frameworks might be defined every few years.

Dept Curric Admin

DLS

Grade Set

Department

initial as required

Grade Sets are “fixed”. New Grade Sets might be defined once or twice per decade.

Dept Curric Admin

DLS

School (Institution)

Parent Institution (Department)

initial as required

Schools are “fixed”. On-boarding a new school (or closing an old one) would be planned ahead of time (i.e. not ad-hoc).

DLS

Dept Admin

SIF 2.2

People

NULL

initial ad-hoc

After the initial load of people, new people are provisioned (and un-provisioned) on a daily basis.

DLS

SIF 2.2

Teacher/ Student Relationship

SchoolPerson

initial ad-hoc

Teachers and students are provisioned (and un-provisioned) on a daily basis.

DLS

Dept Admin

School Admin

SIF 2.2

Parent Relationship

Person

initial

ad-hoc

Parents are provisioned (and un-provisioned) on a daily basis.

DLS

Dept Admin

School Admin

SIF 2.2

School Admin Role

SchoolPerson

ad-hoc

Assignment (and un-assignment) of school admin roles should be delegated to the schools.

School Admin

Dept Admin

DLS

SIF 2.2

Dept Admin Role

DepartmentPerson

initial

ad-hoc (infrequent)

There would only ever be a handful of Department Administrators.

Dept Admin

DLS

SIF 2.2

Institution Group

NULL

initial as required

Should only be created to support assignment of Curriculum Frameworks to schools.

Dept Admin

DLS

School Calendar

SchoolCalendar

initial

annual

Adopt Calendar - Ideally part of school on-boarding and annual rollover process.

DLS

Dept Curric Admin

School Curric Admin

School Curriculum

School CalendarCurric Fwk

initial

annual

Adopt Curriculum - Ideally part of school on-boarding and annual rollover process.

DLS

Dept Curric Admin

School Curric Admin

School Grade Sets (Adopt)

SchoolGrade Sets

initial as required

Adopt Grade Set - Ideally part of school on-boarding and Grade Set creation.

DLS

Dept Curric Admin

School Curric Admin

School Grade Sets (Create)

School

as required

Not recommended. Manual process if required.

School Curric Admin

DLS

School Courses

School

initial

ad-hoc (infrequent)

Reviewed by schools after each year with minor changes. Ideally there would be minimal latency between changes made in schools and flow on to the LT in an automated process.

DLS

School Curric Admin

School Offerings

School CalendarSchool Courses

initial

ad-hoc (infrequent)

Created by schools after each year and/or semester. Ideally there would be minimal latency in flow on to the LT.

DLS

School Curric Admin

School Classes

School Offerings

initial ad-hoc

Created by schools after each year and/or semester. Expect frequent changes even in to early part of semester. Ideally there would be minimal latency in flow on to the LT.

DLS

School Curric Admin

Class Enrolments

School Classes

initial ad-hoc

Created by schools after each year and/or semester. Expect frequent changes throughout semester. Ideally there would be minimal latency in flow on to the LT.

DLS

School Curric Admin

Preferences

NULL

initial as required

Only preference that is subject to ad-hoc change is Student Workspace.

Dept Admin

School Admin

DLS

Footnote Legend
Footnote 1: In the case of Parents, this is a person-person relationship (that is Parent to Child)

A List of Values (LOVs)

This appendix describes each of the LOVs that are used by OSL.

A.1 LOVs Matrix

The following table provides a list of LOVs.

Cust – LOV can be customized

Remv – Value can be removed or end-dated

Table A-1 LOVs Matrix

LOV

Purpose

Value

Value Description

Cust

Remv

OSL_ACCESSIBILITY_LEVEL

The level of accessibility.

Yes

ACCESSIBILE

Supports accessibility features

No

INACCESSIBLE

Accessibility features are removed to optimize performance

No

SCREEN_READER

Accessibility features are added to improve behaviour in a screen reader, but not for users

No

OSL_ADDRESS_USAGE_TYPE

Presented to the administrator as options for the purpose of an address.

No

HEADQUARTERS_FOR

No

HOME

No

OTHER

No

TEMP_ADDRESS

No

VACATION_HOME

No

PRIMARY

No

PRIMARY_HOME

No

MAILING

No

OSL_APPROVAL_STATUS

Not used

OSL_ASSESSED_OUTCOME_TYPE

Denotes the type of an assessed outcome.

No

C

Confirmation

No

D

Demonstration

No

OSL_ASSESSMENT_TYPE

Denotes the type of an assessment.

No

G

Graded assessment

No

N

Numeric (marks) assessment

No

OSL_COLLECTION_CATEGORY

Denotes the type of a collection.

No

CLASS

Class collection

No

GROUP

Group collection

No

LEARNINGITEM

Learning item collection

No

LEARNINGPLAN

Learning plan collection

No

OSL_COLLECTION_GROUP_RELATION

Denotes the type of relationship between two collections.

No

CLASS-GROUP

Class-core group relationship

No

LEARNINGPLAN-CLASS

Learning plan-class group relationship

No

LEARNINGITEM-CLASS

Learning item-class group relationship

No

EXTERNAL_CLASS-LEARNINGPLAN

External class-learning plan group relationship

No

OSL_COLLECTION_RELATIONSHIP

Denotes the type of relationship that a party has with a collection.

No

STUDENT_OF_CLASS

Student of class

No

TEACHER_OF_CLASS

Teacher of class

No

STUDENT_OF_CORE_GROUP

Student of core group

No

TEACHER_OF_CORE_GROUP

Teacher of core group

No

STUDENT_OF_LEARNING_PLAN

Student of learning plan

No

STUDENT_OF_LEARNING_ITEM

Student of learning item

No

EXTERNAL_STUDENT_OF_CLASS

External student of class

No

OSL_CONTACT_POINT_PURPOSE

Denotes the purpose of a party's contact point.

No

ASSISTANT

Assistant

No

BUSINESS

Business

No

HOME_BUSINESS

Home business

No

PERSONAL

Personal

No

EMERGENCY

Emergency

No

HOMEPAGE

Homepage

No

OSL_CONTACT_POINT_TYPE

Denotes the type of a party contact point.

No

EMAIL

Email

No

FAX

Fax

No

PHONE

Phone

No

PAGER

Pager

No

SMS

SMS

No

WEB

Web

No

OSL_CONTENT_RESOURCE_TYPE

Denotes the type of a content resource

No

FILE

File resource

No

IMAGE

Image resource

No

AUDIO

Audio resource

No

OSL_CUSTOMISATION_LEVEL

Denotes the level of customisation that is allowed for LOVs.

No

APPL

Cannot be customised

No

INSTN

Department can customise

No

OSL_DEFAULT_ROLE

Denotes the role to be taken by default if the user has multiple roles.

No

PARENT

Parent role

No

TEACHER

Teacher role

No

OSL_DISCUSSION_TYPE

Presented to the user as options for the type of discussion post.

Yes

ANNOUNCEMENT

Announcement

Yes

ANSWER

Answer

Yes

NORMAL

Normal

Yes

QUESTION

Question

Yes

OSL_GENDER

Presented to the administrator as options for the gender of a person.

No

FEMALE

Female

No

MALE

Male

No

UNKNOWN

Unknown

No

OSL_INSTITUTION_TYPE

Denotes the type of an institution

Yes

DEPARTMENT

Department

No

NON-SCHOOL

Non-school (For example, Region or district)

No

PRIMARY

Primary school

Yes

SECONDARY

Secondary school

Yes

SPECIAL

Special school

Yes

OSL_LANGUAGE

Not used

OSL_LEARNING_ITEM_TYPE

Denotes the type of a learning item.

No

CLASS

Class learning item

No

DISCUSSION

Discussion learning item

No

DOCUMENT

Document learning item

No

FOLDER

Folder learning item

No

JOURNAL

Journal learning item

No

PERSONAL

Personal planning area

No

REFERENCE

Reference learning item

No

SUBMISSION

Submission learning item

No

TASK

Task learning item

No

OSL_LIST_NAME_FORMAT

Format of the list of names.

No

DISPLAY_NAME

The defined Display Name is displayed.

No

LAST_FIRST_NAME

Names are displayed as ''Lastname Firstname''.

No

LAST_PREFERRED_NAME

Names are displayed as ''Lastname Preferredname''. If the Preferredname is null, the name is displayed as ''Lastname Firstname''.

No

LAST_COMMA_FIRST_NAME

Names are displayed as ''Lastname, Firstname''.

No

LAST_COMMA_PREFERRED_NAME

Names are displayed as ''Lastname, Preferredname''. If the Preferredname is null, the name is displayed as ''Lastname, Firstname''.

No

FIRST_LAST_NAME

Names are displayed as ''Firstname Lastname''.

No

PREFERRED_LAST_NAME

Names are displayed as ''Preferredname Lastname''. If the Preferredname is null, the name is displayed as ''Firstname Lastname''.

No

FIRST_MIDDLE_LAST_NAME

Names are displayed as ''Firstname MiddleName Lastname''.

No

LAST_COMMA_FIRST_MIDDLE_NAME

Names are displayed as ''Lastname, Firstname Middlename''.

No

OSL_LOCK_TYPE

Not used

OSL_NAME_SORT_OPTIONS

Options for sorting names.

No

DISPLAY_NAME

Names are sorted in order of Sort Name, Display Name.

No

LAST_FIRST_NAME

Names are sorted in order of Last Name, First Name, Middle Name.

No

LAST_PREFERRED_NAME

Names are sorted in order of Last Name, Preferred Name, First Name, Middle Name.

No

FIRST_LAST_NAME

Names are sorted in order of First Name, Last Name, Middle Name.

No

PREFERRED_LAST_NAME

Names are sorted in order of Preferred Name, First Name, Last Name, Middle Name.

No

OSL_OBSERVATION_AUDIENCE

Presented to the teacher as options for the viewing audience when creating an observation

No

kInternal

INTERNAL

Internal audience - teachers only

No

kExternal

EXTERNAL

External audience - teachers, student, parents

No

OSL_OBSERVATION_CATEGORY

Presented as options for the category of an observation when it is being created

Yes

ADVICE

Learning advice

Yes

IMPROVEMENT

Areas for improvement

Yes

REFLECTIONS

Reflections of learning

Yes

SUPPORT

Learning support

Yes

WELLDONE

Things student does well

Yes

OSL_OBSERVATION_TYPE

Denotes the type of an observation

No

LI

Learning Item Observations

No

GLOBAL

Global Observations

No

OSL_OUTCOME_STATEMENT_TYPE

Denotes the type of an outcome statement

No

ANNOTATIVE

Annotative outcome statement

No

DEMONSTRABLE

Demonstrable outcome statement

No

INDICATIVE

Indicative outcome statement

No

OSL_PARTY_TYPE

Denotes the type of a party

No

PERSON

Person

No

ORGANISATION

Organisation

No

OSL_PERSON_TITLE

Presented to the administrator as options for the title of a person

No

DR

Dr

No

MR

Mr

No

MRS

Mrs

No

MS

Ms

No

OSL_PHONE_TYPE

Denotes the type of a party's phone contact

No

OFFICE

Office phone

No

HOME

Home phone

No

MOBILE

Mobile phone

No

OSL_PROFICIENCY_LEVEL_TYPE

Denotes the type of a proficiency level

Yes

CORE

Core level

Yes

FOUNDATION

Foundation level

Yes

OSL_PROFICIENCY_SET_TYPE

Denotes the type of a proficiency set

No

GRADED

Graded proficiency set

No

OUTCOME

Outcomes proficiency set

No

OSL_RELATIONSHIP_TYPE

Denotes the type of relationship (or role) that one party has with another

No

STUDENT_OF

Student of a school or class

No

TEACHER_OF

Teacher of a school or class

No

SCHOOL_ADMIN_OF

Administrator of a school

No

SCHOOL_CURRICULUM_ADMIN_OF

Curriculum administrator of a school

No

DEPARTMENT_ADMIN_OF

Administrator of a department

No

DEPARTMENT_CURRICULUM_ADMIN_OF

Curriculum administrator of a department

No

GUEST_OF

Guest of a school or class

No

PARENT_OF

Parent of a student or class

No

GUARDIAN_OF

Guardian of a student

No

PARENT_INSTITUTION_OF

Parent institution of another institution

No

SYSTEM_ADMIN_OF

System administrator of OSL

No

SIBLING_OF

Sibling of a student

No

OSL_SPOKEN_COMPREHENSION_LEVEL

Not used

OSL_WORKSPACE_TYPE

The LT workspaces that are available to students

No

BASIC

Basic student workspace

No

STANDARD

Standard workspace

No

OSL_YES_NO

Denotes how 'Yes' & 'No' is represented in the DB

No

N

No

No

Y

Yes

No

B Property Files

This appendix describes each of the property files that are used by OSL.

B.1 Property Files

The following table provides a list of property files.

Table B-1 List of property files

Property Files

Description

DashboardUIRes.properties

Labels used in the common "Dashboard" tab of the LT

GlobalUIRes.properties

Labels for in common global components (such as print, help, logout, and so on)

ImagesRes.properties

Images used in the LT

LearnUIRes.properties

Common labels used throughout the LT

LIIconRes.properties

Images that can be applied as "Learning Item Icons" in the LT

MessagesRes.properties

Warnings and error messages used in the LT

ObservationsUIRes.properties

Labels used specifically for observations throughout the LT

PreferenceAdminUIRes.properties

Labels and images used in the "Preferences" tab of the LTAdmin

ReviewUIRes.properties

Labels used in the common "Review" tab (also known as "Curriculum" and "My Progress") of the LT

RichDataUIRes.properties

Labels used in the common Rich Text Editor (RTE) component of the LT

TeachUIRes.properties

Labels used in the LT Teacher UI

AdminImageBundle.properties

Image used in the LT Admin

AdminLookupBundle.properties

Look Up Values in OSL Learning Tool Admin Module

AdminMessageBundle.properties

All types of Messages in OSL Learning Tool Admin Module

AdminWebBundle.properties

UI Naming in OSL Learning Tool Admin

C Preferences Matrix

This appendix describes the preferences used by OSL.

C.1 Preferences Matrix

The following table provides a list of preferences.

US - User Specific

UM - User Modifiable

Table C-1 List of preferences

Code

Name

Description

US

UM

Default

Behaviour Definition

Type

OSL_ACCESSIBILITY_MODE

Accessibility mode

The accessibility mode

Y

Y

ACCESSIBLE

If the value is Accessible, Output supports accessibility features.If the value is Inaccessible, Accessibility-specific constructs are removed to optimize output size.If the value is Screen Reader, Accessibility-specific constructs are added to improve behavior under a screen reader.

LOV

OSL_ALLOW_HIDDEN_FEEDBACK

Allow teacher to hide feedback from students

Enable teachers to hide feedback from students

N

N

FALSE

Setting to TRUE allows teachers to provide student feedback that can only be read by other teachers.

Boolean

OSL_ALLOW_INTERNAL_OBSERVATIONS

Allow internal audience observations

Enable teachers to create observations for an internal audience

N

N

TRUE

Setting to TRUE allows teachers to create observations that can only be read by other teachers.

Boolean

OSL_DASHBOARD_TAB_ORDER

Display order of the Dashboard tab

Display the Dashboard tab in the Teacher UI

N

N

0

Setting to anything other than 0 ensures that the Dashboard tab is displayed in the Teacher UI.

Integer (0-4)

OSL_DEFAULT_ROLE

User default role

The user's default role.

Y

Y

TEACHER

Defines the default role for users that have multiple role (For example, teacher and parent).

LOV

OSL_DISPLAY_CONTENT_BUTTON

Display content link in LT

Display content link in LT

N

N

FALSE

When the value is TRUE, the chart icon is displayed in the toolbar of the Curriculum tab.

Boolean

OSL_DISPLAY_CURRICULUM_CHART_ICON

Display curriculum chart icon

Defines whether the chart icon is displayed in the Curriculum tab toolbar

N

N

FALSE

When the value is true,the chart icon is displayed in the Curriculum tab toolbar.

Boolean

OSL_DISPLAY_END_DATED_STUDENTS

Display end dated students by default

Display end dated student in teachers' class lists by default

Y

Y

TRUE

Setting to TRUE ensures that end-dated students are displayed to the teacher by default.

Boolean

OSL_DISPLAY_EXTERNAL_STUDENTS

Display external students by default

Display external students in teachers' class lists by default

Y

Y

TRUE

Setting to TRUE ensures that externally enrolled students are displayed to the teacher by default.

Boolean

OSL_DISPLAY_STUDENT_COLUMNS

Display the student columns by default

Defines whether to display the student columns by default in the Class page of the Teacher UI

N

N

FALSE

Setting to TRUE will ensure that the student columns are displayed in the Class page of the Teacher UI by default.

Boolean

OSL_EXPAND_ACTIVITIES

Display activities expanded

Defines whether activities should be automatically expanded

N

N

FALSE

Setting to TRUE ensures that container activities are automatically expanded in the Class page of the Teacher UI.

Boolean

OSL_EXPAND_FRAMEWORK

Expand frameworks

Defines whether frameworks should be automatically expanded

N

N

FALSE

When the value is true, frameworks should be automatically expanded.

Boolean

OSL_LIST_NAME_FORMAT

Display format of listed names

Defines the display format of listed student names

Y

Y

DISPLAY_NAME

Defines the format in which student names are displayed when listed in the Teacher UI.

LOV

OSL_NAME_SORT_ORDER

Sort order of listed names

Defines the sort order for listed names of institutions and persons

Y

Y

DISPLAY_NAME

Defines the sort order for names of institutions and persons when listed in any UI.

LOV

OSL_OBSERVATIONS_TAB_ORDER

Display order of the Observations tab

Display the Observations tab in the Teacher UI

N

N

3

Setting to anything other than 0 ensures that the Observations tab is displayed in the Teacher UI.

Integer (0-4)

OSL_PARENT_ACCESS_TO_DISCUSSIONS

Allow parent access to discussions

Enable parents to view the posts in discussion learning items

N

N

TRUE

Setting to TRUE allows parents to access the posts of all students in discussion learning items.

Boolean

OSL_PARENT_ACCESS_TO_STUDENT_LIST

Allow parent access to student list

Enable parents to view the list of students assigned to a learning item

N

N

TRUE

Setting to TRUE allows parents to access the list of students enrolled in their student's learning items.

Boolean

OSL_RECENT_DEMONSTRATIONS_MONTHS

Months of recent demonstration data to display

The default number of months worth of demonstration data to display in all interfaces

Y

Y

12

Used by the Teacher UI and Standard UI to control how many months' worth of demonstrations data to display by default.

Integer (0-168)

OSL_RECENT_OBSERVATIONS_NUMBER

Number of recent observations

The number of recent observations to display on the Standard UI

Y

Y

7

Used by the Standard UI to control how many recent observations to display by default.

Integer (1-20)

OSL_REVIEW_TAB_ORDER

Display order of the Curriculum tab

Display the Curriculum tab in the Teacher UI

N

N

2

Setting to anything other than 0 ensures that the Curriculum tab is displayed in the Teacher UI.

Integer (0-4)

OSL_RTE_DISPLAY_UPLOAD_TAB

Display upload tab in RTE

Defines whether to display the upload tab in the rich text editor

N

N

TRUE

When the value is true, display the upload tab in the rich text editor.

Boolean

OSL_SHOW_FOOTER

Display footer in LT and LT Admin

Defines whether to display the footer in the LT and LT Admin

N

N

TRUE

Setting to TRUE ensures that the footer is displayed on the Teacher UI and Admin UI.

Boolean

OSL_SHOW_LOGOUT_LINK

Display logout link in LT & LT Admin

Display logout link in LT and LT Admin

N

N

FALSE

Setting to TRUE ensures that the Logout button is displayed on all UIs.

Boolean

OSL_STUDENT_WORKSPACE

Student workspace

The student's preferred workspace - Standard or Basic

Y

N

Standard

Defines which LT interface is displayed to the student

LOV

OSL_TEACH_TAB_ORDER

Display order of the Class tab

Display the Class tab in the Teacher UI

N

N

1

Setting to anything other than 0 ensures that the Class tab is displayed in the Teacher UI.

Integer (0-4)

OSL_TEACHER_ACCESS_TO_ALL_SCHOOLS

Allow teacher access to all schools

Enable teachers to view classes in all schools

N

N

TRUE

Setting to TRUE allows teachers to view the details of classes in schools in which they do not teach.

Boolean

OSL_TEACHER_ACCESS_TO_OTHER_STUDENTS_OBSERVATIONS

Allow teacher access to observations about other students

Enable teachers to view and create observations about students they don't teach

N

N

TRUE

Setting to TRUE allows teachers to access observations about students that they do not teach.

Boolean

OSL_TEACHER_ACCESS_TO_OTHER_STUDENTS_WORK

Allow teacher access to work of other students

Enable teachers to view the work of students they don't teach

N

N

TRUE

Setting to TRUE allows teachers to access the work of students that they do not teach.

Boolean

OSL_TEACHER_ACCESS_TO_SHARE_SCHOOLS

Allow teacher access to all schools when sharing Learning Items

Enable teachers to share Learning Items with classes from any school

N

N

TRUE

Setting to TRUE ensures that teachers are able to share learning items with classes from any school.

Boolean

OSL_USE_HIGH_CONTRAST

Use high contrast colours in Class screen

Enable teachers to select the regular colors or high contrast (color-blind) colors for cells in Class screen

Y

Y

FALSE

Setting to TRUE ensures that the Class screen uses high contrast colors to indicate student progress, which are more clearly distinguished for color-blind teachers.

Boolean

OSL_WORKSPACE_BACKGROUND

Workspace background

Preferred workspace background

Y

Y

Grey

Defines which background is displayed on the Standard UI or Basic UI.

String

D Default Content Integration

This release ships with default integration with Oracle Universal Content Management (UCM) and can be used with UCM straight out of the box.This appendix provides content configurations that may be easily and quickly applied to a default deployment of UCM 11g, which is known as "DCI" as described in Chapter 5.

D.1 Prerequisites

Oracle Universal Content Management Content Server 11g has to be installed and Oracle Universal Content Management Inbound Refinery 11g is recommended for installation as well.

D.2 Configuring Content Server

Log in to Content Admin Server.

D.2.1 OSL Content Users

Users defined below have to be set up in Content Server using the User Admin applet.

Table D-1 Users definition

Users

Roles

Security Groups

Accounts

oslcontent

OSLSystemRole

OSLDocuments(RWDA), Public(RW)

OSL/oslcontent/main(RWDA)

oslmetadata

OSLMetadataRole

OSLDocuments(RWDA), Public(RW)

OSL(RWDA)

All accounts(RWDA)

D.2.2 Additional Configuration Variables

Click the General Configuration link. Add the following new configuration variables to the list of Additional Configuration Variables.

Table D-2 List of configuration variables

Variable Name

Variable Value

Usage

SearchIndexerEngineName

OracleTextSearch

Index content items

CustomWebRoot

http://ipadderss:port

Content Server IP address, port

CustomParentLocation

http://ipadderss:port

LT IP address, port

D.2.3 Content Security

Click the Content Security link. Enable the Allow author to delete revision option.

D.2.4 Override Configuration Variables

Configuration variables listed below are set to default values by a custom component, so these variables should be commented from the list of Additional Configuration variables.

- IsAutoNumber= false

- AutoNumberPrefix=

- UseAccounts=false

D.3 Component Deployment

Perform the following steps to deploy components.

D.3.1 Custom Components Deployment

Click Component Manager and click Advanced Component Manager link. Then install and enable the custom components, which are available under <OSL_INSTALL_DIR>/LearningTool/ContentIntegration/components/ folder.

1. OSL_Add_Cancel.zip

2. OSL_AdvSearchComponent.zip

3. OSL_CheckinLayout

4. OSL_ClassicSearchTemplate.zip

5. OSL_CustomAction.zip

6. OSL_DefaultEnv.zip

7. OSL_Home_Page_Content.zip

8. OSL_InterfaceChanges.zip

9. OSL_Javascript.zip

10. OSL_LocaleString.zip

11. OSL_RemoveStandardProfileLinks.zip

12. OSL_RemoveSwitchProfile.zip

13. OSL_School.zip

14. OSL_SearchResults.zip

15. OSL_SearchTemplate.zip

D.3.2 Standard Components Deployment

1. If your UCM is already configured, do the following:

1. Click Component Manager.

2. Disable and then uninstall the SelectivelyRefineAndIndex component.

3. Go to <OSL_INSTALL_DIR>/LearningTool/ContentIntegration/components, and then install and enable OSL_SelectivelyRefineAndIndex.zip.

2. If your UCM is not yet configured, do the following:

1. Click Component Manager.

2. Go to <OSL_INSTALL_DIR>/LearningTool/ContentIntegration/components, and then install and enable AdditionalSortFields.zip and OSL_SelectivelyRefineAndIndex.zip.

3. Restart the Content Server.

D.4 UCM Schema Setup

1. Select Admin Applets from the Administration menu.

2. Click the Configuration Manager applet. This pops up the applet.

D.4.1 Create Table

Click the Tables tab. Click the Create table button. Create two tables as specified below:

Table D-3 School

Name

Type

Primary

SchoolId

Int

Yes

SchoolName

varchar(500)

dDocAccount

varchar(100)

Table D-4 Scope

Column

Data Type

Primary Key

ScopeId

Int

Yes

ScopeName

varchar(500)

Table D-5 Visibility

Column

Data Type

Primary Key

dName

varchar(50)

Yes

dDescription

varchar(50)

Table D-6 YesNo

Column

Data Type

Primary Key

dName

varchar(25)

Yes

dDescription

varchar(25)

Note:

On completion of all the setup, ensure that the School and Scope information are in sync with the OSL data. Refer to the script DB_Insert.sql available in <OSL_INSTALL_DIR>/LearningTool/ContentIntegration/scripts/ucm folder.

D.4.2 Create View

Click the Views tab. Create two views as specified below:

Table D-7 Creating Views

View Name

Internal Column

Visible Column

Default Display Expression

Display (DisplayRule for all Locales)

Security

School_View

SchoolId

SchoolName

Select Use standard document security.

Scope_View

ScopeId

ScopeName

Visibility_View

dName

dDescription

<$dDescription$>

<$lc(dDescription)$>

YesNoAlt_View

dName

dDescription

<$dDescription$>

<$lc(dDescription)$>

D.5 Custom Metadata

1. Log in to Content Server user interface as administrator.

2. Select Admin Applets from Administration Menu.

3. Click the Configuration Manager applet. This pops up the applet.

4. Add the metadata listed below in the Informations tab.

Table D-8 List of metadata

Metadata Name

Metadata Type

Enabled in User Interface

Enabled for Search Index

Enable Option List

Use View

Field Caption

Select List Validated

Scope

Text

Yes

Yes

Yes

Scope_View

wwxScope

Yes

Visibility

Text

Yes

Yes

Yes

Visibility_View

wwxVisibility

Yes

Endorsed

Text

Yes

Yes

Yes

YesNoAlt_View

wwxEndorsed

Yes

Searchable

Text

Yes

Yes

Yes

YesNoAlt_View

wwxSearchable

Yes

OSL_SchoolId

Long Text

Yes

Yes

Yes

School_View

wwxSchool

Yes

OSL_Tag

Long Text

Yes

Yes

No

None

wwxTag

No

OSL_FrameworkItemId

Long Text

Yes

Yes

No

None

wwxFrameworkItem

No

OSL_OutcomeStatementId

Long Text

Yes

Yes

No

None

wwxOutcomeStatement

No

When the custom metadata are created, click the Update Database Design button found on the right of the screen. Only then, the changes get committed. Then go to options and click Publish Schema. Then click Options -> Exit to exit the screen.

Now, it is recommended to restart the UCM Content Server.

D.6 Add Profile Options

Click the Edit Values button for IdcProfile metadata listed in the Informations tab.

Click the Add button. Add the dProfileTriggerValue that are listed below with the same dProfileTriggerOrder 11.

- OSLPublic

- OSLSchool

- OSLDepartment

- OSLSchoolNotEndorsed

D.7 Advanced Search Design

Click Advanced Search Design to modify the settings. The metadata that are defined as Filter Category are:

- Content Type (dDocType)

- Format (dFormat)

- Scope (xScope)

- Endorsed (xEndorsed)

Edit the metadata that are listed above and enable the Is a filter category option.

D.8 Rules

Click the Rules tab. Select and delete the default HideStandardRules if it is listed.

D.9 Roles/Groups/Permissions

Roles defined in the Content Server should match the OSL roles defined in OID. Create the Roles using User Admin applet.

1. Select Admin Applets from the Administration menu.

2. Click the User Admin applet. This pops up the applet.

Table D-9 Creating Roles, Groups, and Permissions

Role

Group

Permission

SchAdminGroup

Public

RWDA

DeptAdminGroup

Public

RWDA

TeacherGroup

Public

RWD

ParentGroup

Public

R

StudentGroup

Public

R

D.10 DCI Configuration Assistant

The steps to run DCI Configuration Assistant are given below:

1. Unzip DCI_Config_Assistant.zip file on to the server directory in which UCM is installed.

2. Modify the dci_configuration property that is available in EXTRACT_DIR/config/.

Table D-10 Configuration property

Property Name

Valid Value (Do not change)

Sample Property Value

osl.dci.cs.url

idc://ipaddress:port

ipaddress – Content server

port –Intradoc port

osl.dci.cs.username

sysadmin

Conent server admin username

osl.dci.cs.password

idc

Content server admin password

osl.dci.rule.src.path

./rule/

osl.dci.rule.dest.path

<UCM_DOMAIN_HOME>/cs/data/profiles/docum

osl.dci.profile.src.path

/profile/

osl.dci.profile.dest.path

<UCM_DOMAIN_HOME>/cs/data/profiles/docum

osl.dci.search.pne.src.path

/searchtemplate/

osl.dci.search.pne.dest.path

<UCM_DOMAIN_HOME>/cs/data/users/profiles/

osl.dci.search.template.src.path

/searchtemplate/customlisttemplates/

Log in to EM Console. Click Servers -> Content Server -><UCM server instance name>. Click the configurations link and check if IP address filter and the intradoc port have been set properly. For related information, see Oracle Student Learning Installation and Deployment Guide.

Note:

UCM_DOMAIN_HOME is the UCM directory inside the WebLogic domain of the UCM installation.

3. Ensure the JDK used to run the DCI Config Assistant is the latest, for example, JDK 1.6.To run the DCI Config Assistant run the following command:

java -jar DCI_Config_Assistant.jar

4. Individual actions can be performed with the following commands:

java -jar DCI_Config_Assistant.jar "Add Rule"
java -jar DCI_Config_Assistant.jar "Copy Rule"
java -jar DCI_Config_Assistant.jar "Add Profile"
java -jar DCI_Config_Assistant.jar "Copy Profile"
java -jar DCI_Config_Assistant.jar "Copy Template"

Note:

Initially, Search Templates are created for administrator user only. Only when a user has successfully logged in to the Content Server at least once, the search templates can be added. This can be accomplished by executing the DCI Configuration Assistant with "Copy Template" parameter.

D.11 Inbound Refinery Setup

IBR server must be added as a Provider for Content Server before making any configuration changes.

1. Log in to Content Server user interface as administrator.

2. Click the Administration menu.

3. Click the Providers link.
Verify that IBR is listed as an "Outgoing" provider.

If the IBR provider is not listed, create a new Provider for IBR.

4. To create a new Provider for IBR.

1. Click Add.

2. Enter the details of the Inbound Refinery server:
- Provider Name: IBR
- Provider Description: IBR Provider
- Server Host Name: IP address for IBR server
- HTTP Server Address: <IP Address for IBR>:<IBR port>
- Server Port: 5555
- Instance Name: IBR_server1
- Relative Web Root: /ibr/
- Convertion Options: Enable "Handle Inbound refinery Conversion Jobs".

D.11.1 File Formats Wizard (Content Server)

1. Click the Administration menu.

2. Click the Refinery Administration link.

3. Click the File Formats Wizard and select the following File Types.

- GIF 87 Image

- JPEG Image

- PNG

- Windows Bitmap Image

- TIFF Image

4. Click the Update button.

D.11.2 Inbound Refinery Conversion Options (Content Server)

1. Click the Administration menu.

2. Click the Refinery Administration link.

3. Click the Conversion Options link.

4. Enable the "When a conversion sent to an Inbound Refinery fails, set the conversion to Refinery Passthru" option.

D.11.3 Conversion Listing (Inbound Refinery)

Log in to Inbound Refinery server as administrator.

1. Click the Conversion Settings menu.

2. Click the Conversion Listing. Verify that the following entries are selected:

- Image Thumbnail

- Native Thumbnail

- MultipageTiff

D.11.4 Additional Renditions (Inbound Refinery)

Enable the Create Thumbnail Images using Outside In option.

D.12 Using Content Server in Non-English Environments

To use the Content Server in non-English environments, you must perform the following configuration tasks before and after installing the Content Server.

1. Set database encoding to AL32UTF8.

2. Select Locale under Administration > Localization.

3. Set the server locale in System Properties > Server.

4. If you are an individual user, set the locale in your profile using the User Profile > Locale menu.

Additionally, enter any custom data setup according the server locale. For example, for custom metadata LOVs, enter data using the selected language.

E Oracle Internet Directory (OID) Setup for Default Content Integration

This appendix provides the Oracle Internet Directory (OID) setup that are needed to configure the UCM accounts for default content integration.

E.1 Prerequisites

Configure OID for LT before configuring OID for DCI.

E.2 Configuring OID

Set the environment variables listed below in the server where OID is installed.

Table E-1 Environment variables

Variables

Description

<ORACLE_HOME_DIR>

IDM directory in the middleware installation.

For example: =/home/oracle/Middleware/Oracle_IDM1

<ORACLE_INSTANCE_DIR>

AS directory in the middleware installation.

For example: =/home/oracle/Middleware/ asinst_1

<IDM_SID>

The SID for the OID DB.

For example: idm

<JAVA_HOME_DIR>

Java isntallation directory.

For example: =/home/oracle/app/jdk1.6.0_17/

<DOMAIN_HOME_DIR>

Middleware domain directory.

For example: =/home/oracle/Middleware/user_projects/domains/IDMDomain

unset ORACLE_HOME
export ORACLE_HOME=<ORACLE_HOME_DIR>
export ORACLE_INSTANCE=<ORACLE_INSTANCE_DIR>
export ORACLE_SID=<IDM_SID>
export JAVA_HOME=<JAVA_HOME_DIR>
export DOMAIN_HOME=<DOMAIN_HOME_DIR>
export PATH=$ORACLE_INSTANCE/bin:$ORACLE_HOME/bin:$ORACLE_HOME/ldap/bin:$JAVA_HOME/bin:$PATH

E.2.1 Command to execute Idiff files

Table E-2 List of variables

Variables

Description

<OID_hostname>

Hostname for the OID server.

<OID_port>

Port for the OID directory server.

<OID_admin_username>

OID Admin username.

<OID_admin_password>

OID admin password.

<ldiff_filename>

Ldiff file name.

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>"  -w <OID_admin_password> -f <ldiff_filename>

Note:

The ldiff files needed to create the OID data are available in <OSL_INSTALL_DIR>/LearningTool/ContentIntegration/scripts/oid folder.

E.2.2 Create Tree

The WebLogic OID provider for UCM must be configured with the Group Base DN. This group DN should include both OSL groups (For example: cn=osl,cn=groups,dc=sg,dc=oracle,dc=com) and DCI accounts (For example: cn=dci,cn=groups,dc=sg,dc=oracle,dc=com).

Create a new tree in OID to hold the accounts. Execute the following command:

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>"  -w <OID_admin_password> -f  create_dci_group_tree.ldiff

E.2.3 Create Groups

Create a list of Groups that would be translated to UCM accounts. Execute the following command:

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>"  -w <OID_admin_password> -f  create_dci_groups.ldiff

E.2.4 Create School Groups

Create a list of Groups for each School that would be translated to UCM accounts. Execute the following command:

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>"  -w <OID_admin_password> -f  create_dci_groups_for_school.ldiff

Note:

A list of accounts needed for each school is listed in the ldiff file. Add the group for each of the school ids that are available in OSL. The list of schools can be retreived from OSL LT database using the sql statement:
select id, name from osl_parties where par_type='ORGANIZATION';

E.2.5 Assign Members to Groups

Assign the users that are assigned to different groups like DeptAdminGroup, SchoolAdminGroup, TeacherGroup, StudentGroup, and ParentGroup to the corresponding accounts. The mapping of different accounts to OSL Groups is listed below:

Table E-3 Mapping of different accounts to OSL Group

OSL Role

UCM Accounts

DeptAdminGroup

@Endorsed(RWDA)

@Unendorsed(RWDA)

@Public(RWDA)

SchAdminGroup

@Endorsed/School/SchoolId(RWDA) @Unendorsed/School/SchoolId(RWDA)

TeacherGroup

@Endorsed/Department(R) @Endorsed/School/SchoolId(R) @Unendorsed/School/SchoolId(RW) @Public(RWD)

ParentGroup

@Endorsed/Department(R) @Endorsed/School/SchoolId(R) @Unendorsed/School/SchoolId(R) @Public(R)

StudentGroup

@Endorsed/Department(R) @Endorsed/School/SchoolId(R) @Unendorsed/School/SchoolId(R) @Public(R)

Only users that belong to the school must be assigned to school accounts.

- Retrieve schools in OSL by running the following SQL script:
select id, name from osl_parties where par_type='ORGANIZATION';

In the above SQL script, ID is the <School_Id>.

- Retrieve teachers belonging to a school by running the following SQL script:
select id, party_identifier from osl_parties where id in (select src_par_id from osl_party_relationships where dest_par_id=<School_Id> and relationship_type='TEACHER_OF') order by id asc;

- Retrieve students belonging to a school by running the following SQL script:
select id, party_identifier from osl_parties where id in (select src_par_id from osl_party_relationships where dest_par_id=<School_Id> and relationship_type='STUDENT_OF') order by id asc;

- Retrieve parents belonging to a school:
select id, party_identifier from osl_parties where id in (select src_par_id from osl_party_relationships where dest_par_id in (select src_par_id from osl_party_relationships where dest_par_id=<School_Id> and relationship_type='STUDENT_OF') and relationship_type='PARENT_OF' ) order by id asc;

Note:

SchoolId listed in the UCM accounts are the SchoolId that are listed in OSL LT database.
Modify and execute the following commands to assign members to groups:

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>" -w <OID_admin_
password> -f assign_deptadmin_group_member.ldiff

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>" -w <OID_admin_
password> -f assign_schooladmin_group_member.ldiff

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>" -w <OID_admin_
password> -f assign_teacher_group_member.ldiff

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>" -w <OID_admin_
password> -f assign_parent_group_member.ldiff

ldapadd -h <OID_hostname> -p <OID_port> -D "<OID_admin_username>" -w <OID_admin_
password> -f assign_student_group_member.ldiff

E.2.6 Configure OID Provider for UCM with Group DN

Details on adding an OID provider for UCM is listed in the UCM setup found in section 6.2.3 Configuring OID as Security Provider for Content Server 11g of the Oracle Student Learning Installation and Deployment Guide. This section is limited to the setup of Groups in OID provider.

1. Log in to WebLogic console for the UCM domain.

2. Click Security Realms.

3. Click the Providers tab.

4. Click OID Provider. Enter the value of the Group base DN. For example, (cn=groups,dc=sg,dc=oracle,dc=com). Take note that the groups for OSL and DCI exists in a subtree.

Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved.