SLCM Product Architecture

Student Lifecycle Management
Product and Architecture
Applies to:
SAP Student Lifecycle Management
Summary
The purpose of this document is to provide an introduction to the Student Lifecycle Management product and
its architecture. For detailed description of the Student Lifecycle Management product please refer to the
Student Lifecycle Management documentation BS7 (EHP 4)
Created on: February 2011
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

© 2008 SAP AG 1
Student Lifecycle Management Product and Architecture
Table of Contents
1. Solution Scope..........................................................................................................................................3
1.1 Functional Areas: Business Processes covered by Student Lifecycle Management ..............................3
1.2. Business Processes covered by Third Party Solutions ........................................................................5
2. Solution Architecture .................................................................................................................................6
2.1. Overview ............................................................................................................................................6
2.2. Glossary .............................................................................................................................................8
2.3. Architecture of SAP SLCM Master Data Management.........................................................................9
2.4. Architecture of SAP SLCM Academic Structure.................................................................................10
3. Organizational Structure..........................................................................................................................12
3.1. Academic Calendar ..........................................................................................................................12
3.2. Program Catalogue...........................................................................................................................12
3.3. Module Catalogue.............................................................................................................................13
3.4. Event planning..................................................................................................................................13
3.5. Process Control by Rules..................................................................................................................13
3.6. External Academic Structure.............................................................................................................15
4. Student Master Data ...............................................................................................................................16
4.1. Student as an HR object ...................................................................................................................17
4.2 Student as Business Partner..............................................................................................................18
4.3. Student Contract Account .................................................................................................................19
5. Student Lifecycle Processes....................................................................................................................19
5.1. Admission and Recruitment ..............................................................................................................19
5.2 Program Registration.........................................................................................................................20
5.3 Equivalency Determination ................................................................................................................20
5.4 Module Booking.................................................................................................................................20
5.5 Grading .............................................................................................................................................20
5.6 Progression .......................................................................................................................................21
5.7 Audits ................................................................................................................................................21
5.8 Assessment Process .........................................................................................................................21
5.9 Graduation.........................................................................................................................................22
6. Student Accounting .................................................................................................................................22
7. General Concepts ...................................................................................................................................23
7.1. Authorization ........................................................................................................................................23
7.2. Audit Trail of Processes ....................................................................................................................24
7.3. Correspondence ...............................................................................................................................24
7.4. Archiving...........................................................................................................................................24
7.5. Student Self Services........................................................................................................................25
7.5.1. Online Course Registration ............................................................................................................27
7.6. Integration of SAP.............................................................................................................................29
7.1. Integration with SAP CRM ................................................................................................................29
7.2. Integration with SAP NetWeaver Identity Management......................................................................30
7.3. Integration with SAP/Non-SAP Applications ......................................................................................30
7.4. Resources ........................................................................................................................................30

© 2008 SAP AG 2
1. Solution Scope
1.1 Functional Areas: Business Processes covered by Student Lifecycle Management
This table lists Business Processes/Transactions available in SAP Student Lifecycle Management. For
details please refer to the following chapters.
1. Curriculum Management: Academic Structure and Course Scheduling (Event Planning)

1.1. Maintenance of Academic Programs
Define degree objectives: define qualification with level and type of degree or non degree
1.1.2. Define programs of study: define structure (based on study conditions of program)
expressed with objects program of study (SC), module group (CG)
1.1.3. Define majors, minors and concentrations: define specializations of program (based
on study conditions of program) with module groups (CG)
1.1.4. Define modules (courses): define modules (SM) the student should complete to
achieve qualification of program
1.1.5. Define pre- and co-requisites: define requirements for a module Student has to fullfill
before s/he is able to book this module
1.1.6. Publish academic catalog: publish study program in active versions on university
page
1.2. Maintenance of Course Catalog
1.2.1. Define and set up courses: define and plan course (events) which are offered in
current session with schedule and resources (date, time, room, etc.)
1. 2.2. Publish course catalog
1.3. Maintenance of Degree Audit Requirements
1.3.1. Define degree requirements: define requirements for a program a student has to fullfill
before s/he achieves its qualification.
1.3.2. Associate courses with degree requirements: assign degree requirements to the
academic objects (courses) of the academic program.
1.4. Class Scheduling
1.4.1. Demand Analysis: The “course demand report” shows bookings, module plan
assignments, and course registration cart counts of students. It helps to determine how
many students are likely to book a course for a future year and session.
1.4.2. Define sections and classes: Determine details of course offerings, e.g. sequence of
courses and form of teaching (lecture, classroom trainings, lab, etc.), start/end times, and
capacity.
1.4.3. Assign and schedule instructors, rooms, equipment: Maintain human and technical
resources as well as location required for the academic offering.
1.4.4. Faculty Workload Management: maintain data regarding planned and actual workload
for academic events.
1.4.5. Publish Class Schedule
2. Recruitment (-> SAP CRM)

2.1. Gathering Prospect Data
2.2. Prospect Segmentation
2.3. Campaign Management

© 2008 SAP AG 3
3. Student Administration
4. Academic Lifecycle/Student Portal Role
5. Academic Advising
5.1. Degree Audit Simulation
6. Admission and Equivalency Determination
7. Academic Work Completion
7.1. Course Registration
7.1.1. Course Selection: Student selects course (module plus event) via course registration
UI. Selection might be influenced by program objectives on the basis of a module plan.
7.1.2. Check course requirements: the needed requirements are checked; special approvals
are taken into account.
7.1.3. Course Booking: Student books modules and events.
7.1.4. Waitlisting: Student books module and event on the waitlist.
7.1.5. Course Cancellation: Student cancels booked course.
8. Study Management:
Module Plan
9. Progression (Standard Report) and Auditing
10. Teaching and Examinations
11. Student Accounting
12. Graduation
13. Student Self-Services and Faculty Self-Services
Students
13.1. Student Admission Application
13.2. Student Admission Audit
13.3. Change of Program
13.4. Change of Specialization
13.5. Grade Change Request
13.6. Graduation Request
13.7. Address Maintenance
13.8. Special Booking Authorization
13.9. Equiv. Determination Simulation
13.10. Transcript Request
13.11. Course Registration
Faculty
13.12. Online Grading
13.13. Course Request
13.14. Room Search
13.15. Maintain Transcript
13.16. Attendance Tracking

© 2008 SAP AG 4
14. Tools/Functions
14.1. Reports
14.2. Mass Processes
14.3. Selection Methods
14.4. Correspondence
14.5. Data Archiving
14.6. Authorization
14.7. Workflow
14.8. Migration Tools
14.9. Interfaces
15. IDM Integration
1.2. Business Processes covered by Third Party Solutions

Financial Aid:
In the US, Financial Aid is the total amount of financial assistance (federal and nonfederal) a
student is offered by the school. Related software solutions must address a complex set of US-
only requirements, which involves close communication with US Government agencies and
databases, as well as frequent updates regarding eligibility (etc) rules provided by the US
Government. SAP does not offer an own solution to cover this requirement but works together
with the partner Sigma Systems for the US market.
SAP ERP and SAP SLCM provide much of the data and manage e.g. the financial transactions
necessary for handling financial aid in the sense of internal grants in general.
The partner solution supports processes such as “Packaging”, "Eligibility Verification" and
"Disbursement" and provides some specific functionality such as accessibility, database
interfaces, and compliance (reports and rules updates).
SAP supports this through a partner because
1. This is US-only and SAP’s HER solution strategy is global.
2. This capability relies heavily on domain (content) knowledge which the partner has.
3. The partner solution sends data to and receives data from specific sources such as the
National Student Loan Data System (NSLDS), the database for federal student financial aid
where students can find out about the aid they have received.
4. The partner solution provides information and reports for the school, parents, and students.
Scheduling / Enhanced Event Management
Webservices are available in SLCM EHP 4 which allow for integrating SLCM with a scheduling
software. Additional effort is required in defining that integration and adapting the services.
Housing
There is no configuration delivered for integrating Student Lifecycle Management with SAP’s
Real Estate Management solution RE-FX.
Library Management
There is no library vendor with whom SAP has a partner relationship. Touchpoints between
SAP's industry solution for Higher Education, SAP Student Lifecycle Management, and a (third)
party library system are minimal:
The Library system needs to know student IDs, and probably look at any student holds that
would prevent the student from using the library services.
The Library system needs to post fines/fees to the student account
Alumni / Fundraising Management: See BPX HER -> Knowledge Center -> Fundraising Management

© 2008 SAP AG 5
Business Requirement and SLCM Module Mapping Example
No Business Requirement SAP Module Mapping
1 Organizational Structure Organizational Management, Academic Structure,

Business Partner
2 Recruiting and Admissions Admissions Recruitment via CRM Marketing and SLCM
Admission Module
3 Curriculum Management SLCM Academic Structure and Assessment
4 Calendars SLCM Academic Calendar
5 Class Timetabling SLCM Resource and Event Planning
6 Correspondence SAP Print Workbench
7 Student Records SLCM Student File/ Student Records
8 Student's Academic History SLCM Student File/ Student Records
9 Academic Advisement Academic Advisor User Interface
10 Grade book SLCM Appraisal and Assessment
11 Campus Self Service Student Self Services and Faculty Self Services
12 Student Financials SLCM Student Accounting

13 Reporting SAP BI (see SLCM BW extractors described in SLCM
Reporting cookbook on BPX HER)
2. Solution Architecture
2.1. Overview
SAP Student Lifecycle Management (SAP SLCM) is the SAP Industry Solution for educational institutions. It
is developed in software component IS-PS-CA (Industry Solutions Public Sector Contract Accounting) on top
of FI-CA (SAP ERP Financials, Contract Accounting). SLCM is part of the SAP ERP and can be activated
using the switch framework. After the technical installation of SAP ERP, the switch framework allows to
activate one industry solution in that installation.
SAP SLCM extends the functionality of SAP ERP through specific academic business processes which
cover the lifecycle of a student starting from a student’s application for a program of study at university up to
the student’s graduation. Educational institutions can manage their academic structure and curriculum, main-
tain student master data, and perform admission of students, registration, fee calculation, grading, grant
management, and graduation with SLCM. Most business processes are done in SAP GUI transactions but
self services are provided for students, academic advisors and instructors in the SAP NetWeaver Portal.
SLCM is built using different components of SAP ERP Human Capital Management (SAP ERP HCM) and
SAP ERP Financials (SAP ERP FIN). The academic structure of the university is realized using the HR
Personal Development Infotype Framework (HR PD Infotype framework). The student master data resides in
SAP Business Partner and HR PD Infotype framework. Student accounting covers business processes such
as fee calculation and grant management is built on the Public Sector extension (PSCD) of SAP Financials
Contract Accounting (FI-CA). SAP SLCM also reuses Validation Substitution Rules (VSR) from SAP ERP
FIN, correspondence from FI-CA, Internal Service Request (ISR) for admission application processing,
structural authorization from SAP ERP HCM, and business rules framework (BRF) from SAP ABA.

© 2008 SAP AG 6
Administrative users of SLCM such as registrars work directly on the SAP ERP system, whereas students
and instructors use self services such as course registration and appraisal self services. Academic Advisors
who guide and help the students in various activities such as booking courses can work on SAP ERP system
and also use the self service „Academic Advisor Web UI to view the student study details and help students
progressing in the university. Student self services are applications which can be either deployed in the
portal or function as standalone applications.
Administrators take care of master data maintenance that includes setting up the academic structure of the
university and setting up the student master data and student accounts. Student master data is implemented
using the infrastructure of SAP Business Partner and personal development infotype framework of SAP ERP
HCM. The university master data is built on SAP HCM using the PD infotype framework, Organization
management (OM) and Training and Event Management (TEM).
Post processing framework together with the business rules framework (BRF) enable universities to enhance
and adapt the student lifecycle processes to their specific needs. The post processing framework is plugged
into the business logic of the student lifecycle processes to enable the execution of follow-up activities after
the execution of the standard business process. For example, when the grading process is executed, it calls
the post processing framework, which triggers the evaluation of rules in the business rules framework (BRF).
The rules define that the university wants to inform the academic advisor in case a student gets a low grade
so that the advisor can get in touch with the student for improvements. In case the rules say that the
academic advisor needs to be informed the post processing framework triggers an email message.
Student accounting is a separate component which implements the business logic for university-specific
financial processes. For example, fee calculation is used to calculate and bill the tuition fee students have to
pay. Universities run reports that calculate the fees for the students and post the amount due into the student
accounts. Student accounts are contract accounts built on FI-CA where the amounts can be posted as tuition

© 2008 SAP AG 7
fees, meal fess, hostel fess etc. Grant evaluation allows to maintain grants and scholarships and to trigger
the corresponding payments. Student accounting is built on PSCD and FI-CA and is integrated to FI
processes such as general ledger, cash payments and so on. Universities use standard FI-CA processes
such as correspondence to send student fee invoices and dunning to dun the student if they do not pay.
SAP SLCM provides enterprise services for integration with other SAP or non-SAP applications. It provides
enterprise services for sending student master data, event planning data to other application such as a
Learning Management System. SLCM also provides enterprise services for checking the existence or
creation of academic structure objects such as academic course and program of study.
To activate the industry solution SAP SLCM the business function set „CAMPUS_MANAGEMENT needs to
be activated. Activation of the business function set will activate all the basic configurations that are required
to run SAP SLCM. Technically IS-PS-CA sits on top of software component FI-CA (Financial Contract
Accounting) and requires the following software components: SAP_BASIS, SAP_ABA, SAP_AP,
SAP_APPL, and FI-CA.
2.2. Glossary
Term Definition
Academic Advisor An academic staff member who is responsible for advising selected
students who are assigned to him or her.
Program of Study A plan of academic offerings leading to a specific degree, certificate, or
comparable qualification.
Course/Module/course module Combination of business event types and associated rules that can be
used in one or more program of study.
Module Group Combination of modules that can be used in one or more programs.
Assessment Process used to monitor and evaluate academic work which a student
submits to successfully complete the module or program.
Time limit Date or time period classification. You can use the time limit to enter a
date or time period in the academic calendar.
Infotype A set of data grouped according to subject matter. The HCM component
allows to process employee data in accordance with business
requirements. The data structure of infotypes mirrors a logical set of data
records. Infotypes can be identified by their four-digit keys, for example,
the address infotype (0006). To facilitate reporting on past employee
data, infotypes can be saved for specific periods. You can edit infotype
records individually or by using fast data entry. The following functions
are used for infotype records: Create, Change, Copy, Delimit, Delete
Business Partner A person, organization, group of persons, or group of organizations
within or outside the institution.
General ledger A ledger presents data used in creating financial statements. It records
values at company code level.
Exchange program Agreement between designated universities regarding student exchange
Rule Container Helps to manage relationships between rules and academic objects.
Rule Module Contains validations and substitutions that the system processes to
execute a check which is triggered by the occurrence of specific events.
Booking Window Time period during which only defined students are allowed to book
courses / modules.

© 2008 SAP AG 8
2.3. Architecture of SAP SLCM Master Data Management
The most important master data of SAP SLCM is the following:
Academic structure of the educational institution which describes the organizational structure of the
institution as well as programs and courses offered by it
Student master data which includes personal data
Student contract account
The master data uses the infotype framework from SAP ERP HCM, SAP Business Partner and FI-CA.

© 2008 SAP AG 9
2.4. Architecture of SAP SLCM Academic Structure
The academic structure constitutes the programs of studies a university offers, the various qualifications that
it imparts to students, and the academic offering. In SAP SLCM, the academic structure consists of:
Organizational Unit
Organizational units provide a structure to the university. The university may consist of different schools or
colleges and have departments assigned to them. The organizational structure of an institution is built using
the organization management (OM) tool of SAP HCM.
Academic Calendar
Academic Calendar is an HR PD object which is used to manage dates and time in the university.
Program of Study
A program of study represents an approved combination of modules in one or more subjects which fulfill the
requirements for a degree. Program of study is an HR PD object that constitutes the academic structure and
is maintained using the program catalogue.
Module
Module is an academic unit in which students learn about a defined content and can acquire credits for this.
Module is an HR PD object and is studied for an academic period. Universities offer the module in an
academic period so that students book the module and attend classes. Modules are assigned to a program
of study in the program catalogue. Offering of modules is maintained in the module catalogue.
Module Group
Module Groups are entities to group modules into a certain structure within the program catalogue.
Qualifications
A qualification represents the successful result of a student’s academic career. An internal qualification is an
HR object that represents degrees, diplomas and certificates awarded at institutions. They are assigned to
programs of studies that students pursue and for which final qualifications are awarded during graduation.
Event Package
An event package groups the various business events that are offered for an academic period. Business
event packages are HR objects and are maintained via event planning.
Business Event Type

Business event types give a generic structure to business events. Business event types are HR objects and
are maintained via event planning.
Business Event
Business events are classes or online learning sessions that can be scheduled and offered so that students
can book them and attend them.
Individual Work
Individual work represents a student s academic work such as a thesis or project works that can contribute to
her/ his academic work. Individual work is maintained using the program catalogue or the module catalogue.
Rule Containers

© 2008 SAP AG 10
Rule containers group business rules that need to be checked during the business processes. Rule
containers are associated to academic structure objects such as programs of study, modules, and event
packages in the program catalogue. Rule containers are used to control the business process flow.
External Academic Structure Objects

Universities can create an external academic structure as part of their academic structure using different
external academic structure objects. The external academic structure is used to determine equivalent
courses or qualifications of an incoming student from a previous organization.

© 2008 SAP AG 11
3. Organizational Structure
In Organization management, each organizational unit is an HR object which can have relationships to other
objects. This supports the assignment of positions such as heads of department positions/faculty to each
organization object. The position represents another HR object which is occupied by an employee (HR object
Person) in the university or an external employee (HR object external person).
3.1. Academic Calendar
The academic calendar contains the different dates related to business processes of the university. Business
processes of a university are aligned with its academic periods. Academic periods are time periods to
structure the academic programs of the university over time. They can be full academic years or academic
sessions e.g. fall session, winter session, summer session, or spring session. Academic years and academic
sessions are defined in customizing. Their dates are maintained in the academic calendar to indicate
When the academic session starts and ends

when the classes starts and end for that session
when the registration to courses starts and ends
when the grading period starts and ends
deadlines for the students to pay fees, etc…
Academic calendars can be assigned at the organizational unit level or at lower levels such as program of
study, module group, module, or event package. Dates are maintained using time limits. They indicate the
specific purpose for which the date and time are maintained for the relevant academic period. For example,
the standard duration of an academic period is maintained using a time limit. This time limit indicates the
start date and end of the academic period in the university. To maintain when the classes start and end for
an academic period, there will be a different time limit.
During the execution of the business process, the dates are derived from the academic calendar and
assigned to the object that takes part in the process execution. For example, when an admission is given to
a student for a program of study in academic year 2011 fall session the validity dates of the admission are
taken from the academic calendar which is associated to the program of study for which admission is
granted. If there is no academic calendar assigned to the program of study, the calendar is derived using an
evaluation path. Evaluation path is the way of finding the next object using the relationship between HR
objects that are defined in the evaluation path. Please refer to the SLCM EHP 4 documentation for details.
3.2. Program Catalogue
The program catalogue defines the structure of programs of studies that are offered by the university.
Program catalogue is a view to structure and maintain academic structure objects such as programs of
studies, module groups, modules, and qualifications. It is created by the administrator of the department
which offers the program of study.
A program of study represents an approved combination of modules in one or more subjects which fulfill the
requirements for a degree. Universities offer programs of study with different qualification levels. Students
register for one or several programs of study.
A program of study can also consist of stages. Stages structure a program of study according to a time line.
For example, a program of study with 8 stages splits the content of the program into 8 and its content is
studied in 8 academic sessions. Students have to enroll to the first stage of the program of study. The
modules or module groups that structure such programs are also associated into these stages. A student
registers to only those modules or module groups which belong to the current stage of the programs/he
studies. Progression of the student takes place along the stages of the program until s/he completes the final
stage and graduates.
Module or course is an academic unit in which students learn about a defined content and can acquire
credits for this. Most modules are offered as courses but they can also represent a more generic type of
academic work, such as a thesis. They can be offered as one business event or as a number of business
events.

© 2008 SAP AG 12
Module groups are entities that group modules to give a structure to the program catalogue. Module groups
can be used for two different purposes:
1. Module groups refer to a combination of modules and represent for example a structure for a catalog or
set of modules for a degree requirement. For example, a university can have modules Mathematics Part1
and Mathematics Part2 as part of their core mathematics study. They create a module group Mathematics
Core to include both the modules.
2. Specialization for a Program of Study such as major and minor: A university allows students to take
specialization subjects like major or minor and these will be considered for the progression of a student. E.g.
a major in computer science can contain modules „artificial intelligence or „neural networks . Students
studying these major subjects get additional eligibility or credits to progress further.
The academic structure is based on HR Personal Development (HR PD) framework and uses an object
oriented approach. There are object types that generalize characteristics of objects. The described objects
like organizational unit, program of study, module group, module, event type, event etc. are PD objects.
Attributes of these objects are grouped into infotypes, e.g. personal data details like name, age, birthplace,
etc. can be grouped into an infotype „Personal Data . The advantage is that the infotypes can be reused, e.g.
the personal data infotype is used to represent a student and lecturer.
3.3. Module Catalogue
The module catalogue defines the academic offerings of the university. In this transaction, sessions of
offerings for modules and individual work data for modules can be maintained. It is typically administered by
the administrator of the department which offers modules, classes, and individual work. As the program
catalogue, the module catalogue is used to enter academic structure data but only to maintain the offerings.
3.4. Event planning
Event planning or class scheduling supports the planning of lectures, classes, and the assignment of
resources such as rooms for these offerings. Event planning reuses objects from Training and Event
Management (TEM).
Lecture classes are maintained with business event objects, for online courses time independent events are
used. Business events and Time independent events are created for a course module for a particular
academic period. These events are created from a template called Business Event Type.
Business events include data such as schedule information with the time of lecturing, the instructor’s name of
the session, the room in which the lecture is held and the location or the building where the event takes
place. There can be events without schedule and events with irregular schedule.
Business events and Time independent events are grouped into event packages. Event package is also an
HR PD object that is assigned to a course module through HR relationships. Modules, event packages and
events are created and offered for academic periods. During the course registration (module booking)
process, students book the course module and also the event package or the event. Unless a module or
event package is offered, the students cannot book or register to these modules or event packages.
3.5. Process Control by Rules
Universities set up guidelines on how business processes work in their environment. All these policies and
guidelines constitute the business rules that a university uses for its business processes. E.g., to decide
whether a student can be given admission, rules need to be checked to find out the student’s eligibility.
To manage business rules, SAP SLCM uses rule engines such as Validations Substitutions Rules (VSR) and
Business Rules Framework (BRF). Some rules are also built using the relationships of objects in the
academic structure. For a specific scenario, a course module should not be allowed to be booked unless a
pre-requisite module is completed successfully. This rule is built using the pre-requisite relationship of
academic course modules. To decide whether a business process can be carried out for a student, statuses

© 2008 SAP AG 13
or holds are used. One example may be that students who have not paid the registration fee will get a
financial hold. Further processes such as booking of academic course modules and the booking of class
lectures will not be possible unless the financial holds are removed for that student.
VSR is a rules engine from SAP ERP Financials to manage validation and substitution of business data
during the business process. Multiple rules that are created in VSR are grouped into rule containers to
support the control of the different business processes at the university. Rule containers are associated
either to a process or to specific objects in the academic structure so that during the process execution the
rule containers are evaluated and data validations or substitutions are carried out. Rule containers are
associated to the processes using „call up points. Call up points are points or places within SLCM processes
where business rules are checked. Call up points are defined for every process in SAP. Rule containers are
associated to call up points in two ways. Either by assigning them directly to call up points. Or by assigning
them to academic structure objects using HR relationships and specifying the call up point in the relationship.
When the process is executed, the call up points are reached and the rule containers are determined by
reading those rule containers that are directly assigned and also those that are indirectly assigned via the
academic structure objects. Rule containers associated to the academic structure objects are only
considered if the academic structure object is part in that specific process.
The below graphic describes the existing rule frameworks in SLCM.
BRF is a rules engine in SAP NetWeaver and is used by the SAP SLCM Post Processing framework.
Business rules are checked and when a rule is fullfilled, the post processing activity is carried out. Students
may drop or cancel course registrations because of their unavailability. Cancelling a course registration can

© 2008 SAP AG 14
lower the performance index of a student. If the performance of a student is below the expected value, the
academic advisor needs to be informed. In this case, cancelling the course registration is the business
process and informing the advisor is the post-processing activity. The check whether the student
performance is below the expected value is done by business rules. Business rules are maintained in BRF
and are associated to business events in BRF. For each business process, there is a business event in BRF.
On successful execution of the business process, the business event in BRF is called.
Statuses are used to map a student s general status or status in relation to a specific program of study. E.g,,
when an admission application is created for a student, s/he gets a status „Applicant assigned. On approval
of the admission application, the status changes to „Admitted Applicant . On registering or enrolling to the
program, the status changes to „Student . There are system statuses and customer statuses. Statuses are
associated to call up points and processes and are checked during the execution of the process. Depending
on the status of the student, the process can be continued or discontinued.
Holds have the same concept as statuses but they are used only for preventing the student from execution of
a business process. Holds are also associated to call up points and processes. When the call up point is
reached upon the execution of the business process, the holds are checked. If the holds are active, the user
is stopped from execution of the business process. A student has to pay the registration fee or hand in a
certain certificate before he/she is allowed to continue his/her studies. The system sets a hold and displays
an error message that the student has to pay the fee or hand in the certificate before he/she can book
modules. This prevents a student from module booking until the hold is deactivated.
Apart from the above rule engines, SAP SLCM also has an inbuilt rules engine – the audit framework. The
audit framework is used for admission audit and degree audit and is linked with the assessment process.
Assessment is a process where the performance of students is evaluated during exams. Users can create
rules in terms of requirements such as university general requirements or program specific requirements. For
example, students should have a specific GPA to be graduated. This represents a university specific
requirement that applies to all the programs in the university. To get admission to a masters program in
Electronics, the students must have completed successfully a graduation program in electronics describes a
program specific requirement. All such rules are grouped into rule containers and are called only by the
specific process such as admission audit and degree audit.
Extended Booking Check Framework is another rule framework that is used for managing rules for academic
course module booking. For example an academic course module should not be booked unless
certain course modules are completed successfully by the student (pre-requisite relationship)
certain course modules are also booked in the same academic period (co-requisite relationship)
students have obtained certain credits or booked certain number of course modules
Above rules are set up using the extended booking check framework. The framework technically re-uses the
audits framework for setting up the rules.
3.6. External Academic Structure
Apart from the academic structure of the university, the university also maintains an external academic
structure. It consists of entities such as external organizations, external qualifications, and external subjects.
All these constitute the external achievements of the student. Through the business process “equivalency
determination (ED)” the university transfers the external works of the students to internal academic work.
External educational organizations (EO) are high schools and transfer institutions that students attended
prior to coming to university. They can also be testing agencies/sources from which universities receive the
test score results of prospective students.
External qualifications (EQ) are qualifications students acquired during prior studies (e.g. high school
certificate, degrees).
External subjects (SU) are the subjects students took at external educational organizations or previous
school results.
Exchange programs are programs offered by the external organization that can be transferred to an internal
program of study.

© 2008 SAP AG 15
4. Student Master Data

Students represent the core objects in the SLCM and drive the various business processes in the university.
Student master data stores students’ personal data such as address, bank account, and study data.
A student object technically consists of
Student as an HR PD (Personal Development) object of type „ST . This object is used in student
administration processes. Attributes of students such as personal data and study data are stored as
infotypes for student object.
Student as a business partner object with BP Roles PSCM10 (Student) and MKK (Contract Partner).
When a student is created, an HR object and a BP are created. Therefore the student master data
maintenance transaction has screens for maintaining student HR data and central business partner data.
The Business Data Toolset (BDT) is used to support screens for maintaining BP related data for the student.
A student HR object will always have a student business partner attached to it. The student is also a BP.
Business partner with role Contract Partner can have many contract accounts. A student business partner
will always have a student contract account and can hold many other contract accounts also. The contract
account is used for student accounting purposes. All fees that the student has to pay for the studies are
posted to this contract account. Also the financial aids or grants that the student gets are also posted into this
contract account. The student contract account will have many contract objects. Contract Objects hold the
accounting information for the contract account. Contract objects are optional but are used in student
accounting to group postings made to the student contract account such e.g. as tuition fees, and library fees.

© 2008 SAP AG 16
4.1. Student as an HR object

In academic processes such as admissions, program registration, module booking, progression, and
graduation, the relevant object which is involved is the student HR object. The object is identified by a unique
object ID and is characterised by a number of attributes which are stored as info types.
The HR student object stores the following information:
Personal Data
Personal data contain information such as First /Last name, Country of Birth, date of birth, Nationality, etc.
Additional Personal Data

Additional Personal Data contain information such as religion, social status, social service number, etc.
Individual Study Data

Study data holds information as student group, module booking data, campus data, and organizational unit.
VISA data
VISA data contain information about the various VISA details of the student.
Residency Data
Residency data contain information about the resident country, state, county, passport details etc.
Challenge
Challenge data stores information such as challenge type and e.g. the degree of the physically challenge.
Employment
Employment data stores details about the employments that the student did in the past or is currently doing.
Alumnus Data
Alumnus data stores details about the previous organizations of the student where s/he is an alumni.
Fee Calculation Data

Fee calculation data contain information as fee category, benefit category, and discounts for the student.
The student object is also responsible for storing various transactional data such as academic work record
usages, progression results, audit results, student statuses, student holds, student notes during various
business processes within SLCM.

© 2008 SAP AG 17
4.2 Student as Business Partner
Student object as central business partner plays an important role in student accounting activities and also in
integration scenarios where the student objects are distributed. For example, the SLCM - CRM integration is
based on the student BP. Standard student master data integration to any other system including any 3rd
party system using enterprise services is based on BP integration. Student master data integration is an
enhancement to the BP integration to contain HR related student information.
The student BP is created with two business partner roles: PSCM10 (Student) and MKK (Contract Partner).
The student role identifies the business partner as student, the role Contract Partner allows that the student
business partner holds the student contract account where student fee and student grant data is posted.
The student business partner always has a student contract account and optionally some contract objects.
It stores information about:
Personal data
Personal data stores information such as first name, last name, nationality, date of birth, etc. The same
information is also stored as infotype in the student HR object. The data is first saved in the student business
partner and is then synchronized into the HR infotype.
Student address
Student addresses such as standard address, correspondence address, etc, are stored in the BP. Here the
complete address functionality of the central BP is re-used.
Identification numbers
Stores identification numbers of a student.
Bank details
Stores bank details of the student.
Payment details
Payment details capture information such as the payment method, credit card details etc.
To maintain all the data, standard business partner screen are used based on the BDT (Business Data Tool)
framework. Using BDT allows easy enhancement of fields and screens by customers.

© 2008 SAP AG 18
4.3. Student Contract Account
Whenever a student master data record is created, a student contract account is created in contract
accounting of SAP ERP Financials.
Student contract account data is used for student accounting at the institute. All fees that the student needs
to pay to the institution, all the grants or awards or scholarships that the student receives is recorded or
posted in the student s contract account data. Contract accounts can be created for business partners with
role contract partner (MKK). Student BPs are created with role contract partner so that contract accounts can
be created for them.
The fee calculation process calculates the fees that the student has to pay for the academic period and
finally posts the amount into the student account.
Grant evaluation process evaluates the amount the student gets as grant for her/his studies in the university
and posts the amount into the contract account.
Dunning is an FI-CA process which can be used to dun the student and send correspondence in case the
student has some outstanding amount due in the contract account. The contract accounts are collected at
the end and updated into the university s general ledger.
Contract objects hold the accounting information for the contract account. Contract objects are optional for a
contract account. Contract Objects can be of two types. Tangible contract objects such as person or property
(car, house) and intangible contract objects such as specific fee categories such as tuition, housing, meal
voucher, etc.. Intangible contract objects are used in SLCM to post the fee amounts. For example, in a
student contract account, fees are posted as tuition fee or meal fees. In SLCM, the required contract objects
are automatically created on creation of contract accounts.
5. Student Lifecycle Processes
SAP SLCM provides business processes support for administering a student lifecycle at an educational
institution. These business processes cover the student’s application for admission up to the student’s
graduation from the university. The different processes are explained in the following.
5.1. Admission and Recruitment

Students may enter educational institutions either through the recruitment process or directly through the
admissions process. Universities can run recruitment campaigns to make prospects aware of the academic
programs offered by the university. Through recruitment campaigns, the university identifies these prospects
with the goal to turn them into students. The recruitment process is realized using a BP integration of SAP
CRM and SAP SLCM. Running marketing campaigns and identifying the prospects and leads is performed in
SAP CRM. Prospects turn into students when they apply for the program of study at the university. Here the
BP data from SAP CRM is used to create the student in SAP SLCM. The recruitment process is not part of
the standard SAP SLCM offering, but can be implemented by the customer.
Students enter into the university through the admissions process. Students get to know about the programs
offered by the university and apply for getting an admission. Universities can provide an online admission
application form to the student in the university portal which is provided by SAP NetWeaver Portal. Students
fill the form with the required details and submit the form. When the form is submitted, an admission
application is created in SAP SLCM either manually or automatically depending on the configuration.
The online student admission application form is supported by Internal Service Request (ISR – also called
Internet Service Request, as the tool can also be used for web based internet applications). ISR is a SAP
NetWeaver tool to support online processing of form requests. Actions or workflows can be configured to
start on submission of ISR forms using ISR notifications. Applicants submit the admission application form
after filling all the details required for the university. On submission of the application form, an ISR notification
is created. Actions or workflows can be configured as different steps for the processing of the ISR
notification. These actions or workflows can create the student master data and the admission application
automatically. An admission officer can create an admission application manually, too. When an admission
application is created, status „Applicant is assigned to the BP.

© 2008 SAP AG 19
After the admission application is created, the eligibility of the applicant for admission is checked. The
admission audit can be used to determine based on the results whether the admission can be approved or
not. Once the admission is approved, the „Applicant becomes an „Admitted Applicant at the university.
5.2 Program Registration

Via the program registration, a student enrolls at the university for the academic period. The registration is
typically executed by the Registrar office. A program registration is required for the student’s entry at the
university. For a program that spans across many academic periods, students need to enroll for each
academic session to continue their studies. Program registration is a pre-requisite for all further business
processes such as course registration, grading, and progression. After the program registration, an „Admitted
Applicant becomes a „Student
5.3 Equivalency Determination

Equivalency determination (ED) is a process through which the university transfers external academic work
of students to internal academic work.
Students submit transcripts of their previous university and based on this, the university maintains external
academic work for the students. The university can set up transfer agreements for transferring the external
achievements to internal academic work. Transfer agreements are agreements which decide which external
academic work can be considered and transferred to an internal academic work. Transfer agreements are
built based on the policies and guidelines of the university. For example a transfer agreement can be that a
post graduate program in Electronics from university A is equivalent to a graduate program at university B.
Another example could be that course „Basic Electronics from university A with Grade A translates into
academic course „Advanced Basic Electronics at university B with grade B.
5.4 Module Booking

Module booking (Course Registration) is the process whereby students register for academic courses and
classes. Students register to academic courses (modules) either through their academic advisors or by using
the student self service in SAP NetWeaver Portal for course registration. Course registration creates an HR
relationship between the student object and the module object. If the capacity of the module has reached an
optimum level, students are booked as waitlisted if the system has been configured accordingly. It is then
possible to move up the students from waitlisted bookings to normal bookings when there are booking
cancellations or capacity of the module is increased.
The course registration self service for students is built as a composite application and the front end is
completely decoupled from the backend. All communication from the front end to the backend takes place
through Remote Function Calls (RFC’s). The calls to RFC’s are made through Business AddIn (BAdI)
implementations so that potentially the RFC calls can be easily replaced by the enterprise service calls. This
represents a security measurement for the self service web application. Students also have access to further
self services in the portal like change of address and request for a change of program.
Instructors or teachers evaluate students through the grading process. Teachers can do an online grading
through the corresponding self service application for appraisers.
5.5 Grading
Students’ academic work is evaluated and awarded a grade by instructors during this process. The process
typically starts at the end of an academic session. Grades and credits are used to evaluate the performance
of the student and to finally decide on the student’s progression.
Instructors can grade the students using the online grading self service functionality or through the
corresponding backend functionality in the SAP GUI. If required configuration has been done, instructors will
get the list of students for whom they are responsible for grading and grade them accordingly. Grades are
stored as academic work record in the academic work history.

© 2008 SAP AG 20
5.6 Progression
Students performance is calculated based on the grades and credits that they achieved at the end of an
academic session. Indexes are used to evaluate performance. Based on these indexes, students progress in
their studies. For example, they are awarded with the academic standing such as honors, first class, and
second class at the end of progression. There are two types of progression supported: Program Type
Progression and Stage Progression.
Program Type Progressions is used for undergraduate and graduate programs in the United States.
Students are promoted depending on the program type, such as undergraduate or postgraduate.
Progression categories for undergraduates include freshman, sophomore, junior and senior.
In contrast to program type progression, stage progression is typical for European universities and for
professional programs in the US. A staged program of study requires the completion of a stage before
students can progress to the next stage. Each stage sets requirements which have to be fulfilled to complete
the stage. Stage audits are used to check whether requirements were met. The stage completion process is
part of the student’s academic progression.
5.7 Audits
Auditing is a process that defines and checks requirements that a student has to fulfill for the completion of
certain business processes. The audit returns a result based on which the university can e.g. execute an
admission or award a degree for a student. SAP SLCM supports the following three types of audit runs:
Admission Audit: Before granting admission to a student, specified university requirements can be
checked to see if the student full fills the admission criteria. If configured, the admission audit is called
before executing the admission application for the student.
Stage Audit: A program of study can be divided into stages. A student starts with the first stage and
progresses to subsequent stages based upon successful completion of each of the stages. Via stage
audit it can be determined at the end of an academic period whether a student can progress from one
stage to another.
Degree Audit: After completion of a program of study, a degree audit determines whether the student is
eligible to receive the degree or final qualification. A degree audit is executed upon the graduation
request by the student.
Business rules are created in the audit framework based on the type of audit run and are called and
evaluated during the audit run.
The audit framework is built using rule containers, rule modules and BAdI implementations. The rules or the
conditions are created as rule modules and are called sub-requirements. Sub requirements are actually
implemented as BAdI implementations. Sub-requirements are grouped into requirements which are stored as
rule containers. There are two kinds of requirements - concrete requirements and abstract requirements.
Concrete requirements are actual requirements which are associated to academic structure objects and call
up points. Abstract requirements contain requirement pattern that give a structure to the requirements. For
example, in a university, a degree can be awarded if the program requirements are fulfilled by the student.
The program requirement can consist of general requirements and major requirements. This structuring is
achieved by using a requirement pattern. The requirement such as that the student should have an overall
credit of 35 to be graduated is a concrete requirement. The requirements are associated into requirement
catalogs. Requirement catalogues are created for each audit types and are associated to students and/or to
the programs of study. When an audit is run for the student, the requirement catalogues are checked and the
requirements are determined. Sub requirements are evaluated to get the final result.
5.8 Assessment Process

During the assessment process students’ academic work is evaluated. Two types of assessments are
supported in SLCM: Assessments for Exams and Assessments for Program Completion/ Stage completion.
Assessments are created as academic structure objects and are scheduled for academic periods. When
registering to these assessments, an assessment process for the specified student is opened. The
assessment process sets a status at the student based on the assessment process step.

© 2008 SAP AG 21
Exam assessments are created for academic course modules. Students register to course modules and also
to exam assessments. Once the exam assessment has been completed, it can be re-used in grading to
derive the grade for that student.
Finally, a student’s request for graduation, opens an assessment for program completion. The assessment
can link to the degree audit and its result will set the status of the assessment as completed. Once the
assessment process has been completed successfully, students are awarded a degree.
The assessment process is an optional process in SLCM.
5.9 Graduation
Students progress during the course of their study and this process is referred to as progression. To
complete their studies at the university, students can use the graduation self service request to request for
their graduation. On receipt of the request, the degree audit process is triggered to check whether a student
successfully meets the requirements of the institution to get the degree qualification. Based on the audit
result, students are awarded the respective degree. After their graduation, the alumni status can be assigned
to them by the institution.
6. Student Accounting (for details refer to the Student Accounting cookbook in BPX HER)
Student accounting supports the following processes at universities and educational institutions:
Calculating fees that students need to pay for their studies. The fees are posted in the contract account
of the student and then to the general ledger (G/L) of the institution. Here SAP SLCM is integrated to
SAP ERP Financials.
Calculating the grants that students receive to pay for their studies and other institutional expenses. The
grant amounts are also posted onto the student s contract account and finally to the G/L of the university.
Managing the university funds in providing the grants or awards to the students. Here SAP SLCM is
integrated with Controlling and Funds Management of SAP ERP FIN.

© 2008 SAP AG 22
The fee calculation process uses the student’s study data and calculates the fees that the student needs to
pay to the university. Fee calculation allows calculation of fees for individual students, or in a mass run for
several students. Calculation takes place based on a set of business rules referring to the student master
data and study details. The rules are set up using the SAP ERP SD pricing tool. During fee calculation the
rules are evaluated and results are calculated
Each fee calculation run creates fee calculation documents. Fee calculation documents are required for
audits and are used to analyze the calculated result. After calculating the fees, administrators can manually
correct the calculated result and finally post the result to the student contract account.
Calculated fees are posted into the student contract account as an FI-CA document. It is a Financial Contract
Account document that contains the fee information for the students. The document’s line items show the
fees that the student has to pay based on grouping such as tuition fee, meal fee, hostel fee. The grouping
can be configured and is based on contract object types that are defined for the contract account.
The contract object type defines the type of fees which are posted.
The due date schedule defines the date when the student has to pay a certain fee. These dates are derived
from the academic calendar. Based on the due date schedule, the fees are split and posted separately into
the student contract account.
Universities can also distribute these revenues using Public Sector Funds Management. The fees calculated
for the students or the financial aid calculated for the students can be integrated to funds management. For
example the revenue that the university gets out of fees can be linked to a fund. In addition a university can
use their own funds in giving grants or financial aids to the students. The fund center, fund and controlling
rules are associated to the objects in the academic structure. During posting of the fees or the financial aid
amount, the correct fund centre, fund, and profit centre are derived from the academic structure objects such
as organization unit and the program of study. The derivation of the fund management objects is based on
the controlling rules defined at these academic structure objects.
7. General Concepts
7.1. Authorization (for details refer to the SLCM authorization cookbook in BPX HER)
Access to SLCM data can be restricted in the sense that authorization is based on the type of data - master
data and transaction data. Master data access authorizes users to create/change/delete master data.
SLCM master data is mainly HR data and BP data. For HR data the authorization is carried out using
Basic authorization
For basic authorization, objects are created and checked in the programs. User profiles and PFCG roles
are created based on these authorization objects and are assigned to the users using SU01.
Structural Authorization
Authorization checks in Student Lifecycle Management are using HCM’s structural authorization. It is
based on HR objects P_CM_PROC and PIQ_PLOG. PLOG checks whether a user is allowed to read,
write or insert specific HR infotypes. P_CM_PROC checks whether a user has the authorization for a
specific Student Lifecycle Management process. SLCM provides BADI HRPIQ00AUTHORITY which is
called during each authorization check but this BADI cannot be used for complex requirements, e.g.
“context sensitive authorization checks”. That means that the assignment of different activities
(=business contexts) which span across different organization units is not possible.
The list of HR objects that a user can access are determined using an evaluation path. The evaluation
path is configurable and has a root object. All other objects are determined from the root object which is
related to the root object where the relationship is maintained in the evaluation path. A profile is created
using the evaluation path and assigned to the user using HR customizing. For checking additional
authorizations at student master data, there are BAdIs available. To set authorization at Business
Partner data, event AUTH1 for BP object BUPA can be used.
Transaction data access authorizes users to execute business processes within SLCM. For example, an
instructor is allowed to do grading but not to carry out admission. This process based authorization is
achieved using authorization objects which check the authority of the user to execute the process.
The list of processes is delivered by SAP.

© 2008 SAP AG 23
7.2. Audit Trail of Processes (for details refer to the SLCM audit trail cookbook in BPX HER)
Audit Trails track master data changes and changes within administrative processes to show which data was
changed when and by whom. Student Lifecycle Management offers two concepts: Change Documents and
Activity Documents:
Change Documents
Change documents log master data changes and always refer to an application. They show the technical
audit trail of a process and record changes to data base tables.
Activity Documents
Activity documents show the business audit trail of the process and always refer to a business process
and the student for whom the process is executed. Activity documents are linked to the change
documents that are created during the execution of the process. Activity documents are created for all
business processes that are delivered by SAP.
7.3. Correspondence
The correspondence functionality enables universities to print documents containing student and academic
information. The tool can be run for individual students or for a group of students. Correspondence is FI-CA
based and has been adapted to support correspondence requirements for SLCM by adding correspondence
types specific for SLCM.
There are three correspondence types supported in SLCM depending on the available data:
Student Correspondence
Student correspondence helps to create and print documents containing student information.
Admission Correspondence
Admission correspondence creates documents containing information about the admission details of the
student. Admission correspondence is run immediately after the admissions process is completed.
Module Correspondence
Module correspondence creates documents with information about the courses that the student studies.
Correspondence is done in two steps:
Correspondence creation: This creates the document and stores data in the correspondence container.
Correspondence Print: This step moves data from the correspondence container to the print workbench
and uses the print workbench to print the document.
7.4. Archiving (for details refer to the SLCM archiving cookbook in the BPX HER Knowledge Center)
SLCM supports archiving information that is no longer required, e.g. after the student has graduated such as:
Student master records
Contract objects and contract accounts
Activity documents
Change documents
FI-CA documents
Fee calculation documents
Audit runs, etc.
Archiving re-uses standard archiving functionality from SAP_BASIS. Archiving functionality is developed
based on ADK (Archiving Development Kit) which is the technical framework for archiving. ADK provides the
runtime and administration environment for SAP archiving. Archiving objects are created for SLCM to
support the archiving requirements.

© 2008 SAP AG 24
7.5. Student Self Services

The University provides students self services for students and staff based on SAP web dynpro technology.
These online applications are available:
Degree Audit
Grading / Appraisal
Academic Advisor User Interface
Course Registration User Interface
Missing Grades (alert report)
Incomplete Grades (alert report with Web Interaction)
Student Self-Services
Student Admission Application
Student Admission Audit
Change of Program
Change of Specialization
Grade Change Request
Graduation Request
Address Maintenance
Special Booking Authorization
Equiv. Determination Simulation
Transcript Request
Online Audits—Audit run application in student mode
View academic work information
Course Request
Room Search
Maintain Transcript
Attendance Tracking
Faculty Workload report
Academic Substitution
Universities need to ensure that data which students can change via self services are in a secure
environment and do not allow access directly via the HTTP protocol. To achieve this, self services need to be
deployed in a specific way at the universities. The self service online course registration is deployed in a
different way. See the following chapter for details.
To achieve secured calls from the web application (self services), the recommended way is that all student
sensitive data is decoupled from the system in which students access the self service applications. This
means the solution IS-PS-CA needs to be installed in two different systems. One is the front end application
where student self services are deployed, the other one is the back end application where all the student
data is maintained. The university can set up a firewall between the front end and the backend system so
that access to the backend system takes always place through the firewall. Students request data in the
frontend application. This request picks data from the backend application via RFC calls to ensure security.
The figure 6-1 below shows the architecture of all student self services except the Online Course registration.
Students can access the application either as a standalone application through a web browser or through the
application deployed in SAP Enterprise Portal. In the latter case, the enterprise portal should be connected to
the front end application where IS-PS-CA is installed. The user interface is built with web dynpro screens. All
UI displays and actions of web dynpro screens are handled by the user interface handling layer.
UI handling layer consist of a set of assistant classes that handle the user requests in the applications. The
assistant classes use the model classes to fetch the required data. All those data such as customizing
settings and academic structure data that are read only in the web application are read from the front end
system so they need to be set up in the front end system.
All student related information is read and updated in the back end system using RFC calls. So the back end
will have all the student information maintained. In addition the back end system can be firewall protected (to
allow only RFC protocol based calls) to prevent attacks from outside.

© 2008 SAP AG 25

© 2008 SAP AG 26
7.5.1. Online Course Registration (for details refer to the Online Registration cookbook in BPX HER)
With this web application, students can register for courses themselves without having to contact their
academic advisor or administrative staff to book a particular course:
Students can see their courses with statuses registered, cancelled, waitlisted and special approvals.
Students can search for courses and store them in the registration cart to be booked later.
The Course Registration application allows students to view and register for courses that have been
suggested by their academic advisors for a particular year and session. Course registration corresponds to
the module booking function in the back-end system. The application has an intuitive and flexible user
interface characterized by high performance. A general authorization check at application level and data
level ensures that users can perform permitted actions only. In addition, customers can implement a firewall
to protect their productive server from outside attacks. This means that the UI layer and the business logic
layer are totally separated and are installed on different servers.
As shown in the below figure, students access the application either as a standalone application through a
web browser or through the application deployed in SAP Enterprise Portal. In the latter case, the enterprise
portal should be connected to the front end application where the thin client application (package
PMIQ_COMP) is installed on a SAP NetWeaver instance without installing any ECC (ERP Core
components) on it. The separation as two layers – front end and back end has a twofold meaning here:
Functional Separation
The Course Registration UI like the student UI in general, should have a clear separation between UI
and backend function. The frontend part (the part shown in green) includes only the UI related functions,
such as UI presentation or help text/documents or UI related handling and logics. All the business logic
and data storage are controlled only by the backend part such as read/change/check/search information.
The frontend communicates with backend parts only via RFC calls. The user requests are handled by
the UI handler layer which calls business abstraction layers. Business Abstraction layer handle the logic
of decoupling the front end application with the back end. Abstraction layer contain a list of BAdI
implementations that direct the calls to the backend application. The BAdI implementations call the
Business Logic Layer in the backend using RFC enabled function modules. The BAdI implementations
can be replaced by „Enterprise Service Calls that also call the backend application.
DDIC Separation/Independence
The objects in frontend and backend shall be stored in 2 different packages: PMIQ_COMP and
PMIQ_ESOA_ST.
The package PMIQ_COMP should only use DDIC objects from package SAP_BASIS or SAP_ABA. Any
DDIC objects from PMIQ* (except PMIQ_COMP) are NOT to be used.
Customer can then install the frontend layer on a very „thin and clean system, which has no ERP
components.
Due to the separation of frontend and backend, customers can add a firewall (to allow only RFC protocol
based calls or enterprise service calls) between the frontend and backend system. Students can only
access the frontend servers which are outside of firewall. Their operations are filtered and limited by the
firewall. All the productive servers are inside the firewall and are protected.
Another advantage is that in case the frontend system faces technical problems, the backend system
can still be kept safe still. Internal staff, e.g. registrars or administrators, can still work in the productive
and secured system.

© 2008 SAP AG 27

© 2008 SAP AG 28
7.6. Integration of SAP SLCM
SAP SLCM offers integration capabilities to other applications. In all integration scenarios, the business
partner part of the student is the leading entity. The following integrations already exist:
Integration SAP CRM and SAP SLCM BP to support student recruitment

Integration with SAP NetWeaver Identity Management
Integration with SAP/non-SAP applications: SAP SLCM uses SAP NetWeaver Process Integration (PI) to
provide student master data, academic structure data and student study data to any SAP or non-SAP
applications.
Integration to SAP Records Management to manage students’ study records: During admissions, the
university can request study records such as certificates and transcripts from the applicant’s previous
university. These documents are stored in records management to support the admission process.
7.1. Integration with SAP CRM (for details refer to the SLCM–CRM integration cookbook in BPX HER)
SAP Customer Relationship Management helps an organization to manage the relationships with its
customers. In a university environment, customers are represented by applicants and students and the
university can manage its relationship with them through SAP CRM Marketing functionality.
Student Recruitment is a process for which the BP integration of SLCM with CRM can be used. Educational
institutions can set up and run recruitment campaigns to attract and recruit students for their upcoming
academic session. Recruitment activities include campaigns in which different communication channels can
be applied to keep in touch with prospects (e.g. via surveys, follow up activities, emails, etc.). Survey results
can e.g. be used to identify the academic interests of prospects and to send out appropriate academic
information materials. The SAP Business Partner is the entity that exists in both systems and acts as entity
for integration. A student in SLCM is a business partner with role „Student . This business partner can be
replicated to SAP CRM as business partner with role „Student Record Holder . This happens vice versa also.
When a student record holder business partner from SAP CRM is replicated in SAP SLCM, it will have the
role „Student assigned to it. The integration takes place through CRM middleware. The integration reuses
standard functionality of CRM BP integration with ERP. The replication can be triggered from both systems.

© 2008 SAP AG 29
7.2. Integration with SAP NetWeaver Identity Management

User management of SAP SLCM is integrated with SAP NetWeaver Identity Management (IDM) which
allows to manage users centrally in an identity management system. In a typical educational institute
landscape, there are multiple applications in which students have users, for example, library management
system, university portal, and SAP SLCM. With the SAP NetWeaver Identity Management it is possible to
manage student users for all these applications centrally. The integration is available from SAP SLCM
Enhancement Package 5 release onwards.
SLCM is integrated to IDM from the student perspective. All students who have a user in SLCM receive an
identity in IDM. Creation of student identities in the identity hub and provisioning of users in SLCM and portal
are similar to the existing HCM employee scenario in IDM. The student identity in IDM will have attributes of
a person or employee (attributes relevant from an SU01 user) and additional attributes relevant for a student
user. The additional attributes are set by SLCM when the identities are created. These attributes distinguish
the student identity from other employee identities. After identities are created, users can be provisioned in
SLCM system or enterprise portal or other applications connected to IDM. This provisioning can be manual
or automatic. The attributes of the identity are used to create rules or logic to assign business roles while
user provisioning from IDM. The rules or logic are scripts such as Javascripts which decide what roles to be
assigned to the user during provisioning.
7.3. Integration with SAP/Non-SAP Applications (for details refer to the SLCM Post Processing cookbook
in BPX HER)
SAP SLCM offers Enterprise Services to integrate SAP or non-SAP applications. For master data exchange,
services exist which reuse existing BP integration services and include SLCM specific attributes.
SLCM also offers Remote Function Modules (RFCs) for integration with other applications.
Student master data are replicated or integrated to other systems using the standard integration feature of
SAP Business Partner (BP). The enterprise services for BP are enhanced to include student details so that
standard BP integration is used for student master data integration.
There are enterprise services available to integrate academic structure data and event planning data to a
Learning Management System (LMS). Also, student lifecycle processes like admission, registration, and
graduation can call enterprise services to push data from SAP SLCM to other SAP/non-SAP applications.
Often integration with external non-SAP systems requires additional integration logic, data evaluations, and
mappings. The post processing framework which is part of SAP ERP allows to insert certain logic after a
standard student process is executed successfully. A real-time integration is possible by calling the outbound
asynchronous process enterprise services on successful completion of an SAP SLCM process.
Systems such as financial aid systems require the study details of a student. Financial aid systems help
universities to find and manage the aid or scholarship for students. The financial aid systems require the up-
to-date details of the student studies. The post processing framework calls the enterprise services
automatically on change of the student study details. These enterprise services can be used by the financial
aid system to get updates of the student s studies.
Mass reports help in replicating data to other systems during the initial set up of the integration scenarios.
Reports are used for initial load where the integration is just set up or during delta load where the integration
should be switched off for some time and switched on again. The reports call the enterprise services and
update the data from SAP SLCM.
7.4. Resources
All mentioned cookbooks are available at the Higher Education & Research Business Process Expert (BPX)
Community at https://www.sdn.sap.com/irj/sdn/bpx-highered.
The Student Lifecycle Management Online Documentation is available on the Help Portal:
https://help.sap.com/ -> SAP ERP Central Component-> SAP ERP Enhancement Packages-> Industries in
SAP ERP-> Student Lifecycle Management (IS-HER-CM)

© 2008 SAP AG 30
Copyright
© 2008 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,
zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere,
Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of
IBM Corporation.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems
Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of
Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts
Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by
Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All
other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP
Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the
express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied
warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may
result from the use of these materials.
SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these
materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and
does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.
Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be
used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of
certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors
or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

© 2008 SAP AG 31

SLCM Product Architecture

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SLCM Product Architecture

Uploaded by

Copyright:

Available Formats

Student Lifecycle Management

Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

1. Curriculum Management: Academic Structure and Course Scheduling (Event Planning)

2. Recruitment (-> SAP CRM)

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

1.2. Business Processes covered by Third Party Solutions

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

Business Requirement and SLCM Module Mapping Example

No Business Requirement SAP Module Mapping

1 Organizational Structure Organizational Management, Academic Structure,

12 Student Financials SLCM Student Accounting

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

2.3. Architecture of SAP SLCM Master Data Management

The most important master data of SAP SLCM is the following:

Student master data which includes personal data

Student contract account

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

2.4. Architecture of SAP SLCM Academic Structure

Business Event Type

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

External Academic Structure Objects

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

3.1. Academic Calendar

When the academic session starts and ends

3.2. Program Catalogue

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

3.3. Module Catalogue

3.4. Event planning

3.5. Process Control by Rules

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

The below graphic describes the existing rule frameworks in SLCM.

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

3.6. External Academic Structure

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

4. Student Master Data

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

4.1. Student as an HR object

The HR student object stores the following information:

Additional Personal Data

Individual Study Data

Fee Calculation Data

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

4.2 Student as Business Partner

It stores information about:

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

4.3. Student Contract Account

5. Student Lifecycle Processes

5.1. Admission and Recruitment

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

5.2 Program Registration

5.3 Equivalency Determination

5.4 Module Booking

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

5.8 Assessment Process

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

Correspondence is done in two steps: