Previous Topic

Next Topic

Book Contents

Book Index

Asset Integration: Checking Status Before Applying changes

When using the OLSA Asset Integration Service for catalog synchronization, adhere to the following coding best practice to handle specific exceptional circumstances.

Background

The following example illustrates at a high level how your LMS should execute the OLSA Asset Integration Service Initiate-Poll-Acknowledge cycle: 

set mode to ‘all’ or ‘delta’
set format to ‘aicc’ or ‘scorm’, etc…
loop (forever) { 
  try {
    handle = AI_InitiateAssetMetaData (mode, format)
    loop (forever) {
      sleep X minutes // polling interval
      try {
        resp = AI_PollForAssetMetaData(handle)
        exitloop // exit polling loop
      } catch (DataNotReady) {
        // stay in polling loop
      }
    }
    Retrieve file via URL in resp
    Process file
    AI_AcknowledgeAssetMetaData(handle)
    if mode==all then exitloop // performing 'all' exit main loop
  } catch (AnyException) { 
    try {
      AI_AcknowledgeAssetMetaData(null)
    } catch (AnyException) {
      // ignore
    }
  }
  sleep N hours // main Asset Integration Cycle interval
}

Exceptional Circumstance

There is a remote possibility that OLSA will return false positives for entitled, not_entitled and modified status values for content under the following scenario.

During the AI_AcknowledgeAssetMetadata() call, OLSA crashes and cannot process the request. If this occurs then on the next iteration of the Initiate-Poll-Acknowledge cycle, the LMS receives the same set of changes as in the previous cycle, plus additional changes that might have occurred in the interim.

Depending on the nature of the Acknowledge failure, the caller could see an OLSA GeneralFault or some sort of network exception. There really is no recourse for the LMS at this point. Nor should there be a need for recourse since the LMS has successfully processed its side of this cycle.

Recommendation

SkillSoft recommends coding the course processing loop defensively to make this exceptional circumstance transparent to your LMS. The LMS should first verify if the course is installed or uninstalled, then perform the respective install or uninstall action as shown in the following example: 

// course-processing-loop-B
while (there-are-courses-to-process-in-the-zip-file) {
  if (OLSA-course-status-is-entitled) {
    if (course-is-uninstalled-in-LMS) install the course;
  }
  if (OLSA-course-status-is-not_entitled) {
    if (course-is-installed-in-LMS) uninstall the course;
  }
  if (OLSA-course-status-is-modified) update the course;
}

If an a priori check is not possible, then SkillSoft recommends wrapping the install and uninstall actions in an exception-handling block so that the LMS can ignore the relevant exception that could occur as shown in the following example: 

// course-processing-loop-C
while (there-are-courses-to-process-in-the-zip-file) {
  if (OLSA-course-status-is-entitled) {
    try {
      install the course;
    } catch (AlreadyInstalledException) {
      //ignore
    }
  }
if (OLSA-course-status-is-not_entitled) {
  try {
    uninstall the course;
  } catch (NotInstalledException) {
    //ignore
  }
}
    if (OLSA-course-status-is-modified) update the course;
}

The update-action is an idempotent operation, which means the operation has no real impact, so you can perform the update redundantly without any special checking or handling.