student lifecycle management business rule … lifecycle management business rule framework cookbook...

Student Lifecycle Management Business Rule Framework Cookbook

Applies to: All described functionality is based upon Student Lifecycle Management (SLCM) with ERP6 Enhancement Package 4 (EHP4).

For more information, visit the Higher Education & Research homepage.

Summary The purpose of this document is to describe how the business rule framework functionality can be used for automation of standard business processes in Student Lifecycle Management. This may concern follow-up activities or the enablement of integration scenarios across different system components.

Author: Student Lifecycle Management Development Team

Company: SAP AG

Created on: November 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 Introduction .........................................................................................................................................................5 1. Glossary..........................................................................................................................................................6 2. Concept ..........................................................................................................................................................7

2.1. General Concept......................................................................................................................................7 2.2 Business Rule Framework ........................................................................................................................8

2.2.1 BRF Events.........................................................................................................................................................8 2.2.2 BRF Rules.........................................................................................................................................................12 2.2.2.1 BRF Expressions ...........................................................................................................................................15 2.2.2.2 BRF Actions ...................................................................................................................................................17

2.3. Error Handling........................................................................................................................................22 2.3.1 Application Log .................................................................................................................................................23 2.3.2 Event Rescheduling ..........................................................................................................................................25 2.3.3. Event Cancelled...............................................................................................................................................25

2.4 Switching ON/OFF Post Processing.......................................................................................................26 3. Events...........................................................................................................................................................27

3.1 Event for Admission (0ADMISSION) ......................................................................................................27 3.1.1 Activities............................................................................................................................................................27 3.1.2 Context..............................................................................................................................................................27 3.1.2.1 Sub-contexts ..................................................................................................................................................27 3.1.2.1.1 0ADMISSION_BEF ...............................................................................................................................28 3.1.2.1.2 0ADMISSION_UPD...............................................................................................................................30

3.2 Event for Anticipated Graduation Date (0ANTICGRAD) ........................................................................30 3.2.1 Activities............................................................................................................................................................30 3.2.2 Contexts............................................................................................................................................................30

3.3. Event for Module Edited (0MODULE)....................................................................................................31 3.3.1 Activities............................................................................................................................................................31 3.3.2 Contexts............................................................................................................................................................31

3.4 Event for Event Package Edited (0EVENTPACKAGE) ..........................................................................32 3.4.1 Activities............................................................................................................................................................32 3.4.2 Contexts............................................................................................................................................................32

3.5 Event for Academic Event Edited (0ACADEMICEVENT).......................................................................33 3.5.1 Activities............................................................................................................................................................33 3.5.2 Contexts............................................................................................................................................................33

3.6. Event for Status Indicators (0STATUSINDIC) .......................................................................................34 3.6.1 Activities............................................................................................................................................................34 Contexts.....................................................................................................................................................................34

3.7 Event for Performance Index Updated (0PERFINDEX) .........................................................................34 3.7.1 Activities............................................................................................................................................................34 3.7.2 Context..............................................................................................................................................................34

3.8 Event for Program Registration (0PROGREGIST) .................................................................................37 3.8.1 Activities............................................................................................................................................................37 3.8.2 Context..............................................................................................................................................................37 3.8.2.1 Sub-contexts ..................................................................................................................................................37 3.8.2.1.1 0PROGREG_SES_UPD .......................................................................................................................37



3.8.2.1.2 0PROGREG_SGM_UPD ......................................................................................................................38 3.8.2.1.3 0PROGREG_SGM_BEF.......................................................................................................................39

3.9 Event for Program Re-Registration (0PROGREREG)............................................................................39 3.9.1 Activities............................................................................................................................................................39 3.9.2 Context..............................................................................................................................................................39 3.9.2.1 Sub-contexts ..................................................................................................................................................39 3.9.2.1.1 0PROGREREG_SES_UPD .................................................................................................................39 3.9.2.1.2 0PROGREREG_SES_BEF...................................................................................................................39

3.10 Event for Change of Program (0PROGCHANGE)................................................................................40 3.10.1 Activities..........................................................................................................................................................40 3.10.2 Context............................................................................................................................................................40 3.10.2.1 Sub-contexts ................................................................................................................................................40 3.10.2.1.1 0PROGCHANGE_SES_CLD ...........................................................................................................40 3.10.2.1.2 0PROGCHANGE_SES_DLM ...........................................................................................................40 3.10.2.1.3 0PROGCHANGE_SGM_CLD ..........................................................................................................41 3.10.2.1.4 0PROGCHANGE_SES_NEW ..........................................................................................................41 3.10.2.1.5 0PROGCHANGE_SGM_NEW .........................................................................................................41

3.11 Event for Program De-Registration (0PROGDEREGIST) ....................................................................41 3.11.1 Activities..........................................................................................................................................................41 3.11.2 Context............................................................................................................................................................41 3.11.2.1 Sub-contexts ................................................................................................................................................41 3.11.2.1.1 0PROGDEREG_ATTR.....................................................................................................................42 3.11.2.1.2 0PROGDEREG_SGM_UPD.............................................................................................................42 3.11.2.1.3 0PROGDEREG_SES_CLD..............................................................................................................42 3.11.2.1.4 0PROGDEREG_SES_DLM..............................................................................................................42 3.11.2.1.5 0PROGDEREG_SGM_BEF .............................................................................................................42

3.12 Event for Extended Maintenance of Program Registration Data (0REGIST_EXT)..............................43 3.12.1 Activities..........................................................................................................................................................43 3.12.2 Context............................................................................................................................................................43 3.12.2.1 Sub-contexts ................................................................................................................................................44 3.12.2.1.1 0REGIST_EXT_SES_INS ................................................................................................................44 3.12.2.1.2 0REGIST_EXT_SES_DEL ...............................................................................................................44 3.12.2.1.3 0REGIST_EXT_SGM_INS ...............................................................................................................44 3.12.2.1.4 0REGIST_EXT_SGM_DEL ..............................................................................................................44

3.13 Events for Fee Calculation (0FEECALC_REAL and 0FEECALC_STAT) ............................................44 3.13.1 Activities..........................................................................................................................................................44 3.13.2 Context............................................................................................................................................................44 3.13.2.1 Sub-contexts ................................................................................................................................................45 3.13.2.1.1. 0FEECALC_REAL_DOC (0FEECALC_STAT_DOC).......................................................................45

3.14 Events for Financial Aid (0GRANTEVAL_DIS and 0GRANTEVAL_EXP) ...........................................46 3.14.1 Activities..........................................................................................................................................................46 3.14.2 Context............................................................................................................................................................46 3.14.2.1 Sub-contexts ................................................................................................................................................46 3.14.2.1.1 0GRANTEVAL_DIS_DOC (0GRANTEVAL_EXP_DOC)..................................................................46

3.15 Event for Module Booking (0MODBOOK) ............................................................................................47 3.15.1 Activities..........................................................................................................................................................47 3.15.2 Context............................................................................................................................................................47



3.15.2.1 Sub-contexts ................................................................................................................................................47 3.15.2.1.1 0MODBOOK_CONTEXT..................................................................................................................47 3.15.2.1.2 0MODBOOK_MODULES .................................................................................................................48 3.15.2.1.3 0MODBOOK_EVENTS.....................................................................................................................50

3.16. Event for Module Grading (0GRADING)..............................................................................................51 3.16.1 Activities..........................................................................................................................................................51 3.16.2 Context............................................................................................................................................................51 3.16.2.1 Sub-contexts ................................................................................................................................................51 3.16.2.1.1 0GRADING_TOP_APP_UPD...........................................................................................................51 3.16.2.1.2 0GRADING_TOP_APP_BEF....................................................................................................................53

3.17 Event for Academic Work (0ACADEMIC_WORK)................................................................................53 3.17.1 Activities..........................................................................................................................................................53 3.17.2 Context............................................................................................................................................................53 3.17.2.1 Sub-contexts ................................................................................................................................................53 3.17.2.1.1. 0ACADEMIC_WORK_UPD..............................................................................................................53 3.17.2.1.2. 0ACADEMIC_WORK_BEF ......................................................................................................................54

3.18. Event for Program Type Progression (0PROGRESSION) ..................................................................54 3.18.1 Activities..........................................................................................................................................................54 3.18.2 Context............................................................................................................................................................54 3.18.2.1 Sub-contexts ................................................................................................................................................54 3.18.2.1.1 0PROGRESSION_RES....................................................................................................................55 3.18.2.1.2 0PROGRESSION_CANC .........................................................................................................................56

3.19 Event for Registration to Specializations (0SPECIALS) .......................................................................57 3.19.1 Activities..........................................................................................................................................................57 3.19.2 Context............................................................................................................................................................57 3.19.2.1 Sub-contexts ................................................................................................................................................57 3.19.2.1.1 0SPECIALS_UPDT...................................................................................................................................57

3.20 Event for Event Bookings (0EVBOOKING) ..........................................................................................58 3.20.1 Activities..........................................................................................................................................................58 3.20.2 Context............................................................................................................................................................58 3.20.2.1. Sub-contexts ...............................................................................................................................................58 3.20.2.1.1 0EVBOOKING_UPD.................................................................................................................................59

4. Applications Using Post Processing .............................................................................................................60 4.1 Integration Using XI ................................................................................................................................60

4.1.1 Integration to Financial Aid Systems.................................................................................................................60 4,1.2 Integration to Learning Management Systems..................................................................................................63 4.1.3 Saving of Performance Index............................................................................................................................63

Copyright ..........................................................................................................................................................65



Introduction Providing functionality for customers to implement post-processing for standard business processes in Student Lifecycle Management allows the automation of many follow-up activities and enables integration scenarios across system components that either cannot supported at all without a corresponding functionality or can be implemented only at much higher cost for the customer.

The scope of this document is to describe the concept and explain the usage of the post-processing framework in Student Lifecycle Management. This is a development for SLCM which re-uses the Business Rule Framework (BRF) and should not to be confused with the Post Processing Framework, also called PPF’ as used in CRM.

Some examples:

• A leave of absence is created with a given reason. It triggers an action that cancels all module bookings for the academic session;

• a student is assigned a new progression status and a XI notification to a 3rd party financial aid system is sent as consequence;

• a failed grade is entered for a module booking of the student and the responsible advisor is alerted;

• a program registration is executed which triggers the print of a registration certificate



1. Glossary

English Term English Abbreviation

Definition

Post-processing The execution of automatic actions after an application finishes manipulating data. Such actions are related to the business context with which the main application is working, but they build a separate entity from a business and technical point of view.

Business Rule Framework

BRF The BRF is an event-controlled runtime environment for processing rules. You can assign any number of rules to each event, whereby a rule normally consists of a Boolean expression and an action. If the expression returns the value TRUE, the action is executed. The BRF also contains a maintenance environment in which you can edit and configure BRF objects. You can configure both technically oriented as well as business process oriented rules. This means that you configure the rules in the maintenance environment, and the rules are processed in the runtime environment.

Event An event is the (logical) location in a business process at which actions can be triggered. It is the link between the application and the actions to be executed. BRF events are those triggered using the BRF. Not to be confused with (business) events as used in Training and Event Management.

Action An action is the term for any manipulation of any data sets that makes sense from a business point of view and that can be performed technically. A BRF action is assigned to a BRF event and is executed whenever that event is triggered.

Event context The context contains information about the application that triggers the event. BRF events have context attached to them, which makes possible to implement business rules based on it.



2. Concept The post processing functionality in Student Lifecycle Management enables customers to have configurable actions to be triggered on completion of different business processes in the SLCM system. Completion here means the process specific data is saved successfully in the system.

The focus is mainly on one-step actions that can be executed automatically at certain points. Such a one-step action can itself start some kind of process chain (e.g. start an integration scenario using XI or start a work flow, depending on the implementation of actions in customer systems).

2.1. General Concept

The post processing functionality is summarized in the following steps:

• SLCM system provides events for the business processes defined in the system. The triggered events contain the context relevant to the application or the process which triggered them.

• Customers create rules and attach them to the events. Rules contain expressions and actions. With expressions you create your own business check and decide whether it is required to trigger the attached action. If the outcome of the expression is true, your action will be executed. Actions are the activities that you want to perform once the business process is completed.

• You execute the business process and complete it. Completion means you saved the data successfully.

• The system then triggers the event which corresponds to the business process. This in turn calls the rules that you have defined for that event which in turn execute the action attached to the rule if the outcome of the expression is true. All this happens asynchronously in the background so that the user is not interrupted during the process. Once you are done with executing the process, you do not need to wait for the post processing actions to be executed but may go ahead with other activities in the system.

o Example: you create an admissions record for a student and wish to notify the responsible advisor. Creating the admissions record is the business process. Notifying the advisor is the related post processing action. When the user creates the admissions record and saves it, the system triggers the admissions event (0ADMISSION) and the rules defined for the events are executed.

• If the action executed was successful, you get an application log of the successful run. You can also drill down to the activity document for the process created.

• If the actions failed in execution, you get an error log. Some errors could be temporary, e.g. data base lock errors. The system offers the possibility to reschedule the event to a later time.

•

SLCM Process



2.2 Business Rule Framework

The system uses the BRF to create/maintain the events, rules and actions used in the post processing framework. BRF has BRF objects through which the runtime behavior of the applications can be controlled. These BRF objects are BRF events, BRF expressions, BRF actions.

BRF offers flexibility for users to define their own expressions, actions and attach them to the events.

The transaction to maintain the BRF objects is BRF. Objects in BRF are logically grouped using the application class. All the objects of SLCM belong to the application class ISHERCM_PP.

See the screen shot of the BRF transaction:

2.2.1 BRF Events

Events are the BRF objects which control the runtime behavior of the application. Events are configured in the framework and later triggered from the system upon successful execution of the business process. An object takes part in the process and triggers the event. For most of the business processes in SLCM, the object which triggers the event is STUDENT (object type ST). For some of the processes they are MODULE (SM) and EVENT (E or EL).

For each object, an instance of the event is created which controls the entire post processing activity for that event. In mass processing there could be many objects, which take part in the process. For each object an event will be created. The post processing for each of this event will be INDEPENDENT from each other.

Events also carry application specific data as event context. One event can have only one context. But one context can have sub contexts. This way it is possible to have many contexts for an event.

Some of the most common events are delivered. All events in SLCM have a context header as main context. The structure of the context header is the same for all events. The context header contains information about



• The object which triggered the event

• The process which triggered the events

• Administration details like user, time etc at which the event got triggered.

The context header is a structure of type PIQPP_EV_CH. As said above the structure has the elements listed in details below.

Component Description

PLVAR Plan Version

OTYPE Object type of activity reference object

OBJID Object ID of activity reference object

MAIN_ACTIVITY Activity

REASON Activity reason

KEY_DATE Activity key date (General)

KEY_TIME Time on activity key date

KEY_TIMEZONE Time zone of activity key date and time

REF_DOCID Reference activity identification key

TIMESTAMP Time stamp of event

UNAME User who triggered event

LOGSYSTEM Logical system

Detail contexts will be added to the context header as sub contexts. Depending on the event, detail contexts are delivered. The detail context contains the data before the process was executed and also the data after the save is done. The data in the context can be used for defining the expressions for rules and for defining the actions.

Go to transaction BRF. Search for objects in application class ISHERCM_PP.

Go to node All Groups->Events. Right click on event and go to Event Maintenance.



See the following screen shot for details.



The event maintenance screen displays the context of the event. You can further drill down to the context by double clicking on it to see the sub context for the context header.

Context



See the screen shot of sub-contexts shown for the academic event 0ADMISSION.

Sub-contexts

2.2.2 BRF Rules

BRF Rules are the check points for triggering BRF actions from events. A rule contains a Boolean expression and an action. If the expression returns TRUE, the action is triggered. If there is no expression in the rule, it is always true and the action is triggered always when the event gets triggered.

Users are allowed to create any rules and attach them to the event. This mean, you configure the rules for the event and the rules are processed at runtime. All the rules attached to the event will be processed upon trigger of the event. Processing of the rules follows the ALL OR NOTHING principle. If any of the actions end up in error, all the actions in the event are ROLLED BACK. You still have the possibility to reschedule the entire event again.

Go to transaction BRF. Search for objects in application class ISHERCM_PP.

Go to node All Groups->Events. Double click on the event. You can now see the rules for that event.



See below the screen shot showing the configuration of rules to an event.

Rules for event



To add new rules to the event, change to edit mode and start creating new rules by clicking on the ‘Create Rule’ button. See the screen shot below

Edit mode

Create Rule



2.2.2.1 BRF Expressions

Expressions are used in rules to decide on the triggering of actions. Expressions can return results of type Boolean, integer, DDIC type etc. You can use expressions inside expressions to give a new result type. For example you can have an expression (EXP1) which gets the data from the context which the event carries. You can then create a new expression EXP2 which compares the value of this expression to a constant or any other expression and then returns a Boolean value.

To create an expression, you can right click on the node expressions and click to create expressions. Expressions that you create vary in behavior depending on the type of implementation you choose. Please see the screen shot to see which implementation types are supported by the BRF.

Implementation Type

Implementation types supported

As visible from the screen shot, there are lots of possible ways to create own expressions. You can have a constant, use SAP formula interpreter, case expressions, Boolean expressions, etc.



Below is an example where an expression is created to get the module booking context (program type). This context will be available with event 0MODBOOK.

Data from expression

Event Context



Below is another example where the formula interpreter is used to compare the earlier expression to return a Boolean value.

Return type of expression

Formula of comparison

2.2.2.2 BRF Actions

BRF actions are the executable actions which correspond to your post processing activity. Actions are part of BRF rules. For each rule, you assign one action. An action can be anything related to a business process execution.

Currently in BRF, the following action types are supported

• BAdI as Action

• Trigger BOR Event

• Function Module as Action

• Message Output via BDT (Only Makes Sense to Use in BDT Environment)

• Start Action Workflow



This screenshot shows how actions can be configured

Right click on actions node to create a new action




Action types, which can be set up. Double click to add the function module name or BAdI name etc.

Action Types


Function module name

Parameters to the function module (action)

• BAdI as Action:

You can create a BAdI implementation as an action. You need to implement BAdI BRF_ACTION and implement the method PROCESS.

The method PROCESS has the following parameters:

Component Type Typing Method Type

FLT_VAL Importing Type BRF_FILTER_VALUE_ACT

IT_EXPRESSION Importing Type SBRF178A_T

IO_EVENT Importing Type Ref To IF_EVENT_BRF

IO_ACTION Importing Type Ref To IF_ACTION_BRF

FLT_VAL is the filter value of your BAdI implementation.

IT_EXPRESSION will have the parameters passed from actions. See the screen shot above which shows the method of passing parameters to the action.

IT_EXPRESSION has the line type SBRF176A which has the structure shown below:



CLIENT Client

IMPORT_STATUS BRF: Import Status

APPLCLASS BRF: Application Class

ACTION Name of Action

VERSION BRF: Version

EXEC_ON_FALSE Execute Subaction if Function = False

EXEC_FUNCTION Action - Function to Be Executed

SEQUENCE Sequence Number

EXPRESSION BRF: Expression

EXPRESSION_REF BRF: Expression

RESULT_VALUE Result

RESULT_DATA

RESULT_TYPE BRF: Result Type

RESULT_LENGTH Field Length/Structure Length

RESULT_CURRENCY Currency Key

RESULT_OUT_LEN Output Length

RESULT_DECIMALS Decimal Places for Type P

RESULT_DATA_MISSING Data Missing

RESULT_ERROR SPACE = False, 'X' = True

The expressions are passed as parameters and you can evaluate these expressions in the actions. This is the best way to put your own business checks in the actions.

IO_EVENT is the event instance. You can get the context data associated with the event from this event instance.



To get the context, you may use the following coding

DATA : lo_prog_event TYPE REF TO cl_event_context_base_brf.

*-- Cast to cl_event_context_base_brf to retrieve context

lo_prog_event ?= io_event. lv_brf_context = <context name>. *-- Get the context header CALL METHOD lo_prog_event->if_event_context_brf~get_context EXPORTING iv_context = lv_brf_context IMPORTING es_context_data = <context_data> EXCEPTIONS invalid_context = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 . ENDIF.

• Function Module as Action:

You can have a function module as an action. The function module should have a predefined interface as given below

*"---------------------------------------------------------------------- *"*"Local Interface: *" IMPORTING *" REFERENCE(IT_EXPRESSIONS) TYPE SBRF176A_T *" REFERENCE(IO_EVENT) TYPE REF TO IF_EVENT_BRF *" REFERENCE(IO_ACTION) TYPE REF TO IF_ACTION_BRF *" EXCEPTIONS *" TECHNICAL_ERROR *"----------------------------------------------------------------------

The parameters IT_EXPRESSIONS, IO_EVENT and IO_ACTION also serve the same purpose here as well.

Use IT_EXPRESSIONS to carry out business checks in the post processing activities and use IO_EVENT to get the context data associated with the event and to use it in the post processing activity.

The post processing framework takes care of execution of the actions attached to the event. As said above, it is based on the ‘all or nothing’ principle. If any of the actions assigned to the event is not successful, then all the other actions assigned to the same event are rolled back. So care must be taken that the actions you define do not COMMIT by themselves. The framework does the COMMIT WORK for all the actions. Otherwise it will create inconsistencies. This also means that all data base updates and other actions must be executed on commit work only.

2.3. Error Handling

If all of the actions associated with the triggered event are executed successfully, the system stores the trace in an application log.

As many actions can be configured for an event, it can happen that one of the actions ends up in error. The system then rolls back all actions and decides whether to reschedule the entire event again or not. Rescheduling means the event will be scheduled again to trigger after a gap of time. All the actions associated with the event will be executed again. The time for rescheduling is customizable. The decision to reschedule the event or not is taken from the errors that the system got while executing the actions. It is customizable which error will lead to rescheduling and which not. If the decision was not to reschedule the event, the errors are logged and visible in transaction SM58.



2.3.1 Application Log

You run the business process and saved it. This triggers the event and all actions configured for the event are executed. If all the actions are executed successfully, the trace is written to the application log.

• For each successfully executed event instance, the application log is created for log object ISHERCM_POSTPROC and sub-object <EVENT>

Go to transaction SLG1 to see the application log

• The log includes a message about the successful run of the BRF event. The detail of this message will give you the BRF trace for the event. The BRF trace shows which rules of the event were checked and which actions were executed successfully.



See the screen shots below for details.

See below the screen shot of the BRF trace for that event. You can further navigate to the event and action level directly from here.

• The log will also have a message about the activity which triggered the post processing. The details of this message will give the activity document if it was at all created for that activity.



See below the screen shot showing the activity document.

Details of activity

2.3.2 Event Rescheduling

If any of the action ends up in error, the framework decides whether to reschedule the event later or not. The decision is depending on the category of the error that you configured in the system. There are 3 error categories: • Error (E): the framework cancels the event. • Temporary Error (T): the framework reschedules the event. • Error that can be ignored (I): the framework ignores the message.

Error categories can be assigned to messages using the following activity in IMG node:

Student Lifecycle Management-> Student Lifecycle Processes->General Settings->Post Processing->Maintain Error Categories for Post Processing

2.3.3. Event Cancelled

If there are errors and the category of the errors are all E (permanent errors), the framework cancels the event. In that case the error log will be available in transaction SM58. This is the transaction to show the log of all transactional RFC’s.



2.4 Switching ON/OFF Post Processing

It is not mandatory to use the post processing every time in the application. Situations could be, e.g., that you use post processing to update the changes from your system to another system. For example, updating admissions change details to a financial aid system through middle wares like XI. In such cases, at some point of time in the year you expect lots of frequent changes in the data and you don’t wish to update the other system about these new changes as these changes would again change later. Also, the cost incurred for updating the changes, are higher. In such cases you can switch off the post processing in customizing.

Go to IMG->Student Lifecycle Management-> Student Lifecycle Management Processes->General Settings->Post Processing->Activate Post Processing

For group POSTPROC and setting PPACTIVE, set either X or space.

Value X - Activate the post processing

Value ' ' - Deactivate the post processing



3. Events For each of the standard business process in Student Lifecycle Management, an event is delivered. Please see in subsequent chapters what each event offers.

3.1 Event for Admission (0ADMISSION)

3.1.1 Activities

The activities in Student Lifecycle Management that trigger event 0ADMISSION are

• AD01 Create Admissions Application.

• AD02 Change Admissions Application.

• AD03 Delete Admissions Application.

• AD05 Execute Admission

• AD06 Reject Admissions Application

• AD07 Change Admission

• AD08 Change Rejected Admissions Application.

• AD09 Change of Program in Adm. Application

• AD10 Change of Program in Admissions

• AD11 Undo Rejected Admissions Application

• AD12 Undo Admission

• AD13 Withdraw Admission Application.

• AD14 Decline Offer of Admission

• AD15 Reverse Decision

•

3.1.2 Context

The context associated with event 0ADMISSION is 0ADMISSION_CH. The context 0ADMISSION_CH is the context header and has a structure PIQPP_EV_CH. Context header has information about

• The object which triggered the event

• The activity which triggered the events

• Administrative details such as user, time, etc. at which the event was triggered.

3.1.2.1 Sub-contexts

The sub contexts for 0ADMISSION_CH are

• 0ADMISSION_BEF

• 0ADMISSION_UPD



3.1.2.1.1 0ADMISSION_BEF

Context 0ADMISSION_BEF contains the state of data before the activity was executed. The structure for 0ADMISSION_BEF is PIQPP_EV_ADM. Please see below for the contents.

ACTIVITY Activity

PLVAR Plan Version

ST_OBJID Object ID of Student

CS_OBJID Object ID of Study Object (CS)

SC_OBJID Program ID

BEGDA Valid-From Date

ENDDA Valid-To Date

ISTAT Admission Application Status

SEQNR Number of Infotype Record With Same Key

Sub contexts



.INCLUDE Additional Relationship Data

CHOICE_NO Program Choice

ADM_AYEAR Academic Year

ADM_PERID Academic Session

ADM_ACLEVEL Stage

ADM_PROGCLASS Progress Classification

ADM_PARTT Indicator: Part-Time Study

ADM_CATEG Admission Category

ADM_ENRCATEG Registration Type

ADM_CODE Admission Code

ADM_PERCT Completed Length of Study

ADM_QMNUM Notification Number

ADM_STATUS_SUP Status Supplement

ADM_DEC Decision Date of Rejection or Admission

ADM_RECPT Date of Admission Application Receipt

ADM_WITH_DECL Date of Withdrawal or Declination

ADM_GUID Unique Key (GUID) of the Admission

COKEY Correspondence key

TIMEUNIT Time Unit for Program Duration

Context 0ADMISSION_BEF will be filled for the following activities

• AD02 Change Admission Application.

• AD03 Delete Admission Application.


• AD08 Change Rejected Admission. Application.


• AD10 Change of Program in Admission



3.1.2.1.2 0ADMISSION_UPD

Context 0ADMISSION_UPD has the state of data after the activity was executed. The structure for 0ADMISSION_UPD is PIQPP_EV_ADM. It is the same as for 0ADMISSION_BEF. Please see above.

Context 0ADMISSION_UPD will be filled for the following activities:

• AD01 Create Admission Application.

• AD02 Change Admission. Application.

• AD05 Execute Admission

• AD06 Reject Admission. Application.


• AD08 Change Rejected Admission. Application.


• AD10 Change of Program in Admission

• AD11 Undo Rejected Admission Application

• AD12 Undo Admission

• AD13 Withdraw Admission. Application.

• AD14 Decline Offer of Admission

• AD15 Reverse Decision

3.2 Event for Anticipated Graduation Date (0ANTICGRAD)

When an anticipated graduation date is created, changed or reset for a student, event 0ANTICRAD is triggered.

3.2.1 Activities

The activities that trigger the event 0ANTICRAD are

• AGD1 - Create anticipated graduation data

Here you create a new record of anticipated graduation date

• AGD2 - Change anticipated graduation data

Here you change the record of anticipated graduation date to another date.

• AGD3 - Reset anticipated graduation data

Here you cancel the anticipated graduation date. That means the date is put to initial.

These are new activities created in the system.

3.2.2 Contexts

The context header of the event is 0ANTICGRAD_CH which is a structure of type PIQPP_EV_CH.

The context 0ANTICGRAD_CH has two sub contexts:

• 0ANTICGRAD_BEF

• 0ANTICGRAD_UPD

Both the sub contexts are of same structure of type PIQAGD_DATESEXT.



0ANTICGRAD_BEF will be filled with the old record and 0ANTICGRAD_UPD will be filled with the new record. That means 0ANTICGRAD_BEF will be filled with values for activities AGD2 and AGD3. Context 0ANTICGRAD_UPD will be filled with values for activities AGD1 and AGD2.

Both details contexts have the structure given below

AGD_DATE Anticipated Graduation Date

AGD_YEAR Anticipated Graduation Year

AGD_PERIOD Anticipated Graduation Session

AGD_SETMODE Mode Used To Determine Anticipated Graduation

BEGDA Start Date

ENDDA End Date

CS_OBJID Object ID of Study Object (CS)

3.3. Event for Module Edited (0MODULE)

The event 0MODULE will be triggered when any attribute of the module is changed. That means if any Infotype or Infotype related data of HR PD object of type SM is created/changed/deleted, the event 0MODULE is triggered.

3.3.1 Activities

Any activity that leads to a change in the Infotypes of a module will trigger the event. For example you change the module attributes through module catalogue (transaction PIQ_ACCATLG).

3.3.2 Contexts

The context associated with event 0MODULE is 0MODULE_CH. It is a structure of type PIQPP_EV_CH. The context 0MODULE_CH has sub context 0MODULE_UPD.

The context 0MODULE_UPD has all details of the data changed for the module.

0MODULE_UPD is a structure of type PIQPP_EV_MODULE_CXT.

OBJECT_TYPE Object Type

OBJECT_ID Object ID

BEGINDATE Start Date

ENDDATE End Date

UPDATE_MODE Update Mode for Business Object

INFTYTABLE Table type for Infotype Data



The context will have information about the object type (here SM), ID of the object (here module ID), validity period of the object, update mode and the table of Infotypes.

The update mode has fixed values –

I Business Object Created

U Business Object Changed

D Business Object Deleted

C Business Object Cancelled.

C is relevant for objects like E where we can cancel the events.

The table of Infotype has lines which are of type PIQPP_EV_INFTY.

INFTY Infotype

RELAT_OBJTYPE Type of Related Object

RELAT_OBJID ID of Related Object

SUBTY Subtype

BEGDA Start Date

ENDDA End Date

UPDATE_MODE Update Indicator (Insert: I, Change: U, Delete: D)

As mentioned above in the table, the record will have information about the Infotype record changed.

3.4 Event for Event Package Edited (0EVENTPACKAGE)

The event 0EVENTPACKAGE is triggered when any attribute of the event package is changed. That means if any Infotype or Infotype related data of HR PD object of type SE is created/changed/deleted, the event 0EVENTPACKAGE is triggered.

3.4.1 Activities

Any activity that leads to a change in the Infotypes of event packages, will trigger the event. For example you change the event package attributes through the event planning screen (transaction PIQACADOFFER00).

3.4.2 Contexts

The context associated with event 0EVENTPACKAGE is 0EVENTPACKAGE_CH. It is a structure of type PIQPP_EV_CH. The context 0EVENTPACKAGE_CH has sub context 0EVENTPACKAGE_UPD.

The context 0EVENTPACKAGE_UPD has all details of the data changed for the event package.

0EVENTPACKAGE_UPD is a structure of type PIQPP_EV_EVENTPACKAGE_CXT.

The structure is similar to the context for event ‘Module Edited’. The structure details are given below.


OBJECT_ID Object ID




ENDDATE End Date



The field INFTYTABLE is a table of line type PIQPP_EV_INFTY

3.5 Event for Academic Event Edited (0ACADEMICEVENT)

The event 0ACADEMICEVENT is triggered when an academic event is created/changed/deleted/cancelled. That means if any Infotype or Infotype related data of HR PD object of type E or EL is created/ changed/ deleted, the event 0ACADEMICEVENT is triggered. The object type could be either E or EL

3.5.1 Activities

Any activity that leads to a change in the Infotypes of object type E or EL, will trigger the event. For example you create/ change/ delete/ cancel an event through transaction PIQACADOFFER00.

3.5.2 Contexts

The context associated with event 0ACADEMICEVENT is 0ACADEMICEVENT_CH. It is a structure of type PIQPP_EV_CH. The context 0ACADEMICEVENT_CH has sub context 0ACADEMICEVENT_UPD.

The context 0ACADEMICEVENT_UPD has all details of the data changed for the object E or EL.

0ACADEMICEVENT_UPD is a structure of type PIQPP_EV_ACADEVENT_CXT.

The structure is similar to the context for event ‘Module Edited’. The structure details are given below.


OBJECT_ID Object ID


ENDDATE End Date



The field INFTYTABLE is a table of line type PIQPP_EV_INFTY.



3.6. Event for Status Indicators (0STATUSINDIC)

3.6.1 Activities

You can activate or deactivate holds or customer statuses through the student file. These will trigger the event. The activity is HSMA.

Contexts

The context associated with the event is 0STATUSINDIC_CH. The context 0STATUSINDIC_CH is a structure of type PIQPP_EV_CH. It has a sub context 0STATUSINDIC_DET. The context 0STATUSINDIC_DET has the information about the status indicators that are being currently updated in active or inactive state.

The context 0STATUSINDIC_DET is a structure of type PIQPP_EV_HS_CXT.

It is a table containing the info about the indicators.

The table has a line type BAPISTUDENT_STATIND. The details of the structure is given below

OTYPE Object Type

OBJECTID Object ID

PLANVERSION Plan Version

FROM_DATE Start Date

TO_DATE End Date

STATUS Status

STATE Status Specification

3.7 Event for Performance Index Updated (0PERFINDEX)

Whenever the performance indices for a student are created or updated the event 0PERFINDEX is triggered. When a module booking is changed or when grading is done or academic work is changed, the performance indices for the student are affected. Performance Indices are calculated and are created/ updated in the database. This triggers the event 0PERFINDEX.

3.7.1 Activities

Any activity that affects the performance indices of a student will trigger event 0PERFINDEX. For example

• Module booking changed

• Grading done

• Academic work is edited etc

3.7.2 Context

The event 0PERFINDEX carries context 0PERFINDEX_CH as main context (Context header). Context 0PERFINDEX_CH is a structure of type PIQPP_EV_CH.

It has context 0PERFINDEX_UPD as the sub context.



Context 0PERFINDEX_UPD has all data related to the created/updated performance indices. 0PERFINDEX_UPD is a structure of type PIQPI_BRF_CONTEXT.

The structure is shown below in detail:

STOBJID Object ID of Student

PINDEX_TAB Performance Index ( BRF Context )

It has the information of the student for whom the performance index is saved and also a table PINDEX_TAB containing the info related to the created/updated performance indices.

PINDEX_TAB is a table of line type PIQPI_PINDEX_BRF. Details of PIQPI_PINDEX_BRF are given below:

PINDEX_ACTION Action Executed for Performance Index (Fixed values: I & U)

PINDEX_ID Performance Index GUID

CALCPOINT_ID Calculation Point

OBJID Object ID of Student

PLVAR Plan Version

TIMESTAMP UTC time stamp in long form (YYYYMMDDhhmmss,mmmuuun)

CALC_DATE Date

CALC_TIME Time

CALC_TIMEZONE Time Zone

GUID UUID in character form

GUIDTYPE Identifier Type (GUID)

ACAD_YEAR Academic Year

ACAD_SESSION Academic Session

PROGRAM_TYPE Program Type

PROGRAM_ID Program ID

PROGRESS_CAT Progression Category

CHECK_FROM Check-From Date for Progression

CHECK_TO Check-To Date for Progression



YYHAUPTFACH Module Group ID

ACADPI_ID Performance Index

GRADESYM Grade Symbol

GRADE Std Value for Scale Value

GRADESCALE Academic Scale Identification (ID)

ACPI_VALUE Value of Performance Index

ACPI_UNIT Unit of a Performance Index Result

ACADPI_DEGRELY Degree of Performance Index Reliability

GRADESYMBEF Grade Symbol

GRADEBEF Std Value for Scale Value

GRADESCALEBEF Academic Scale Identification (ID)

ACPI_VALUEBEF Value of Performance Index

ACPI_UNITBEF Unit of a Performance Index Result

The field PINDEX_ACTION indicates whether the Performance index is created or updated in the database.

In case of an update, the structure also gives information about the value of the old performance index. All fields with suffix BEF will have the information about the old performance index. They are:

GRADESYMBEF

GRADEBEF

GRADESCALEBEF

ACPI_VALUEBEF

ACPI_UNITBEF



3.8 Event for Program Registration (0PROGREGIST)

The event 0PROGREGIST is triggered by the activities related to initial program registration so that one sessional registration record as well as one study segment is involved.

3.8.1 Activities

The activities in Student Lifecycle Management that trigger event 0PROGREGIST are

• RA01 Initial Registration.

• RA02 Extend Study Segment.

3.8.2 Context

The context associated with event 0PROGREGIST is 0PROGREG_CH. The context 0PROGREG_CH is the context header and has a structure PIQPP_EV_CH which is explained above.


The sub contexts for 0PROGREG_CH are

• 0PROGREG_SES_UPD

• 0PROGREG_SGM_UPD

• 0PROGREG_SGM_BEF

3.8.2.1.1 0PROGREG_SES_UPD

This context contains information about the initial sessional registration that is created. The structure is PIQRFC_SESS_REGISTS:

STUDENT_OBJECTID Object ID of Student

STUDY_OBJECTID Object ID of Study Object (CS)

PROGRAM_OBJECTID Program ID

BEGDA Start Date

ENDDA End Date

STUDY_PRIORITY Program Priority (In Period)



STAGE Stage

REGIST_DATE Activity Key Date for Sessional Registration



PARTTIME Indicator: Part-Time Study

LEAVE_REASON Leave of Absence Reason

COMPL_LENGTH_STUDY Completed Length of Study

REGIST_TYPE Registration Type

DEGREE_SEEKING Degree Seeking (Indicator)

REGIST_STATUS Sessional Registration Status

REGIST_STATE Sessional Registration Status Specification

REGIST_CLASS Registration Classification

CANCEL_PROCESS Cancellation Activity (for Registration)

CANCEL_REASON Cancellation Reason (For Registration)

CANCEL_DATE Cancellation Date (Registration)

This context is filled by both activities triggering the event – RA01 and RA02.

3.8.2.1.2 0PROGREG_SGM_UPD

This context contains information about the study segment created with the initial registration by activity RA01 or updated, i.e. its technical validity was extended forward by activity RA02. The latter is possible only in the US mode for module booking whenever a sessional registration is created before the start date of the previously existing study segment. The structure used for the context is PIQRFC_STUDYSEGMENTS.




BEGDA Start Date of Program Registration

ENDDA End Date of Program Registration

BEG_PROCESS Activity for Program Registration

BEG_REASON Activity Reason

BEG_KEY_DATE Activity Key Date for Start of Study Segment

END_PROCESS Activity for De-registration from Program



END_REASON De-registration Reason

END_KEY_DATE Activity Key Date of De-registration

LAST_ATTENDANCE Last Day of Attendance

3.8.2.1.3 0PROGREG_SGM_BEF

This context contains information about the previously existing study segment of the student for the program of study. 0PROGREG_SGM_BEF will be only filled for activity RA02 where the extended study segment is available for comparison in context 0PROGREG_SGM_UPD.

0PROGREG_SGM_BEF has also structure PIQRFC_STUDYSEGMENTS

3.9 Event for Program Re-Registration (0PROGREREG)

Event 0PROGREREG is triggered by activities related to program re-registration that create, change or cancel a sessional registration of a leave of absence. In this case only one sessional registration record is involved.

3.9.1 Activities

The activities in Student Lifecycle Management that trigger event 0PROGREGIST are

• RK01 Sessional Registration

• RL01 Leave of Absence

• RK02 Change Sessional Registration

• RL02 Change Leave of Absence

• RM03 Cancel Sessional Registration

• RMS2 Change Cancellation (Sess. Registration)

3.9.2 Context

The context header associated with event 0PROGREREG is 0PROGREG_CH and references structure PIQPP_EV_CH which is explained above.


3.9.2.1.1 0PROGREREG_SES_UPD

This context contains information about the sessional registration (or leave of absence) that is created (RK01 or RL01) or changed (RK02 or RL02) or cancelled (RM03, where RMS3 changes a cancelled sessional registration). It is the sessional registration record that is stored in the database after the activity is executed.

The data structure used for this context is PIQRFC_SESS_REGISTS which is explained above.

3.9.2.1.2 0PROGREREG_SES_BEF

This context contains information about the sessional registration before it was changed by the activity. This is not relevant for the activities RK01 and RL01 which both create a new record.



3.10 Event for Change of Program (0PROGCHANGE)

This event is triggered by activities related to change of program so that registration data from two programs is involved – the ‘old’ program the student is being deregistered from and the ‘new’ program the student is transferring to. The following data is involved in particular:

- one or more sessional registrations at the old program of study of the student (if they are cancelled at the date of the program change)

- the study segment at the old program that is delimited at the date of the program change

- one sessional registration that can be created for the new program of study or several sessional registrations that are transferred from the old to the new program of study. It is also possible to execute a change of program without creating a new sessional registration at first at all

- the study segment created for the new program

-

3.10.1 Activities

This event is triggered by activity • RQ01 Change of Program

3.10.2 Context

The context header associated with event 0PROGCHANGE is 0PROGCHANGE_CH and references structure PIQPP_EV_CH which is explained above.


3.10.2.1.1 0PROGCHANGE_SES_CLD

In this context, information about cancelled sessional registrations for the old program of study is available. The change of program is valid from a selected key date onwards. Any sessional registrations for the old program of study valid after this key date are cancelled.

The structure used for this context is PIQPP_EV_SESR_CXT. This structure itself contains one complex field only which references a table type with line type PIQRFC_SESS_REGISTS (see screenshot below).

Structure PIQRFC_SESS_REGISTS which is used for holding information about sessional registrations is already explained above.

The context is empty if the date of the change of program is after the last sessional registration for the old program.

3.10.2.1.2 0PROGCHANGE_SES_DLM

If the key date for the change of program falls within an academic session for which the student was registered at the old program of study, the sessional registration for that particular session is split in two at the key date. The part starting after the key date is cancelled and will be available in the context 0PROGCHANGE_SES_CLD. The part ending right before the key date is available in context



0PROGCHANGE_SES_DLM. This part is still an active sessional registration but was delimited at the date of the program change minus one day.

The structure for context 0PROGCHANGE_SES_DLM is flat as only one sessional registration can be delimited at most and has structure PIQRFC_SESS_REGISTS.

This context will be filled only if that particular data constellation occurs, otherwise it is empty.

3.10.2.1.3 0PROGCHANGE_SGM_CLD

This context contains the study segment at the old program of study that was delimited by the change of program. The structure used is PIQRFC_STUDYSEGMENTS (see above). This context will be always filled.

3.10.2.1.4 0PROGCHANGE_SES_NEW

This context contains information about the sessional registrations that were created for the new program of study. The number of records may be:

- zero if no sessional registration was created. The student is only transferred to the new program;

- one, if the option was selected to create one initial sessional registration for the new program of study;

- any number, if the option was selected to transfer sessional registrations that were cancelled at the old program of study to the new program of study. This is possible only if the two programs of study use the same years, sessions and academic stages.

The context uses structure PIQPP_EV_SESR_CXT which is already explained above.

3.10.2.1.5 0PROGCHANGE_SGM_NEW

This context contains information about the study segment created for the new program of study and refers to structure PIQRFC_STUDYSEGMENTS.

3.11 Event for Program De-Registration (0PROGDEREGIST)

This event is triggered by activities in Student Lifecycle Management related to de-registering students from a program of study.

3.11.1 Activities

The activities triggering the event in particular are:

• RV01 Dismissal From Program

• RV02 Change Dismissal

• RW01 Withdrawal from Program

• RW02 Change Withdrawal

• RZ03 Cancel De-registration

3.11.2 Context

The context header associated with event 0PROGDERGIST is 0PROGDEREG_CH which references structure PIQPP_EV_CH as explained above.




3.11.2.1.1 0PROGDEREG_ATTR

This contexts contains the options chosen for the deregistration activity – shall an alumnus relationship be created, shall module bookings be cancelled or shall the study segment be cancelled altogether (instead of being just delimited at a specified deregistration date). The structure used is PIQPP_EV_DEREG_CXT:

ALUMNUS_RELAT_CREATED Checkbox

MODULES_CANCELLED Cancel Module Bookings

SEGMENT_CANCELLED Cancel Study Segment

3.11.2.1.2 0PROGDEREG_SGM_UPD

This context contains information about the study segment that was changed by the activity. The study segment might be delimited by activities RV01 or RW01. It may be changed by activity RV02 and RW02 (here only the key date and the de-registration date can be changed actually). The validity of the study segment can also be extended to 31.12.9999 by activity RZ03 if it was previously delimited by an earlier deregistration activity.

The structure used for that context is PIQRFC_STUDYSEGMENTS.

3.11.2.1.3 0PROGDEREG_SES_CLD

This context contains information about sessional registrations cancelled after the de-registration date. The context uses structure PIQPP_EV_SESR_CXT which is explained above.

3.11.2.1.4 0PROGDEREG_SES_DLM

This context contains information only if a sessional registration is split into two parts by the de-registration date – the fist part remains active but is delimited at the date of deregistration, the second part (valid after this date) is cancelled. The structure used is PIQRFC_SESS_REGISTS. This is similar to context 0PROGCHANGE_SES_DLM explained above.

3.11.2.1.5 0PROGDEREG_SGM_BEF

This context is the counterpart of 0PROGDEREG_SGM_UPD and is filled with the study segment that existed before the activity was executed. The structure used is PIQRFC_STUDYSEGMENTS.



3.12 Event for Extended Maintenance of Program Registration Data (0REGIST_EXT)

This event is triggered only if registration is maintained via the extended maintenance dialog accessed from transaction PIQST10:

3.12.1 Activities

The activity that can trigger this event is

• R011 Maintain Registrations (Ext. Maint. Dialog)

This activity allows editing all registration data (sessional registrations and study segments) for a given program of study. It is not related to a particular business process but offers a simplified UI where all actions can be executed in one step.

3.12.2 Context

The context header associated with this event is 0REGIST_EXT_CH with references structure PIQPP_EV_CH as explained above. Since the extended maintenance offers a technical view on the registration data for a given program, it is not always possible to identify the business reason for the change. The sub contexts there just contain information about the data records that were inserted to the database (sessional registrations and study segments) and the data records that were deleted in the same step. There are no activities like change, delimit or cancel. Every change consists technically of deletion and creating anew.




3.12.2.1.1 0REGIST_EXT_SES_INS

This context contains information about any sessional registrations that were inserted. The structure used is PIQPP_EV_SESR_CXT (see above for list of attributes).

3.12.2.1.2 0REGIST_EXT_SES_DEL

This context contains information about any sessional registrations that were deleted. The structure used is PIQPP_EV_SESR_CXT (see above for list of attributes).

3.12.2.1.3 0REGIST_EXT_SGM_INS

This context contains information about any segments that were inserted. The structure used is PIQPP_EV_SEGM_CXT. PIQPP_EV_SEGM_CXT contains only one complex field that consists itself of a table with line type PIQRFC_STUDYSEGMENTS.

3.12.2.1.4 0REGIST_EXT_SGM_DEL

This context contains information about any segments that were deleted. The structure used is PIQPP_EV_SEGM_CXT. PIQPP_EV_SEGM_CXT contains only one complex field that consists itself of a table with line type PIQRFC_STUDYSEGMENTS.

3.13 Events for Fee Calculation (0FEECALC_REAL and 0FEECALC_STAT)

The fee calculation triggers two events – one whenever actual FICA documents are posted to the student’s contract account and a second one, whenever statistical FICA documents are posted. The contexts of the two events are therefore identical and only the names differ.

A fee calculation run itself will not trigger any of these two events – only when FICA documents are posted (new fees or delta posting) will one of the events be triggered as appropriate.

3.13.1 Activities These two events are triggered by activity AC00 Calculate Tuition Fees. This may be the case when the fee calculation is executed for an individual student or the ee calculation report is run in mass mode.

3.13.2 Context The context header associated with event is 0FEECALC_REAL_CH which references structure PIQPP_EV_CH as explained above. The context header associated with event 0FEECALC_STAT is 0FEECALC_STAT_CH.




3.13.2.1.1. 0FEECALC_REAL_DOC (0FEECALC_STAT_DOC)

The detail context for event 0FEECALC_REAL is 0FEECALC_REAL_DOC. This context uses structure PIQPP_EV_FEECALC_CXT. PIQPP_EV_FEECALC_CXT contains two fields:

The first field FEES is itself a table with line type CMAC_BRF_FEECALC with the following components:

PERSL Key for Period Assignment

PSOBTYP Contract Object Type

BUKRS Company Code

DOCAMT Calculated Amount in Document Currency

DOCCUKY Document Currency

DUEDATE Due Date


For technical reasons, there is no detailed information about the FICA documents that were actually posted. The second field in structure PIQPP_EV_FEECALC_CXT – FEE_DOCNR – contains the ID of the saved fee calculation documents as used in Student Lifecycle Management. Using this ID additional information can be retrieved in a BRF expression if necessary.

In a similar way the detail context for 0FEECALC_STAT is 0FEECALC_STAT_DOC which has the same structure as 0FEECALC_REAL_DOC.



3.14 Events for Financial Aid (0GRANTEVAL_DIS and 0GRANTEVAL_EXP)

The financial aid evaluation report can trigger two events:

• 0GRANTEVAL_DIS is raised whenever actual disbursements are posted to student’s contract account (real postings)

• 0GRANTEVAL_EXP is raised whenever expected financial aid is posted (statistical postings)

Technically both events are very similar and will be presented together.

3.14.1 Activities

The activity triggering these two events is AC01 Calculate Financial Aid. The events will be triggered whenever the financial aid evaluation report is run for individual students or in mass mode.

3.14.2 Context

The context header associated with event 0GRANTEVAL_DIS is 0GRANTEVAL_DIS_CH and the one associated with 0GRANTEVAL_EXP is 0GRANTEVAL_EXP_CH. Both context headers have structure PIQPP_EV_CH.


3.14.2.1.1 0GRANTEVAL_DIS_DOC (0GRANTEVAL_EXP_DOC)

The detail context for event 0GRANTEVAL_DIS is 0GRANTEVAL_DIS_DOC and for event 0GRANTEVAL_EXP it is 0GRANTEVAL_EXP_DOC. The structure used for both sub-contexts is PIQPP_EV_GRANTEVAL_CXT.

Again the first component of this structure is a table with line type CMAC_BRF_GRANTEVAL (see below).

PERSL Key for Period Assignment

PSOBTYP Contract Object Type

BUKRS Company Code

DOCAMT Calculated Amount in Document Currency

DOCCUKY Document Currency

DUEDATE Due Date



AMODE Grant Evaluation Mode

GRANT_NBR Grant




AID_STATUS Grant Status

The second component contains the ID of the grant document (this is not the posted FICA document but the grant documents used by Student Lifecycle Management in addition to the FICA documents and stored in tables TCMACGRHD and TCMACGRIT).

3.15 Event for Module Booking (0MODBOOK)

Event 0MODBOOK is triggered by activities in Student Lifecycle Management related to module booking – module bookings and cancellation of module bookings. Related event bookings are also part of the event context. There are two other events that are also triggered whenever academic work is changed but in different scenarios – see below for events 0ACADEMIC_WORK (triggered by extended maintenance of academic work and equivalency determination) and 0GRADING (triggered by grading).

Event 0MODBOOK will be triggered both after saving the data in the module booking dialog in the student file as well as when using RFC function module HRIQ_STUDENT_BOOKING. The event will not be triggered currently if a module booking or the where-used lists related to it are maintained in transaction PP01.

In the context of this event more than one module booking (and more than one event bookings) can be found as often several modules will be booked together.

3.15.1 Activities

The main activity triggering this event is MB00 Module Booking. There is also an activity derived per module booking (as there can be several in the context of the event – see below). These activities can be

• MB01 Create Module Booking

• MB02 Change Module Booking

• MB03 Cancel Module Booking

3.15.2 Context

The context header for this event is 0MODBOOK_CH.


3.15.2.1.1 0MODBOOK_CONTEXT

This context contains information about the program type and/or program selected as module booking context, as well as the academic year and session for all the bookings. The structure used is PIQMRCONTEXT:

CONT_PROGRAM Module Booking Context (Program)

CONT_PROGRAMTYPE Module Booking Context (Program Type)



CONT_PERYR Academic Year

CONT_PERID Academic Session

When the event is triggered there is no information yet available about the where-used lists that are created asynchronously after the module bookings are saved. If the module context contained in this structure does not suffice to program a BRF action or expression, the where-used lists can be read from the database additionally.

3.15.2.1.2 0MODBOOK_MODULES

This context contains information about the module bookings themselves. There can be one or more module bookings of the same student if they are stored together in a single step (logical unit of work).

The structure used for the context is PIQPP_EV_MODBOOK_CXT. This structure has one component only (MODULEBOOKINGS) which is a table with line type PIQPP_EV_MODBOOK:

ACADEMICWORKID Academic Work Identifier (GUID)

ACTIVITY Activity (this can be MB01, MB02 or MB03, whereas the main activity in the header context will always be MB00)

INS_OR_UPD Single-Character Flag (‘I’ for new record and ‘U’ for an updated record, i.e. the module booking existed previously and was changed in some way. Only in the latter case will the fields ending with *BEF in structure PIQPP_EV_MODBOOK will be filled)

AWOTYPE Object Type of Academic Work (this will be only ‘SM’ for this event)

AWOBJID Object ID of Academic Work

AWBEGDATE Validity Start Date of Academic Work

AWENDDATE Validity End Date of Academic Work

AWLOCKFLAG Change Lock

AWSTATUS Academic Work Status

CANCELREASON Cancellation Reason



CANCELDATE Cancellation Date

BOOKDATE Booking Date

AWRATING Alternative Assessment Method for Academic Work

CHARGEFREE Free of Charge

TRANSFERFLAG External Academic Work or Qualification Transferred

EVENTPACKAGE Event Package



BOOKREASON Module Booking Reason

ANNULMENT Exclusion Indicator for Module Bookings

COBOK Conditional Booking

PRIOX Priority

CPATTEMP Attempted Credits

CPUNIT Unit of Measurement for Credits

AWOTYPEBEF Object Type of Academic Work (all fields ending with *BEF will be filled for module bookings that existed prior to the activity triggering the event – field INS_OR_UPD in this structure will be ‘U’ like ‘Updated’)

AWOBJIDBEF Object ID of Academic Work

AWBEGDATEBEF Validity Start Date of Academic Work

AWENDDATEBEF Validity End Date of Academic Work

AWLOCKFLAGBEF Change Lock

AWSTATUSBEF Academic Work Status

CANCELREASONBEF Cancellation Reason

CANCELDATEBEF Cancellation Date

BOOKDATEBEF Booking Date



AWRATINGBEF Alternative Assessment Method for Academic Work

CHARGEFREEBEF Free of Charge

TRANSFERFLAGBEF External Academic Work or Qualification Transferred

EVENTPACKAGEBEF Event Package

ACAD_SESSIONBEF Academic Session

ACAD_YEARBEF Academic Year

BOOKREASONBEF Module Booking Reason

ANNULMENTBEF Exclusion Indicator for Module Bookings

COBOKBEF Conditional Booking

PRIOXBEF Priority

CPATTEMPBEF Attempted Credits

CPUNITBEF Unit of Measurement for Credits

PROGRAMTYPESBEF Table Type for Program Type (in this and the last field of the structure the where-used lists are contained in their state before the activity that triggered the event was executed. The current state must be read from the database if necessary – see the explanation for this in the chapter for the context 0MODBOOK_CONTEXT above)

PROGRAMSBEF Table Type for Program

3.15.2.1.3 0MODBOOK_EVENTS

If any event were booked or cancelled together with a module booking, context 0MODBOOK_EVENTS will be filled. The structure used is PIQPP_EV_EVBOOK_CXT:



Again this structure has one component only – EVENTBOOKINGS – that is a table with line type PIQPP_EV_EVBOOK:

ACADEMICWORKID Academic Work Identifier (GUID) (this is necessary as there can be more than one module booking in context 0MODBOOK_MODULES and via the ACADMICWORKID a relationship between a module booking and the event bookings belonging to it can be established in BRF expressions or actions)

OTYPE Object Type (this can be ‘E’ for Business Event or ‘EL’ for a Time-Independent Event)

OBJID Object ID

REVERSE General Indicator (this will be set if the event booking is reversed i.e. cancelled)

3.16. Event for Module Grading (0GRADING)

This event is triggered whenever grades and credits are maintained in the top appraisal for a module booking. The event will not be triggered when entering a grade for a conferred qualification (there is no event currently for that activity), for transferred academic work or when using the extended maintenance for academic work (own event is available in the two latter cases - 0ACADEMIC_WORK). The event will not contain any information about the appraisal details (i.e. about the so called sub-appraisals).

3.16.1 Activities

The related activity is AF01 Edit Appraisal.

3.16.2 Context The context header for this event is 0GRADING_CH and the structure used is again PIQPP_EV_CH.


3.16.2.1.1 0GRADING_TOP_APP_UPD

Context 0GRADING_TOP_APP_UPD contains information about the top appraisal stored together with the related module booking. The structure used is PIQAW_ACWORKK:

ACADEMICWORKID Academic Work Identifier (GUID)

AGRID Appraisal ID

AWOTYPE Object Type of Academic Work (this can only be ‘SM’ – Module for this event)

AWOBJID Object ID of Academic Work

AWBEGDATE Validity Start Date of Academic Work

AWENDDATE Validity End Date of Academic Work

AWLOCKFLAG Change Lock



AWSTATUS Academic Work Status

CANCELREASON Cancellation Reason

CANCELDATE Cancellation Date

BOOKDATE Booking Date

AWRATING Alternative Assessment Method for Academic Work

CHARGEFREE Free of Charge

TRANSFERFLAG External Academic Work or Qualification Transferred

EVENTPACKAGE Event Package



BOOKREASON Module Booking Reason

ANNULMENT Exclusion Indicator for Module Bookings

COBOK Conditional Booking

PRIOX Priority

AGRTYPE Appraisal Type

AGRSTAT Appraisal Status

GRADESYMBOL Grade Symbol

GRADE Std Value for Scale Value

GRADESCALE Academic Scale Identification (ID)

AGRNOTRATED Appraisal Grade Not Relevant

AGRDATE Appraisal Date

AGRCOMPLETED Appraisal Completed

CPATTEMP Attempted Credits

CPEARNED Earned Credits



CPGRADED Graded Credits

CPUNIT Unit of Measurement for Credits

AGRREMARK Appraisal Remark

AGRBEGDA Start of Appraisal Validity

AGRENDDA End of Appraisal Validity

ARCH_STATUS Appraisal Archiving Status

AWTEXT Additional Description for Academic Work

3.16.2.1.2 0GRADING_TOP_APP_BEF

This context contains information about the top appraisal and the related module bookings in their state prior to the activity that triggered the event. The structure used is the same as the one for context 0GRADING_TOP_APP_UPD.

3.17 Event for Academic Work (0ACADEMIC_WORK)

This event is triggered in two scenarios. The first one is equivalency determination: whenever an equivalency is released (and transfer academic work is created) or the release is cancelled (and the transfer academic work is deleted) event 0ACADEMIC_WORK will be triggered. The second scenario is the extended maintenance of academic work transaction PIQST10) – whenever academic work is edited there, the event will be triggered for every record. The event will be triggered for both module academic work (object type SM) and credited work (object type CW).

3.17.1 Activities

The following activities in Student Lifecycle Management can trigger event 0ACADEMIC_WORK:

• AW01 Create Acad. Work (Ext.Maint.Dialog)

• AW02 Change Acad. Work (Ext.Maint.Dialog)

• AW03 Delete Acad. Work (Ext.Maint.Dialog)

• ED01 Equivalency Determination (Create)

• ED02 Equivalency Determination (Change)

3.17.2 Context

The context header for this event is 0ACADEMIC_WORK_CH which uses again structure PIQPP_EV_CH.


3.17.2.1.1. 0ACADEMIC_WORK_UPD

This context contains information about the academic work record after it was updated by the activity that triggered the event. The structure used is PIQAW_ACWORKK which was already explained above.



3.17.2.1.2. 0ACADEMIC_WORK_BEF

This context contains information about the academic work record in the state prior to the execution of the activity that triggered the event. The structure used is PIQPI_ACWORK .

PIQPI_ACWORK includes structure PIQAW_ACWORKK and has two more components – PROGRAMTYPESBEF and PROGRAMSBEF. These are two tables which contain a list with the program type and program usages of the academic work record that existed before the activity was executed. The usages for program types and programs after the execution of the activity are not available immediately in the context 0ACADEMIC_WORK_UPD but must be read from the database if required for BRF actions and expressions.

3.18. Event for Program Type Progression (0PROGRESSION)

Event 0PROGRESSION is triggered whenever program type progression results are stored into the database. The event is triggered both by the program type progression report that is normally run in mass mode as well as when an individual’s student results are edited using the progression tab in the student file. One event will be triggered for the result in every program type/progression category of the student. If progression is executed for academic standing and progress classification at the same time, two separate events will be triggered. If results for all 5 available progression categories are calculated at the same time, 5 events will be triggered.

Whenever the program type progression calculates performance indexes, another event - 0PERFINDEX – is triggered that contains information about the new or updated performance indexes. These performance indexes are stored in an own database table.

3.18.1 Activities

The activities in Student Lifecycle Management that trigger event 0PROGRESSION are the following:

PG1A Program Type Progression

PG2M Program Type Progression (Manual)

PG3C Reset Program Type Progression

3.18.2 Context

The context header of the event is 0PROGRESSION_CH and again structure PIQPP_EV_CH is used.




3.18.2.1.1 0PROGRESSION_RES

This sub-context contains information about the progression result set. The previous value for the same program type and progression category – if available – is also filled in the context. The structure used is PIQPROG_GR_PROT_DETAIL:

PLVAR_ST Plan Version

OTYPE_ST Object Type

OBJID_ST Object ID

PROGC_VAR Program Type

PROG_TYPE Progression Category

PROCESSTYPE Execution Category Used in Progression

PROCESSTYPE_INT Internal Execution Category Used In Progression

EXECUTED Academic Prerequisite for Progression Fulfilled

BEF_RESULT Result Before Progression

BEF_RESULT_STAT Result Status Before Progression

AFT_RESULT Result After Progression

AFT_RESULT_STAT Result Status After Progression



CHECK_TO_INTERN Internal Check-To Date for Progression

VALID_FROM Valid-From Date for Progression Result

VALID_TO Valid-To Date for Progression Result

ACTIVITY Activity

PERYR Academic Year for Progression Result

PERID Academic Session for Progression Result

Only one new result for the same program type and progression category can be calculated per student at the same time.



3.18.2.1.2 0PROGRESSION_CANC

Whenever progression results are cancelled (activity PG3C), the context 0PROGRESSION_RES will contain only information about the student, the program type, progression category, the dates but no information on the previous values of progression results that were cancelled and no longer available in the database (progression was reset). Cancelled progression results are available for BRF expressions and actions in context 0PROGRESSION_CANC. Since more than one result for the same program type and progression category can be reset in one step, a structure is used - PIQPP_EV_PROG_R_CXT – which contains a component that is a table.

The line type of component REST_PROG_RESULTS is BAPIPROG_GROUP_RESULT:

PROGRAM_TYPE Program Type

PROGRESSION_CATEGORY Progression Category

PROGRESSION_RESULT Progression Result

PROGRESSION_RESULT_STATUS Result Status



VALID_FROM Valid-From Date for Progression Result

VALID_TO Valid-To Date for Progression Result

ACAD_YEAR Academic Year for Progression Result

ACAD_SESSION Academic Session for Progression Result



3.19 Event for Registration to Specializations (0SPECIALS)

Event 0SPECIALS is triggered by activities related to registration to specializations (‘major/minor bookings’).

3.19.1 Activities

The following activities are relevant for this event:

• CB01 Assign Acad. Specializations

• CB02 Change Acad. Specializations

• CB03 Cancel Acad. Specializations

3.19.2 Context

The header context for 0SPECIALS is 0SPECIALS_CH and again the referenced structure is PIQPP_EV_CH.


3.19.2.1.1 0SPECIALS_UPDT

The details are contained in context 0SPECIALS_UPDT which uses structure PIQPP_EV_SPEC_CXT.

The one component of structure PIQPP_EV_SPEC_CXT is PIQPP_EV_SPEC:

ACTIVITY Activity




MODULEGROUP_OBJECTID Module Group ID

MODULEGROUP_CATEGORY Module Group Category

BEGDA Start Date

ENDDA End Date

MODULEGROUP_PRIORITY Specialization Priority



STAGE_BEG Start of Stage

STAGE_END End of Stage

SPECBOOK_GUID Unique Key (GUID) for Specialization Booking

PREV_BEGDA Start Date

PREV_ENDDA End Date

PREV_MODULEGROUP_PRIORITY Specialization Priority

PREV_STAGE_BEG Start of Stage

PREV_STAGE_END End of Stage

If a new specialization is booked, the component ACTIVITY will be ‘CB01’ and the fields starting with PREV* will be empty. If a specialization is cancelled, the activity is ‘CB03’ and again the PREV* fields will be empty. If an existing specialization booking is changed (priority, time validity or stage assignment), the activity will be ‘CB02’ and the fields starting with PREV* will contain the data for that specialization booking prior to the execution of the activity.

3.20 Event for Event Bookings (0EVBOOKING)

Normally in Student Lifecycle Management business events will be booked or cancelled in the context of module bookings. In such cases BRF event 0MODBOOK will be triggered which also contains information about business event bookings. There is only one special use case in which a separate BRF event will be triggered: when an event offering is cancelled then all event bookings will be cancelled as well.

3.20.1 Activities

This event is not related to an Student Lifecycle Management activity.

3.20.2 Context

The header context is called 0EVBOOKING_CH and has the same structure as all other header contexts.

3.20.2.1. Sub-contexts



3.20.2.1.1 0EVBOOKING_UPD

The sub-context for this event is PIQPP_EV_EVBOOKING_CXT:

The last component INFTYTABLE is a table with line type PIQPP_EV_INFTY:

INFTY Infotype

RELAT_OBJTYPE Type of Related Object

RELAT_OBJID ID of Related Object

SUBTY Subtype

BEGDA Start Date

ENDDA End Date

UPDATE_MODE Update Indicator (Insert: I, Change: U, Delete: D)



4. Applications Using Post Processing A number of applications in Student Lifecycle Management use delivered post processing functionality. Customers can add more applications.

4.1 Integration Using XI

There are two scenarios where integration was made possible using post processing. They are

• Integration to Financial Aid Systems

• Integration to Learning Management Systems

Both the integrations used XI as the middle ware. The delivered content has the services sending the required data to the XI system. With the use of post processing it was possible to put the process related data to the services so that it could be then send to XI.

4.1.1 Integration to Financial Aid Systems

Financial Aid Systems mainly deal with the financial aid that the student gets while pursuing academic studies. These systems require the study details of the student to calculate the financial aid and carrying out their own processes. That means, Student Lifecycle Management and the Financial Aid systems must be integrated. Real time integration is the case when a process in SLCM results in a data change that needs to be replicated in the Financial Aid System. It is made possible using post processing.

For each process in Student Lifecycle Management, events are triggered. Events carry the process related data as context along with them. Actions are configured for these events as function modules. Those function modules get the data from the context and fill the XI services which send data to XI.

For example, when an admission is created, a notification is sent to XI system with the details of the admission creation.

You can go to transaction SXMB_MONI to see the details of the XML message that is send to XI system.



See the screen shot showing an admission record.

Admission for B.A.ENGL, Year 2007, Session 1,

Student is TAA, tester



Now in transaction SXMB_MONI, notification for StudyAdmissionCreateNotification_Out is received.

StudyAdmissionCreateNotification_Out



Details of the message are shown below

Click to get the document in detail

Notice the academic year and session and other details also

4,1.2 Integration to Learning Management Systems

Learning Management Systems (LMS) mainly deal with the content or the course material for students. These systems require details like the schedule of classes, the booking details, reservation of rooms etc. That means the SLcM and the Learning Management Systems must be integrated. Real time integration is the case when a process in Student Lifecycle Management results in a data change that needs to be replicated in the Learning Management Systems. It is made possible using post processing.

For example when an event (Object type E or EL) is created or changed, its schedule or course details are changed or a booking made to the course or class is changed or a new booking created, LMS should be informed about that. Events are triggered. Actions are configured for those events. Actions are function modules which take the context from the events and fill the XI service which sends the data to XI.

You can go to transaction SXMB_MONI to see the details of the XML message that is send to XI system.

4.1.3 Saving of Performance Index

Performance indices are calculated based on the academic work of a student. They are either grade averages (e.g. grade point averages) or numbers of units (e.g. credit totals per academic session or a number of modules booked.

Apart from a special usage in the audits functionality in Student Lifecycle Management and apart from activity documents for the program type progression, performance indices results were not stored in the database persistently and are always calculated dynamically like for example in the academic work overview or in correspondence forms.



In many processes like when a module booking is changed or when a grading is done or in extended maintenance the academic work is changed etc, saving of performance is required. Post processing is used to save the performance index as an activity once these processes are completed successfully.

All the above processes will trigger a BRF event. A BRF action is subscribed to this BRF event to update the relevant performance indices. In the BRF action the affected years and sessions as well as program types or programs and other values are derived in BaDI and used as parameters for the calculation of performance indices. A more complex scenario is when we wish to send notification to XI when a change in the performance index. To achieve this, after all performance indices are stored in the database, another BRF event will be triggered. To the event BRF actions are subscribed to distribute the performance indices to a third party system via XI.

• The program type progression will also store its performance indices together with the actual progression results.

• There is also be a mass report that can calculate and store performance indices assigned to a configurable context like program type, program, academic year and session. This report will also trigger a BRF event for every updated performance index.




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.

student lifecycle management business rule … lifecycle management business rule framework cookbook...

Documents