Skip to end of metadata
Go to start of metadata
Icon

this is still very much a draft

What is KRMS & PeopleFlow?

KRMS is a new module of Kuali Rice that allows business rules that were previously coded within electronic documents or applications to be externalized into a rules repository with its own set of user interfaces. Removing this critical logic from being coded into the document allows for the maintenance of rules in a fashion that does not require application deployment or development for updates. In addition to the rules, a new routing option called PeopleFlow has been introduced to provide a streamlined way to view and update routing actions without having to have a deep understanding the KEW and its user interfaces or the impact changes may incur.

The first half of this document will focus on the PeopleFlow with the second half looking at KRMS.

PeopleFlow Terms and Concepts

PeopleFlows are a new, graphical way of representing routing. A PeopleFlow is a function of how it's invoked, there are no settings of Approval, FYI, or Acknowledgment in the PeopleFlow.

  • Stop - a numerical assignment of priority. If multiple stops of the same priority are defined, they are activated in parallel and the next stop is not called until all are completed. However, when a PeopleFlow is called for acknowledgement or FYI, all stops are activated regardless of priority.
  • Member Type - this refers to who is assigned on a stop. These can be principals, groups, or roles.
  • Delegate - Each stop's member can have one or more delegates. PeopleFlow delegation can be of a primary or secondary type. Primary Delegation replaces the member of the stop, where as secondary supplements the stop.
  • Type - a PeopleFlow may optionally have a Type associated with it. The type can be configured to provide additional elements for specification on the PeopleFlow. This greatly enhances how the PeopleFlow can be used. For example, a Type could be configured to provide options for Department. Based on attributes on a document, it could invoke a specific PeopleFlow for that specific department.

When to use PeopleFlows?

With PeopleFlow it is possible for end-users to set these up easily via the user interface and maintain them. Changing a document type process definition in KEW is intended to be an infrequent and somewhat "heavy-weight" event, typically requiring someone with a strong understanding of the effect it will have on the overall process (and often requiring appropriate change management procedures).  There for, if the process "players" change frequently and it's desired to roll the maintenance of routing out to a larger group of less technical users, then PeopleFlow may be the better option.

Creating a PeopleFlow

The following outlines the basic steps needed, along with example screenshots, to create a sample PeopleFlow. Please note, the screens are still being developed and may change; we'll make our best efforts to keep this document up-to-date with those changes.

  1. From the Main Menu tab of the default Rice portal click on the PeopleFlow link located in the Workflow channel
  2. Click on the Create New link on the PeopleFlow Lookup document.
  3. Finally, fill out the PeopleFlow Maintenance document.
    1. Name is used as the identifier of the PeopleFlow and must be unique in the selected Namespace.
    2. The Type needs to be setup by the technical team prior to being used, this will define the optional attributes (Travel Account Number & Travel Fiscal Officer Id in the example below) that are available. For testing, you can use the KR-SAP - Sample Type.
    3. Stop is the ordering in which the action requests are generated. If you put them in out of sequence, the screen will re-render to present the changed ordering. However, if you can change the stop number in the bottom list no reordering will happen.
    4. Selecting the different Member Type drop down options will change the lookup below that to reflect the member type selection.
    5. Once you've selected a member, you MUST click the add button for it to appear in the below list.
    6. After you've added the member you can add delegates and set their respective delegation type. Note, you can mix delegation member types and delegation types
    7. Once you've filled in all the stops and delegats desired, the document can be submitted for approval

Working Example

Throughout this next section we’ll use the following business rule case as an example…

Previously, if a newly hired employee met a set of criteria, they would need to have an eVerify check run in addition to the standard I-9 process. The initial requirement stated that if the original hire date of an employee was later than August 1, 2006, the grant was of a Government type, the grant amount was greater than $5,000, the grant was longer than 2 months, and the employee had not previously completed an eVerify check, then their hire document needed to be routed to the special HR eVerify workgroup.

... or put another way...

KRMS Terms and Concepts

  • Agenda - a collection of rules in a defined plan.
  • Rule - the logical expression in an Agenda. It consists of two parts, a proposition that returns a true of false value and an action or set of actions. The entire example presented above is a rule.
  • Proposition - the logic that makes up a rule. A proposition is a single expression of logic that returns true or false. Propositions can be compounded, created using AND, OR, or both to create more complex logic. The entire IF statement in the example above comprises a compound proposition.
  • Action - the steps to perform in the event that the rule, after being evaluated against the propositions, returns TRUE. In the example stated above this would involve routing the document to the HR eVerify workgroup and presenting a warning on the document.
  • Term - the definition of data that is evaluated in a proposition. hr.hire_date, cg.grant_type, etc. are examples of Terms in the working example.
  • Term Specification - the definition of the type of data that is to be expected in the UI. In our example, hr.everify_comp would be a string so java.lang.String would be the specification of the term.
  • Fact - the actual data for the term being evaluated in a proposition, the data being passed in for evaluation. In the example above, if the grant in question had an amount of $10,000, then $10,000 would be the fact.
  • Context - a collection of agendas, rules, terms, term specifications. In our example a context of "HReVerify" would be established for easy identification of the items related to these business rules.
  • Term Resolver - A term resolver tells the engine where to get the value for a term. In some cases the term may be passed into the rule, in other cases a term resolver will be necessary to pull the value of a term from another source (a database for example). Term resolvers can be chained to each other as well to find the value of the desired term based on the presence of another term.
  • PeopleFlow - routing stops with members and delegates. Can be comprised of principals, groups, and/or roles.
  • Category - Categories are a way, within a namespace to group terms. When you create a rule, you can select a category to narrow down the term options you get.

When to use KRMS?

A big question: When should you use KRMS rules, and when should you use logic directly coded in an application or document?  The biggest advantage to using KRMS is that the business rules that govern a document or workflow are externalized in a way that can be updated on the fly and by functional users. Traditionally, this type of logic would be coded into the document, requiring development time to make changes and a redeployment of the application for the changes to take effect.

Creating a KRMS Agenda

The following outlines the steps needed, along with example screenshots, to create an Agenda. Please note, the screens are still being developed and may change; we'll make our best efforts to keep this document up-to-date with those changes.

Create a Namespace

Namespaces allow for application, module, or document categorizations of items within Rice. These items can be contexts, workgroups, roles, or any other attributes that Rice offers. We'll create an HR namespace for this example since HR will be responsible for the maintenance of the eVerify logic. Be sure to create a Permission and Role for the Namespace created and assign them to a Role or Principal. Without this, no one will be able to create an Agenda using these items.

  1. From the Administration tab of the default Rice portal, click on the Namespace link located in the Configuration channel.
  2. Next click on the Create New link from the Namespace lookup.
  3. Finally, on the Namespace screen fill in all the required information and route the document. The Namespace Code is the unique identifier for the context being created and must be unique to your instance of Rice.

Create a Context

You only need one context for this example, but if your application has multiple, logically categorizable collections, it will make sense to have more than one context within a namespace. We'll create a context here for eVerify logic and attributes within the HR Namespace

  1. From the Main Menu tab of the default Rice portal, click the Context Lookup link located in the KRMS Rules channel under the Lookups heading.
  2. Next click the Create New link from the Context Lookup.
  3. On the context screen fill in all the required information and route the document. The Id is the unique identifier for the context being created and must be unique to the namespace selected.

Create a Term Specification

A term specification tells the Agenda UI what kind of data is going to be compared and needs to be established before a related term can be used. Term specifications allow for constant specifications of common data to be shared across various terms that may be used within rules.

  1. From the Main Menu tab of the default Rice portal, click the Term Specification Lookup link located in the KRMS Rules channel under the Lookups heading.
  2. Next click the Create New link from the Term Specification Lookup.
  3. On the Term Specification screen fill in all the required information and route the document. The Name is a unique identifier for the Term Specification being created and must be unique to the namespace selected. Notice that a Term Specification can belong to multiple Contexts within a given Namespace.

Create a Term

  1. From the Main Menu tab of the default Rice portal, click the Term Lookup link located in the KRMS Rules channel under the Lookups heading.
  2. Next click the Create New link from the Term Lookup.
  3. On the Term screen fill in all the required information and route the document. The Description is a unique identifier for the Term being created and must be unique to the namespace selected. Remember that you can have multiple terms with the same specification. In this case we've created one called federalGrantType, you could also created one for privateGrantType, etc.

Repeat the creation of Term Specifications and Terms for each Term needed in the Agenda

Category

  • Category can not currently be created or maintained via a User Interface

Create an Agenda

Now it's time to tie all of these pieces together in an agenda, a collection of rules that can be called for defined actions. The actions a rule can perform are defined by the application (there is currently no UI for defining them). In this example we'll simply provide the setup for the rule, not the action itself.

  1. From the Main Menu tab of the default Rice portal, click the Create New Agenda link located in the KRMS Rules channel under the Maintenance Docs heading.
  2. On the Create New Agenda Maintenance screen, first fill in all the required information for the agenda itself. The Name is a unique identifier for the Term being created and must be unique to the namespace selected.
  3. Next click the Add Rule button in the rules section. This will take you to the screen where you can create the actual rule to be evaluated.
    1. First fill in the descriptive information for the rule.
    2. Now click on the Add button in the propositions section. This is where you use the terms previously defined to evaluate them in a logical proposition. If Actions have been defined, below is where you would specify what to do in the event that this validated to TRUE (i.e. grant type = GOV). Once you've filled in all the necessary information press the add rule button at the bottom of the screen.
  4. Now you are back to the main agenda editor screen and can repeat the above steps to add additional rules. Say you wanted to check and see if the grant type was FUN and perform another action in this case, you could add an additional rule to evaluate against that. Once you have all your rules, route the document for approval.

Term Resolver

  • Term resolvers can not currently be created or maintained via a User Interface

Actions

  • Actions can not currently be created or maintained via a User Interface