Callista Connect is comprised of four broad components:

• Callista Staff Connect - the web pages and applications enabling staff to query Connect Student information
• Callista Connect Manager - enables the administration of security, applications, global configuration and users. These functions are managed within Callista forms
• Callista Connect Web Administrator - enables the creation of Web pages and delivery of student applications. These functions are managed within Web forms
• Callista Connect Student Applications Suite - the web pages and applications seen and used by student end user

• What Callista Connect Manager does
• Terms used in Callista Connect Manager
• How Callista Connect Manager is used
• User Responsibilities
• Callista Connect Applications
• System Applications
• Institution Defined Applications
• Web Element Applications
• Configuring Application Data
• Callista Connect Global Configuration
• Callista Connect Security
• Maintaining Callista Connect User Authentication Information and other Security Related Details
• Callista Connect Messaging
• Activity Logging
• Cohort Process Windows

Detailed explanations and instructions for the use of individual Callista Connect Manager (self serve) forms can be accessed from the Callista Connect Table of Contents or via the numerous links provided here.

Information regarding the Web Administrator is provided separately in Understanding the Web Administrator.

What Callista Connect Manager does

This facility is used to manage Callista Connect security and applications, to maintain validation messages and an institution level configuration, and to administer individual user details. Key functions in this management process are:

• The creation of Self Serve Applications, including: 
  • The recording of institution defined applications 
  • The grouping of web pages and their associated applications under one overarching institution defined application
  • The management of information displayed in applications
• The management of Callista Connect's institution level configuration, including:
• An institution level web style
• An institution level login page
• Institution level authentication timeouts
• The creation and management of Callista Connect access codes and the mapping of user categories to these codes to create security levels for web applications
• The creation and management of user categories to provide levels and methods of security access to Callista Connect functionality (web pages), including the definition of user:
• Mapping methods
• Authentication methods and related login input requirements
• The maintenance of individual user authentication information and other security related details
• The maintenance of messages displayed within Callista Connect web pages/applications

Terms used in Callista Connect Manager

To understand Callista Connect Manager, it is necessary to understand several key terms. Details of these terms can be found in the Subsystem Glossary. 

How Callista Connect Manager is used

User Responsibilities

Each institution will use Callista Connect Manager according to its own business practices and security requirements. For example, an institution may choose to use only a subset of Callista Connect's student applications, and to implement a pre-existing external authentication protocol rather than the internal authentication methods provided with Callista Connect.

Callista Connect Applications

Callista Connect applications are web page facilities for displaying or adding/updating Callista held information. For example: view student results, view enrolment details, change addresses.

There are three levels of applications - system, institution and web element.

System Applications

These are the system applications incorporated in Callista Connect web pages. Examples are PE-PREFS (View/Change Personal Web Page Preferences), PE-RESULTS (View Results) and LOGIN. Each application has specific functionality and incorporates system defined data.

A facility has been provided to enable the update of the system application templates. This can be found in SSFF1120 (Maintain System Self Serve Application). However, it is recommended that any required changes to the application templates are undertaken in the Web Administrator. Details on this are provided in both SSFF1120 and the Maintain Application form.

Institution Defined Applications

An institution defined application must be created for each system application that the institution wishes to make available to users. These are defined in SSFF1100 (Maintain Self Serve Applications). Institution defined applications are then defined in the Maintain Application page of Web Administrator, enabling the Web Administrator to incorporate an application as one of the elements of a specific page. See below for further details on web element applications.

• The access code must be specified for each application. This defines the security level for the application. A self-serve delivery type must also be specified. The WEB delivery type must be selected for applications that are to be made available via the Web.
• Global access to an application can be prevented via the Prevent Access check box in the form SSFF1200 Maintain System Self Serve Configuration. This makes it unnecessary to remove the application from the page in Web Page Administrator when it is unavailable for use.
• A facility has been provided to place a number of web pages and their associated applications under one overarching institution defined application. This means that the web pages have one overriding Self Serve Access Code and all features of the pages, not just the applications, are protected by the 'parent' application's access code. For example: an institution may create several web pages for Self Serve Applications dealing with aspects of enrolments - UNIT ENROLMENT, CHANGE ADDRESS and PERSON STATISTICS. It may wish to secure all of these applications and all of Web Page Elements (textual information, etc) behind a single application and access code. To achieve this it would be necessary to:
• Create an institution defined application of ENROL in SSFF1100 with a System Self Serve Application of USERDEF (User Defined).
• Assign a Secure Access Code to the application ENROL.
• Navigate to SSFF1110 (Maintain Self Serve Application Page) by selecting the WEB Page Mapping button.
• The form is entered in context of the institution defined application ENROL. Select from the LOV the web pages containing the System Self Serve Applications UNIT ENROLMENT, CHANGE ADDRESS and PERSON STATISTICS. These are now mapped to the institution-defined application ENROL.
• When a student accesses these web pages, the login application will be displayed, requiring the student to authenticate before displaying any of the pages containing the enrolment related applications and other associated information in the web pages. The Web Login Page can be either:
• The web login page defined as the global page in SSFF1200 (more details about self serve configuration below); or
• In SSFF1110, a web login page code can be mapped to the web page containing the application. The web login page specified here will override the global web login page when accessing the application.
• In future releases, institutions may also use the system application USERDEF to integrate their own applications with Callista Connect.

Some system Self Serve Applications may be mapped to more than one Self Serve Application, depending on which applications the institution wishes to include in the suite of Self-Enrolment applications. Refer to the PERSON-INQ and ENR-STEPS System Self Serve Applications for further details.

Web Element Applications

To enable the insertion an application in a web page, the application must be created as a web element. Web elements are created in the Maintain Application page of the Web Administrator tool. An application web element is created by assigning the same name as the institution defined self serve application name defined in SSFF1100. Once created as a web element in the Maintain Application page, the application (web element) can be used within web pages. In the Maintain Application page, the web element template can be altered without affecting the system application template. For further details on system application templates refer to SSFF1120. For further details on the Web Administrator refer to Understanding the Web Administrator.

Configuring Application Data

A facility is provided to allow institutions to manage the information displayed in each Callista Connect system application.

• The current release of Callista Connect enables field prompts to be defined for each data item in an application. This facility is provided in the Maintain System Self Serve Application Data form (SSFF1300).
• SSFF1300 allows links from displayed application data to be defined. Such links can be to another system application. For example, a link from student's course attempt status to the system application SCA-STATUS, which displays an explanation of the statuses. In these cases, the data item has a pre-defined System Self Serve Application Link. To activate these links, the user administrator must specify a Link Web Element Code associated with a web page containing the linked system application. Data elements may also link to another page containing related information, but not incorporating a system application. For example, a page containing instructions for using an application. These pages may have been created externally or within the Web Administrator. To specify a link, a valid Link Web Element Code must be inserted from the LOV. All Web Link Codes are first created in Web Administrator.
• Optionally record redirection web element codes for slow loading pages. Redirection web element codes are web pages containing a message for the user explaining that their web page will be loaded in a few moments. Web pages are created in Web Administrator.

Callista Connect Global Configuration

Using the form SSFF1200 (Maintain Self Serve Configuration), an institution level style for all web pages can be specified. The web style must first be defined in the Styles section of the Web Administrator. This global style may be overridden for individual pages by specifying a web page style. It may also be overridden by individual users via the PE-PREFS (Person Preferences) system application. This application allows a user to select a style for applications they access.

As part of the self serve Callista Connect configuration, a login page may be created in Web Administrator with the LOGIN application included as part of the page. The Web Login Page Code is selected in SSFF1200. Wherever security over the entire contents page/s is required (rather than over the application/s only) this login page will display first, before the target page. Login is then verified before allowing the user access to the target pages and their components (i.e. the applications, text blocks, etc). In such cases it is also necessary to map the target pages to a user-defined application in SSFF1110. (see institution defined applications above).

A series of timeouts can be recorded to ensure further protection of secured applications. These times, when reached, require the user to re-authenticate when navigating to secured applications. An Encryption Key Age Timeout can also be recorded. It adds further protection by changing a user's ID/Password Encryption Key after the specified time expires.

If the CALLISTA ID authentication method is used:

Callista Connect Security

Institutions will typically apply different levels of security to their web pages according to content. For example: information on the institution and links to the course guides may be seen as not requiring any security (i.e. PUBLIC access). However, access to a student's results requires a high level of security — users should be required to confirm their identity by providing the necessary valid authentication (login) details. To achieve this, a facility has been provided to enable institutions to define levels of access (access codes) and types of users (user categories).

• Access codes are maintained in SSFF1600 (Maintain Self Serve Access). Examples: SECURE, PUBLIC and ADMIN. One or more user categories can be mapped to each access code. The relationship between access code and user categories defines the types of users that may authenticate for applications mapped to the access code. Note: as described above, access codes are mapped to applications in SSFF1100 (Maintain Self Serve Applications).
• User categories are maintained in SSFF1700 (Maintain Self Service User Category). Categories are institution defined groups of users accessing Callista Connect web pages. For each user category, one or more authentication methods can be defined. Typically, each user category is associated with a single authentication method. The authentication method is the protocol used to validate the login credentials of the user and defines where the authentication information is held. For some authentication types (eg. ORACLE USER and LDAPBASIC), authentication configuration details must be recorded. This configuration information enables Callista Connect to establish a connection with the correct database. Each user category must also be associated with at least one mapping method. A mapping method is the mechanism used by Callista Connect to match each user with the correct Callista person record. Input codes must also be specified. These define the login details required for each user (e.g. user ID and password).

Maintaining Callista Connect User Authentication Information and other Security Related Information

• A facility is provided to record individual user identifier and password details for use with the CALLISTA ID authentication method. These are maintained in SSFF2300 (Maintain Self Serve User). This form is used primarily to reset lost or forgotten passwords. It can also be used to immediately deny a person access to secure Callista Connect applications, via the Active User indicator, but only if the CALLISTA ID authentication method is used.
• If the ORACLE USER authentication method is used, a user's password may be reset in SECF0021 (Maintain System Users). The Active Oracle User check box in the same form can be used to immediately deny access to Callista Connect (and other Callista applications).
• If external authentication methods are used (eg. LDAPBASIC), it is assumed that those facilities will contain functionality for re-setting passwords and removing access to Callista Connect. For details on establishing LDAP Authentication refer to the LDAP Configuration form and the technical documentation.
• The blocking of access to Callista Connect student applications can also be achieved via the imposition of encumbrances. The system encumbrance effect types RVK-SRVC, SUS-SRVC and SSF-BLK block access to all secure Callista Connect applications. The effect type RESULT-BLK blocks access to results released on or after the encumbrance start date, in all Callista Connect applications which display student unit attempt outcomes. This process is controlled via a date alias defined in ASSF01N0(Maintain Assessment Calendar Configuration).

Callista Connect Messaging

A facility is provided for the maintenance of Callista Connect validation messages. These are maintained in the System Self Serve Message window in the form GENF0003(Maintain System Message). Each self serve message is mapped to a system message.

Activity Logging

A facility is provided to display information on the errors encountered by students when trying to access Callista Connect and any of its applications. This information can be viewed in SSFF4000 (Inquire on Self Serve Activity Log). This form is used primarily to advise administrators of the reasons for students not being able to access Callista Connect or a particular application. Users query a student's record and advise why they could not gain access. For example: a student trying to access the PE-RESULT application may be unable to do so because there is not a valid Cohort Process Window for the student or they have a Results Block Encumbrance applied.

To prevent large numbers of activity logging records building up for each student a job has been provided to remove all activity log records older than the specified number of days. For example: the job could be run to delete all records older than 31 days. Records can be deleted by running the Delete Self Serve Activity Log process (SSFJ0010)

Cohort Process Windows

As part of the core Callista functionality, cohorts and Cohort Process Windows have been developed to allow institutions to define windows for when applications are available to students. For further details refer to Understanding Cohort Process Windows in the General Service subsystem in Callista.