SCORM Engine Local Web Services is becoming SCORM Engine


Over the years we’ve had a number of different methods for integrating the SCORM Engine with our customers’ applications. One of the more interesting approaches we’ve used involved making the Web Service APIs that SCORM Cloud uses available on premise for our customers that preferred that to our older source code style solution. We call this SCORM Engine Local Web Services (LocalWS) and the response we’ve gotten over the years has been extremely positive.


We’ve spent a lot of time over the last year taking this feedback and using it to guide the design of our core product, SCORM Engine. What this means for SCORM Engine is that the primary method for integrating with the application is being moved to a set of REST web services that represent the core integration concepts our customers have come to understand. We think this will be faster and easier for all of our customers.


What does this mean for you?

So, what does this mean for you, the LocalWS customer? LocalWS, the on premise version of the SCORM Cloud API, is officially deprecated. Most important details first, you can keep using the application as your license allows without upgrading if you like. We’ll continue to answer your questions and help you use the application. What we won’t do is backport bug fixes and new features. However, we’ve spent a lot of effort over the last year making sure we can support a relatively painless upgrade path for you, our LocalWS customers.


LocalWS has been using SCORM Engine’s 2013.2 release for a long time now. The upgrade path we’ve been working on will bring those LocalWS customers up to SCORM Engine 2016.1 with all of the benefits that new version makes available. You’ll find a detailed list of what new items have landed in SCORM Engine since 2013.2 below, but I know you’re wondering about what is lost, what has changed, and what upgrading looks like.


First, what’s lost?

We hope that nothing is lost. We’ve built the Web Services for SCORM Engine based on the existing SCORM Cloud and LocalWS API usage patterns. Our goal is to be able to provide replacements for all of the most popular API calls our customers have been using. It’s possible you’re using an API we haven’t provided a direct replacement for. In that case we’d expect to identify these as we walk your technical team through the upgrade process. In most cases we’ll be able to provide alternative approaches to solving your problem or make additions to our REST resources to enable the same functionality.


What does your team’s level of effort look like?

First, you’ll be running our upgrade tool just like all of our other customers. Your existing data will be moved from a system using AppIDs to a new concept in SCORM Engine called Tenants. You’ll use your existing AppIDs when communicating with the SCORM Engine API to tell the application which tenant you’re communicating on behalf of. Next, your technical team will replace API calls in your application with new API calls. Lastly, you’ll need to handle the data coming back from the SCORM Engine differently as the application moves from XML as the structure for moving data around to JSON.

Don’t worry if all of this is unclear

We approach customer upgrades as internal projects where we have one of our developers help you through the process by gaining an understanding of your integration and data. We’re more than happy to talk to your tech team and work with them to make the transition as painless as possible when you’re ready to upgrade.

What’s new for LocalWS Customers in Engine 2016.1?

  • Support for cmi5
  • xAPI overhaul to improve performance and conformance
  • Responsive Default Player UI
  • Improved Postgres support
  • Improved Oracle support
  • Security Fixes

Please contact if you have any questions.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request
Powered by Zendesk