KEW Definitions

Document Type The Document Type defines the routing definition and other properties for a set of documents. Each document is an instance of a Document Type and conducts the same type of business transaction as other instances of that Document Type.

Document An electronic document containing information for a business transaction that is routed for actions in KEW. It includes information such as Document ID, Type, Title, Route Status, Initiator, Date Created, etc.

Document Content In KEW, a document will typically have an XML payload attached to it which is used when making routing decisions.

Route Node A Route Node represents a point in the routing process of a document. A node can be defined to perform any function, but the most common functions are to generate Action Requests or to split/join the route path.

Route Path The path a document follows during the routing process. Consists of a set of route nodes and branches. The route path is defined as part of the document type definition.

DocumentType XML<documentType> <name/> <parent/> <description/> <label/> <active/> <postProcessorName/> <docHandler/> <attributes/>

<routePaths/>

<routeNodes/>

</documentType>

<routePaths> <routePath> <start name=“one" nextNode=“two" /> <requests name=“two" nextNode=“three" /> ... </routePath></routePaths> <routeNodes> <start name=“one"> <activationType/> <mandatoryRoute/> <finalApproval/> </start> <role name=“two"> <activationType/> <qualifierResolverClass/> </role> ...</routeNodes>

Document Content

<documentContent> <applicationContent> <cluProposalDocInfo> <cluId>0ed64e1f-9d24-4b10-b21a-e366fc77cc9d</cluId> <orgId>69</orgId> <proposalId>44edf1d5-88d0-46d5-b51b-c6e833029ced</proposalId> </cluProposalDocInfo> </applicationContent></documentContent>

Qualifier Resolverimport org.kuali.rice.kew.engine.RouteContext;import org.kuali.rice.kim.bo.types.dto.AttributeSet;

/** * A QualifierResolver is responsible for resolving qualifiers that might be used * to identify a Qualified Role from a Document. Information about the Document * can be obtained from the RouteContext. * * @author Kuali Rice Team (rice.collab@kuali.org) * */public interface QualifierResolver {

public List<AttributeSet> resolve(RouteContext context);

}

Post Processor

ProcessDocReport afterProcess(AfterProcessEvent processEvent) Executed after processing by the workflow engine has completed.

ProcessDocReport beforeProcess(BeforeProcessEvent processEvent) Executed prior to processing by the workflow engine.

ProcessDocReport doActionTaken(ActionTakenEvent event) Executed whenever an action is taken against the document.

ProcessDocReport doDeleteRouteHeader(DeleteEvent event) Executed whenever a deletion of the document is required.

ProcessDocReport doRouteLevelChange(DocumentRouteLevelChange levelChangeEvent) Executed whenever the document transitions from one node to another.

ProcessDocReport doRouteStatusChange(DocumentRouteStatusChange statusChangeEvent) Executed whenever the status of the document changes.

Long getDocumentIdsToLock(DocumentLockingEvent lockingEvent) Executed prior to document locking in the workflow engine.

Dictionaries

• Service Dictionary, Data Dictionary, DTO Dictionary

• Search Dictionary• Orchestration Dictionary, DOL Dictionary• Search Orchestration Dictionary– Not just lookup meta data– Most likely part of regular Search Dictionary

• Application Dictionary?

Service Dictionary Configuration

• Override value settings• Add constraints• Remove constraints• Override constraints• Override global constraints?– We don’t think this is likely

Spring Config Files

• Inheritance from parent bean• Last bean defined with same ID wins• Include files from classpath– Could we include from url?– Would we want to include from url?

• Parent bean pattern for overrides

InheritanceCurrent Dictionary Modified to use inheritance<dict:objectStructure key="cluIdentifierInfo"> <dict:type key="CreditCourse.identifier.official">

<dict:state key="active“ > <dict:field id="course.official.no" key="code"> <dict:fieldDescriptor/> <dict:constraintDescriptor/> </dict:field> ... <dict:field id="internal.id" key="id"> <dict:fieldDescriptor/> <dict:constraintDescriptor/> </dict:field> </dict:state>

<dict:state key="inactive"> <dict:fieldRef bean="course.official.no" /> ... <dict:fieldRef bean="internal.id" /> </dict:state> </dict:type></dict:objectStructure>

<dict:objectStructure key="cluIdentifierInfo"> <dict:type key="CreditCourse.identifier.official">

<dict:state id=“active” key="active"> <dict:field id="course.official.no" key="code"> <dict:fieldDescriptor/> <dict:constraintDescriptor/> </dict:field> ... <dict:field id="internal.id" key="id"> <dict:fieldDescriptor/> <dict:constraintDescriptor/> </dict:field> </dict:state>

<dict:state key="inactive” parent=“active”/> <dict:state key=“proposed” parent=“active”/> </dict:type></dict:objectStructure>

Parent Bean Patternorganization-dictionary-config.xml<!-- The abstract field definition --><dict:field key="OrgCodeInfo.default.desc-parent“ id="OrgCodeInfo.default.desc-parent" abstract="true"> <dict:fieldDescriptor> <dict:name>desc</dict:name> <dict:desc>The description of …</dict:desc> <dict:dataType>String</dict:dataType> </dict:fieldDescriptor> <dict:constraintDescriptor> <dict:constraintRef bean="single"/> </dict:constraintDescriptor></dict:field>

<!-- The actual implementation of the field description--><dict:field key="OrgCodeInfo.default.desc" id="OrgCodeInfo.default.desc" parent="OrgCodeInfo.default.desc-parent"/>

<dict:objectStructure key="OrgCodeInfo-parent" id="OrgCodeInfo-parent" abstract="true"> <dict:type key="default" id="OrgCodeInfo.type.default"> <dict:state key="default" id="OrgCodeInfo.state.default"> <dict:fieldRef bean="OrgCodeInfo.default.desc"/> <dict:field key="value"> <dict:fieldDescriptor> <dict:name>value</dict:name> <dict:desc>The code value.</dict:desc> <dict:dataType>String</dict:dataType> </dict:fieldDescriptor> <dict:constraintDescriptor> <dict:constraintRef bean="single"/> </dict:constraintDescriptor> </dict:field> </dict:state> </dict:type></dict:objectStructure>

Parent Bean PatterInstitutional-organization-dictionary-override.xml

<!-- Import the base configuration --><import resource="organization-dictionary-config.xml"/>

<!-- Override the OrgCodeInfo.default.desc. The other --><dict:field key="OrgCodeInfo.default.desc" id="OrgCodeInfo.default.desc" parent="OrgCodeInfo.default.desc-parent">

<dict:constraintDescriptor> <dict:constraint key="maxChars"> <dict:maxLength>30</dict:maxLength> </dict:constraint> <dict:constraintRef bean="single"/> </dict:constraintDescriptor>

</dict:field>

Tooling

• Could use standard XML tools• Excel generation– This needs updated output for configurability

• Application based tooling– Implementing institution could contribute

• Recently added functionality that reads java service DTO’s and creates dictionary stub

We Have Schema Posted

Orchestration Dictionary

• Is this orchestration/transformation only or should it control UI?

• Needs linkage to Service Dictionary– Remove redundant constraints– Provide global config

Application Dictionary Could:

• Configure document content• Configure document type• Configure UI• Tie screen to orchestration dictionary/object

Transactions

• Solution must implement ws-coordination spec and jta spec (in order to be swappable/purchaseable)

• Attempt to create new service methods to reduce numbers of transactions

• Currently stuck deploying all services and UI as single application

• Possibly attempt to write transactions based on ws spec

• Compensation is as much or more work than writing atomic

Transactions In Glassfish

• Dropping KS on Glassfish does not get transaction support

• Must integrate with some or all of containers implementations of– JTA– JPA– JAX-WS– JNDI Datasource

• KSB integration with Metro on Glassfish

Dynamic Attributes

• Supported via simple configuration at– Service level– Service dictionary– Pickers

• DOL– Must create Orchestration dictionary– Must modify DOL Assemblers

• Must modify UI via deferred binding• Need to build an “LU/Course” example into

codebase or deployment lab

Authorization Layers

• Service Layer– KS application clients and external clients– Lowest level of row/field authorization

• Orchestration Layer– May need access to row/fields user can’t access– Needs to respect service layer authZ

• Application Layer– Access to particular application– View a specific section– Data must be filtered before this layer since it runs on the

browser

Field level AuthZ and Masking

• Permissions are positive• Configurations are negative– Assume all fields are editable unless configured

otherwise in Dictionary (DOL or Service)• Permissions checked to override configuration

Application Authorization

Service LayerDOLAuthZFilter

GWT Client

KIM Permission Service

12

34

56

7

AuthN Diagram

• https://test.kuali.org/confluence/display/KULSTG/KS+Authentication