SAP Q&A - Student Lifecycle Management Rules ......A module group (CG) can inherit rules from organizational units that offer the module group. A module group can inherit rules from

Student Lifecycle Management Rules & Regulations: Rules Cookbook (incl. Validations, Substitutions and Rules) – VSR

Applies to: Student Lifecycle Management 4.71 (with updated Appendix table for EHP 3). For more information, visit the Higher Education & Research homepage.

Summary This VSR cookbook describes the basic concept of rule containers and call-up points in the different application areas of Student Lifecycle Management (SLCM).

Author: SAP AG

Company: SAP AG

Created on: 21 August 2008

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 1

https://www.sdn.sap.com/irj/sdn/bpx-highered


Table of Contents 1. Basic Concept.................................................................................................................................................3

1.1 Application areas.......................................................................................................................................3 1.2 Call-up Points............................................................................................................................................3

1.2.1 Non-Academic Call-up Points .............................................................................................................................4 1.2.2 Academic Call-up Points .....................................................................................................................................4

1.3 Inheritance of Rule Containers .................................................................................................................6 2. Three-Level-Architecture ................................................................................................................................8

2.1 Defining Rule Container............................................................................................................................8 2.2 Defining Rule Modules..............................................................................................................................9 2.3 Defining Rule Elements / VSR ................................................................................................................10

2.3.1 Changing the Assignment of Message Class to Boolean Class........................................................................12 2.3.2 Miscellaneous ...................................................................................................................................................13

3. Data available for Evaluation........................................................................................................................14 3.1 Application areas with the common set of structures .............................................................................14

3.1.1 Data provided depends on call-up points ..........................................................................................................15 3.1.2 Admission .........................................................................................................................................................16 3.1.3 Registration / Re-Registration / De-Registration / Leave of Absence................................................................17 3.1.4 Academic specialization booking ......................................................................................................................17 3.1.5 Module booking.................................................................................................................................................17

3.2 Program Type Progression .....................................................................................................................18 3.3 How to get missing data..........................................................................................................................19

4. Useful Hints ..................................................................................................................................................20 4.1 Handling of Messages used in Validation Steps.....................................................................................20 4.2 Reading Infotypes not provided in the Standard (e.g. SE-infotypes)......................................................20 4.3 Analyzing Data available for VSR using a Break-point in an User-Exit ..................................................21 4.2 Using Report RGUGBR00 for regenerating Code ..................................................................................24

5. Appendix.......................................................................................................................................................25 5.1 Student Lifecycle Management Rules in SAP Easy Access ..................................................................25 5.2 Rules in IMG Student Lifecycle Management.........................................................................................25 5.3 Content of system table T7PIQCHECKTP (available call-up points within Student Lifecycle Management) ................................................................................................................................................26 5.4 Content of system table T7PIQCHECKOT (object types to which rule containers may be attached at academic call-up points.................................................................................................................................27 5.5 Content of system table T7PIQOTTP (possible combinations of academic call-up points and objects types..............................................................................................................................................................28 5.6 Application Areas and assigned Call-Up Points .....................................................................................30

Copyright...........................................................................................................................................................31




1. Basic Concept The following chapters involve the description of the basic concept of rule container and call-up points in the different application areas of Student Lifecycle Management (SLCM).

1.1 Application areas

The following list shows the application areas of Student Lifecycle Management which use rules:

Admission

Registration (student file)

Re-registration (student file)

Leave of absence (student file)

Academic specialization booking

Module booking

Program-type progression Figure 1: Application areas of Student Lifecycle Management

These application areas provide several call-up points at which substitutions may be processed and validations may be checked. The call-up points are defined by SAP.

1.2 Call-up Points

Figure 2 gives an overview of all call-up points defined within Student Lifecycle Management. Within Student Lifecycle Management there are two types of call-up points - non-academic (N) and academic (A) call-up points1. The call-up point concept extends to other areas than the VSR rule checks. Call-up points can also be used for calendar retrieving and holds. It is possible for customers to define their own call-up points and use these call-up points in customer enhancements.

1 The call-up points are defined in the system table T7PIQCHECKTP, the content of this table is shown in appendix 5.3. Content of system table T7PIQCHECKTP (available call-up points within Student Lifecycle Management) This table is maintained by SAP.



Progression

N 0053 Progression

Booking

ModuleBookingA 0001 Module Booking (General)A 0002 Module Booking (Set)A 0003 Module Booking (Single)

Acad. Specialization BookingA 0004 Acad. Specialization Booking (General)A 0005 Acad. Specialization Booking (Set)A 0006 Acad. Specialization Booking (Single)

A: academic callup pointN: non-academic callup point

AdmissionA 0017 Admission

N 0019 Admission (Non-Academic)

Registration / Re-Registration / Leave of Absence /

De-Registration

De-RegistrationN 0041 Create De-registrationN 0045 Save De-registration

RegistrationA 0012 Create Registration (Struc. Dep.)A 0016 Save Registration (Struc. Dep.)

N 0011 Create Registration (General)N 0015 Save Registration (General)

Re-Registration / LvAbsA 0022 Create Re-Registration (Struc.-Dep.)A 0026 Save Re-Registration (Struc. Dep.)A 0036 Save Leave of absence (Struc. Dep.)

N 0021 Create Re-registration / LvAbs (General)N 0025 Save Re-registration (General)N 0035 Save Leave of Absence (General)

Figure 2: Application Areas using Rules and VSR-call-up Points within Student Lifecycle Management2

1.2.1 Non-Academic Call-up Points

Non-academic call-up points are used to directly assign rule containers (object type RC) to application areas such as admission. Rule containers related to non-academic call-up points are valid for all objects of the academic structure (IMG: → Student Lifecycle Management → Student Lifecycle Management Processes → General Settings → Rules → Rule Containers → Assign Rule Containers to Callup Points).

1.2.2 Academic Call-up Points

Academic call-up points are used to assign rule containers to objects of the academic structure (SAP menu: Student Lifecycle Management → Academic Structure (Curriculum) → Study Planning → Program Catalog or Module Catalog). A rule container that is related to an object of the academic structure is valid for that specific object (relationship 509) and for objects in the academic structure to which the rule container is inherited. The call-up point is an obligatory attribute of the relationship. If a rule container is no longer valid for an object, the relation 509 should be delimited at end.

2 Cf. Appendix Table. Possible combinations of academic call-up points and objects types



The objects of the academic structure to which rules can be attached are shown in table 1.3

Object type Name O Organizational Unit SC Program of Study CG Course Group SM Module SE Event Package

Table 1: Object types to which rules can be attached

Rule containers assigned to organizational units can be used for any academic call-up point. Rule containers assigned to event packages will only be evaluated during module booking (call-up points 0002 Module Booking (Set) and 0003 Module Booking (Single) ). Table 2 shows the valid combinations of object types and call-u 4p points .

Rule containers can be directly attached to academic call-up point in customizing table T7PIQRULEMODTP.

VSR Call-up Point (academic) O SC CG SM SE 0001 Module Booking (General) E E 0002 Module Booking (Set) E E E E E

0003 Module Booking (Single) E E E E E

0004 Acad.Specialization Booking (General) E E 0005 Acad.Specialization Booking (Set) E E E 0006 Acad.Specialization Booking (Single) E E E 0012 Create Registration (Struct.-Dep.) E E 0016 Save Registration (Struct.-Dep.) E E 0017 Admission E E E 0022 Create Re-registr./LvAbs. (Struct.-Dep.) E E 0026 Save Re-registration (Struct.-Dep.) E E 0036 Save Leave of Absence (Struct.-Dep.) E E

Table 2: Valid Combinations of academic call-up points and object types

Question: Why does Student Lifecycle Management differentiate between two types of call-up points?

Answer: If a rule is only valid for a specific object of the academic structure, an academic call-up point can be used to attach the rules to that specific object. There is no need to define this object in the prerequisites (see chapter 0 2.3 Defining Rule Elements / VSR) of the rule itself. This makes the maintenance of the rule definitions easier.

On the other hand, if a rule is valid for all objects of the academic structure, there is no need to attach the rule to the academic structure. In this case non-academic call-up points can be used.

The Student Lifecycle Management processes runs through different call-up points. Academic call-up points have the advantage that rule containers can be attached to an object of the academic structure, so the attached rule containers are valid only for a part of the academic structure. The disadvantage is that the

3Object types to which RCs can be attached have to be defined in the system table T7PIQCHECKOT by SAP (see appendix Table: Available call-up points within Student Lifecycle Management) 4 The valid combinations of academic call-up points and object types are defined in the system table T7PIQOTTP by SAP (see appendix. )). Valid Combinations of academic call-up points and object types



retrieval of all rule containers in the academic structure needs a lot of time (dependent of the complexity of the academic structure).

The retrieval of rule containers assigned to non-academic call-up points is fast because the assignment is done in one a table and the academic structure have not to be traversed.

1.3 Inheritance of Rule Containers5

Rule containers are inherited down the academic structure. The inheritance depends on:

The academic structure and

The call-up points used.

The inheritance along the path of the academic structure can be described by the relations between the objects of the academic structure (cf. figure at the right):

An organizational unit (O) can inherit rules from other organizational units at a higher level in the academic structure.

A program (SC) can inherit rules from organizational units that offer the program.

A module group can inherit rules from a program that includes the module group.

A module group (CG) can inherit rules from organizational units that offer the module group.

A module group can inherit rules from other module groups at a higher level in the academic structure.

A module (SM) can inherit rules from organizational units that offer the module.

A module can inherit rules from a program that includes the module.

A module can inherit rules from module groups that include the module

An event package (SE) can inherit rules from a module (SM) that is a generalization of the event package.

The inheritance mechanism will be described in the following example in more detail.

5 The retrieval of the rule containers for an object of the academic structure at a specific call-up point is done by function module 'HRIQ_READ_ACAD_RC_EXT'.

O

CG

SM

SC

SE

(1)

(2)

(4) (3)

(5)

(6)(7)

(8)

(9)


O2

CG1

SM

SC1

O3

CG2

SC3

O1

O4

SC2

SC4

RC3

RC8

RC6

RC12

RC11

RC7

RC5

RC1

RC4

RC2

RC9

RC10

0017

0017

0017

0006

0003

0016

0003

0006

00030003

0016

0003 0003

Figure 3: Inheritance of rule containers along the academic structure

If a module booking is performed for the module SM (see Figure 3) the academic call-up point 0003 Module Booking (Single) will be processed. At this call-up point, the following rule containers will be checked:

RC1: Rule container RC1 is inherited from organizational units O1 and O2 to which the rule container is directly linked.

RC7: Rule container RC7 is inherited from organizational unit O4.

RC8: Rule container RC8 is inherited from program SC4 which offers module group CG2 which consists of module SM.

RC9: Rule container RC9 is inherited from module group CG1 which consists of module group CG2. Module group CG2 consists of module SM.

RC12: Rule container RC12 is directly attached to module SM.

A student who wants to study program SC1 has to run through admission process. For the academic call-up point 0017 Admission the following rule containers will be processed:





2. Three-Level-Architecture Student Lifecycle Management uses a three-level architecture for rules (cf. figure 3). The rule containers are at the top level. A rule container contains rule modules (one or many). Rule modules consist of one or more rule elements, and are modular and reusable. Rule elements are either validations or substitutions.

FI-SL-VSR

Rule Container

Step 'xyz' up to 999

SubstitutionValidation

Rule Module

Step 'abc' up to 999

Rule

Validation Exit Prerequisite

Substitution

Prerequisite

Check

Message

N

M

N

M M

Substitution Exit

Rul

e C

onat

aine

rsR

ule

Mod

ules

Rul

e E

lem

ents

(Val

idat

ions

, Sub

stitu

tions

)

Figure 4: Three level architecture of rules in Student Lifecycle Management

2.1 Defining Rule Container

Rule containers are objects of object type RC. They have the infotypes Object (1000), Relationships (1001), Description (1002) etc. To create rule containers use transaction PIQRC in the application menu (Student Lifecycle Management → Academic Structure (Curriculum) → Rules → Edit Rule Container). Rule modules can be assigned to a rule container by maintaining infotype Rule Modules (1747). Only if the results of all rule modules are true, the result for the rule container itself will be true.

A rule container will be evaluated if it is used by a non-academic (see chapter 0 1.2.1 Non-Academic Call-up Points) or an academic (see chapter 0 1.2.2 Academic Call-up Points) call-up point. If a rule container with no rule modules in infotype Rule Modules (1747) will be evaluated an error message arises.

Rule Containers can carry message control information in infotype Message Control (1749) for overriding of message types.

Rule containers can also have conditional booking option in additional data and can be marked for Callup point 3.Presently only module booking uses the conditional nature of a rule container



Rule container with the attribute Conditional Booking option selected at callup point 0003 becomes a conditional rule container.

The result of such a rule container can be taken as pending (decided by the application) and can be evaluated again at a later point by the required application component (for example module booking).

2.2 Defining Rule Modules

Rule modules are the middle level of the three-level-architecture. They are maintained in the IMG (Student Lifecycle Management → General Settings → Rules → Rule Modules → Set Up Rule Modules). Rule modules consist of one or more rule elements, and are designed for modularization and reusability.

The following elements are used to define a rule module:

Open parentheses : '('

Rule type: 'V' (Validation) or 'S' (Substitution)

Rule element: Identifier of the validation or substitution

Close parentheses: ')'

Combination: 'AND' or 'OR'

Sort sequence: natural number to order the lines e.g.: '10'

Example: Interpretation of combined validations within rule modules

The user wants the AND operator to be stronger than the OR operator in the following expression:

V1 AND V2 OR V3 OR V4 AND V5

First the user maintains the rule module in the customizing without parentheses:

sorting sequence

opening parenthesis

rule element closing parenthesis

combination

10 V1 AND 20 V2 OR 30 V3 OR 40 V4 AND 50 V5

Table 3: A rule module definition with combinations of rule elements

This rule module will in interpreted by the rule manager as follows:

Description in customizing Interpretation of this expression V1 AND V2 OR V3 OR V4 AND V5 � ((V1 AND V2) OR (V3 OR V4)) AND V5 It will not be interpreted as follows: (V1 AND V2) OR V3 OR (V4 AND V5) ((((V1 AND V2) OR V3) OR V4) AND V5) (V1 AND (V2 OR (V3 OR (V4 AND V5))))

Table 4: Interpretation of a rule module by the rule manager



This interpretation is not, what the user wanted to get. He changes the customizing by adding parentheses:

sorting sequence

opening parenthesis

validation or substitution

closing parenthesis

combination

10 ( V1 AND 20 V2 ) OR 30 V3 OR 40 ( V4 AND 50 V5 )

Table 5: The rule module definition after adding parenthesis

Recommendation of SAP: To make the customizing unambiguous, always use parentheses '(' and ')' when using operators 'AND' and 'OR' at the same time.

Moreover, it is recommended only to build simple Boolean expressions. The construction capability of the rule modules is limited.

Substitutions are possible before validations within rule modules. They are used to get additional data that are not provided by the call-up point interface in SAP standard. A substitution itself doesn't return a Boolean value, therefore rule modules that only contain substitutions are always interpreted as true.

If a rule module contains neither substitutions nor validations but is evaluated at a call-up point, the system will return an error message.

The rule modules can be classified into two types

• Basic rule modules

• Rule modules with extended check

Different rule containers can consist of same rule modules. If the extended check is marked for a rule module then it becomes an extended rule module. The results of the extended rule modules are set to the message type ‚Information‘, if they are of message type ‚Error‘ or ‚Abort‘. This means that the process can continue even if the checks are not met.

2.3 Defining Rule Elements / VSR

VSR (validations, substitutions and rules) is a generic tool developed by SAP in the application component FI-SL (special ledger). VSR is described in the documentation:

VSR Documentation This cookbook will refer to documentation in the component FI-SL where appropriate.

Student Lifecycle Management (SLCM) and FI-SL VSR sometimes use the same term for different things:

Rules

o FI-SL: logical rules can be used in validations and substitutions

o SLCM: ‘Rules and Regulations’ are a term to summarize all issues concerning rule containers, rule modules and rule elements.

Application Area

o FI-SL: Student Lifecycle Management is defined as application area 'IQ' in VSR.

o SLCM: see chapter 0 1.1 Application areas


http://help.sap.com/erp2005_ehp_03/helpdata/EN/c0/74da3889432f48e10000000a114084/frameset.htm



Call-up point

o FI-SL: In VSR call-up points are defined by VSR application area. For the VSR application area ‘Student Lifecycle Management’ three VSR-call-up points have been defined. These VSR call-up points are encapsulated in the Student Lifecycle Management rule manager. You will never see these VSR call-up points in Student Lifecycle Management.

Validations can consist of 1-999 steps (see

Figure 4). In every step there can be a check. Validations can use VSR rules and validation exits in prerequisites and in checks.

Within Student Lifecycle Management there is no validation exit program delivered. The validation exit RGGBR000 can be used as a template for copying. When creating a new user-exit module pool, you should not forget to maintain the assignment to the application area for user exit control (GBLR for validations; GBLS for substitutions) in customizing:

'Student Lifecycle Management → General Settings → Rules → Rule → Elements → Maintain Client-Specific User Exits'

Substitutions can also consist of 1-999 steps (see figure 3). VSR rules can be used in the prerequisites, substitution exits can be used in the substitution itself.

Substitutions are used in Student Lifecycle Management in two ways:

1. Substitutions are used to provide additional data for upcoming checks within validations.

2. Substitutions are used during program type progression to set a new progression status6.

Rule Container RC

Rule Module RM2Rule Module RM1

Substitution S

Validation V1

Validation V2

Prerequisite

Prerequisite

Message

Check

Substitution

Prerequisite

Message

Check

6 The application progression writes the new progression status to the database. The rule manager only sets the new status if the prerequisite of the substitution is fulfilled.


Figure 5: Example of a rule container

The example in Figure 5 shows a rule container consisting of two rule modules RM1 and RM2. Rule module RM1 consists of a substitution S and a validation V1. The substitution S may contain a substitution exit, which reads additional information needed for the following validation V1. Rule module RM2 only consists of a validation V2.

Evaluation of rule container RC includes the evaluation of both rule modules. Only if both validations V1 and V2 will be evaluated as true, then rule container RC will be evaluated as true. If the prerequisite of a validation is not true, the check will not be processed and the result will be set to true.

For more detailed information, see VSR documentation:

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → What are Validations?

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → Validation → *

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → What are Substitutions?

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → Substitution → *

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → Rules → *

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → User Exits in Validations/Substitutions/Rules

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → Boolean Logic/Syntax →*

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → Boolean Logic/Syntax →Using Boolean Operators in Truth Tables → *

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → Rules → Examples of Rules

2.3.1 Changing the Assignment of Message Class to Boolean Class

If a validation result is false, a message will be issued. If the validation is defined by the customer, a message belonging to a customer message class should be used.

The message class has to be defined for the FI-SL application area 'IQ' for the Boolean classes ‘IQ1’, ‘IQ2’ and ‘IQ3’. The new message class will be available in all clients. The assignment should be done by running report RGUGBR28 as shown in the next screen shot with a new message class ZZHRPIQ000 for boolean class IQ3.

Figure 6: Change of the message class for a boolean class in VSR



2.3.2 Miscellaneous

If rules were interpreted dynamically, bad performance would be the result. Therefore the system will generate a program in the background, if a rule element is created or changed. When a rule element is processed the generated program will be performed. However if a rule element is deleted the generated program is not updated. This can result in syntax errors during rule evaluation. If this happens, run program RGUGBR00 for the application area ‘IQ’.

For more information look at:

Special Purpose Ledger → Tools → Validations, Substitutions and Rules → Boolean Logic / Syntax → Miscellaneous Procedures → Using the Rule Manager Reports




3. Data available for Evaluation When a call-up point is reached within an application area, the application passes available data to the specific SLCM rule manager7. The SLCM rule manager may read additional data. The data provided by the application area and the additional data, collected by the rule manager, will be passed on to VSR.

If the data passed on to VSR is not enough, a substitution with a user exit can be used to read more data.

The following structures (defined in the SAP ABAP Dictionary) are used to transfer data to VSR.

The application area program type progression uses a different set of structures than the other application areas.

3.1 Application areas with the common set of structures

Structures:

PIQRULESTUDENT (Structure for student data) including personal data as well as organizational data, some fee data, student category, etc.

PIQRULESC (Program data for student in SLCM rules) including information about the program of study that is associated with the student, like short text and long text, infotype Capacity (1724), infotype Program data (1730) (program data with session variant, program plan, program duration, study type, module group variant, program type), infotype Credit information (1735) (credit information, degree level, etc).

PIQRULESM (Modules defined in SLCM rules individual check) including information about the module to be booked like 'Module booking status', 'Booking date', 'Attempted credits', 'Academic session', etc.

PIQRULECG (Academic specializations defined in SLCM rules) including information about the module group that is selected like 'Module group category' and 'Discipline'.

PIQRULEAPP (Application data) including the application data of an applicant like personal data, address data, admission data, campus data, visa data, etc.

PIQRULEACADIX (Average grades for student in SLCM rules) including data concerning several academic averages.

PIQRULESTSC (Data for relationship between student and program) including data concerning the relationship of the student and the program of study like stage, registration/re-registration date, registration status, progress classification stage.

PIQRULE9 (Data for customer)

PIQRULEMASTERS (Main structure for rules concerning student) The table PIQRULEMASTERS is a complex table including several substructures:

o PIQRULEMASTER_SM Modules related to a student

o PIQRULEMASTER_CG Academic specializations related with a student

o PIQRULEMASTER_CA Academic calendar data for checking dates against academic periods in rules

7 there are different rule managers within Student Lifecycle Management belonging to the different application areas


o PIQRULEMASTER_E Business events in rules concerning student

o PIQRULEMASTER_APP Data concerning application

o PIQRULEMASTER_QQ Internal and external qualifications in SLCM rules

The table PIQRULEMASTERS contains a field PIQONE. This has the value 1, if fields are filled in a line. PIQONE has the value 0, if the complete line is empty. Empty lines can be used to add lines via substitutions. PIQONE can be used to count lines that fulfill certain conditions.

The PIQRULE* structures except PIQRULECG and PIQRULEMASTER_CG contain CI_Includes to be expanded by customers. CI_Include structures must be filled with data using the substitution exit technique (see documentation in SAP Library: Special Purpose Ledger → Tools → Validations, Substitutions and Rules → User Exits in Validations/Substitutions/Rules).

In one line of the table never all fields are populated. To be more precise, you will never find a line with data for more than one substructure. For example, PIQRULEMASTERS could contain 3 lines with data for the substructure PIQRULEMASTER_QQ, because the student has 3 qualifications, and another 3 lines with data for the substructure PIQRULEMASTER_SM, because the student booked 3 modules in the past. Altogether the table contains 6 filled lines.

PIQRULEMASTER_SM

PIQRULEMASTER_CG

PIQRULEMASTER_CA

PIQRULEMASTER_E

PIQRULEMASTER_APP

ONECNT

1

11

.499500

501502503

PIQRULEMASTER_QQ504505506

.

.

.

.00

111

.

.

.

Figure 7: Table PIQRULEMASTERS

3.1.1 Data provided depends on call-up points

With Student Lifecycle Management all application areas use the same data structures (as above) to transfer information to VSR. Depending on the call-up point, different data is transferred to VSR by the system. Module booking doesn't provide the application data, therefore structure PIQRULEAPP is empty for the call-up points 0001 – 0003.

The registration provides four call-up points. At the beginning of the registration process (0011 'Create Registration (General)' and 0012 ‘Create Registration (Struct.-Dep.)’ ) the program of study is known but not the stage. The stage is set by the user in a pop-up that is processed after call-up point 0011 and 0012. However, it will be available for the call-up points 0015 ‘Save Registration (General)' and 0016 'Save Registration (Struct.-Dep.)'. The level is contained in the structure PIQRULESTSC in the field ACLEVEL.



If you need to know in detail, which data is available at a call-up point in a specific process, you can use a trick:

Attach a rule container that includes a user exit to the call-up point.

Set a break-point in the user-exit.

Start the transaction that will invoke the call-up point. When the call-up point is reached, the program will stop in the debugging mode. Here you can analyze the data transferred to VSR.

The following sections give an overview of call-up points and the data that will be provided if it is available in the system for the specific objects involved.

3.1.2 Admission

Call-Up Point Academic Call-Up Point Text 0019 Admission (Non-Academic) 0017 X Admission

Table 6: Valid call-up points for Admission

At these call-up points the structures PIQRULESC and PIQRULEAPP and the sub table PIQRULEMASTER_APP of the table PIQRULEMASTERS will be filled with available data.

The structure PIQRULEAPP consists of the following sub-structures:

PIQAPP_PERSONAL personal data

PIQAPP_ADDPERSONAL additional personal data

PIQAPP_ADDRESS first address of student

PIQAPP_ADMISSION special admission data

PIQAPP_CAMPUS campus to which the student is assigned

PIQAPP_CHALLENGE challenge data

PIQAPP_EMAIL e-mail data

PIQAPP_RESIDENCY residence data

PIQAPP_STUDYDATA study data belonging to student

PIQAPP_VISA visa data

CI_PIQRULEAPP possibility for customer to append customer-specific data

All fields used by the customer in his ISR-scenario and filled by the student in the application will be available at the admission call-up points.

Additional addresses (e.g. address of parents structure PIQAPP_ADDRESS) and the academic specializations (PIQAPP_MODGRP) will be filled with data in the table part. Furthermore the header data of the transcript will be available.

If the student already exists on the database, the data will be read from the database. In this case, the transcript and test result data will be read from the database, and also the data of the transcript body is filled and will be available for rule checking.



3.1.3 Registration / Re-Registration / De-Registration / Leave of Absence

Call-Up Point Academic Call-Up Point Text 0011 Create Registration: Callup Point 0015 Save Registration 0021 Create Re-registr./LvAbs. (General) 0025 Save Re-registration (General) 0035 Save Leave of Absence (General) 0041 Create De-registration 0045 Save De-registration 0012 X Create Registration: Acad. Callup Pnt 0016 X Save Registration: Acad. Callup Pnt 0022 X Create Re-registr./LvAbs.:Acad.Callup Pt 0026 X Save Re-registration: Acad. Callup Pnt

Table 7: Call-up points for Registration and Deregistration

At these call-up points the structures PIQRULESTUDENT and PIQRULESC and PIQRULESTSC will be filled with available data. The structure PIQRULESTSC will only be filled at call-up points beginning with 'Save*' in the text. The table PIQRULEMASTERS is empty.

3.1.4 Academic specialization booking

Call-Up Point Academic Call-Up Point Text 0004 X Acad.Specialization Booking (General) 0005 X Acad.Specialization Booking (Set) 0006 X Acad.Specialization Booking (Single)

Table 8: Call-up points for booking of academic specializations

At all these call-up points the structures PIQRULESTUDENT and PIQRULESC will be filled with available data.

At call-up point 0005 the sub table PIQRULEMASTER_CG of the PIQRULEMASTERS table will be filled with module groups booked in the past and module groups to be booked in the current booking process.

At call-up point 0006 the sub table PIQRULEMASTER_CG of the PIQRULEMASTERS table will be filled with module groups booked in the past.

3.1.5 Module booking

Call-Up Point Academic Call-Up Point Text 0001 X Module Booking (General) 0002 X Module Booking (Set) 0003 X Module Booking (Single)

Table 9: Call-up points for module booking

At all these call-up points the structures PIQRULESTUDENT, PIQRULESC be filled with available data.

At call-up point 0001 Module Booking (General) the sub table PIQRULEMASTER_SM of the table PIQRULEMASTERS will be filled with modules (information from the relation ST-SM) booked by the student in the past.

At call-up point 0002 Module Booking (Set) the sub table PIQRULEMASTER_SM of the table PIQRULEMASTERS will be filled with modules (information from the relation ST-SM) booked by the student in the past and modules to be booked from the booking screen. The sub table PIQRULEMASTER_CG will be filled with module groups the student is assigned to within his study. Furthermore in the structure PIQRULESM the fields SM_ACTIVE_PERYR and SM_ACTIVE_PERID are filled with the current booking period.



At call-up point 0003 Module Booking (Single) the sub table PIQRULEMASTER_SM of the table PIQRULEMASTERS will be filled with modules (information from the relation ST-SM) booked by the student in the past. The sub table PIQRULEMASTER_CG will be filled with module groups the student is assigned to within his study. Furthermore in the structure PIQRULESM will be filled with available data for the module to be booked.

Within application module booking the call-up point 0001 will be processed first. Then for each module selected in the booking screen call-up point 0003 will be processed and finally call-up point 0002 will be processed for the set of modules. If we book three modules five checks will be executed.

3.2 Program Type Progression

The application 'program type progression' delivered with SLCM uses the non-academic call-up point 'Program type progression' (0053). The program type progression only uses rules and substitutions, no validations. The application uses an own set of structures for rules and substitutions:

PIQRULEPROGR_GR general fields for the program type progression to be performed

PIQRULEPROGR_GR_EXT table that is filled with performance indicies for a student

PIQRULEPROGR_GR_RESULT progression result

The structure PIQRULEPROGR_GR and the table PIQRULEPROGR_GR_EXT are read-only.

PIQRULEPRGR_EXTPIQRULEPRGR

Rules and substitutions from VSRPIQRULEPRGR_RES

Figure 8: Data for program type progression

In the structure PIQRULEPROGR_GR_RESULT the progression result can be set. Field PG_EXECUTE allows to do progression in two steps: First check the academic prerequisites for the progression and set the flag for fulfilled academic prerequisite. In a second step the exact standing can be set dependent on the performance indices in the table PIQRULEPROGR_GR_EXT. The determination of the new progression result itself will be done in field PG_RESULT. The status of a progression result (field PG_RESULT_STATUS) will be determined and set within the performance index calculation (for details look at the progression/performance indices documentation). It is possible to set (to override) the status within a substitution.

PG_EXECUTE Academic Prerequisite for Progression Fulfilled

PG_RESULT Progression Result

PG_RESULT_STATUS Result Status




Call-Up Point Academic Call-Up Point Text 0053 Program Type Progression

Table 10: Call-up point for program type progression

All data will be delivered to the VSR by the progression application and the performance index calculation. Retrieving additional data via substitutions is not necessary.

All substitutions contained in rule container (via rule modules) which are assigned to the non-academic call-up point 'Program type progression' (0053) will be evaluated for all program types and all progression categories.

3.3 How to get missing data

Student Lifecycle Management delivers the module pool RHIQVS01 which includes the exit forms UCP1-UCP7 for substitutions. The exits may be used within substitutions (substitution variant: „exit only“) to fill data for evaluation of validation checks. This may be needed, if the application doesn’t provide the data. SAP delivers the substitution exits as samples. Customers can create their module pool in the customer name space8 by copying the module pool RHIQVS01 and then adjust it according to their needs.

Substitution Exit

Description PIQRULE* data structures for substitution

UCP1 Replace average grades for admission

fills structure PIQRULEACADIX

UCP2 Replace academic calendars

fills sub-table PIQRULEMASTER_CA of table PIQRULEMASTERS

UCP3 Replace business events of students

fills sub-table PIQRULEMASTER_E of table PIQRULEMASTERS

UCP4 Replace modules of students

fills sub-table PIQRULEMASTER_SM of table PIQRULEMASTERS

UCP5 Replace qualifications of students

fills sub-table PIQRULEMASTER_QQ of table PIQRULEMASTERS

UCP6 Replace additional data of students

fills additional student data in structure PIQRULESTUDENT_S (included in structure PIQRULESTUDENT)

UCP7 Replace test results and external subjects of students

replaces data in sub-table PIQRULEMASTER_APP of table PIQRULEMASTERS

Table 11: Substitution exits delivered within Student Lifecycle Management in module pool RHIQVS01

8 The names of the module pools for exits has to be maintained in the IMG 'Student Lifecycle Management → Rules → Rule Elements → Maintain Client-Specific User Exits' under application areas 'GBLR' (validation exits) and 'GBLS' (substitution exits)


4. Useful Hints

4.1 Handling of Messages used in Validation Steps

In the message part of a validation step a message can be specified that should arise if the check is not fulfilled. There are four types of messages available:

Type Text Meaning A Cancel Action should be terminated immediately E Error Important error W Warning Not so important I Information Only for information

Table 12: Message types used in validation steps

A validation will be always evaluated as false if a check isn’t fulfilled and a message arises regardless of the message type.

4.2 Reading Infotypes not provided in the Standard (e.g. SE-infotypes)

Infotypes not provided as VSR data in the standard (i.e. infotypes of object type SE or customer infotypes) can be read by using function module HRIQ_READ_INFTY_NNNN. The function module expects the following parameters (assumption: the key of the object for which data will be retrieved of type HROBJECT is known):

INFTY: the customer infty e.g.: 9007

BEGDA and ENDDA: beginning data and ending date of data

OBJECTS: a internal table of structure HROBJECT: the key of the object with components plan variant, object type and object identifier (e.g.: 01 ST 00000007) lt_hrobject[] in example

INNNN: a internal table of the infotype structure which will be filled by the function module lt_p9007[] in example

If you need more information about related objects in the academic structure the program can read relations between objects. This can be done with function module HRIQ_READ_INFTY_1001.

The function module expects the following parameters:

SUBTY: subtype of infotype Relation (1001) e.g.: B514 (relation between SE and SM 'is specialization of')

BEGDA and ENDDA: beginning data and ending date of relation

OBJECTS: a internal table of structure HROBJECT: the key of the object with the components plan variant, object type and object identifier (e.g.: 01 SM 00000008) lt_hrobject[] in example

I1001: a internal table of the infotype structure which will be filled by the function module lt_sm_se_p1001[] in example



4.3 Analyzing Data available for VSR using a Break-point in an User-Exit

Data passed to VSR is contained in the ABAP structure 'BOOL_DATA'. With a break-point in an user-exit you can examine the data filled in the structure.

SAP recommends to use a break-point in a substitution exit. While evaluating rule modules the substitutions will be processed first. There are two possible ways of using break-points: hard-coded and soft-coded break-points.

You can use a hard coded break-point in a special substitution exit as the only command and use this exit in a special substitution for analyzing data. The advantage is that you can reuse this substitution for analyzing purposes in many rule modules by including the substitution into the rule module you want to analyze and remove it after analyzing. You can use the substitution for analyzing purposes in rule module customizing without using the ABAP Development Workbench to (re-)enter soft-coded break-points each time you want to analyze available data.

Figure 9: Hard-coded break-point in a substitution exit

If the rule module you want to analyze already uses a substitution exit you can use a soft-coded break-point. A soft-coded break-point is available only during one session at the SAP system. We use substitution exit UCP1 in a rule module. Via transaction SE80 we start the ABAP Development Workbench. After choosing Program RHIQVS01 (respectively the customer exit program) expand the node 'Subroutines' and double click on 'UCP1'. For setting the break-point go to the first line: 'FORM ucp1 USING bool_data TYPE gb002_iq3.' and then hit the stop sign. Now the line executed is marked. The SAP system stops when this line is processed. Now make sure that you use the substitution exit in a substitution and include the substitution in the rule module.

Now execute the process. In this example the rule should be checked at the non-academic call-up point 0015 'Save registration'. The substitution exit program UCP1 will be stopped at the break-point.

Now look at the main structure of the VSR: 'BOOL_DATA'. (double click on it or type it in the line at the bottom of the screen). Then double click on 'BOOL_DATA' at the bottom of the screen.



Figure 10: Analyzing BOOLDATA within the debugger

You can look at all different rule structures used in the VSR. By double clicking on them, or pressing the expand symbol, you will see the content of the structures. You can investigate which data is available for validations. E.g., structure PIQRULESTUDENT (the structure with the student data):

Figure 11: Analyzing BOOLDATA-PIQRULESTUDENT within the debugger



You can investigate which of the fields of the table PIQRULEMASTERS are filled with data:

Figure 12: Analyzing BOOLDATA-PIQRULEMASTERS within the debugger




4.2 Using Report RGUGBR00 for regenerating Code

The VSR rule manager generates programs for the validations, substitutions and rules. In some cases the programs generated by the VSR are not current. This may be the case if syntax errors appears while processing rules. The programs for the validations, substitutions rules can be generated by running report RGUGBR00 from the ABAP editor (transaction SE38). Choose 'IQ' for parameter Application area and enter '*' for parameter Callup point. Then set all indicators except for the 'usage' indicators and the last indicator ('Gen. substn routns in all clnts') and run the report9. Because VSR is client dependent it could be that report RGUGBR00 has to be run in other clients as well (e.g. in client 000).

Figure 13: Report RGUGBR00 (regenerate coding for VSR)

9 Cf. SAP-note 44352


5. Appendix

5.1 Student Lifecycle Management Rules in SAP Easy Access

5.2 Rules in IMG Student Lifecycle Management



5.3 Content of system table T7PIQCHECKTP (available call-up points within Student Lifecycle Management EHP 3)

Call-Up Point Academic Call-Up Point Text 0001 X Module Booking (General) 0002 X Module Booking (Set) 0003 X Module Booking (Single) 0004 X Acad.Specialization Booking (General) 0005 X Acad.Specialization Booking (Set) 0006 X Acad.Specialization Booking (Single) 0010 X Booking prerequisites for module 0011 Create Registration: Callup Point 0012 X Create Registration: Acad. Callup Pnt 0015 Save Registration 0016 X Save Registration: Acad. Callup Pnt 0017 X Admission 0019 Admission (Non-Academic) 0021 Create Re-registrtn/LvAbs.: Callup Pnt 0022 X Create Re-registr./LvAbs.:Acad.Callup Pt 0025 Save Re-registration 0026 X Save Re-registration: Acad. Callup Pnt 0030 Create Change of Program: Callup Point 0031 Save Change of Program 0035 Save Leave of Absence 0036 X Save Leave of Absence: Acad. Callup Pnt 0039 X Cancel Sessional Registration 0041 Create De-registration: Callup Pnt 0045 Save De-registration 0047 Cancel De-registration: Callup Pnt 0049 Save De-registration Cancellation 0053 Program Type Progression 0060 Degree Audit 0061 Stage Audit 0070 Admission for Degree Audit 0071 Admission for Stage Audit 0080 Admission Audit 0100 Fee Calculation 0110 Financial Aid Calculation 0200 Check Resource Availability 0201 Calendar Determination in Event Planning 0202 Subscreen Enhancement for Business Event 0300 Confer Qualification 0301 Graduation 0401 Create Admission Application 0402 Change Admission Application 0403 Delete Admission Application



0406 Reject Admission Application 0407 Change Admission 0408 Change Rejected Admission Application 0409 Change of Program in Admission Application 0410 Change of Program in Admission 0411 Undo Rejected Admission Application 0412 Undo Admission 0413 Withdraw Admission Application 0414 Decline Offer of Admission 0415 Reverse Decision 0600 Open Assessment Process 0601 SEVIS Customer Hold

Table 13: Available call-up points within Student Lifecycle Management

5.4 Content of system table T7PIQCHECKOT (object types to which rule containers may be attached at academic call-up points in release EHP 3)

Object Type Object Type Text CE Assessment CG Module Group O Organizational Unit SC Program of study SE Event Package SM Study Module

Table 14: Object types to which rule containers may be attached at academic call-up points



5.5 Content of system table T7PIQOTTP (possible combinations of academic call-up points and objects types, EHP 3)

Object Type

Object Type Text Academic

Call-Up Point

Academic Call-Up Point Text

CE Assessment 0600 Open Assessment Process CG Module Group 0002 Module Booking (Set) CG Module Group 0003 Module Booking (Single) CG Module Group 0005 Acad.Specialization Booking (Set) CG Module Group 0006 Acad.Specialization Booking (Single) CG Module Group 0017 Admission CG Module Group 0060 Degree Audit CG Module Group 0061 Stage Audit CG Module Group 0070 Admission for Degree Audit CG Module Group 0071 Admission for Stage Audit CG Module Group 0080 Admission Audit O Organizational Unit 0001 Module Booking (General) O Organizational Unit 0002 Module Booking (Set) O Organizational Unit 0003 Module Booking (Single) O Organizational Unit 0004 Acad.Specialization Booking (General) O Organizational Unit 0005 Acad.Specialization Booking (Set) O Organizational Unit 0006 Acad.Specialization Booking (Single) O Organizational Unit 0012 Create Registration: Acad. Callup Pnt O Organizational Unit 0016 Save Registration: Acad. Callup Pnt O Organizational Unit 0017 Admission O Organizational Unit 0022 Create Re-registr./LvAbs.:Acad.Callup Pt O Organizational Unit 0026 Save Re-registration: Acad. Callup Pnt O Organizational Unit 0030 Create Change of Program: Callup Point O Organizational Unit 0031 Save Change of Program O Organizational Unit 0036 Save Leave of Absence: Acad. Callup Pnt O Organizational Unit 0047 Cancel De-registration: Callup Pnt O Organizational Unit 0049 Save De-registration Cancellation O Organizational Unit 0060 Degree Audit O Organizational Unit 0061 Stage Audit O Organizational Unit 0070 Admission for Degree Audit O Organizational Unit 0071 Admission for Stage Audit O Organizational Unit 0080 Admission Audit SC Program of study 0001 Module Booking (General) SC Program of study 0002 Module Booking (Set) SC Program of study 0003 Module Booking (Single) SC Program of study 0004 Acad.Specialization Booking (General) SC Program of study 0005 Acad.Specialization Booking (Set) SC Program of study 0006 Acad.Specialization Booking (Single) SC Program of study 0012 Create Registration: Acad. Callup Pnt SC Program of study 0016 Save Registration: Acad. Callup Pnt




Object Type

Object Type Text Academic

Call-Up Point

Academic Call-Up Point Text

SC Program of study 0017 Admission SC Program of study 0022 Create Re-registr./LvAbs.:Acad.Callup Pt SC Program of study 0026 Save Re-registration: Acad. Callup Pnt SC Program of study 0030 Create Change of Program: Callup Point SC Program of study 0031 Save Change of Program SC Program of study 0036 Save Leave of Absence: Acad. Callup Pnt SC Program of study 0047 Cancel De-registration: Callup Pnt SC Program of study 0049 Save De-registration Cancellation SC Program of study 0060 Degree Audit SC Program of study 0061 Stage Audit SC Program of study 0070 Admission for Degree Audit SC Program of study 0071 Admission for Stage Audit SC Program of study 0080 Admission Audit SC Program of study 0600 Open Assessment Process SE Event Package 0002 Module Booking (Set) SE Event Package 0003 Module Booking (Single) SM Study Module 0002 Module Booking (Set) SM Study Module 0003 Module Booking (Single)

Table 15: Possible combinations of academic call-up points and objects types


5.6 Application Areas and assigned Call-Up Points

Application Area Callup

Point

Academic Call-up Point Text

Admission 0019 Admission (Non-Academic) 0017 X Admission Registration 0011 Create Registration: Callup Point 0015 Save Registration 0012 X Create Registration: Acad. Callup Pnt 0016 X Save Registration: Acad. Callup Pnt Re-Registration / 0021 Create Re-registr./LvAbs. (General) Leave of Absence 0025 Save Re-registration (General) 0035 Save Leave of Absence (General) 0041 Create De-registration 0045 Save De-registration 0022 X Create Re-registr./LvAbs.:Acad.Callup Pt 0026 X Save Re-registration: Acad. Callup Pnt 0036 X Save Leave of Absence: Acad. Callup Pnt Acad. Specialization 0004 X Acad.Specialization Booking (General) Booking 0005 X Acad.Specialization Booking (Set) 0006 X Acad.Specialization Booking (Single) Module Booking 0001 X Module Booking (General) 0002 X Module Booking (Set) 0003 X Module Booking (Single) Program Type Progression

0053 Program Type Progression

Table 16: Application areas and assigned call-up points




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.

SAP Q&A - Student Lifecycle Management Rules ......A module group (CG) can inherit rules from organizational units that offer the module group. A module group can inherit rules from

Documents