Content can communicate with Plateau using one of two technologies:
- a direct HTTP Post
- a client-side API
AICC content uses direct HTTP posts to send information to Plateau
SCORM content uses a client-side API
The Plateau Tracking Functions can use either direct HTTP posts or a client-side API. When content is using a client-side API for communication, that content must be hosted under the same DNS as the API it is attempting to use. If the content and the API are hosted under separate DNS names, the browser will prevent them from communicating.
It is important to note that this is not a Plateau specific issue. It is a restriction that is inherent in the SCORM communication standard.
In the diagram above, the content and the API's are hosted under the same DNS.
As a result, the content can access both the SCORM and Plateau Tracking API's for communication.
In the diagram above, the content and the API's are hosted under separate DNS names, preventing them from
communicating with one another. Under this scenario, only direct HTTP posts may be used for communication.
If it is necessary to host your content under a separate DNS, several solutions exist to work around the cross-domain restriction. ADL, the writers of the SCORM spec, have compiled a collection of potential solutions for the cross-domain issue. This paper is available on the ADL web site (http://www.adlnet.gov):
Solutions discussed in the ADL paper fall under three categories:
- Combination LMS and content solution
- Network architecture solution
- LMS-based solution
SuccessFactors Learning Management System (LMS) - All Supported Versions
One common network architecture solution to work around the cross-domain restriction is the reverse proxy. This is essentially a proxy server that sits in front of the LMS and any content servers in your environment. All requests for the LMS or content are routed through the reverse proxy and are forwarded to the appropriate servers based on the context of the request.
For Example, if your network contained the following servers:
- LMS = http://lms.customer.com/learning/user/login.jsp
- Content Server 1 = http://content.customer.com/content1/course_x/sco_x.htm
- Content Server 2 = http://content2.customer.com/content2/course_y/index.htm
A reverse proxy server (http://revProxy.customer.com) could be added to your network with the following rules:
- route any "/learning" request to http://lms.customer.com/learning
- route any "/content1" request to http://content.customer.com/content1
- route any "/content2" request to http://content2.customer.com/content2
This would allow a user to use the following reverse proxy requests to access the LMS or content:
- LMS = http://revProxy.customer.com/learning/user/login.jsp
- Content Server 1 = http://revProxy.customer.com/content1/course_x/sco_x.htm
- Content Server 2 = http://revProxy.customer.com/content2/course_y/index.htm
The browser would see the content and the LMS as coming from the same DNS and thus the cross-domain restriction would not apply.
SCORM (and some AICC) content expects your Learning Management System (LMS) to be in the same Domain Name Space (DNS) as your eLearning content. If you host your content on another server other than Success Factors, a solution needs to be set up in order for this to work.
The proxlet is a set of files you install on your content server that enables your SCORM content to communicate Cross Domain back to LMS using a trusted server to server communication. It makes the content believe it is located on the same server as the LMS and allows content to be taken and tracking to work.
In Plateau 5.5 an entirely LMS-based solution (no changes required in the content) was introduced. This solution resolves the cross-domain restriction by placing the communication APIs on the content server and relies on a communication proxy (proxlet) on the content server to relay tracking data back to Plateau (section 1.3.8 of the ADL document). It can be thought of as placing part of the LMS, needed by the content for communication, on the content server. This solution is enabled via the LMS configuration files, and requires additional settings at the content object or question object level.
This solution resolves the cross-domain restriction for the following APIs:
The diagram above shows the LMS-based solution introduced in Plateau 5.5. The content and the APIs are loaded into a
wrapper. The APIs communicate back to Plateau via a communication proxy running on the content server.
Document Domain Manipulation
Plateau 4.1 introduced a cross-domain configuration setting in the LMS configuration framework. This setting allows a user to set the domain of the SCORM and Plateau Tracking API's to a root domain. For instance, the diagram above has the API's hosted under LMS.PLATEAU.COM, so Plateau could be configured to host the API's under PLATEAU.COM (it is not possible to specify just COM as a domain).
Or this code can be used to dynamically set the domain to the top root-level domain. For instance, if the domain was MY.CONTENT.SERVER.PLATEAU.COM, this code would set the domain to PLATEAU.COM.
midDotLoc = document.domain.lastIndexOf('.');
dotLoc = document.domain.lastIndexOf('.',midDotLoc-1);
Once the Plateau API domain and the content domain have been set to a common root, the cross-domain restriction no longer applies. and the content will be able to access the APIs.
- Plateau Tracking
SF SuccessFactors LMS Learning Cross domain cross-domain communication restriction , KBA , LOD-SF-LMS , SuccessFactors Learning , LOD-SF-LMS-CNT , Content , How To