Rise Courses not completing

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."