Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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

(warning) Note that <messageRoutingKey> in the above specs is not an actual XML tag. It represents the message routing key for the message being described.

Connection Settings

Setting

Value

Comments

Host

esb.hawaii.edu

 

Port

5671

SSL

Vhost

uhims

 

Exchange

uhims-exchange

 

User, Password

(app-specific)

This will be provided when you request your UH Message Broker account

Queue and Bindings

(app-specific)

This will be provided when you request your UH Message Broker account

Reading UHIMS Events

See Consuming UHIMS Events

Retrofit Messages

Your application usually tracks people who are currently active, and will typically do an initial load of all active people from UHIMS, followed by ongoing synchronization via UHIMS Events. One problem with this model is that 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 has not been previously encountered by your application.

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

<retrofitPerson> (always)
<retrofitUsername> (if person has a username)
<retrofitEmail> (if person has email)
<retrofitContactInfo> (if person has contact info)

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.

  • No labels