WORKFLOW Training Workbook

WF8X-BannerWorkflowDevelopmentIntroduction-WB.pdf

WORKFLOW Modeler

Workflow Models

All workflow models should start with “OU_” to distinguish them from Sungard delivered models, followed by the code for the module, then a sequential four digit number, and finally, a descriptor of the workflow. A departmental code may precede the description.

Example:

• OU_S0001_GRADM_SORCMJRChangeNotify
• S - Student
• 0001 – sequential number
• GRADM – Graduate Admissions
• SORCMJRChangeNotify – Notification of change made to SORCMJR table

Sequential Number: The sequential number and module name combination will uniquely identify each workflow model. This combination will be used when naming the Parameter Group Codes in BANNER.

Models should include a note at the top indicating the name of the workflow, the trigger, the business event and the business process associated with the workflow.

Workflow Activities

The name of an activity that requires action on the part of a user will appear on the user's worklist, so special consideration should be taken when naming the activities.

Activities that open Banner Forms – Activites that open Banner forms should include a brief description of the action required and the name of the form being opened, with underscores ('_') in place of spaces. The name will appear on the user's worklist (i.e. "SPAPERS_Enter_Marital_Status ", " FRAGRNT _Create_New_Grant ").

Activities that open Custom Workflow Forms - Names for custom activities should match the title of the custom form as closely as possible, in upper and lower case, with underscores ('_') in place of spaces (i.e. "Account_Request_Form", "Application_Approval_Form").

Workflow activities that will not appear on a user's worklist should be named with a prefix indicating the activity type and a descriptor The descriptor should be named with readability in mind so upper and lower case and no spaces or special characters should be used. An example of a workflow activity descriptor is:

NotifyStudentRecords

The activity names may appear on the user’s work list. The name should be something meaningful and easily readable for the user. Workflow developers should work with the requestor of the workflow work request to decide on names for Workflow activities to ensure that the activity name will be meaningful to those who will be performing the Workflow activities. Each activity within a workflow must have a unique name.

Email Activities –Email descriptors should include as much detail as possible, in upper and lower case, without spaces (i.e. "eml_NotifyPayroll", "eml_GradAppAcknowledge").

Workflow Specifics Names The workflow listed on the user's worklist is the Workflow Specifics name. It should, therefore, be named in a way that reflects the scope of the workflow and include as much specific information as possible (i.e. "New Employee Entered - #name of employee#", "New Grant Requested", "Payment Requested - #Vendor name#")

Workflow Context Parameters Context parameters should be named to reflect corresponding Banner data fields when relevant, including table name (example: SORCMJR_CURR_RULE). For parameters not related to Banner data fields names should reflect the corresponding component parameters.

Context parameters that correspond to Banner data fields should list only the data field in the description with all capital letters (ie. SPRIDEN_FIRST_NAME).

Descriptions for context parameters that do not correspond to Banner data fields should be a descriptive, dual case sentence. The component associated with the parameter should be included in brackets [] for reference.

Local Parameters within Workflow Activities

The local parameter within the activity should be named the same as the context parameter to avoid confusion.

Workflow Administration

Business Events

Parameters defined within Business Events should be named exactly as the context parameters defined within the workflow.

Business Component

One business component category should exist for each module of Banner as defined by Oakland University. The category name should be prefaced with ‘.Oakland University’. For example: .Oakland University Student Business Components in each category should represent the package and procedure, form or function being called or table being queried.

Examples:

The description should include a list of all tables being queried and all parameters that are being retrieved. This will be especially important when qureiying components effected by changes in parameters.

If a delivered SCT business component is used, it should be moved to the appropriate OU category and modified to follow OU naming conventions.

Roles

Roles should be designed to reflect specific tasks for specific workflows. The role should be named with the

Roles should be designed to reflect tasks being performed so they can be transferred from user to user or proxied as required. For example, a user may be assigned many different roles to cover a number of tasks assigned. This allows for tasks to be reassigned without the need for creating new or modifying roles.

Roles for Workflow Owners and Administrators The Workflow Owner listed in a Workflow is a role. The person assigned to this role monitors the Workflow and is identified during Workflow Process Analysis. This role should include a Proxy.

The Workflow Administrator listed in a Workflow is a role. The administrator technically maintains the Workflow. The person typically assigned to this role is the appropriate Data Custodian or their designee. For example, the role “Student Records Data Custodian” would be the administrator for all Student Records Workflows.

There will be an administrator role specifically defined for cross-functional Workflows and all involved Data Custodians will choose who is assigned to this role.

It is recommended that each Data Custodian have a backup who is also assigned as a Proxy.

BANNER

Parameter Codes

Parameters defined within Banner Events should be named exactly as the context parameters defined within the workflow with the exception of those parameters that are required by the Workflow Product. These are: EVENTNAME, PRODUCTTYPE and WORKFLOWSPECIFICNAME.

Parameter Group Codes

The Parameter Group Code can have a maximum length of 10 characters. Therefore, parameter group codes will correspond with the first 5 characters of the Workflow name. This will be the module and workflow number or S0001. Parameter group codes can be assigned to multiple Banner events when multiple events launch the same workflow.

Event Codes

The Event Code in Banner can have a maximum length of 20 characters. Therefore, the Event Code will correspond with the first 20 characters of the Workflow Business Event name. The Event Code must be all uppercase. The Event Code Description should correspond to the full Workflow Business Event name.

ORACLE

Workflow Oracle Objects

These policy and procedures only apply to Oracle objects created specifically for a workflow. Objects that exist currently in Banner or are created for uses other than workflow will follow the existing standards for those objects. Additionally, reuse of objects is encouraged. Where an existing package, procedure, or function can be used within a workflow, it should be. Source for Oracle objects created specifically for a workflow will reside in the workflow directory. Names refer to module letters, which are defined by SunGard Higher Education and documented by them. An incomplete list is given below:

Triggers

Triggers names are limited to 30 characters, and should be named according to the following convention:

• Module Letter + “TOU_” + table_name + “_” + “A” (after) or “B” (before) + “R” (row) or “S” (statement) + “_WKFLOW”

For example, a trigger to launch a workflow after the execution of an update statement on SPRIDEN would be named:

ST OU_ SPRIDEN_AS_WKFLOW

Because multiple triggers on a single table may cause performance issues, it is not desirable to create a new trigger for each event that might be launched. Therefore, triggers may be written to launch multiple events. However, there is a size limit on triggers (approximately 21000 bytes at this writing). If an additional trigger is needed, its name will have “_” and a sequence number appended to it. For example, if a second trigger is written to launch an event after an update statement on SPRIDEN, its name will be:

STOU_SPRIDEN_AS_WKFLOW_2

Packages

Procedures and functions written specifically for workflow should be placed in a package. Package names are limited to 30 characters, and are based on the following formula:

Module letter + “ZKWFLW_” + Component Catalog name (with the leading “.Oakland University” abbreviated to “OU” and spaces replaced with “_”)

For example, a package created for University Relations procedures and functions stored in the “.Oakland University University Relations” component catalog would be named:

AZKWFLW_ UNIVERSITY_RELATIONS

Procedures and functions within the package can be given any descriptive name (limited to 30 characters). However, function and procedure names should generally start with text that indicates the purpose of the object, as shown in the table below.

References to a function or procedure within a package must include:

Package name + “.” + Function or Procedure name.

For example, a packaged function to determine whether a person is a student might be (note: this function may not really exist):

SZKWFLW_OU_STUDENT.IS_STUDENT

As another example, a packaged procedure to return an employee’s class code might be (note: again, this may not really exist):

PZKWFLW_OU_PAYROLL.GET_EMPL_ECLS

---

DatabaseAdministration