blackboard sis framework initial impressions

Fri, Nov 18, 2011

I’ve been playing around with the Blackboard 9 SIS framework which basically consists of a simple REST service that accepts IMS 1.1 XML records and punts them to the internal gubbins that does the actual processing. I was advised that it’s a separate system from Blackboard itself, in that, if you create users using the normal Blackboard User tool, then SIS won’t know about them and cannot update/delete them. My initial testing has disproved this but there is a subtle gotcha. If you create a user using the User tool, you cannot use the SIS to enrol them on courses. To do so, you must first ‘reconcile’ them by updating them using the SIS. The SIS will then known about them and will be able to enrol them accordingly.

Setting up your SIS is a two step process and is fairly simple:

  • System Admin -> Data Integration -> Data Sources -> Create Data Source. Give it a Key and a Description. I called mine MATRIX as I’ll be using the Matrix provisioning system to drive it.
  • System Admin -> Data Integration -> Student Information System Integrations -> Create Integration. I created an IMS Enterprise 1.1. This lets you send IMS 1.1 XML to it. Fill in the fields and point it to the MATRIX data source created earlier. All account messages sent to its URL will be associated with the MATRIX data source from then on. Once it’s created, you can click on the chevron next to it to get its HTTP Information. Use this info to send it stuff.
You can use this handy curl script to send your new SIS integration IMS 1.1 XML messages:
curl -vv -k -w %{http_code} -H “Content-Type:xml” -u USERNAME:PASSWORD 
–data-binary @./person.xml ENDPOINT
To create a user you send it IMS 1.1 XML in person.xml:
<?xml version=“1.0” encoding=“UTF-8”?>
<enterprise xmlns:webct=“">

<properties> <datasource>MATRIX</datasource> <datetime>2011-20-10T17:06:36</datetime> </properties>

<!– 1 = Add, 2 = Update, 3 = Delete > <person recstatus=“1”> <sourcedid> <source>MATRIX</source> <id>testuser</id> </sourcedid>

<userid password=“d4-ju7f”>testuser</userid> <name> <!– This fn is ignored –> <fn>Test User</fn> <n> <family>User</family> <given>Test</given> </n> </name> <email></email>




There are two options for updating a user. Either set person/recstatus=“2” or omit person/recstatus and set the integration to use smart updates. It will then decide whether to create or update the user accordingly. You can send the original create message with updated fields to update the user but it will ignore the password.

This is what a delete message looks like:

<?xml version=“1.0” encoding=“UTF-8”?>
<enterprise xmlns:webct=“">

<properties> <datasource>MATRIX</datasource> <datetime>2011-20-10T17:06:36</datetime> </properties>

<!– 1 = Add, 2 = Update, 3 = Delete –> <person recstatus=“3”> <sourcedid> <source>MATRIX</source> <id>testuser</id> </sourcedid> <datasource>MATRIX</datasource> </person>


There is quite a big problem with SIS though. There’s a disconnect between the SIS front and backends as no matter what you send the SIS it returns “HTTP 200 OK”, even if you send it rubbish. I submitted a bug report to Behind Blackboard and they replied that this was FAD (Functioning As Designed) and they saw no reason to change it. The SIS web service just acknowledges it got ‘something’. It doesn’t care what it gets as it’s happy to pass garbage to the backend, which then either logs a crash or logs the message if it can parse it.

The major problem with this is that you can’t use the SIS in a real-time provisioning system that requires auditing and preemptive action on account failures as in SIS land, there are no failures, ever. The only failure you can detect is SIS offline. Even if the SIS front end is the last man standing and the rest of Blackboard has been taken out, it will still return 200 OK.

I suspect SIS is primarily designed for manual integration as Blackboard advised that it should be used in conjunction with the system administrator sitting in front of their machine, keeping an eye on the error count. The problem is, if you send a corrupt message to SIS you cannot tell which account has failed, even from the logs as the account info is locked inside the corrupt message which cannot be parsed and all you get is a Java Exception trace. The medieval thing about it is it needs a person to watch it and if the backend burps and stops working, you’ll never know about it until the complaints of no access flood in, unless you’ve tied your sysadmin to their chair.

There is some light at the end of the tunnel though, as you can develop your own frontend to the SIS backend and here are some handy resources which I’ll be looking at:

comments powered by Disqus