Workflow Introduction

Workflow Facility

See Also:

Admission Application Workflow Instance Inquiry (ADMF4800)
Student Course Attempt Workflow Inquiry (ENRF4800)
Student Unit Set Attempt Workflow Instance Inquiry (ENRF4810)
Student Unit Attempt Workflow Instance Inquiry (ENRF4820)
Maintain Workflow Process Type (GENF4800)
Maintain Workflow Process Activity Attribute (GENF4810)
Workflow Process Type Instance Inquiry (GENF4850)
Person Workflow Instance Inquiry (GENF4870)
Maintain Person Preferences (SECF0066)

Introduction

Callista SMS enables the integration of Oracle Workflow with elements of the student management system.

There are three main aspects to the Workflow facility, these are:

The ability to identify the definition of an Oracle Workflow process within Callista SMS and the means to display details of instances of the workflow processes
The ability to control various attributes of a workflow activity based on cohort rules
The forms that provide a contextual link between Callista SMS data structures and an Oracle Workflow process instance.

The first area provides a way to identify the definition of an Oracle Workflow process within Callista SMS. This includes a facility within Callista SMS to display details of instances of the workflow processes. Functionality also links to the Oracle Workflow Monitor tool.

The second area provides a facility that enables the control of various attributes of a workflow activity based on cohort rules. The attributes that can be controlled by cohort rules are Other, Performer, Priority and Timeout.

The Callista SMS forms provide a contextual link between Callista SMS data structures and an Oracle Workflow process instance. Forms are available at the person, student course attempt, student unit attempt and student unit set attempt levels. These forms (GENF4810 and GENF4850) are accessed from the main menu or buttons at the bottom of GENF4800.

Workflow Infrastructure

Linking to Oracle Workflow Processes within Callista

GENF4800 allows the user to give a standard Callista name to an Oracle Workflow Process. This enables the process to be easily identified throughout Callista.

From GENF4800 the Workflow Process Instance Inquiry button navigates to GENF4850 showing all instances of this workflow process type. The form provides navigation to the Oracle Workflow Monitor tool in 'ADMIN' mode via the iconic button.

Running the monitor tool in this administrator mode enables you to manually complete, reassign or cancel workflow activities regardless of their current state. This means activities that are 'return an error' or have other problems can be maintained.

From GENF4800 the Workflow Process Activity Attribute button navigates to GENF4810.

Access to both GENF4800, GENF4810 and GENF4850 is expected to be restricted to a small set of specialist users.

Linking an Instance of a Workflow Process to a Context Callista Record

Various tables enable a particular instance of a workflow process to be linked to a Callista table to provide context for the workflow. These tables are populated by the system when a workflow instance is initiated.

The set of Callista tables that provide context for workflow process are Student Course Attempt Workflow Inquiry (ENRF4800), Student Unit Set Attempt Workflow Instance Inquiry (ENRF4810), Student Unit Attempt Workflow Instance Inquiry (ENRF4820) and Person Workflow Instance Inquiry (GENF4870).

Admission Application Workflow Instance Inquiry (ADMF4800). This form allows all Workflow Process instances related to an Admission Application to be viewed.

Defining System Recognised Workflow Activity Attributes

Four types of attributes are used to control workflow based on the cohort of the student. These attributes are Other, Performer, Priority and Timeout. These are defined in GENF4810.

Setting Workflow Activity Attributes Based on Cohorts

This structure maps an attribute of an activity in a process to a specific value for a cohort of students. This provides the ability to set a number of options in workflow based on cohorts. These attributes are derived and set for the activity at run time.

Example

Take the scenario where the same workflow process models students in all faculties however, each faculty has a different person that performs a specific task in the workflow process. If you set the performer of the task to be based on a workflow attribute you can then dynamically set that attribute based on the cohort. If the person or cohorts change you can alter the definition in Callista rather than having to change the workflow definition.

This same principal can be applied to an activity priority or timeout. If you want to process a certain group of students first then their priority can be set based on cohort. If the timeout to process these students is shorter for the same set of students then this can also be set dynamically. This saves having to create a separate workflow process for each different kind of student.

See WFINTRO2 for further details of a Sample Worflow Module.

Last Modified on 24 May, 2005