We are currently in the process of uploading a few courses (built in Rise) into a new LMS community. Some slight changes have been made to the courses which have required them to be republished.
It seems only the courses that have recently (last 48 hours) been republished in Rise (TinCan API) are not completing in our LMS.
We have confirmed completion is still achievable on existing courses build in Rise but not in courses that have been republished recently.
Hi there, Ben. I see that you opened a case with our team as well. Darrell advised that you check the course on SCORM Cloud, and to check in with your LMS as well.
Please reply back to Darrell with additional findings or thoughts - we'll be happy to keep helping!
Please see response below from our vendor after following up with LRS suppier Rustici.
Here is what they have come back with;
"I see the issue, I believe. The 400 responses you saw in the screenshot are the culprit, as they are showing that we are not saving the state that the course is trying to set. The error message that is in the response indicates the problem -- there is an extra parameter coming back with the request that is not expected by Engine. In its default configuration, the LRS will reject requests with 'unexpected' parameters.
I looked at the tincan.xml manifest for the course you posted, and I see this:
You can see the course has included a value as a url parameter (looks random?). When the course launches, it is built to take any parameter passed to that start page and reflect it back in the requests it makes to the LRS. It does this because that's what is required by the guidelines for Tin Can launches.
I'm guessing that your older packages did not have this generated value on the launch url like this, and so did not fall afoul of our validation in Engine. You have three choices, really:
1. re-import the course without that parameter (and figure out why it's there)
**This is the option we have chosen to implement which requires manipulation of the Rise published course prior to import to the LMS.
2. If it's a static, known value, you could add it to xAPIPostProcessContextParameters setting in Engine so that we would 'expect' it. You'd want to take the default value for that setting, and then add your value to the list (ie, the value you'd set would be something like ""top , left , content_token , width , content_endpoint , height, Content-Length, eyJjcHYiOiJ1bEVEQ0VGbCIsInJsZCI6ZmFsc2V9").
3. You could configure Engine to not validate the existence of 'unexpected' parameters. To do that, you would configure the xAPIValidations setting to have the value "AttachmentContentTransferEncoding, SignatureContentType, IdenticalDocumentsCanConflict, StatementSchemaValidation, StatementSchemaValidationIncludingInteractions, NewDocumentsRequireETag", which is the default list minus the NoUnexpectedParameters item.
It likely works in Cloud because they've done option 3 in order to allow slightly naughty content to still work. That is probably the easiest short-term solution, as I doubt option 2 will work with the random nature of the value I'm seeing on your url.
What's interesting is we've just had another customer run into the exact same thing. It makes me wonder if Rise has just recently started adding that random string to their launch urls."
Hi there, Ben! Thanks so much for including this detailed information.
We recently released an update in Rise 360 that inadvertently added an additional parameter to the <launch> string. The string normally looks like this: <launch lang="en-US">index.html?</launch>
But after the update, we started seeing this: <launch lang="en-US">index.html?eyJjcHYiOiJzdXVpU3dJcSIsInJsZCI6ZmFsc2V9</launch>
We quickly reverted the change on March 31st. Please re-export your TinCan (xAPI) courses experiencing this issue, and let us know if that solves it.
3 Replies
Hi there, Ben. I see that you opened a case with our team as well. Darrell advised that you check the course on SCORM Cloud, and to check in with your LMS as well.
Please reply back to Darrell with additional findings or thoughts - we'll be happy to keep helping!
Please see response below from our vendor after following up with LRS suppier Rustici.
Here is what they have come back with;
"I see the issue, I believe. The 400 responses you saw in the screenshot are the culprit, as they are showing that we are not saving the state that the course is trying to set. The error message that is in the response indicates the problem -- there is an extra parameter coming back with the request that is not expected by Engine. In its default configuration, the LRS will reject requests with 'unexpected' parameters.
I looked at the tincan.xml manifest for the course you posted, and I see this:
<launch lang="en-US">index.html?eyJjcHYiOiJ1bEVEQ0VGbCIsInJsZCI6ZmFsc2V9</launch>
You can see the course has included a value as a url parameter (looks random?). When the course launches, it is built to take any parameter passed to that start page and reflect it back in the requests it makes to the LRS. It does this because that's what is required by the guidelines for Tin Can launches.
I'm guessing that your older packages did not have this generated value on the launch url like this, and so did not fall afoul of our validation in Engine. You have three choices, really:
1. re-import the course without that parameter (and figure out why it's there)
**This is the option we have chosen to implement which requires manipulation of the Rise published course prior to import to the LMS.
2. If it's a static, known value, you could add it to xAPIPostProcessContextParameters setting in Engine so that we would 'expect' it. You'd want to take the default value for that setting, and then add your value to the list (ie, the value you'd set would be something like ""top , left , content_token , width , content_endpoint , height, Content-Length, eyJjcHYiOiJ1bEVEQ0VGbCIsInJsZCI6ZmFsc2V9").
3. You could configure Engine to not validate the existence of 'unexpected' parameters. To do that, you would configure the xAPIValidations setting to have the value "AttachmentContentTransferEncoding, SignatureContentType, IdenticalDocumentsCanConflict, StatementSchemaValidation, StatementSchemaValidationIncludingInteractions, NewDocumentsRequireETag", which is the default list minus the NoUnexpectedParameters item.
It likely works in Cloud because they've done option 3 in order to allow slightly naughty content to still work. That is probably the easiest short-term solution, as I doubt option 2 will work with the random nature of the value I'm seeing on your url.
What's interesting is we've just had another customer run into the exact same thing. It makes me wonder if Rise has just recently started adding that random string to their launch urls."
Hi there, Ben! Thanks so much for including this detailed information.
We recently released an update in Rise 360 that inadvertently added an additional parameter to the <launch> string. The string normally looks like this:
<launch lang="en-US">index.html?</launch>But after the update, we started seeing this:
<launch lang="en-US">index.html?eyJjcHYiOiJzdXVpU3dJcSIsInJsZCI6ZmFsc2V9</launch>We quickly reverted the change on March 31st. Please re-export your TinCan (xAPI) courses experiencing this issue, and let us know if that solves it.