Content Comparison

Table of Contents

Overview

UHIMS Events refers to messages that UHIMS publishes to the UH Message Broker. It is a convenient way of receiving identity, affiliation, and contact information about the students, faculty and staff that your application serves. The data comes from several official sources, including Banner, PeopleSoft, RCUH, SECE and WPMS. UHIMS digests the information from these various systems and makes it available in one place.

Message Specs

...

UHIMS Events is currently being used by the following UH applications:

• KFS
• myGRANT
• Honolulu Community College

Message Specs

• UHIMS Events - Message Specs (future), includes retrofit messages

...

• History
  • 7/17/2013 5pm HST

    • Adds <uids> to every message where <uhUuid> is the key, e.g

      No Format
      <addContactInfo> <messageData> <uhUuid> 00000000 </uhUuid> <uids> <uid> jsmith </uid> </uids> ...

      • This is useful for apps that use the UH Username as the key identifier.
      • It lists all usernames a person has at the time of the message. Most people should have only one username, but it is not impossible to see multiple usernames.
      • <uids> is skipped if the person does not have any usernames
      • <uids> is not included in username messages (addUsername, modifyUsername*, deleteUsername) because their key is a single <uid>.
  • 1/23/2013 5pm HST
    • Adds optional <displayName> to <addPerson> and <retrofitPerson>
    • Adds a new value to <role>, staff.executive.overload, its roleCategory in message routing key is staff)
    • Deleted references to date of birth and SSN because they are not usually included:
      • Deleted <modifyPersonSsn>
      • Deleted <modifyPersonDob>
      • Deleted <dob>
  • 8/14/2012 5pm HST
    • includes 13403405 messages

Connection Settings

Requesting Access

1. Review UHIMS Events - Message Specs and determine which messages you are interested in.
2. Contact its-iam-help@lists.hawaii.edu to request access:
   • Provide a desired username for the UH Message Broker. This should be something related to your application, not your personal username, e.g.
     • student_housing
   • Provide a desired queue name. It will always be preceded by the above username, e.g.
     • student_housing.prod
     • You must register your queues with us. We will declare the queue and its bindings for you. This is to ensure the queues exist and have the correct settings for persistence, high-availability, etc.
   • Provide the message routing key pattern for the messages you want to be routed to your queue. It is OK to provide multiple patterns. Here are some examples:
     • # (you are interested in all messages)
     • username.# (you only want username messages)
     • affiliation...uhm.hris (you only want affiliation changes for UH Manoa coming from PeopleSoft)

Reading UHIMS Events

See Consumer Code ExampleTo request access to UHIMS Events, refer to Consuming UHIMS Events

Reading UHIMS Events

See Consuming UHIMS Events

Anchor
retrofit retrofit

Retrofit Messages

Your application usually tracks people who are currently active. It will typically do an initial load of all active people from UHIMS, followed by ongoing synchronization via UHIMS Events. One problem with this model occurs when a previously inactive person becomes active: UHIMS will not generate an <addPerson> (because person already exists in UHIMS), and your application will receive an <addAffiliation> message for a person that it has not previously encountered.

We solve this problem by generating retrofit messages that contain all data about a person.  Retrofit messages are sent prior to any <addAffiliation>, <addScopedHomeOrg>, <addUsername>, <addEmail> or <addContactInfo> messages:

<retrofitPerson> (always)
<retrofitUsername> (if person has a username)
<retrofitEmail> (if person has email)
<retrofitContactInfo> (if person has contact info)
<retrofitScopedHomeOrg> (if person has a home org for 'hris' and/or 'sis', see uhScopedHomeOrg)

We will only include retrofit messages for data that exists for that person. For example, if the person has no username, email or contact info, we will only generate a <retrofitPerson> message prior to generating an <addAffiliation> message.

An efficient way of using retrofit messages is to cache them and use them only when an unknown-person condition is encountered:

• Cache all the retrofit messages as they arrive.
• Process the subsequent add/modify/deleteSomething message if the message is applicable to your application. Otherwise ignore the message and clear the cached retrofit messages.
• When processing as an applicable message, catch exceptions due to the person not being known to your application.   The exception handling should use the cached retrofit messages to retroactively add the person to your application.

UHIMS Events Request Form

• UHIMS Events Request Form