Student 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 2008 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1
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 3.1.2.1.2 0ADMISSION_BEF ...............................................................................................................................28 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.4 Event for Event Package Edited (0EVENTPACKAGE) ..........................................................................32

3.5 Event for Academic Event Edited (0ACADEMICEVENT).......................................................................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 3.8.2.1.3
0PROGREG_SGM_UPD ......................................................................................................................38 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 3.9.2.1.2 0PROGREREG_SES_UPD .................................................................................................................39 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 3.10.2.1.2 3.10.2.1.3 3.10.2.1.4 3.10.2.1.5 0PROGCHANGE_SES_CLD ...........................................................................................................40 0PROGCHANGE_SES_DLM ...........................................................................................................40 0PROGCHANGE_SGM_CLD ..........................................................................................................41 0PROGCHANGE_SES_NEW ..........................................................................................................41 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 3.11.2.1.2 3.11.2.1.3 3.11.2.1.4 3.11.2.1.5 0PROGDEREG_ATTR.....................................................................................................................42 0PROGDEREG_SGM_UPD.............................................................................................................42 0PROGDEREG_SES_CLD ..............................................................................................................42 0PROGDEREG_SES_DLM..............................................................................................................42 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 3.12.2.1.2 3.12.2.1.3 3.12.2.1.4 0REGIST_EXT_SES_INS ................................................................................................................44 0REGIST_EXT_SES_DEL ...............................................................................................................44 0REGIST_EXT_SGM_INS ...............................................................................................................44 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 3.15.2.1.2 3.15.2.1.3 0MODBOOK_CONTEXT..................................................................................................................47 0MODBOOK_MODULES .................................................................................................................48 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 Post-processing English Abbreviation Definition 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. 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. 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. 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. 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.
Business Rule Framework
Event
Action
Event context
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 onestep 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 PLVAR OTYPE OBJID MAIN_ACTIVITY REASON KEY_DATE KEY_TIME KEY_TIMEZONE REF_DOCID TIMESTAMP UNAME LOGSYSTEM
Description Plan Version Object type of activity reference object Object ID of activity reference object Activity Activity reason Activity key date (General) Time on activity key date Time zone of activity key date and time Reference activity identification key Time stamp of event User who triggered event 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.
Event Context
Data from expression
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 FLT_VAL IT_EXPRESSION IO_EVENT IO_ACTION
Type Importing Importing Importing Importing
Typing Method Type Type Type Ref To Type Ref To
Type BRF_FILTER_VALUE_ACT SBRF178A_T IF_EVENT_BRF 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 IMPORT_STATUS APPLCLASS ACTION VERSION EXEC_ON_FALSE EXEC_FUNCTION SEQUENCE EXPRESSION EXPRESSION_REF RESULT_VALUE RESULT_DATA RESULT_TYPE RESULT_LENGTH RESULT_CURRENCY RESULT_OUT_LEN RESULT_DECIMALS RESULT_DATA_MISSING RESULT_ERROR
Client BRF: Import Status BRF: Application Class Name of Action BRF: Version Execute Subaction if Function = False Action - Function to Be Executed Sequence Number BRF: Expression BRF: Expression Result
BRF: Result Type Field Length/Structure Length Currency Key Output Length Decimal Places for Type P Data Missing 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>. 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.
*-- Get the context header
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 RFCs.
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 dont 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 Value ' ' - Activate the post processing - 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 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. AD01 AD02 AD03 AD05 AD06 AD07 AD08 AD09 AD10 AD11 AD12 AD13 AD14 AD15 Create Admissions Application. Change Admissions Application. Delete Admissions Application. Execute Admission Reject Admissions Application Change Admission Change Rejected Admissions Application. Change of Program in Adm. Application Change of Program in Admissions Undo Rejected Admissions Application Undo Admission Withdraw Admission Application. Decline Offer of Admission Reverse Decision
3.1.2.1 Sub-contexts The sub contexts for 0ADMISSION_CH are 0ADMISSION_BEF 0ADMISSION_UPD
Sub contexts
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 PLVAR ST_OBJID CS_OBJID SC_OBJID BEGDA ENDDA ISTAT SEQNR Activity Plan Version Object ID of Student Object ID of Study Object (CS) Program ID Valid-From Date Valid-To Date Admission Application Status Number of Infotype Record With Same Key
.INCLUDE CHOICE_NO ADM_AYEAR ADM_PERID ADM_ACLEVEL ADM_PROGCLASS ADM_PARTT ADM_CATEG ADM_ENRCATEG ADM_CODE ADM_PERCT ADM_QMNUM ADM_STATUS_SUP ADM_DEC ADM_RECPT ADM_WITH_DECL ADM_GUID COKEY TIMEUNIT
Additional Relationship Data Program Choice Academic Year Academic Session Stage Progress Classification Indicator: Part-Time Study Admission Category Registration Type Admission Code Completed Length of Study Notification Number Status Supplement Decision Date of Rejection or Admission Date of Admission Application Receipt Date of Withdrawal or Declination Unique Key (GUID) of the Admission Correspondence key Time Unit for Program Duration
Context 0ADMISSION_BEF will be filled for the following activities AD02 AD03 AD07 AD08 AD09 AD10 Change Admission Application. Delete Admission Application. Change Admission Change Rejected Admission. Application. Change of Program in Adm. Application 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 AD02 AD05 AD06 AD07 AD08 AD09 AD10 AD11 AD12 AD13 AD14 AD15 Create Admission Application. Change Admission. Application. Execute Admission Reject Admission. Application. Change Admission Change Rejected Admission. Application. Change of Program in Adm. Application Change of Program in Admission Undo Rejected Admission Application Undo Admission Withdraw Admission. Application. Decline Offer of Admission 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 AGD_YEAR AGD_PERIOD AGD_SETMODE BEGDA ENDDA CS_OBJID 3.3. Event for Module Edited (0MODULE)
Anticipated Graduation Date Anticipated Graduation Year Anticipated Graduation Session Mode Used To Determine Anticipated Graduation Start Date End Date Object ID of Study Object (CS)
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_ID BEGINDATE ENDDATE UPDATE_MODE INFTYTABLE
Object Type Object ID Start Date End Date Update Mode for Business Object 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 U D C Business Object Created Business Object Changed Business Object Deleted 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 RELAT_OBJTYPE RELAT_OBJID SUBTY BEGDA ENDDA UPDATE_MODE Infotype Type of Related Object ID of Related Object Subtype Start Date End Date 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_TYPE OBJECT_ID
Object Type Object ID
BEGINDATE ENDDATE UPDATE_MODE INFTYTABLE
Start Date End Date Update Mode for Business Object Table type for Infotype Data
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_TYPE OBJECT_ID BEGINDATE ENDDATE UPDATE_MODE INFTYTABLE Object Type Object ID Start Date End Date Update Mode for Business Object Table type for Infotype Data
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 OBJECTID PLANVERSION FROM_DATE TO_DATE STATUS STATE
Object Type Object ID Plan Version Start Date End Date Status 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 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. Module booking changed Grading done Academic work is edited etc
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 PINDEX_TAB Object ID of Student 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 PINDEX_ID CALCPOINT_ID OBJID PLVAR TIMESTAMP CALC_DATE CALC_TIME CALC_TIMEZONE GUID GUIDTYPE ACAD_YEAR ACAD_SESSION PROGRAM_TYPE PROGRAM_ID PROGRESS_CAT CHECK_FROM CHECK_TO Action Executed for Performance Index (Fixed values: I & U) Performance Index GUID Calculation Point Object ID of Student Plan Version UTC time stamp in long form (YYYYMMDDhhmmss,mmmuuun) Date Time Time Zone UUID in character form Identifier Type (GUID) Academic Year Academic Session Program Type Program ID Progression Category Check-From Date for Progression Check-To Date for Progression
YYHAUPTFACH ACADPI_ID GRADESYM GRADE GRADESCALE ACPI_VALUE ACPI_UNIT ACADPI_DEGRELY GRADESYMBEF GRADEBEF GRADESCALEBEF ACPI_VALUEBEF ACPI_UNITBEF
Module Group ID Performance Index Grade Symbol Std Value for Scale Value Academic Scale Identification (ID) Value of Performance Index Unit of a Performance Index Result Degree of Performance Index Reliability Grade Symbol Std Value for Scale Value Academic Scale Identification (ID) Value of Performance Index 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 RA02 Initial Registration. 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.
3.8.2.1 Sub-contexts 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 STUDY_OBJECTID PROGRAM_OBJECTID BEGDA ENDDA STUDY_PRIORITY ACAD_YEAR ACAD_SESSION STAGE REGIST_DATE Object ID of Student Object ID of Study Object (CS) Program ID Start Date End Date Program Priority (In Period) Academic Year Academic Session Stage Activity Key Date for Sessional Registration
PARTTIME LEAVE_REASON COMPL_LENGTH_STUDY REGIST_TYPE DEGREE_SEEKING REGIST_STATUS REGIST_STATE REGIST_CLASS CANCEL_PROCESS CANCEL_REASON CANCEL_DATE
Indicator: Part-Time Study Leave of Absence Reason Completed Length of Study Registration Type Degree Seeking (Indicator) Sessional Registration Status Sessional Registration Status Specification Registration Classification Cancellation Activity (for Registration) Cancellation Reason (For Registration) 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.
STUDENT_OBJECTID STUDY_OBJECTID PROGRAM_OBJECTID BEGDA ENDDA BEG_PROCESS BEG_REASON BEG_KEY_DATE END_PROCESS
Object ID of Student Object ID of Study Object (CS) Program ID Start Date of Program Registration End Date of Program Registration Activity for Program Registration Activity Reason Activity Key Date for Start of Study Segment Activity for De-registration from Program
END_REASON END_KEY_DATE LAST_ATTENDANCE
De-registration Reason Activity Key Date of De-registration 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 RL01 RK02 RL02 RM03 RMS2 Sessional Registration Leave of Absence Change Sessional Registration Change Leave of Absence Cancel Sessional Registration 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 Sub-contexts 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 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 Sub-contexts 3.10.2.1.1 0PROGCHANGE_SES_CLD RQ01 Change of Program
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: 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 Sub-contexts RV01 RV02 RW01 RW02 RZ03 Dismissal From Program Change Dismissal Withdrawal from Program Change Withdrawal Cancel De-registration
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 MODULES_CANCELLED SEGMENT_CANCELLED 3.11.2.1.2 0PROGDEREG_SGM_UPD Checkbox Cancel Module Bookings Cancel Study Segment
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 Sub-contexts 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 students 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 Sub-contexts 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 PSOBTYP BUKRS DOCAMT DOCCUKY DUEDATE STOBJID Key for Period Assignment Contract Object Type Company Code Calculated Amount in Document Currency Document Currency Due Date Object ID of Student
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 students 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 Sub-contexts 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 PSOBTYP BUKRS DOCAMT DOCCUKY DUEDATE Key for Period Assignment Contract Object Type Company Code Calculated Amount in Document Currency Document Currency Due Date
AMODE GRANT_NBR STOBJID ACAD_YEAR ACAD_SESSION AID_STATUS
Grant Evaluation Mode Grant Object ID of Student Academic Year Academic Session 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 3.15.2 Context The context header for this event is 0MODBOOK_CH. 3.15.2.1 Sub-contexts 3.15.2.1.1 0MODBOOK_CONTEXT MB01 MB02 MB03 Create Module Booking Change Module Booking Cancel Module Booking
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 CONT_PROGRAMTYPE Module Booking Context (Program) Module Booking Context (Program Type)
CONT_PERYR CONT_PERID
Academic Year 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 ACTIVITY Academic Work Identifier (GUID) Activity (this can be MB01, MB02 or MB03, whereas the main activity in the header context will always be MB00) 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) Object Type of Academic Work (this will be only SM for this event) Object ID of Academic Work Validity Start Date of Academic Work Validity End Date of Academic Work Change Lock Academic Work Status Cancellation Reason
INS_OR_UPD
AWOTYPE AWOBJID AWBEGDATE AWENDDATE AWLOCKFLAG AWSTATUS CANCELREASON
CANCELDATE BOOKDATE AWRATING CHARGEFREE TRANSFERFLAG EVENTPACKAGE ACAD_SESSION ACAD_YEAR BOOKREASON ANNULMENT COBOK PRIOX CPATTEMP CPUNIT AWOTYPEBEF
Cancellation Date Booking Date Alternative Assessment Method for Academic Work Free of Charge External Academic Work or Qualification Transferred Event Package Academic Session Academic Year Module Booking Reason Exclusion Indicator for Module Bookings Conditional Booking Priority Attempted Credits Unit of Measurement for Credits 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) Object ID of Academic Work Validity Start Date of Academic Work Validity End Date of Academic Work Change Lock Academic Work Status Cancellation Reason Cancellation Date Booking Date
AWOBJIDBEF AWBEGDATEBEF AWENDDATEBEF AWLOCKFLAGBEF AWSTATUSBEF CANCELREASONBEF CANCELDATEBEF BOOKDATEBEF
AWRATINGBEF CHARGEFREEBEF TRANSFERFLAGBEF EVENTPACKAGEBEF ACAD_SESSIONBEF ACAD_YEARBEF BOOKREASONBEF ANNULMENTBEF COBOKBEF PRIOXBEF CPATTEMPBEF CPUNITBEF PROGRAMTYPESBEF
Alternative Assessment Method for Academic Work Free of Charge External Academic Work or Qualification Transferred Event Package Academic Session Academic Year Module Booking Reason Exclusion Indicator for Module Bookings Conditional Booking Priority Attempted Credits Unit of Measurement for Credits 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) Table Type for Program
PROGRAMSBEF 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) Object Type (this can be E for Business Event or EL for a Time-Independent Event) Object ID General Indicator (this will be set if the event booking is reversed i.e. cancelled)
OTYPE
OBJID REVERSE
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 Sub-contexts 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 AGRID AWOTYPE Academic Work Identifier (GUID) Appraisal ID Object Type of Academic Work (this can only be SM Module for this event) Object ID of Academic Work Validity Start Date of Academic Work Validity End Date of Academic Work Change Lock
AWOBJID AWBEGDATE AWENDDATE AWLOCKFLAG
AWSTATUS CANCELREASON CANCELDATE BOOKDATE AWRATING CHARGEFREE TRANSFERFLAG EVENTPACKAGE ACAD_SESSION ACAD_YEAR BOOKREASON ANNULMENT COBOK PRIOX AGRTYPE AGRSTAT GRADESYMBOL GRADE GRADESCALE AGRNOTRATED AGRDATE AGRCOMPLETED CPATTEMP CPEARNED
Academic Work Status Cancellation Reason Cancellation Date Booking Date Alternative Assessment Method for Academic Work Free of Charge External Academic Work or Qualification Transferred Event Package Academic Session Academic Year Module Booking Reason Exclusion Indicator for Module Bookings Conditional Booking Priority Appraisal Type Appraisal Status Grade Symbol Std Value for Scale Value Academic Scale Identification (ID) Appraisal Grade Not Relevant Appraisal Date Appraisal Completed Attempted Credits Earned Credits
CPGRADED CPUNIT AGRREMARK AGRBEGDA AGRENDDA ARCH_STATUS AWTEXT
Graded Credits Unit of Measurement for Credits Appraisal Remark Start of Appraisal Validity End of Appraisal Validity Appraisal Archiving Status 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: 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 Sub-contexts 3.17.2.1.1. 0ACADEMIC_WORK_UPD AW01 AW02 AW03 ED01 ED02 Create Acad. Work (Ext.Maint.Dialog) Change Acad. Work (Ext.Maint.Dialog) Delete Acad. Work (Ext.Maint.Dialog) Equivalency Determination (Create) Equivalency Determination (Change)
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 individuals 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 PG2M PG3C 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 Sub-contexts Program Type Progression Program Type Progression (Manual) Reset Program Type Progression
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 OTYPE_ST OBJID_ST PROGC_VAR PROG_TYPE PROCESSTYPE PROCESSTYPE_INT EXECUTED BEF_RESULT BEF_RESULT_STAT AFT_RESULT AFT_RESULT_STAT CHECK_FROM CHECK_TO CHECK_TO_INTERN VALID_FROM VALID_TO ACTIVITY PERYR PERID Plan Version Object Type Object ID Program Type Progression Category Execution Category Used in Progression Internal Execution Category Used In Progression Academic Prerequisite for Progression Fulfilled Result Before Progression Result Status Before Progression Result After Progression Result Status After Progression Check-From Date for Progression Check-To Date for Progression Internal Check-To Date for Progression Valid-From Date for Progression Result Valid-To Date for Progression Result Activity Academic Year for Progression Result 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 PROGRESSION_CATEGORY PROGRESSION_RESULT PROGRESSION_RESULT_STATUS CHECK_FROM CHECK_TO VALID_FROM VALID_TO ACAD_YEAR ACAD_SESSION Program Type Progression Category Progression Result Result Status Check-From Date for Progression Check-To Date for Progression Valid-From Date for Progression Result Valid-To Date for Progression Result Academic Year for Progression Result 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: 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 Sub-contexts 3.19.2.1.1 0SPECIALS_UPDT The details are contained in context 0SPECIALS_UPDT which uses structure PIQPP_EV_SPEC_CXT. CB01 CB02 CB03 Assign Acad. Specializations Change Acad. Specializations Cancel Acad. Specializations
The one component of structure PIQPP_EV_SPEC_CXT is PIQPP_EV_SPEC: ACTIVITY STUDENT_OBJECTID STUDY_OBJECTID PROGRAM_OBJECTID MODULEGROUP_OBJECTID MODULEGROUP_CATEGORY BEGDA ENDDA MODULEGROUP_PRIORITY Activity Object ID of Student Object ID of Study Object (CS) Program ID Module Group ID Module Group Category Start Date End Date Specialization Priority
STAGE_BEG STAGE_END SPECBOOK_GUID PREV_BEGDA PREV_ENDDA PREV_MODULEGROUP_PRIORITY PREV_STAGE_BEG PREV_STAGE_END
Start of Stage End of Stage Unique Key (GUID) for Specialization Booking Start Date End Date Specialization Priority Start of Stage 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 RELAT_OBJTYPE RELAT_OBJID SUBTY BEGDA ENDDA UPDATE_MODE Infotype Type of Related Object ID of Related Object Subtype Start Date End Date 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 Framework Cookbook

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Student Lifecycle Management Business Rule Framework Cookbook

Uploaded by

Copyright:

Available Formats

Student Lifecycle Management Business Rule Framework Cookbook

Company: SAP AG Created on: November 2008

SAP DEVELOPER NETWORK | sdn.sap.com 2008 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1