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.