Thursday, November 29, 2012


Banner is an ERP system for higher education. It's owned by Ellucian, and enjoys a huge market share.

I work in a Banner school; I'm in charge of Identity Management on our campus. An awful lot of the data we use in the IdM system(s) comes from Banner, so I've been interacting with the system since I've been here. We've been working on implementing BEIS (Banner Enterprise Identity System) for the last several weeks: it's an add-on to the Banner system to allow interaction between Banner and IdM systems via SPML. I thought it might be worthwhile to document some of our challenges and strategies here.

The first thing Ellucian's people tell you is that BEIS is not a turn-key solution. It's really more of a framework and/or API on which you build your solution. So there's significant work to be done implementing BEIS, at least some of which requires some development effort.

The basic idea behind BEIS is to use an Observer pattern so that your IdM system(s) register as Observers of the Banner ERP system and receive notifications of changes. This is absolutely the correct strategy for keeping the ERP data in synch in the IdM, but the implementation details can be a little complicated.

BEIS is based on Oracle Streams. I've worked with Streams a lot in the past: it's impressive what Ellucian's people have managed to get Streams to do for them. The idea behind Streams is that it's an event-based mechanism (like a trigger), but it doesn't happen inline like a trigger does. So a Streams event doesn't have to complete before the transaction is considered committed. So you can think of Streams sort of like a non-blocking trigger.

From the IdM point of view, BEIS basically consists of three parts:

  1. The RA (Request Authority) generates SPML requests. This is conceptually the database, but that's a bit of an oversimplification.
  2. The PSP (Provisioning Service Proxy) acts as an Observer to the RA. The PSP receives SPML requests from the RA as SOAP calls. It extracts the SPML from the SOAP request, validates it, and then extracts a UDC (Unified Digital Campus) document from the SPML. UDC is yet another XML schema.
  3. The PSP has a Provisioning Service Target (PST). Each PST consumes UDC documents, translating those documents to actual changes to the IdM.
From the DBA's perspective, this isn't very accurate: the DBA is a lot more concerned with the RA than with anything else. But from an integration point of view, really only the second and third parts (PSP and PST) matter.

BEIS used Oracle Streams to capture changes in the ERP that need to be sent to the PSP(s). Streams can be a little quirky, but I've become rather fond of it as a technology. When I was a DBA, we used Streams to create real-time reporting replicas of transactional databases under the ERP. I don't think I ever saw Streams get more than ten seconds out of synch, although I saw it crash a few times. At any rate, the data flow looks something like this:

  1. Streams captures a change to a table that's being monitored
  2. Streams sends the change (via a couple different queues) to the RA
  3. the RA wraps the change in SPML, then in SOAP, and sends it to each PSP that is registered for that kind of change
  4. each PSP extracts the UDC document from the SPML + SOAP request and forwards it to the PST
  5. the PST parses the UDC document and fills the request with the IdM datastore

The RA side of things is DBA stuff, it's not terribly appropriate at the moment. But once the RA has been been set up, there is a lot of work that needs to be done to get a PSP and PST working with IdM.

Ellucian provides a sample PSP that runs as a Java web-app. The sample web-app comes as a WAR file and deploys nicely into Tomcat, or presumably any other Java app server. The WAR file provides three basic parts:

  • an in-memory datastore to use as a test environment
  • a very simple web UI to see UDC data in the in-memory datastore
  • a SOAP servlet to receive SPML requests and apply them to the default datastore
According to Ellucian, the sample web-app is supposed to be used as a starting point for a real-life PSP. In theory, a developer should be able to implement the interfaces for the PST appropriately for their own IdM system, wire their implementations into the appropriate application contexts, and recompile the web-app into a WAR, et voila! you're in business!

We didn't find it was that easy, but we have made it work. I thought it might be worthwhile to share some of the challenges and work-arounds we found in the process. This will take some time and space to document. I guess I'm going to have to write a sort of miniseries here...

No comments: