OpenRegistry Tues., Nov 12, 2013 at 10:45am -- Marina del Rey Room

TOPIC: 

CONVENER: Bill Thompson (Unicon)

SCRIBE: Bert Bee-Lindgren

# of ATTENDEES: 17

MAIN ISSUES DISCUSSED: Person Registries: OR

  1. Omar did demo of Rutgers's OR implementation
    1. Philosophy: Independent sources of record
      1. Can be a SOR for areas not handled by other sources
        1. Guests
        2. Early employees
    2. Architecture & Flow:  Raw Data --> Standardized Data --> Calculated Data
      1. https://wiki.jasig.org/display/OR/Data+Flow
      2. OR Loader (Berkeley/Unicon working to improve this)
        1. Implement/Configure the Load/Validate/Normalize/Standardize pipeline w/o writing java
        2. Batch+Interface requirements in jasig.org
        3. github.com/jasig/openregistry-loader
        4. Built on Spring Batch
          1. Jobs (Writer or Reader)
          2. Saves old/new values and invokes OR APIs on changes
        5. Still need to understand OR schema/APIs
      3. OR Toolkit (Java code from Rutgers)
      4. OR Exporter (Needs most work)
    3. UI Demo: View/Add/Edit People (act as an SOR)/Join/Split/Early F,S on-boarding
    4. Delegated Admin
    5. Functions:
      1. Batch APIs to load data
      2. Stores, normalize, reconciles, identities
      3. Create NetId, activation URLs
      4. Provisioning downstream systems
      5. Registry data model:
        1. Staging tables
        2. Source data (normalized)
        3. Reconciled identities
      6. APIs:
        1. Read data
        2. Add attributes
        3. ...
      7. Audit info available (what changed, when, by whom)
    6. Real-time events & OR Loader
  2. Comparison with CPR or Kuali
    1. See web (Probably within this Google search)
    2. OR designed around independent SoRs
  3. Is this all SOR-syncing process backwards:
    1. Shouldn't identity start in IDM systems?
    2. Feed SORs from IDM
    3. This is a good idea, but not attainable everywhere
    4. Should we push a different model, but use OR model as a Plan B
  4. Rutgers merged with Med School, how did it go?
    1. Registry: Med School was just another feed
      1. Meshed well with existing infrastructure and was generally similar prior loading efforts
      2. Tweak election a lot
    2. Lots of overlap (alumni going to work & med school) & joint programs
    3. They were laughed at when they suggested centralizing ID-creation process

ACTIVITIES GOING FORWARD / NEXT STEPS:

If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.org

  • No labels