Rice Data Overview

Since OLE is one of a number of Kuali Rice-based projects, an installation of it also includes certain Rice tables and their associated data. However, storing this data in our master schema leads to maintenance issues when the master structure changes and potential data collisions with other Kuali projects. As such, we rely on the "master" rice datasource directly.

The database impex tool allows for two database definitions to be overlaid upon one another. So, for a simple install of OLE, where the Rice server is integrated into the application, the impex tool first imports the Rice tables and data into the OLE database and then adds the OLE tables and data.

This, however, does not then include any of the OLE-specific data which needs to be stored in the Rice tables. This includes items such as:

Item	Rice Module
Workflow Documents	Kuali Enterprise Workflow (KEW)
System Parameters	Kuali Nervous System (KNS)
Test Users	Kuali Identity Management (KIM)
Application-Specific Roles	Kuali Identity Management (KIM)
Permissions	Kuali Identity Management (KIM)
Responsibilities	Kuali Identity Management (KIM)

To import those, we have two additional steps. (This will hopefully be a single step in the future, when Rice provides for XML import/export for all of these objects.)

Run Liquibase scripts to add the KNS and KIM data.
Run the workflow XML Ingester tool (part of Rice) to add the workflow definitions.

The definitions for these items are stored in the following locations:

ole/work/db/rice-data (KIM/KNS)
ole/work/workflow (KEW)

After all "normal" import processes are done, these scripts/files are executed/imported as a final step to load the OLE data into the database.

Rice Data Locations and Structure

The Rice data needed by OLE is stored within the main ole project in the locations below:

Directory	Description
`ole/work/db/rice-data`	Rice KNS and KIM data. (Parameters, Roles, Permissions, etc...)
`ole/work/workflow`	OLE workflow document definitions.

The non-workflow Rice data scripts use Liquibase for inserting the data into the Rice tables. Most of them (for practical reasons), simply load a CSV file with the OLE data into the needed tables. Review the Liquibase XML files in the ole/work/db/rice-data for the details.

Demo vs. Bootstrap

The Rice data loads are split up into two sets, demo and bootstrap. Unless specified otherwise, both are executed. Usually, the demo scripts add data not in the bootstrap scripts but in at least one case (system parameters), it overlays the entire set of OLE parameters since the entire set of parameters must be loaded in both cases, except with different values in the demo dataset.

Updating KEW Document Workflow

When the workflow import portion of the impex tool runs, it look at all the subdirectories under ole/work/workflow and runs them in alphanumeric order. Within each directory, the files are run as a single batch. The directory separation is to ensure that parent documents are in place before ingesting child documents.

Adding a new Module

Create the needed parent documents for that module

Each module may have up to three primary parent documents:

Simple Maintenance Documents (do not route)
Complex Maintenance Documents (have defined workflows)
Transactional Documents (non-maintenance documents)

Add these these parent documents to 002_ole_core_parent_docs/OleCoreModulesParentDocuments.xml or 002_ole_core_parent_docs/OleOptionalModulesParentDocuments.xml as appropriate.

Create the documents for the module

Create a new directory starting with a 3-digit number and the name of the module. This number should place it after any documents upon which it is dependent.
Within that directory, create files (again, dependent on the types of documents you have in the module) for each of the categories above for the parent documents.
- The files should have names like the following:
  - <<ModuleName>>SimpleMaintenanceDocuments.xml
  - <<ModuleName>>MaintenanceDocuments.xml
  - <<ModuleName>>TransactionalDocuments.xml
Add the <documentType> entries for the documents in the appropriate file.

Updating KNS System Parameters

The system parameters live in the work/db/rice-data/bootstrap/krns_parm_t.csv and work/db/rice-data/demo/krns_parm_t.csv files. All parameters are defined in each of these files. The reason for this is that a number of the parameters contain IU-specific data. Most of those parameters must be blanked out in the bootstrap dataset. During the import, the demo import process deletes all of the bootstrap-loaded parameters and replaces them with the demo versions.

So, when adding new parameters: they must be added to both files.
When updating parameters, check the value in both files to determine whether the bootstrap version should be set as well.

Updating KIM Data

The KIM data is (unfortunately) fairly complex to update through these CSV files, as there are a number of non-obvious dependencies. This will be rectified in the future, when the Rice project provides a method of XML ingestion for KIM data like it does for workflow documents. (But that's then, this is now...)

Roles/Permissions/Responsibilities

In general, these will all be defined in the bootstrap dataset files. These files set the roles defined by OLE and their relationships to permissions and responsibilities.

File	Description
krim_role_t.csv	Role Definitions
krim_perm_tmpl_t.csv	Permission Templates - usually should not need to be edited
krim_perm_t.csv	KIM Permission entries - represent specific permissions within the application
krim_perm_attr_data_t.csv	Permission details - specifies to what this permission applies
krim_rsp_t.csv	KIM Responsibility entries - represent specific responsibilities within the application
krim_rsp_attr_data_t.csv	Responsibility details - specifies to what document and route level this responsibility applies
krim_role_perm_t.csv	Associates permissions with roles
krim_role_rsp_t.csv	Associates Responsibilities with roles
krim_role_rsp_actn_t.csv	For role/responsibility pairs for which all role members will be required to take the same action (APPROVE/ACK/FYI), there will be a record in this table linked to the unique ID of the role-responsibility record.

People

Most people are defined in the demo dataset as they are only there for testing. In the bootstrap dataset, we only define the single "ole" user used for back-end processing. There should not be a need to add any other users to the bootstrap dataset. In the demo dataset, the following tables would need to be populated to add more testing users:

File	Description
krim_entity_t.csv	The core entity linking object - really just a unique identifier
krim_prncpl_t.csv	The principal (user ID) associated with an entity - may have multiple.
krim_entity_ent_typ_t.csv	Defines the type of entity - currently always "PERSON", but they could have more than one.
krim_entity_nm_t.csv	Name associated with a given entity/type combination
krim_entity_email_t.csv	email addresses associated with a given entity/type combination (optional)
krim_entity_afltn_t.csv	entity/type's affiliation with a given campus
krim_entity_emp_info_t.csv	employee information associated with a given entity/type combination and affiliation (optional)
krim_entity_ext_id_t.csv	Other identifiers associated with an entity. (optional)
krim_entity_priv_pref_t.csv	Entity's privacy settings for FERPA (optional)

Role Members

Role members can be defined in both the demo and bootstrap datasets. In this case, they augment each other. Role members can be principals, groups, or other roles.

In OLE, a large number of roles are composited out of other roles. These relationships are part of the base system which we will ship. Users and groups who may be assigned to these roles are not. So, when adding role members, those which are other roles should be added in the bootstrap directory, all others should be in demo.

File	Description
krim_role_mbr_t.csv	Links the role member's unique identifier (role ID, group ID, principal ID) to the role.
krim_role_mbr_attr_data_t.csv	Role Qualifiers - need depends on the role - but when present, determine the conditions under which the member is considered to have this role. (E.g., the user may only have this role when a document contains entries for a given chart.)
krim_role_rsp_actn_t.csv	For roles which allow for the action (APPROVE/ACK/FYI) required by a workflow responsibility to be different for every role member, this table may have a row linked to the unique ID of the role member table.

Browser not supported