Skip navigation
All Places > Blackboard Developer Community > Blackboard Learn Developers > Blog > Author: mkauffman

We've had several issues pop up we our support team tries to install a 'new' B2s from 3rd-party vendors onto a SaaS system and they can't upload the B2 into our SaaS B2 library. They can't because the vendor has given the B2 the same vendor ID, handle, and version in the B2 manifest included in the .war file that has already been assigned to a different B2 that has already been loaded onto some other client's SaaS system.


Background: There is a Blackboard B2 Library for SaaS. All B2s are stored there prior to deploying the B2 to SaaS systems. I.E. if I want my B2 with a vendor ID of Kauffman, and a handle (program name) of video-server and a version of 4.0.3 to be deployed to a client’s SaaS system, it first goes into Blackboard’s B2 Library for SaaS.


This single B2 library for SaaS will only allow one version of a vendor’s B2. I.E. If Vendor: kauffman, Handle: video-server, version: 4.0.3 is already in the B2 library, then kauffman-videoserver version 4.0.3 can NOT be assigned to a different build of the B2 for a different client and uploaded into the library.


This means that there can be only ONE version of a given B2 in the library for deployment to SaaS environments. A vendor can NOT develop a client-specific B2 and give the B2 the same vendor ID, handle and version that another client has already installed in SaaS. Each B2 given to Blackboard or a Blackboard SaaS Client MUST have a unique vendor ID, handle, and version value. The best practice for a vendor’s client-unique B2s in SaaS is to make the B2 configurable by the client to set some value that indicates which client it's deployed to, or even better, write the B2 code so it figures out who owns the system it's deployed on. To differentiate, one could also give client-unique versions of a B2 a different version or different program-id, or a different handle though that’s not best practice because it massively increases the number of the ‘same’ B2 in the library and makes it difficult to differentiate which B2 is meant for which SaaS system.

Once in a while a question comes in about where to find information on Behind the Blackboard. For example a case just came in asking if Q4 2018 is out and if so, where to find the download. If you're having difficulty finding information on like this, this brief video shows you how to find answers.


Happy New Year!


Adios PK1 Persistent IDs

Posted by mkauffman Dec 5, 2018

In previous Learn APIs (Java and SOAP) the database Primary Key served as a means of identifying Learn Objects. These Primary Keys, or PK1s, are used internally to the Learn system, but are no longer viable as unique identifiers for the objects bound to that database specific identifier.


As we continue rolling out our REST APIs we're working to improve API reliability and the longevity of applications build using them. Part of that decision is a move away from facilitating API use of PK1s as a means of accessing objects via the database primary key, i.e. the PK1, often referenced as the object's id in our APIs and REST results.


There are many compelling reasons for this decision, including creating a loose coupling between the Learn internal database and external code, thereby avoiding issues that inevitably arise when a system is migrated. Migrating a systems database generates new Primary Keys for the object data migrated, and thus created in the new database - this is a characteristic of databases. We may continue to include PK1s in REST results for Courses and Users for use in requests as a convenience*, but these PK1s should never be used as permanent external identifiers of Learn objects.


One example of this change as several have pointed out, is the difference between the soon-to-be deprecated SOAP and our REST membership endpoints. With SOAP calls to the CourseMembership endpoint returned a CourseMembershipVO that contained a field 'id' which is the PK1/ID. That data point is not available from the REST membership endpoints. This is because we have eliminated the id/PK1 field from the response returned by the REST GET/learn/api/public/v1/courses/{courseId}/users endpoints to meet the above stated goals toward reliability and longevity.


What do you use instead of the PK1?

What may have seemed like a good, solid identifier really is not. The way forward is to start using the different objects' UUIDs as returned in REST requests.


You need to replace any use of PK1 or ID as the unique identifier, whether using SOAP or Java APIs. When migrating your application to using REST APIs you may use a lazy identifier migration. In this model you may add the UUID field to your database and populate as you access those objects at runtime. If your code finds your UUID fields empty when making a Learn access, you use the courseID and userName you have to look up the UUID for the course membership, the UUID for the course, and the UUID for the user and populate those fields. Doing it this way eliminates the need for one mass migration, you get the new data as you go. If you see other creative means forward, please share here.


In summary, now is the time to start moving away from using API functionality that uses a PK1 or Database dependent object IDs and move to using the object’s UUID.


  *Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.

Here's a handy URL to have when for some reason the credentials you have for the front-end login to your Learn system don't work.  If you have back end access, this is like having a key hidden under the rock in your back yard. Run the tool and it gives you a one-time login to the front end so you can reset your username/password.


REST API Deprecation Process

Posted by mkauffman Oct 22, 2018

We've had questions come in regarding REST API v1 deprecation. The answers to these questions inline below:



   When it comes to V1 route deprecation what will be process of notifying the V1 route consumers?


   - What will be the notification process?


Deprecation of REST APIs take place only when a new version is released - the deprecation is noted on the API documentation page:



   - How long will it take to completely remove once notified? 


Removal of deprecated REST APIs from product will take place minimally* one year after deprecation is noted in the API documentation.

*In extremely rare cases this removal may take place sooner than one year - if that is the case it will be noted in the above noted documentation.



   - Will the V1 routes be removed from existing BB Learn instance versions?


Deprecated APIs will continue to work with releases prior to the Learn version from which they are removed.


E.G.: API is deprecated in 3300.0 and removed in 3400.0 - the deprecated API will continue to work with all supported Learn versions prior to 3400.0.


   - If not, from which Blackboard instance version upwards will V1 routes be removed and when is it scheduled?



See above.


Leave Some Breadcrumbs

Posted by mkauffman Oct 12, 2018

This one is for B2 developers. All of our current supported Learn builds have a left-navigation menu that comes and goes as you shrink and grow the browser window. Try it. Go into a course and shrink the browser window. You'll see the navigation menu disappear. Now grow the browser window and mouse over the left side of the window. You'll see an arrow that lets you make the navigation menu visible again. But, if your B2 is displaying content on the course page, without the bbNG: pageHeader and bbNG:breadcrumbBar tags, the left-navigation menu will disapper and you will not be able to get it back. Unless you reload the page.


This B2 has a sample course tool link which works correctly. GitHub - mark-b-kauffman/bbdn-bblogbackb2: Demo the use of Logback to create log files.


Here's a video demonstration: Dropbox - 2018-10-12_16-08-30.UseBreadcrumbs.KeepTheNavMenu.mp4


Leave some breadcrumbs!


It's Only A Model

Posted by mkauffman Oct 12, 2018

Camelot (it's only a model) - YouTube

Ok, this is not a blog post about silly movies. I'm writing because of a recent occurrence of difficulty noticing/finding a very important piece of our REST API documentation, the .... wait for it.... Model. As described below reading through the API Models can help reduce the number of REST API calls you make and improve your experience with Blackboard Learn REST endpoints in general.


Here we go. When you visit a REST API, you'll see the following Response Example Value.


All well and good. But! There is a lot of important information hiding under the greyed out Model link. See it? When you click on it, you see the following Model!



You really want to read all of that because... way down in the text you'll read:

Since: 3300.9.0

user (


The user associated with the membership.

Shown when adding the query parameter: "expand=user". And can be filtered with the "fields" query parameter, for example "filter=user.uuid,user.externalId".

Which means that you CAN get all of the information you'd like about users in a course when pulling course memberships, without making additional REST calls to the /users endpoint.


Be certain to check out the Models!

The Announcement! -->> Blackboard Deprecates SOAP Web Services


First - our forward looking statement applies to the information presented here*.


I'm writing this blog post because this week in our Blackboard Learn 9.1 Upgrade Cohort we mentioned our intent to announce deprecation of our SOAP Web Services near the end of this year. We also mentioned our intent to remove the SOAP Web Services from Learn within approx. a year of the deprecation announcement. There have been questions, specifically as to what is being deprecated. Here's a brief video giving the details about what will be deprecated: Dropbox - 2018-09-28_10-08-46BbSoapWSintentToDeprecate.mp4 Also, to be clear, the deprecation, and eventual removal, will only impact new versions of Learn – meaning that existing Learn releases will continue to support SOAP Web Services.


Finally, we need developers using SOAP Web Services to review the REST APIs now and contact us with any gaps that prevent them from migrating their SOAP-based application to a REST-based application. Reach out to us at


For additional context see:


*Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.

It's been a while, and this needs to be said. A few have asked about surfacing Building Block content in Ultra courses. You can't do that. B2 content can be surfaced in an Original course on an Ultra Nav-enabled system, but not in an Ultra course. The way into Ultra is LTI and REST. These offer advantages over B2 integrations in that you can code in any language, your integration is less dependent on the Learn server, and unlike a B2, the integration doesn't run in the same JVM as the Learn server. So, if you want to integrate with Ultra courses, check out REST , Blackboard's LTI Documentation and Basic Overview of How LTI works | IMS Global Learning Consortium


Not So Private

Posted by mkauffman Aug 13, 2018

By way of introduction, this an article about why you should migrate your B2 integration to LTI &/or REST.  With said, I started writing this article because of several B2 issues that have come up over the past year because of the B2's use of 'private' APIs. What is a private API? Simply stated, it's an API that a B2 can use, but it's not been published in our public Building Block API Documentation. Let's look at an example.


Some developers discovered, and have used this private API:



Our development team moved this Java API, and because it's private, they're under no obligation to inform anyone when they do so, or what they've done with it. Then, because it wasn't so private, B2s that used it fail in newer releases of Learn.


The good news is that we're developing and introducing REST APIs at a rapid pace, based on use case. If you have a use case that our APIs don't cover, you can submit submit your idea here. Our goal is to publish REST APIs that meet a majority of use cases, so you don't need to use a 'not so private' API.

Mark O'Neil, our Senior Product Manager, Developer Platform, and his team have been very busy in the past year! If you haven't been following the changes at Blackboard API Services, I'm writing this to give you a sense of what's new since last year around this time. Looking at our internal release notes and  the Learn SaaS Release Schedule | Blackboard Help I see that 3200.6 was released to client test systems near the end of June last year, and 3400.7 was released to client test on June 12th 2018. Given that, I see that we've released over 4 dozen new REST APIs in that period of time. Since the beginning of this year alone we've release many REST APIs that you will be interested in, including course assessments, LTI, course gradebook categories, and attempts. Head over to Blackboard API Services and check it out. And, a big thanks to Mark O'Neil and team!

Several partners have gotten stuck while attempting to update their Learn license. The help documentation needs an update for Windows. We're working on that.  In the meantime, if you're running Learn on a Windows server and run into issues updating your Learn license, do the following.


First, when updating the license, you need to refer to the section at the very bottom of the help documentation, "Upgrade a license without upgrading Blackboard Learn." Open a command prompt, as Administrator, and use the Blackboard Learn ServiceController script to stop all Blackboard services. Check that they are indeed stopped using the Windows Services control panel. Next, on your Windows server, do the following:


  • Rename the old license file: <path-to-blackboard>\blackboard\config\license\blackboard-license.xml to blackboard-license-OLD.xml
  • Copy the new license file to <path-to-blackboard>\blackboard\config\license\blackboard-license.xml
  • cd into the <path-to-blackboard>\blackboard\system\tooldefs\system\LicenseReplace directory
  • .\run-tool.bat  <path to blackboard>\blackboard\config\license\blackboard-license.xml

If you're attempting to build an LTI tool provider that supports Deep Linking aka Content Item Messaging and you see the following symptom described in Behind the Blackboard!


"LTI TP posts back to /webapps/blackboard/controller/lti/contentitem fails. When posting back to /webapps/blackboard/controller/lti/contentitem Learn fails with "The specified resource was not found, or you do not have permission to access it."


You can fix the issue by addressing two items in your code:

a) Blackboard Learn sends an optional "data" field with the LTI launch. Be certain you pass it back to Blackboard Learn.

b) The ContentItemSelection request sent to BB must be signed. You can check your signature with a tool like:

c) When checking the signature of the content received at your tool provider, unescape the content then create the signature to check. Do not sign the content before it has been unescaped. I.E. if you try to check the signature of content containing &quot; the signature will not match because Learn signed it when that character was represented as ".  The same holds in the other direction. Learn expects the content to be signed before the Tool Provider escapes the HTML. To be clear - we're talking about this type of HTML Escape/Unescape - Free Online HTML Escape / Unescape Tool -  Also, when you want to send an empty value to Learn, avoid null. Use "" instead.


Lastly, after calculating the signature, be certain to escape the content posted back to Learn, not encode it. As an example, for the " character use &quot; not %22.


The Partner that originally reported the issue got back to us and said they did the following above two items to their Tool Provider code to resolve it. In the meantime our automated processes created a known-issue article, then when the bug was closed by our LTI engineer as unable to reproduce it was set as being resolved in 3400.1.0. It's not a bug and functions as designed in all versions of Learn that content-item messaging is available.


Note: We've certified Blackboard Learn as an LTI Tool Consumer. If you have issues with your Tool Provider code and Blackboard Learn, our engineering team requests that you first certify your Tool Provider using the Learning Tools Interoperability Certification Suite | IMS Global Learning Consortium  - before bringing the issue to Blackboard.

tl;dr configuring REST in Learn and why doesn't my REST APP authorize with a Learn system that has a self-signed cert? Here's a video with a few pointers. Thanks for watching! Dropbox - RegardingSSLcertsAndRestIntegrationTool.mp4

I'm writing this to share how you can determine whether a given REST API is available in a particular Learn Release. I'm sharing this because we've had several queries, this should make it clear. If not, please do provide feed back in the comments section.


We'll use POST /learn/api/public/v1/courses/{courseId}/gradebook/columns as an example as this is a REST API one partner asked about.


Start by looking at and click the Explore button on the page. Look through the APIs and find course grades. Expand the API of interest by clicking on it.  In this case, POST /learn/api/public/v1/courses/{courseId}/gradebook/columns Notice Since: 3000.7.0 This is the build number that the POST REST API for gradebook columns was released. IMPORTANT: We never back port REST APIs. A cumulative update will not include a REST API release in a later build number. Example: 3000.0.9 will not include the POST gradebook/columns API.


Next, check this community post which explains how one can map recent Learn Releases (Q4 2016, ... etc.) to Build Numbers (3100.0.3, ... etc.).


The Build Number is what determines whether a REST API is available. The REST APIs are never backported via a cumulative update. We see that 3000.1.X is the build number for all Q2 2016 releases. The POST REST API for gradebook is not available there. The build number for all Q4 2016 releases and up is 3100 and greater. The POST REST API for grade book is available for all of these as we saw that is is available since 3000.7.0.


In conclusion, you should now be able to find out when any REST API became available for any QN YYYY release of Learn. For example, can you figure out which Learn releases now have the GET /learn/api/public/v1/courses/{courseId}/gradebook/columns/{columnId}/attempts API?


Happy New Year!