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:
<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@example.com</email>
</enterprise> 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:
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: