80c4cd46-6ba6-2b10-7198-ebb2d0f5650a
TRANSCRIPT
Student Lifecycle Management Business Rule Framework Cookbook
Applies to: All described functionality is based upon Student Lifecycle Management (SLCM) with ERP6 Enhancement Package 4 (EHP4).
For more information, visit the Higher Education & Research homepage.
Summary The purpose of this document is to describe how the business rule framework functionality can be used for automation of standard business processes in Student Lifecycle Management. This may concern follow-up activities or the enablement of integration scenarios across different system components.
Author: Student Lifecycle Management Development Team
Company: SAP AG
Created on: November 2008
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 1
Student Lifecycle Management Business Rule Framework Cookbook
Table of Contents Introduction .........................................................................................................................................................5 1. Glossary..........................................................................................................................................................6 2. Concept ..........................................................................................................................................................7
2.1. General Concept......................................................................................................................................7 2.2 Business Rule Framework ........................................................................................................................8
2.2.1 BRF Events.........................................................................................................................................................8 2.2.2 BRF Rules.........................................................................................................................................................12 2.2.2.1 BRF Expressions ...........................................................................................................................................15 2.2.2.2 BRF Actions ...................................................................................................................................................17
2.3. Error Handling........................................................................................................................................22 2.3.1 Application Log .................................................................................................................................................23 2.3.2 Event Rescheduling ..........................................................................................................................................25 2.3.3. Event Cancelled...............................................................................................................................................25
2.4 Switching ON/OFF Post Processing.......................................................................................................26 3. Events...........................................................................................................................................................27
3.1 Event for Admission (0ADMISSION) ......................................................................................................27 3.1.1 Activities............................................................................................................................................................27 3.1.2 Context..............................................................................................................................................................27 3.1.2.1 Sub-contexts ..................................................................................................................................................27 3.1.2.1.1 0ADMISSION_BEF ...............................................................................................................................28 3.1.2.1.2 0ADMISSION_UPD...............................................................................................................................30
3.2 Event for Anticipated Graduation Date (0ANTICGRAD) ........................................................................30 3.2.1 Activities............................................................................................................................................................30 3.2.2 Contexts............................................................................................................................................................30
3.3. Event for Module Edited (0MODULE)....................................................................................................31 3.3.1 Activities............................................................................................................................................................31 3.3.2 Contexts............................................................................................................................................................31
3.4 Event for Event Package Edited (0EVENTPACKAGE) ..........................................................................32 3.4.1 Activities............................................................................................................................................................32 3.4.2 Contexts............................................................................................................................................................32
3.5 Event for Academic Event Edited (0ACADEMICEVENT).......................................................................33 3.5.1 Activities............................................................................................................................................................33 3.5.2 Contexts............................................................................................................................................................33
3.6. Event for Status Indicators (0STATUSINDIC) .......................................................................................34 3.6.1 Activities............................................................................................................................................................34 Contexts.....................................................................................................................................................................34
3.7 Event for Performance Index Updated (0PERFINDEX) .........................................................................34 3.7.1 Activities............................................................................................................................................................34 3.7.2 Context..............................................................................................................................................................34
3.8 Event for Program Registration (0PROGREGIST) .................................................................................37 3.8.1 Activities............................................................................................................................................................37 3.8.2 Context..............................................................................................................................................................37 3.8.2.1 Sub-contexts ..................................................................................................................................................37 3.8.2.1.1 0PROGREG_SES_UPD .......................................................................................................................37
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 2
Student Lifecycle Management Business Rule Framework Cookbook
3.8.2.1.2 0PROGREG_SGM_UPD ......................................................................................................................38 3.8.2.1.3 0PROGREG_SGM_BEF.......................................................................................................................39
3.9 Event for Program Re-Registration (0PROGREREG)............................................................................39 3.9.1 Activities............................................................................................................................................................39 3.9.2 Context..............................................................................................................................................................39 3.9.2.1 Sub-contexts ..................................................................................................................................................39 3.9.2.1.1 0PROGREREG_SES_UPD .................................................................................................................39 3.9.2.1.2 0PROGREREG_SES_BEF...................................................................................................................39
3.10 Event for Change of Program (0PROGCHANGE)................................................................................40 3.10.1 Activities..........................................................................................................................................................40 3.10.2 Context............................................................................................................................................................40 3.10.2.1 Sub-contexts ................................................................................................................................................40 3.10.2.1.1 0PROGCHANGE_SES_CLD ...........................................................................................................40 3.10.2.1.2 0PROGCHANGE_SES_DLM ...........................................................................................................40 3.10.2.1.3 0PROGCHANGE_SGM_CLD ..........................................................................................................41 3.10.2.1.4 0PROGCHANGE_SES_NEW ..........................................................................................................41 3.10.2.1.5 0PROGCHANGE_SGM_NEW .........................................................................................................41
3.11 Event for Program De-Registration (0PROGDEREGIST) ....................................................................41 3.11.1 Activities..........................................................................................................................................................41 3.11.2 Context............................................................................................................................................................41 3.11.2.1 Sub-contexts ................................................................................................................................................41 3.11.2.1.1 0PROGDEREG_ATTR.....................................................................................................................42 3.11.2.1.2 0PROGDEREG_SGM_UPD.............................................................................................................42 3.11.2.1.3 0PROGDEREG_SES_CLD..............................................................................................................42 3.11.2.1.4 0PROGDEREG_SES_DLM..............................................................................................................42 3.11.2.1.5 0PROGDEREG_SGM_BEF .............................................................................................................42
3.12 Event for Extended Maintenance of Program Registration Data (0REGIST_EXT)..............................43 3.12.1 Activities..........................................................................................................................................................43 3.12.2 Context............................................................................................................................................................43 3.12.2.1 Sub-contexts ................................................................................................................................................44 3.12.2.1.1 0REGIST_EXT_SES_INS ................................................................................................................44 3.12.2.1.2 0REGIST_EXT_SES_DEL ...............................................................................................................44 3.12.2.1.3 0REGIST_EXT_SGM_INS ...............................................................................................................44 3.12.2.1.4 0REGIST_EXT_SGM_DEL ..............................................................................................................44
3.13 Events for Fee Calculation (0FEECALC_REAL and 0FEECALC_STAT) ............................................44 3.13.1 Activities..........................................................................................................................................................44 3.13.2 Context............................................................................................................................................................44 3.13.2.1 Sub-contexts ................................................................................................................................................45 3.13.2.1.1. 0FEECALC_REAL_DOC (0FEECALC_STAT_DOC).......................................................................45
3.14 Events for Financial Aid (0GRANTEVAL_DIS and 0GRANTEVAL_EXP) ...........................................46 3.14.1 Activities..........................................................................................................................................................46 3.14.2 Context............................................................................................................................................................46 3.14.2.1 Sub-contexts ................................................................................................................................................46 3.14.2.1.1 0GRANTEVAL_DIS_DOC (0GRANTEVAL_EXP_DOC)..................................................................46
3.15 Event for Module Booking (0MODBOOK) ............................................................................................47 3.15.1 Activities..........................................................................................................................................................47 3.15.2 Context............................................................................................................................................................47
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 3
Student Lifecycle Management Business Rule Framework Cookbook
3.15.2.1 Sub-contexts ................................................................................................................................................47 3.15.2.1.1 0MODBOOK_CONTEXT..................................................................................................................47 3.15.2.1.2 0MODBOOK_MODULES .................................................................................................................48 3.15.2.1.3 0MODBOOK_EVENTS.....................................................................................................................50
3.16. Event for Module Grading (0GRADING)..............................................................................................51 3.16.1 Activities..........................................................................................................................................................51 3.16.2 Context............................................................................................................................................................51 3.16.2.1 Sub-contexts ................................................................................................................................................51 3.16.2.1.1 0GRADING_TOP_APP_UPD...........................................................................................................51 3.16.2.1.2 0GRADING_TOP_APP_BEF....................................................................................................................53
3.17 Event for Academic Work (0ACADEMIC_WORK)................................................................................53 3.17.1 Activities..........................................................................................................................................................53 3.17.2 Context............................................................................................................................................................53 3.17.2.1 Sub-contexts ................................................................................................................................................53 3.17.2.1.1. 0ACADEMIC_WORK_UPD..............................................................................................................53 3.17.2.1.2. 0ACADEMIC_WORK_BEF ......................................................................................................................54
3.18. Event for Program Type Progression (0PROGRESSION) ..................................................................54 3.18.1 Activities..........................................................................................................................................................54 3.18.2 Context............................................................................................................................................................54 3.18.2.1 Sub-contexts ................................................................................................................................................54 3.18.2.1.1 0PROGRESSION_RES....................................................................................................................55 3.18.2.1.2 0PROGRESSION_CANC .........................................................................................................................56
3.19 Event for Registration to Specializations (0SPECIALS) .......................................................................57 3.19.1 Activities..........................................................................................................................................................57 3.19.2 Context............................................................................................................................................................57 3.19.2.1 Sub-contexts ................................................................................................................................................57 3.19.2.1.1 0SPECIALS_UPDT...................................................................................................................................57
3.20 Event for Event Bookings (0EVBOOKING) ..........................................................................................58 3.20.1 Activities..........................................................................................................................................................58 3.20.2 Context............................................................................................................................................................58 3.20.2.1. Sub-contexts ...............................................................................................................................................58 3.20.2.1.1 0EVBOOKING_UPD.................................................................................................................................59
4. Applications Using Post Processing .............................................................................................................60 4.1 Integration Using XI ................................................................................................................................60
4.1.1 Integration to Financial Aid Systems.................................................................................................................60 4,1.2 Integration to Learning Management Systems..................................................................................................63 4.1.3 Saving of Performance Index............................................................................................................................63
Copyright ..........................................................................................................................................................65
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 4
Student Lifecycle Management Business Rule Framework Cookbook
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
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 5
Student Lifecycle Management Business Rule Framework Cookbook
1. Glossary
English Term English Abbreviation
Definition
Post-processing The execution of automatic actions after an application finishes manipulating data. Such actions are related to the business context with which the main application is working, but they build a separate entity from a business and technical point of view.
Business Rule Framework
BRF The BRF is an event-controlled runtime environment for processing rules. You can assign any number of rules to each event, whereby a rule normally consists of a Boolean expression and an action. If the expression returns the value TRUE, the action is executed. The BRF also contains a maintenance environment in which you can edit and configure BRF objects. You can configure both technically oriented as well as business process oriented rules. This means that you configure the rules in the maintenance environment, and the rules are processed in the runtime environment.
Event An event is the (logical) location in a business process at which actions can be triggered. It is the link between the application and the actions to be executed. BRF events are those triggered using the BRF. Not to be confused with (business) events as used in Training and Event Management.
Action An action is the term for any manipulation of any data sets that makes sense from a business point of view and that can be performed technically. A BRF action is assigned to a BRF event and is executed whenever that event is triggered.
Event context The context contains information about the application that triggers the event. BRF events have context attached to them, which makes possible to implement business rules based on it.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 6
Student Lifecycle Management Business Rule Framework Cookbook
2. Concept The post processing functionality in Student Lifecycle Management enables customers to have configurable actions to be triggered on completion of different business processes in the SLCM system. Completion here means the process specific data is saved successfully in the system.
The focus is mainly on one-step actions that can be executed automatically at certain points. Such a one-step action can itself start some kind of process chain (e.g. start an integration scenario using XI or start a work flow, depending on the implementation of actions in customer systems).
2.1. General Concept
The post processing functionality is summarized in the following steps:
• SLCM system provides events for the business processes defined in the system. The triggered events contain the context relevant to the application or the process which triggered them.
• Customers create rules and attach them to the events. Rules contain expressions and actions. With expressions you create your own business check and decide whether it is required to trigger the attached action. If the outcome of the expression is true, your action will be executed. Actions are the activities that you want to perform once the business process is completed.
• You execute the business process and complete it. Completion means you saved the data successfully.
• The system then triggers the event which corresponds to the business process. This in turn calls the rules that you have defined for that event which in turn execute the action attached to the rule if the outcome of the expression is true. All this happens asynchronously in the background so that the user is not interrupted during the process. Once you are done with executing the process, you do not need to wait for the post processing actions to be executed but may go ahead with other activities in the system.
o Example: you create an admissions record for a student and wish to notify the responsible advisor. Creating the admissions record is the business process. Notifying the advisor is the related post processing action. When the user creates the admissions record and saves it, the system triggers the admissions event (0ADMISSION) and the rules defined for the events are executed.
• If the action executed was successful, you get an application log of the successful run. You can also drill down to the activity document for the process created.
• If the actions failed in execution, you get an error log. Some errors could be temporary, e.g. data base lock errors. The system offers the possibility to reschedule the event to a later time.
•
SLCM Process
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 7
Student Lifecycle Management Business Rule Framework Cookbook
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
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 8
Student Lifecycle Management Business Rule Framework Cookbook
• The object which triggered the event
• The process which triggered the events
• Administration details like user, time etc at which the event got triggered.
The context header is a structure of type PIQPP_EV_CH. As said above the structure has the elements listed in details below.
Component Description
PLVAR Plan Version
OTYPE Object type of activity reference object
OBJID Object ID of activity reference object
MAIN_ACTIVITY Activity
REASON Activity reason
KEY_DATE Activity key date (General)
KEY_TIME Time on activity key date
KEY_TIMEZONE Time zone of activity key date and time
REF_DOCID Reference activity identification key
TIMESTAMP Time stamp of event
UNAME User who triggered event
LOGSYSTEM Logical system
Detail contexts will be added to the context header as sub contexts. Depending on the event, detail contexts are delivered. The detail context contains the data before the process was executed and also the data after the save is done. The data in the context can be used for defining the expressions for rules and for defining the actions.
Go to transaction BRF. Search for objects in application class ISHERCM_PP.
Go to node All Groups->Events. Right click on event and go to Event Maintenance.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 9
Student Lifecycle Management Business Rule Framework Cookbook
See the following screen shot for details.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 10
Student Lifecycle Management Business Rule Framework Cookbook
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
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 11
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 12
Student Lifecycle Management Business Rule Framework Cookbook
See below the screen shot showing the configuration of rules to an event.
Rules for event
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 13
Student Lifecycle Management Business Rule Framework Cookbook
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
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 14
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 15
Student Lifecycle Management Business Rule Framework Cookbook
Below is an example where an expression is created to get the module booking context (program type). This context will be available with event 0MODBOOK.
Data from expression
Event Context
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 16
Student Lifecycle Management Business Rule Framework Cookbook
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
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 17
Student Lifecycle Management Business Rule Framework Cookbook
This screenshot shows how actions can be configured
Right click on actions node to create a new action
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 18
Student Lifecycle Management Business Rule Framework Cookbook
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 19
Action types, which can be set up. Double click to add the function module name or BAdI name etc.
Action Types
Student Lifecycle Management Business Rule Framework Cookbook
Function module name
Parameters to the function module (action)
• BAdI as Action:
You can create a BAdI implementation as an action. You need to implement BAdI BRF_ACTION and implement the method PROCESS.
The method PROCESS has the following parameters:
Component Type Typing Method Type
FLT_VAL Importing Type BRF_FILTER_VALUE_ACT
IT_EXPRESSION Importing Type SBRF178A_T
IO_EVENT Importing Type Ref To IF_EVENT_BRF
IO_ACTION Importing Type Ref To IF_ACTION_BRF
FLT_VAL is the filter value of your BAdI implementation.
IT_EXPRESSION will have the parameters passed from actions. See the screen shot above which shows the method of passing parameters to the action.
IT_EXPRESSION has the line type SBRF176A which has the structure shown below:
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 20
Student Lifecycle Management Business Rule Framework Cookbook
CLIENT Client
IMPORT_STATUS BRF: Import Status
APPLCLASS BRF: Application Class
ACTION Name of Action
VERSION BRF: Version
EXEC_ON_FALSE Execute Subaction if Function = False
EXEC_FUNCTION Action - Function to Be Executed
SEQUENCE Sequence Number
EXPRESSION BRF: Expression
EXPRESSION_REF BRF: Expression
RESULT_VALUE Result
RESULT_DATA
RESULT_TYPE BRF: Result Type
RESULT_LENGTH Field Length/Structure Length
RESULT_CURRENCY Currency Key
RESULT_OUT_LEN Output Length
RESULT_DECIMALS Decimal Places for Type P
RESULT_DATA_MISSING Data Missing
RESULT_ERROR SPACE = False, 'X' = True
The expressions are passed as parameters and you can evaluate these expressions in the actions. This is the best way to put your own business checks in the actions.
IO_EVENT is the event instance. You can get the context data associated with the event from this event instance.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 21
Student Lifecycle Management Business Rule Framework Cookbook
To get the context, you may use the following coding
DATA : lo_prog_event TYPE REF TO cl_event_context_base_brf.
*-- Cast to cl_event_context_base_brf to retrieve context
lo_prog_event ?= io_event. lv_brf_context = <context name>. *-- Get the context header CALL METHOD lo_prog_event->if_event_context_brf~get_context EXPORTING iv_context = lv_brf_context IMPORTING es_context_data = <context_data> EXCEPTIONS invalid_context = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 . ENDIF.
• Function Module as Action:
You can have a function module as an action. The function module should have a predefined interface as given below
*"---------------------------------------------------------------------- *"*"Local Interface: *" IMPORTING *" REFERENCE(IT_EXPRESSIONS) TYPE SBRF176A_T *" REFERENCE(IO_EVENT) TYPE REF TO IF_EVENT_BRF *" REFERENCE(IO_ACTION) TYPE REF TO IF_ACTION_BRF *" EXCEPTIONS *" TECHNICAL_ERROR *"----------------------------------------------------------------------
The parameters IT_EXPRESSIONS, IO_EVENT and IO_ACTION also serve the same purpose here as well.
Use IT_EXPRESSIONS to carry out business checks in the post processing activities and use IO_EVENT to get the context data associated with the event and to use it in the post processing activity.
The post processing framework takes care of execution of the actions attached to the event. As said above, it is based on the ‘all or nothing’ principle. If any of the actions assigned to the event is not successful, then all the other actions assigned to the same event are rolled back. So care must be taken that the actions you define do not COMMIT by themselves. The framework does the COMMIT WORK for all the actions. Otherwise it will create inconsistencies. This also means that all data base updates and other actions must be executed on commit work only.
2.3. Error Handling
If all of the actions associated with the triggered event are executed successfully, the system stores the trace in an application log.
As many actions can be configured for an event, it can happen that one of the actions ends up in error. The system then rolls back all actions and decides whether to reschedule the entire event again or not. Rescheduling means the event will be scheduled again to trigger after a gap of time. All the actions associated with the event will be executed again. The time for rescheduling is customizable. The decision to reschedule the event or not is taken from the errors that the system got while executing the actions. It is customizable which error will lead to rescheduling and which not. If the decision was not to reschedule the event, the errors are logged and visible in transaction SM58.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 22
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 23
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 24
Student Lifecycle Management Business Rule Framework Cookbook
See below the screen shot showing the activity document.
Details of activity
2.3.2 Event Rescheduling
If any of the action ends up in error, the framework decides whether to reschedule the event later or not. The decision is depending on the category of the error that you configured in the system. There are 3 error categories: • Error (E): the framework cancels the event. • Temporary Error (T): the framework reschedules the event. • Error that can be ignored (I): the framework ignores the message.
Error categories can be assigned to messages using the following activity in IMG node:
Student Lifecycle Management-> Student Lifecycle Processes->General Settings->Post Processing->Maintain Error Categories for Post Processing
2.3.3. Event Cancelled
If there are errors and the category of the errors are all E (permanent errors), the framework cancels the event. In that case the error log will be available in transaction SM58. This is the transaction to show the log of all transactional RFC’s.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 25
Student Lifecycle Management Business Rule Framework Cookbook
2.4 Switching ON/OFF Post Processing
It is not mandatory to use the post processing every time in the application. Situations could be, e.g., that you use post processing to update the changes from your system to another system. For example, updating admissions change details to a financial aid system through middle wares like XI. In such cases, at some point of time in the year you expect lots of frequent changes in the data and you don’t wish to update the other system about these new changes as these changes would again change later. Also, the cost incurred for updating the changes, are higher. In such cases you can switch off the post processing in customizing.
Go to IMG->Student Lifecycle Management-> Student Lifecycle Management Processes->General Settings->Post Processing->Activate Post Processing
For group POSTPROC and setting PPACTIVE, set either X or space.
Value X - Activate the post processing
Value ' ' - Deactivate the post processing
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 26
Student Lifecycle Management Business Rule Framework Cookbook
3. Events For each of the standard business process in Student Lifecycle Management, an event is delivered. Please see in subsequent chapters what each event offers.
3.1 Event for Admission (0ADMISSION)
3.1.1 Activities
The activities in Student Lifecycle Management that trigger event 0ADMISSION are
• AD01 Create Admissions Application.
• AD02 Change Admissions Application.
• AD03 Delete Admissions Application.
• AD05 Execute Admission
• AD06 Reject Admissions Application
• AD07 Change Admission
• AD08 Change Rejected Admissions Application.
• AD09 Change of Program in Adm. Application
• AD10 Change of Program in Admissions
• AD11 Undo Rejected Admissions Application
• AD12 Undo Admission
• AD13 Withdraw Admission Application.
• AD14 Decline Offer of Admission
• AD15 Reverse Decision
•
3.1.2 Context
The context associated with event 0ADMISSION is 0ADMISSION_CH. The context 0ADMISSION_CH is the context header and has a structure PIQPP_EV_CH. Context header has information about
• The object which triggered the event
• The activity which triggered the events
• Administrative details such as user, time, etc. at which the event was triggered.
3.1.2.1 Sub-contexts
The sub contexts for 0ADMISSION_CH are
• 0ADMISSION_BEF
• 0ADMISSION_UPD
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 27
Student Lifecycle Management Business Rule Framework Cookbook
3.1.2.1.1 0ADMISSION_BEF
Context 0ADMISSION_BEF contains the state of data before the activity was executed. The structure for 0ADMISSION_BEF is PIQPP_EV_ADM. Please see below for the contents.
ACTIVITY Activity
PLVAR Plan Version
ST_OBJID Object ID of Student
CS_OBJID Object ID of Study Object (CS)
SC_OBJID Program ID
BEGDA Valid-From Date
ENDDA Valid-To Date
ISTAT Admission Application Status
SEQNR Number of Infotype Record With Same Key
Sub contexts
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 28
Student Lifecycle Management Business Rule Framework Cookbook
.INCLUDE Additional Relationship Data
CHOICE_NO Program Choice
ADM_AYEAR Academic Year
ADM_PERID Academic Session
ADM_ACLEVEL Stage
ADM_PROGCLASS Progress Classification
ADM_PARTT Indicator: Part-Time Study
ADM_CATEG Admission Category
ADM_ENRCATEG Registration Type
ADM_CODE Admission Code
ADM_PERCT Completed Length of Study
ADM_QMNUM Notification Number
ADM_STATUS_SUP Status Supplement
ADM_DEC Decision Date of Rejection or Admission
ADM_RECPT Date of Admission Application Receipt
ADM_WITH_DECL Date of Withdrawal or Declination
ADM_GUID Unique Key (GUID) of the Admission
COKEY Correspondence key
TIMEUNIT Time Unit for Program Duration
Context 0ADMISSION_BEF will be filled for the following activities
• AD02 Change Admission Application.
• AD03 Delete Admission Application.
• AD07 Change Admission
• AD08 Change Rejected Admission. Application.
• AD09 Change of Program in Adm. Application
• AD10 Change of Program in Admission
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 29
Student Lifecycle Management Business Rule Framework Cookbook
3.1.2.1.2 0ADMISSION_UPD
Context 0ADMISSION_UPD has the state of data after the activity was executed. The structure for 0ADMISSION_UPD is PIQPP_EV_ADM. It is the same as for 0ADMISSION_BEF. Please see above.
Context 0ADMISSION_UPD will be filled for the following activities:
• AD01 Create Admission Application.
• AD02 Change Admission. Application.
• AD05 Execute Admission
• AD06 Reject Admission. Application.
• AD07 Change Admission
• AD08 Change Rejected Admission. Application.
• AD09 Change of Program in Adm. Application
• AD10 Change of Program in Admission
• AD11 Undo Rejected Admission Application
• AD12 Undo Admission
• AD13 Withdraw Admission. Application.
• AD14 Decline Offer of Admission
• AD15 Reverse Decision
3.2 Event for Anticipated Graduation Date (0ANTICGRAD)
When an anticipated graduation date is created, changed or reset for a student, event 0ANTICRAD is triggered.
3.2.1 Activities
The activities that trigger the event 0ANTICRAD are
• AGD1 - Create anticipated graduation data
Here you create a new record of anticipated graduation date
• AGD2 - Change anticipated graduation data
Here you change the record of anticipated graduation date to another date.
• AGD3 - Reset anticipated graduation data
Here you cancel the anticipated graduation date. That means the date is put to initial.
These are new activities created in the system.
3.2.2 Contexts
The context header of the event is 0ANTICGRAD_CH which is a structure of type PIQPP_EV_CH.
The context 0ANTICGRAD_CH has two sub contexts:
• 0ANTICGRAD_BEF
• 0ANTICGRAD_UPD
Both the sub contexts are of same structure of type PIQAGD_DATESEXT.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 30
Student Lifecycle Management Business Rule Framework Cookbook
0ANTICGRAD_BEF will be filled with the old record and 0ANTICGRAD_UPD will be filled with the new record. That means 0ANTICGRAD_BEF will be filled with values for activities AGD2 and AGD3. Context 0ANTICGRAD_UPD will be filled with values for activities AGD1 and AGD2.
Both details contexts have the structure given below
AGD_DATE Anticipated Graduation Date
AGD_YEAR Anticipated Graduation Year
AGD_PERIOD Anticipated Graduation Session
AGD_SETMODE Mode Used To Determine Anticipated Graduation
BEGDA Start Date
ENDDA End Date
CS_OBJID Object ID of Study Object (CS)
3.3. Event for Module Edited (0MODULE)
The event 0MODULE will be triggered when any attribute of the module is changed. That means if any Infotype or Infotype related data of HR PD object of type SM is created/changed/deleted, the event 0MODULE is triggered.
3.3.1 Activities
Any activity that leads to a change in the Infotypes of a module will trigger the event. For example you change the module attributes through module catalogue (transaction PIQ_ACCATLG).
3.3.2 Contexts
The context associated with event 0MODULE is 0MODULE_CH. It is a structure of type PIQPP_EV_CH. The context 0MODULE_CH has sub context 0MODULE_UPD.
The context 0MODULE_UPD has all details of the data changed for the module.
0MODULE_UPD is a structure of type PIQPP_EV_MODULE_CXT.
OBJECT_TYPE Object Type
OBJECT_ID Object ID
BEGINDATE Start Date
ENDDATE End Date
UPDATE_MODE Update Mode for Business Object
INFTYTABLE Table type for Infotype Data
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 31
Student Lifecycle Management Business Rule Framework Cookbook
The context will have information about the object type (here SM), ID of the object (here module ID), validity period of the object, update mode and the table of Infotypes.
The update mode has fixed values –
I Business Object Created
U Business Object Changed
D Business Object Deleted
C Business Object Cancelled.
C is relevant for objects like E where we can cancel the events.
The table of Infotype has lines which are of type PIQPP_EV_INFTY.
INFTY Infotype
RELAT_OBJTYPE Type of Related Object
RELAT_OBJID ID of Related Object
SUBTY Subtype
BEGDA Start Date
ENDDA End Date
UPDATE_MODE Update Indicator (Insert: I, Change: U, Delete: D)
As mentioned above in the table, the record will have information about the Infotype record changed.
3.4 Event for Event Package Edited (0EVENTPACKAGE)
The event 0EVENTPACKAGE is triggered when any attribute of the event package is changed. That means if any Infotype or Infotype related data of HR PD object of type SE is created/changed/deleted, the event 0EVENTPACKAGE is triggered.
3.4.1 Activities
Any activity that leads to a change in the Infotypes of event packages, will trigger the event. For example you change the event package attributes through the event planning screen (transaction PIQACADOFFER00).
3.4.2 Contexts
The context associated with event 0EVENTPACKAGE is 0EVENTPACKAGE_CH. It is a structure of type PIQPP_EV_CH. The context 0EVENTPACKAGE_CH has sub context 0EVENTPACKAGE_UPD.
The context 0EVENTPACKAGE_UPD has all details of the data changed for the event package.
0EVENTPACKAGE_UPD is a structure of type PIQPP_EV_EVENTPACKAGE_CXT.
The structure is similar to the context for event ‘Module Edited’. The structure details are given below.
OBJECT_TYPE Object Type
OBJECT_ID Object ID
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 32
Student Lifecycle Management Business Rule Framework Cookbook
BEGINDATE Start Date
ENDDATE End Date
UPDATE_MODE Update Mode for Business Object
INFTYTABLE 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 Type
OBJECT_ID Object ID
BEGINDATE Start Date
ENDDATE End Date
UPDATE_MODE Update Mode for Business Object
INFTYTABLE Table type for Infotype Data
The field INFTYTABLE is a table of line type PIQPP_EV_INFTY.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 33
Student Lifecycle Management Business Rule Framework Cookbook
3.6. Event for Status Indicators (0STATUSINDIC)
3.6.1 Activities
You can activate or deactivate holds or customer statuses through the student file. These will trigger the event. The activity is HSMA.
Contexts
The context associated with the event is 0STATUSINDIC_CH. The context 0STATUSINDIC_CH is a structure of type PIQPP_EV_CH. It has a sub context 0STATUSINDIC_DET. The context 0STATUSINDIC_DET has the information about the status indicators that are being currently updated in active or inactive state.
The context 0STATUSINDIC_DET is a structure of type PIQPP_EV_HS_CXT.
It is a table containing the info about the indicators.
The table has a line type BAPISTUDENT_STATIND. The details of the structure is given below
OTYPE Object Type
OBJECTID Object ID
PLANVERSION Plan Version
FROM_DATE Start Date
TO_DATE End Date
STATUS Status
STATE Status Specification
3.7 Event for Performance Index Updated (0PERFINDEX)
Whenever the performance indices for a student are created or updated the event 0PERFINDEX is triggered. When a module booking is changed or when grading is done or academic work is changed, the performance indices for the student are affected. Performance Indices are calculated and are created/ updated in the database. This triggers the event 0PERFINDEX.
3.7.1 Activities
Any activity that affects the performance indices of a student will trigger event 0PERFINDEX. For example
• Module booking changed
• Grading done
• Academic work is edited etc
3.7.2 Context
The event 0PERFINDEX carries context 0PERFINDEX_CH as main context (Context header). Context 0PERFINDEX_CH is a structure of type PIQPP_EV_CH.
It has context 0PERFINDEX_UPD as the sub context.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 34
Student Lifecycle Management Business Rule Framework Cookbook
Context 0PERFINDEX_UPD has all data related to the created/updated performance indices. 0PERFINDEX_UPD is a structure of type PIQPI_BRF_CONTEXT.
The structure is shown below in detail:
STOBJID Object ID of Student
PINDEX_TAB Performance Index ( BRF Context )
It has the information of the student for whom the performance index is saved and also a table PINDEX_TAB containing the info related to the created/updated performance indices.
PINDEX_TAB is a table of line type PIQPI_PINDEX_BRF. Details of PIQPI_PINDEX_BRF are given below:
PINDEX_ACTION Action Executed for Performance Index (Fixed values: I & U)
PINDEX_ID Performance Index GUID
CALCPOINT_ID Calculation Point
OBJID Object ID of Student
PLVAR Plan Version
TIMESTAMP UTC time stamp in long form (YYYYMMDDhhmmss,mmmuuun)
CALC_DATE Date
CALC_TIME Time
CALC_TIMEZONE Time Zone
GUID UUID in character form
GUIDTYPE Identifier Type (GUID)
ACAD_YEAR Academic Year
ACAD_SESSION Academic Session
PROGRAM_TYPE Program Type
PROGRAM_ID Program ID
PROGRESS_CAT Progression Category
CHECK_FROM Check-From Date for Progression
CHECK_TO Check-To Date for Progression
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 35
Student Lifecycle Management Business Rule Framework Cookbook
YYHAUPTFACH Module Group ID
ACADPI_ID Performance Index
GRADESYM Grade Symbol
GRADE Std Value for Scale Value
GRADESCALE Academic Scale Identification (ID)
ACPI_VALUE Value of Performance Index
ACPI_UNIT Unit of a Performance Index Result
ACADPI_DEGRELY Degree of Performance Index Reliability
GRADESYMBEF Grade Symbol
GRADEBEF Std Value for Scale Value
GRADESCALEBEF Academic Scale Identification (ID)
ACPI_VALUEBEF Value of Performance Index
ACPI_UNITBEF Unit of a Performance Index Result
The field PINDEX_ACTION indicates whether the Performance index is created or updated in the database.
In case of an update, the structure also gives information about the value of the old performance index. All fields with suffix BEF will have the information about the old performance index. They are:
GRADESYMBEF
GRADEBEF
GRADESCALEBEF
ACPI_VALUEBEF
ACPI_UNITBEF
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 36
Student Lifecycle Management Business Rule Framework Cookbook
3.8 Event for Program Registration (0PROGREGIST)
The event 0PROGREGIST is triggered by the activities related to initial program registration so that one sessional registration record as well as one study segment is involved.
3.8.1 Activities
The activities in Student Lifecycle Management that trigger event 0PROGREGIST are
• RA01 Initial Registration.
• RA02 Extend Study Segment.
3.8.2 Context
The context associated with event 0PROGREGIST is 0PROGREG_CH. The context 0PROGREG_CH is the context header and has a structure PIQPP_EV_CH which is explained above.
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 Object ID of Student
STUDY_OBJECTID Object ID of Study Object (CS)
PROGRAM_OBJECTID Program ID
BEGDA Start Date
ENDDA End Date
STUDY_PRIORITY Program Priority (In Period)
ACAD_YEAR Academic Year
ACAD_SESSION Academic Session
STAGE Stage
REGIST_DATE Activity Key Date for Sessional Registration
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 37
Student Lifecycle Management Business Rule Framework Cookbook
PARTTIME Indicator: Part-Time Study
LEAVE_REASON Leave of Absence Reason
COMPL_LENGTH_STUDY Completed Length of Study
REGIST_TYPE Registration Type
DEGREE_SEEKING Degree Seeking (Indicator)
REGIST_STATUS Sessional Registration Status
REGIST_STATE Sessional Registration Status Specification
REGIST_CLASS Registration Classification
CANCEL_PROCESS Cancellation Activity (for Registration)
CANCEL_REASON Cancellation Reason (For Registration)
CANCEL_DATE Cancellation Date (Registration)
This context is filled by both activities triggering the event – RA01 and RA02.
3.8.2.1.2 0PROGREG_SGM_UPD
This context contains information about the study segment created with the initial registration by activity RA01 or updated, i.e. its technical validity was extended forward by activity RA02. The latter is possible only in the US mode for module booking whenever a sessional registration is created before the start date of the previously existing study segment. The structure used for the context is PIQRFC_STUDYSEGMENTS.
STUDENT_OBJECTID Object ID of Student
STUDY_OBJECTID Object ID of Study Object (CS)
PROGRAM_OBJECTID Program ID
BEGDA Start Date of Program Registration
ENDDA End Date of Program Registration
BEG_PROCESS Activity for Program Registration
BEG_REASON Activity Reason
BEG_KEY_DATE Activity Key Date for Start of Study Segment
END_PROCESS Activity for De-registration from Program
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 38
Student Lifecycle Management Business Rule Framework Cookbook
END_REASON De-registration Reason
END_KEY_DATE Activity Key Date of De-registration
LAST_ATTENDANCE Last Day of Attendance
3.8.2.1.3 0PROGREG_SGM_BEF
This context contains information about the previously existing study segment of the student for the program of study. 0PROGREG_SGM_BEF will be only filled for activity RA02 where the extended study segment is available for comparison in context 0PROGREG_SGM_UPD.
0PROGREG_SGM_BEF has also structure PIQRFC_STUDYSEGMENTS
3.9 Event for Program Re-Registration (0PROGREREG)
Event 0PROGREREG is triggered by activities related to program re-registration that create, change or cancel a sessional registration of a leave of absence. In this case only one sessional registration record is involved.
3.9.1 Activities
The activities in Student Lifecycle Management that trigger event 0PROGREGIST are
• RK01 Sessional Registration
• RL01 Leave of Absence
• RK02 Change Sessional Registration
• RL02 Change Leave of Absence
• RM03 Cancel Sessional Registration
• RMS2 Change Cancellation (Sess. Registration)
3.9.2 Context
The context header associated with event 0PROGREREG is 0PROGREG_CH and references structure PIQPP_EV_CH which is explained above.
3.9.2.1 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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 39
Student Lifecycle Management Business Rule Framework Cookbook
3.10 Event for Change of Program (0PROGCHANGE)
This event is triggered by activities related to change of program so that registration data from two programs is involved – the ‘old’ program the student is being deregistered from and the ‘new’ program the student is transferring to. The following data is involved in particular:
- one or more sessional registrations at the old program of study of the student (if they are cancelled at the date of the program change)
- the study segment at the old program that is delimited at the date of the program change
- one sessional registration that can be created for the new program of study or several sessional registrations that are transferred from the old to the new program of study. It is also possible to execute a change of program without creating a new sessional registration at first at all
- the study segment created for the new program
-
3.10.1 Activities
This event is triggered by activity • RQ01 Change of Program
3.10.2 Context
The context header associated with event 0PROGCHANGE is 0PROGCHANGE_CH and references structure PIQPP_EV_CH which is explained above.
3.10.2.1 Sub-contexts
3.10.2.1.1 0PROGCHANGE_SES_CLD
In this context, information about cancelled sessional registrations for the old program of study is available. The change of program is valid from a selected key date onwards. Any sessional registrations for the old program of study valid after this key date are cancelled.
The structure used for this context is PIQPP_EV_SESR_CXT. This structure itself contains one complex field only which references a table type with line type PIQRFC_SESS_REGISTS (see screenshot below).
Structure PIQRFC_SESS_REGISTS which is used for holding information about sessional registrations is already explained above.
The context is empty if the date of the change of program is after the last sessional registration for the old program.
3.10.2.1.2 0PROGCHANGE_SES_DLM
If the key date for the change of program falls within an academic session for which the student was registered at the old program of study, the sessional registration for that particular session is split in two at the key date. The part starting after the key date is cancelled and will be available in the context 0PROGCHANGE_SES_CLD. The part ending right before the key date is available in context
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 40
Student Lifecycle Management Business Rule Framework Cookbook
0PROGCHANGE_SES_DLM. This part is still an active sessional registration but was delimited at the date of the program change minus one day.
The structure for context 0PROGCHANGE_SES_DLM is flat as only one sessional registration can be delimited at most and has structure PIQRFC_SESS_REGISTS.
This context will be filled only if that particular data constellation occurs, otherwise it is empty.
3.10.2.1.3 0PROGCHANGE_SGM_CLD
This context contains the study segment at the old program of study that was delimited by the change of program. The structure used is PIQRFC_STUDYSEGMENTS (see above). This context will be always filled.
3.10.2.1.4 0PROGCHANGE_SES_NEW
This context contains information about the sessional registrations that were created for the new program of study. The number of records may be:
- zero if no sessional registration was created. The student is only transferred to the new program;
- one, if the option was selected to create one initial sessional registration for the new program of study;
- any number, if the option was selected to transfer sessional registrations that were cancelled at the old program of study to the new program of study. This is possible only if the two programs of study use the same years, sessions and academic stages.
The context uses structure PIQPP_EV_SESR_CXT which is already explained above.
3.10.2.1.5 0PROGCHANGE_SGM_NEW
This context contains information about the study segment created for the new program of study and refers to structure PIQRFC_STUDYSEGMENTS.
3.11 Event for Program De-Registration (0PROGDEREGIST)
This event is triggered by activities in Student Lifecycle Management related to de-registering students from a program of study.
3.11.1 Activities
The activities triggering the event in particular are:
• RV01 Dismissal From Program
• RV02 Change Dismissal
• RW01 Withdrawal from Program
• RW02 Change Withdrawal
• RZ03 Cancel De-registration
3.11.2 Context
The context header associated with event 0PROGDERGIST is 0PROGDEREG_CH which references structure PIQPP_EV_CH as explained above.
3.11.2.1 Sub-contexts
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 41
Student Lifecycle Management Business Rule Framework Cookbook
3.11.2.1.1 0PROGDEREG_ATTR
This contexts contains the options chosen for the deregistration activity – shall an alumnus relationship be created, shall module bookings be cancelled or shall the study segment be cancelled altogether (instead of being just delimited at a specified deregistration date). The structure used is PIQPP_EV_DEREG_CXT:
ALUMNUS_RELAT_CREATED Checkbox
MODULES_CANCELLED Cancel Module Bookings
SEGMENT_CANCELLED Cancel Study Segment
3.11.2.1.2 0PROGDEREG_SGM_UPD
This context contains information about the study segment that was changed by the activity. The study segment might be delimited by activities RV01 or RW01. It may be changed by activity RV02 and RW02 (here only the key date and the de-registration date can be changed actually). The validity of the study segment can also be extended to 31.12.9999 by activity RZ03 if it was previously delimited by an earlier deregistration activity.
The structure used for that context is PIQRFC_STUDYSEGMENTS.
3.11.2.1.3 0PROGDEREG_SES_CLD
This context contains information about sessional registrations cancelled after the de-registration date. The context uses structure PIQPP_EV_SESR_CXT which is explained above.
3.11.2.1.4 0PROGDEREG_SES_DLM
This context contains information only if a sessional registration is split into two parts by the de-registration date – the fist part remains active but is delimited at the date of deregistration, the second part (valid after this date) is cancelled. The structure used is PIQRFC_SESS_REGISTS. This is similar to context 0PROGCHANGE_SES_DLM explained above.
3.11.2.1.5 0PROGDEREG_SGM_BEF
This context is the counterpart of 0PROGDEREG_SGM_UPD and is filled with the study segment that existed before the activity was executed. The structure used is PIQRFC_STUDYSEGMENTS.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 42
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 43
Student Lifecycle Management Business Rule Framework Cookbook
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 student’s contract account and a second one, whenever statistical FICA documents are posted. The contexts of the two events are therefore identical and only the names differ.
A fee calculation run itself will not trigger any of these two events – only when FICA documents are posted (new fees or delta posting) will one of the events be triggered as appropriate.
3.13.1 Activities These two events are triggered by activity AC00 Calculate Tuition Fees. This may be the case when the fee calculation is executed for an individual student or the ee calculation report is run in mass mode.
3.13.2 Context The context header associated with event is 0FEECALC_REAL_CH which references structure PIQPP_EV_CH as explained above. The context header associated with event 0FEECALC_STAT is 0FEECALC_STAT_CH.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 44
Student Lifecycle Management Business Rule Framework Cookbook
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 Key for Period Assignment
PSOBTYP Contract Object Type
BUKRS Company Code
DOCAMT Calculated Amount in Document Currency
DOCCUKY Document Currency
DUEDATE Due Date
STOBJID 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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 45
Student Lifecycle Management Business Rule Framework Cookbook
3.14 Events for Financial Aid (0GRANTEVAL_DIS and 0GRANTEVAL_EXP)
The financial aid evaluation report can trigger two events:
• 0GRANTEVAL_DIS is raised whenever actual disbursements are posted to student’s contract account (real postings)
• 0GRANTEVAL_EXP is raised whenever expected financial aid is posted (statistical postings)
Technically both events are very similar and will be presented together.
3.14.1 Activities
The activity triggering these two events is AC01 Calculate Financial Aid. The events will be triggered whenever the financial aid evaluation report is run for individual students or in mass mode.
3.14.2 Context
The context header associated with event 0GRANTEVAL_DIS is 0GRANTEVAL_DIS_CH and the one associated with 0GRANTEVAL_EXP is 0GRANTEVAL_EXP_CH. Both context headers have structure PIQPP_EV_CH.
3.14.2.1 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 Key for Period Assignment
PSOBTYP Contract Object Type
BUKRS Company Code
DOCAMT Calculated Amount in Document Currency
DOCCUKY Document Currency
DUEDATE Due Date
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 46
Student Lifecycle Management Business Rule Framework Cookbook
AMODE Grant Evaluation Mode
GRANT_NBR Grant
STOBJID Object ID of Student
ACAD_YEAR Academic Year
ACAD_SESSION Academic Session
AID_STATUS Grant Status
The second component contains the ID of the grant document (this is not the posted FICA document but the grant documents used by Student Lifecycle Management in addition to the FICA documents and stored in tables TCMACGRHD and TCMACGRIT).
3.15 Event for Module Booking (0MODBOOK)
Event 0MODBOOK is triggered by activities in Student Lifecycle Management related to module booking – module bookings and cancellation of module bookings. Related event bookings are also part of the event context. There are two other events that are also triggered whenever academic work is changed but in different scenarios – see below for events 0ACADEMIC_WORK (triggered by extended maintenance of academic work and equivalency determination) and 0GRADING (triggered by grading).
Event 0MODBOOK will be triggered both after saving the data in the module booking dialog in the student file as well as when using RFC function module HRIQ_STUDENT_BOOKING. The event will not be triggered currently if a module booking or the where-used lists related to it are maintained in transaction PP01.
In the context of this event more than one module booking (and more than one event bookings) can be found as often several modules will be booked together.
3.15.1 Activities
The main activity triggering this event is MB00 Module Booking. There is also an activity derived per module booking (as there can be several in the context of the event – see below). These activities can be
• MB01 Create Module Booking
• MB02 Change Module Booking
• MB03 Cancel Module Booking
3.15.2 Context
The context header for this event is 0MODBOOK_CH.
3.15.2.1 Sub-contexts
3.15.2.1.1 0MODBOOK_CONTEXT
This context contains information about the program type and/or program selected as module booking context, as well as the academic year and session for all the bookings. The structure used is PIQMRCONTEXT:
CONT_PROGRAM Module Booking Context (Program)
CONT_PROGRAMTYPE Module Booking Context (Program Type)
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 47
Student Lifecycle Management Business Rule Framework Cookbook
CONT_PERYR Academic Year
CONT_PERID Academic Session
When the event is triggered there is no information yet available about the where-used lists that are created asynchronously after the module bookings are saved. If the module context contained in this structure does not suffice to program a BRF action or expression, the where-used lists can be read from the database additionally.
3.15.2.1.2 0MODBOOK_MODULES
This context contains information about the module bookings themselves. There can be one or more module bookings of the same student if they are stored together in a single step (logical unit of work).
The structure used for the context is PIQPP_EV_MODBOOK_CXT. This structure has one component only (MODULEBOOKINGS) which is a table with line type PIQPP_EV_MODBOOK:
ACADEMICWORKID Academic Work Identifier (GUID)
ACTIVITY Activity (this can be MB01, MB02 or MB03, whereas the main activity in the header context will always be MB00)
INS_OR_UPD Single-Character Flag (‘I’ for new record and ‘U’ for an updated record, i.e. the module booking existed previously and was changed in some way. Only in the latter case will the fields ending with *BEF in structure PIQPP_EV_MODBOOK will be filled)
AWOTYPE Object Type of Academic Work (this will be only ‘SM’ for this event)
AWOBJID Object ID of Academic Work
AWBEGDATE Validity Start Date of Academic Work
AWENDDATE Validity End Date of Academic Work
AWLOCKFLAG Change Lock
AWSTATUS Academic Work Status
CANCELREASON Cancellation Reason
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 48
Student Lifecycle Management Business Rule Framework Cookbook
CANCELDATE Cancellation Date
BOOKDATE Booking Date
AWRATING Alternative Assessment Method for Academic Work
CHARGEFREE Free of Charge
TRANSFERFLAG External Academic Work or Qualification Transferred
EVENTPACKAGE Event Package
ACAD_SESSION Academic Session
ACAD_YEAR Academic Year
BOOKREASON Module Booking Reason
ANNULMENT Exclusion Indicator for Module Bookings
COBOK Conditional Booking
PRIOX Priority
CPATTEMP Attempted Credits
CPUNIT Unit of Measurement for Credits
AWOTYPEBEF Object Type of Academic Work (all fields ending with *BEF will be filled for module bookings that existed prior to the activity triggering the event – field INS_OR_UPD in this structure will be ‘U’ like ‘Updated’)
AWOBJIDBEF Object ID of Academic Work
AWBEGDATEBEF Validity Start Date of Academic Work
AWENDDATEBEF Validity End Date of Academic Work
AWLOCKFLAGBEF Change Lock
AWSTATUSBEF Academic Work Status
CANCELREASONBEF Cancellation Reason
CANCELDATEBEF Cancellation Date
BOOKDATEBEF Booking Date
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 49
Student Lifecycle Management Business Rule Framework Cookbook
AWRATINGBEF Alternative Assessment Method for Academic Work
CHARGEFREEBEF Free of Charge
TRANSFERFLAGBEF External Academic Work or Qualification Transferred
EVENTPACKAGEBEF Event Package
ACAD_SESSIONBEF Academic Session
ACAD_YEARBEF Academic Year
BOOKREASONBEF Module Booking Reason
ANNULMENTBEF Exclusion Indicator for Module Bookings
COBOKBEF Conditional Booking
PRIOXBEF Priority
CPATTEMPBEF Attempted Credits
CPUNITBEF Unit of Measurement for Credits
PROGRAMTYPESBEF Table Type for Program Type (in this and the last field of the structure the where-used lists are contained in their state before the activity that triggered the event was executed. The current state must be read from the database if necessary – see the explanation for this in the chapter for the context 0MODBOOK_CONTEXT above)
PROGRAMSBEF Table Type for Program
3.15.2.1.3 0MODBOOK_EVENTS
If any event were booked or cancelled together with a module booking, context 0MODBOOK_EVENTS will be filled. The structure used is PIQPP_EV_EVBOOK_CXT:
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 50
Student Lifecycle Management Business Rule Framework Cookbook
Again this structure has one component only – EVENTBOOKINGS – that is a table with line type PIQPP_EV_EVBOOK:
ACADEMICWORKID Academic Work Identifier (GUID) (this is necessary as there can be more than one module booking in context 0MODBOOK_MODULES and via the ACADMICWORKID a relationship between a module booking and the event bookings belonging to it can be established in BRF expressions or actions)
OTYPE Object Type (this can be ‘E’ for Business Event or ‘EL’ for a Time-Independent Event)
OBJID Object ID
REVERSE General Indicator (this will be set if the event booking is reversed i.e. cancelled)
3.16. Event for Module Grading (0GRADING)
This event is triggered whenever grades and credits are maintained in the top appraisal for a module booking. The event will not be triggered when entering a grade for a conferred qualification (there is no event currently for that activity), for transferred academic work or when using the extended maintenance for academic work (own event is available in the two latter cases - 0ACADEMIC_WORK). The event will not contain any information about the appraisal details (i.e. about the so called sub-appraisals).
3.16.1 Activities
The related activity is AF01 Edit Appraisal.
3.16.2 Context The context header for this event is 0GRADING_CH and the structure used is again PIQPP_EV_CH.
3.16.2.1 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 Academic Work Identifier (GUID)
AGRID Appraisal ID
AWOTYPE Object Type of Academic Work (this can only be ‘SM’ – Module for this event)
AWOBJID Object ID of Academic Work
AWBEGDATE Validity Start Date of Academic Work
AWENDDATE Validity End Date of Academic Work
AWLOCKFLAG Change Lock
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 51
Student Lifecycle Management Business Rule Framework Cookbook
AWSTATUS Academic Work Status
CANCELREASON Cancellation Reason
CANCELDATE Cancellation Date
BOOKDATE Booking Date
AWRATING Alternative Assessment Method for Academic Work
CHARGEFREE Free of Charge
TRANSFERFLAG External Academic Work or Qualification Transferred
EVENTPACKAGE Event Package
ACAD_SESSION Academic Session
ACAD_YEAR Academic Year
BOOKREASON Module Booking Reason
ANNULMENT Exclusion Indicator for Module Bookings
COBOK Conditional Booking
PRIOX Priority
AGRTYPE Appraisal Type
AGRSTAT Appraisal Status
GRADESYMBOL Grade Symbol
GRADE Std Value for Scale Value
GRADESCALE Academic Scale Identification (ID)
AGRNOTRATED Appraisal Grade Not Relevant
AGRDATE Appraisal Date
AGRCOMPLETED Appraisal Completed
CPATTEMP Attempted Credits
CPEARNED Earned Credits
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 52
Student Lifecycle Management Business Rule Framework Cookbook
CPGRADED Graded Credits
CPUNIT Unit of Measurement for Credits
AGRREMARK Appraisal Remark
AGRBEGDA Start of Appraisal Validity
AGRENDDA End of Appraisal Validity
ARCH_STATUS Appraisal Archiving Status
AWTEXT Additional Description for Academic Work
3.16.2.1.2 0GRADING_TOP_APP_BEF
This context contains information about the top appraisal and the related module bookings in their state prior to the activity that triggered the event. The structure used is the same as the one for context 0GRADING_TOP_APP_UPD.
3.17 Event for Academic Work (0ACADEMIC_WORK)
This event is triggered in two scenarios. The first one is equivalency determination: whenever an equivalency is released (and transfer academic work is created) or the release is cancelled (and the transfer academic work is deleted) event 0ACADEMIC_WORK will be triggered. The second scenario is the extended maintenance of academic work transaction PIQST10) – whenever academic work is edited there, the event will be triggered for every record. The event will be triggered for both module academic work (object type SM) and credited work (object type CW).
3.17.1 Activities
The following activities in Student Lifecycle Management can trigger event 0ACADEMIC_WORK:
• AW01 Create Acad. Work (Ext.Maint.Dialog)
• AW02 Change Acad. Work (Ext.Maint.Dialog)
• AW03 Delete Acad. Work (Ext.Maint.Dialog)
• ED01 Equivalency Determination (Create)
• ED02 Equivalency Determination (Change)
3.17.2 Context
The context header for this event is 0ACADEMIC_WORK_CH which uses again structure PIQPP_EV_CH.
3.17.2.1 Sub-contexts
3.17.2.1.1. 0ACADEMIC_WORK_UPD
This context contains information about the academic work record after it was updated by the activity that triggered the event. The structure used is PIQAW_ACWORKK which was already explained above.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 53
Student Lifecycle Management Business Rule Framework Cookbook
3.17.2.1.2. 0ACADEMIC_WORK_BEF
This context contains information about the academic work record in the state prior to the execution of the activity that triggered the event. The structure used is PIQPI_ACWORK .
PIQPI_ACWORK includes structure PIQAW_ACWORKK and has two more components – PROGRAMTYPESBEF and PROGRAMSBEF. These are two tables which contain a list with the program type and program usages of the academic work record that existed before the activity was executed. The usages for program types and programs after the execution of the activity are not available immediately in the context 0ACADEMIC_WORK_UPD but must be read from the database if required for BRF actions and expressions.
3.18. Event for Program Type Progression (0PROGRESSION)
Event 0PROGRESSION is triggered whenever program type progression results are stored into the database. The event is triggered both by the program type progression report that is normally run in mass mode as well as when an individual’s student results are edited using the progression tab in the student file. One event will be triggered for the result in every program type/progression category of the student. If progression is executed for academic standing and progress classification at the same time, two separate events will be triggered. If results for all 5 available progression categories are calculated at the same time, 5 events will be triggered.
Whenever the program type progression calculates performance indexes, another event - 0PERFINDEX – is triggered that contains information about the new or updated performance indexes. These performance indexes are stored in an own database table.
3.18.1 Activities
The activities in Student Lifecycle Management that trigger event 0PROGRESSION are the following:
PG1A Program Type Progression
PG2M Program Type Progression (Manual)
PG3C Reset Program Type Progression
3.18.2 Context
The context header of the event is 0PROGRESSION_CH and again structure PIQPP_EV_CH is used.
3.18.2.1 Sub-contexts
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 54
Student Lifecycle Management Business Rule Framework Cookbook
3.18.2.1.1 0PROGRESSION_RES
This sub-context contains information about the progression result set. The previous value for the same program type and progression category – if available – is also filled in the context. The structure used is PIQPROG_GR_PROT_DETAIL:
PLVAR_ST Plan Version
OTYPE_ST Object Type
OBJID_ST Object ID
PROGC_VAR Program Type
PROG_TYPE Progression Category
PROCESSTYPE Execution Category Used in Progression
PROCESSTYPE_INT Internal Execution Category Used In Progression
EXECUTED Academic Prerequisite for Progression Fulfilled
BEF_RESULT Result Before Progression
BEF_RESULT_STAT Result Status Before Progression
AFT_RESULT Result After Progression
AFT_RESULT_STAT Result Status After Progression
CHECK_FROM Check-From Date for Progression
CHECK_TO Check-To Date for Progression
CHECK_TO_INTERN Internal Check-To Date for Progression
VALID_FROM Valid-From Date for Progression Result
VALID_TO Valid-To Date for Progression Result
ACTIVITY Activity
PERYR Academic Year for Progression Result
PERID Academic Session for Progression Result
Only one new result for the same program type and progression category can be calculated per student at the same time.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 55
Student Lifecycle Management Business Rule Framework Cookbook
3.18.2.1.2 0PROGRESSION_CANC
Whenever progression results are cancelled (activity PG3C), the context 0PROGRESSION_RES will contain only information about the student, the program type, progression category, the dates but no information on the previous values of progression results that were cancelled and no longer available in the database (progression was reset). Cancelled progression results are available for BRF expressions and actions in context 0PROGRESSION_CANC. Since more than one result for the same program type and progression category can be reset in one step, a structure is used - PIQPP_EV_PROG_R_CXT – which contains a component that is a table.
The line type of component REST_PROG_RESULTS is BAPIPROG_GROUP_RESULT:
PROGRAM_TYPE Program Type
PROGRESSION_CATEGORY Progression Category
PROGRESSION_RESULT Progression Result
PROGRESSION_RESULT_STATUS Result Status
CHECK_FROM Check-From Date for Progression
CHECK_TO Check-To Date for Progression
VALID_FROM Valid-From Date for Progression Result
VALID_TO Valid-To Date for Progression Result
ACAD_YEAR Academic Year for Progression Result
ACAD_SESSION Academic Session for Progression Result
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 56
Student Lifecycle Management Business Rule Framework Cookbook
3.19 Event for Registration to Specializations (0SPECIALS)
Event 0SPECIALS is triggered by activities related to registration to specializations (‘major/minor bookings’).
3.19.1 Activities
The following activities are relevant for this event:
• CB01 Assign Acad. Specializations
• CB02 Change Acad. Specializations
• CB03 Cancel Acad. Specializations
3.19.2 Context
The header context for 0SPECIALS is 0SPECIALS_CH and again the referenced structure is PIQPP_EV_CH.
3.19.2.1 Sub-contexts
3.19.2.1.1 0SPECIALS_UPDT
The details are contained in context 0SPECIALS_UPDT which uses structure PIQPP_EV_SPEC_CXT.
The one component of structure PIQPP_EV_SPEC_CXT is PIQPP_EV_SPEC:
ACTIVITY Activity
STUDENT_OBJECTID Object ID of Student
STUDY_OBJECTID Object ID of Study Object (CS)
PROGRAM_OBJECTID Program ID
MODULEGROUP_OBJECTID Module Group ID
MODULEGROUP_CATEGORY Module Group Category
BEGDA Start Date
ENDDA End Date
MODULEGROUP_PRIORITY Specialization Priority
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 57
Student Lifecycle Management Business Rule Framework Cookbook
STAGE_BEG Start of Stage
STAGE_END End of Stage
SPECBOOK_GUID Unique Key (GUID) for Specialization Booking
PREV_BEGDA Start Date
PREV_ENDDA End Date
PREV_MODULEGROUP_PRIORITY Specialization Priority
PREV_STAGE_BEG Start of Stage
PREV_STAGE_END End of Stage
If a new specialization is booked, the component ACTIVITY will be ‘CB01’ and the fields starting with PREV* will be empty. If a specialization is cancelled, the activity is ‘CB03’ and again the PREV* fields will be empty. If an existing specialization booking is changed (priority, time validity or stage assignment), the activity will be ‘CB02’ and the fields starting with PREV* will contain the data for that specialization booking prior to the execution of the activity.
3.20 Event for Event Bookings (0EVBOOKING)
Normally in Student Lifecycle Management business events will be booked or cancelled in the context of module bookings. In such cases BRF event 0MODBOOK will be triggered which also contains information about business event bookings. There is only one special use case in which a separate BRF event will be triggered: when an event offering is cancelled then all event bookings will be cancelled as well.
3.20.1 Activities
This event is not related to an Student Lifecycle Management activity.
3.20.2 Context
The header context is called 0EVBOOKING_CH and has the same structure as all other header contexts.
3.20.2.1. Sub-contexts
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 58
Student Lifecycle Management Business Rule Framework Cookbook
3.20.2.1.1 0EVBOOKING_UPD
The sub-context for this event is PIQPP_EV_EVBOOKING_CXT:
The last component INFTYTABLE is a table with line type PIQPP_EV_INFTY:
INFTY Infotype
RELAT_OBJTYPE Type of Related Object
RELAT_OBJID ID of Related Object
SUBTY Subtype
BEGDA Start Date
ENDDA End Date
UPDATE_MODE Update Indicator (Insert: I, Change: U, Delete: D)
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 59
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 60
Student Lifecycle Management Business Rule Framework Cookbook
See the screen shot showing an admission record.
Admission for B.A.ENGL, Year 2007, Session 1,
Student is TAA, tester
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 61
Student Lifecycle Management Business Rule Framework Cookbook
Now in transaction SXMB_MONI, notification for StudyAdmissionCreateNotification_Out is received.
StudyAdmissionCreateNotification_Out
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 62
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 63
Student Lifecycle Management Business Rule Framework Cookbook
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.
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 64
Student Lifecycle Management Business Rule Framework Cookbook
SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 65
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.