Understanding Multitarget Integration

Multitarget integration functionality is intended to support campuses that need to provision course roster information into more than one system. For example, they may have a secondary LMS that is used by one or more departments, or an individual faculty member may wish to provision her class into a Web 2.0 tool in addition to the LMS. While previous versions of the SAIP allowed more than one target to receive data, all targets would receive the same data on the same schedule. It was designed to support only one target. Multitarget integration provides a number of enhancements over the previous design:

It is now possible to use both the web service and LDAP bindings simultaneously.
Different course sections may be assigned to different targets.
Each target can have its own settings, for example, frequency and method of update (batch or event-driven), defined end points, etc.
Cascading preferences for targets may be set at the academic institution and academic organization levels.
Sections can be published to more than one target.
Grade return and event-driven updates are now supported on a per-target basis for the web service binding.
If a section is published to more than one target that supports grade return, then a preferred grade return target can be chosen.

Note: While SAIP does support publishing the same section to more than one target, it is advisable for performance reasons to limit the number of targets per section to two or three as a general rule. If sections are going to be provisioned to 4 or more targets on a routine basis, it may be advisable to consider using SAIP to provision into an Identity Management System.

Targeting

In earlier versions of SAIP, the process of selecting course sections for inclusion in the integration is called "scoping." Scoping is still present in SAIP, but there is also a second process called "targeting". Targeting is when one or more external systems (for example, an LMS, Facebook, a portal) are designated as the integration end points. The process within SAIP works as follows:

First sections are "set in scope," meaning that they are designated as ready to be sent to some external systems via SAIP.
Once they are set in scope, sections are then "targeted," meaning that they are assigned to specific external systems for integration.

Note: Course section records will not be sent until a course section has both been set in scope and targeted.

Targets may optionally support grade return. If a section has more than one target that supports grade return, then SAIP provides a functional interface to choose the preferred source of grade import data.

Target Versioning and Legacy Targets

The earliest version of SAIP web services only supported integration with a single target. The introduction of support for multiple targets necessitated some architectural changes and the way in which the SAIP interacted with targets; similarly, the introduction of new capabilities such as producer initiated snapshots and grade push integration also change the way in which you might need to think about the SAIP.

In defining targets, you will now see four versions of the web services: 1.0, 1.5, 2.0-2011, and 2.0-2012r1. In targets designed to work with the 1.0 service versions, no target identifier is included as part of the request/response interchange. If the target does not provide this request parameter, and if SAIP has a web service target set up to use the 1.0 version of the binding, then the system will assume that the requesting target is the one that has been identified as using the 1.0 binding. This is why SAIP can only support one target using the 1.0 web service binding. SAIP web services version 1.5 was modified to support multitarget integration, though it only supported a consumer-requested snapshot model. Because of this, target systems must provide target ID as a request parameter, to provide SAIP with a way to know which data set to prepare for the target.

SAIP services version 2.0 (2.0-2011 or 2.0-2012r1) support a producer-initiated snapshot model, which obviates the need for the target system to define and send a target ID as a request parameter. Instead, the targeting is specified using a set of IMS LIS attributes modeled after the WS-Addressing elements.

To assist you in properly integrating with targets supporting different levels of capability, SAIP includes a per-target binding version.

Note: In version 1.5 and 2.0 , SAIP does not distinguish between Create or Update messages. In version 1.5, any message other than a Delete is sent as a Create; in version 2.0 (2.0-2011 or 2.0-2012r1) any message other than a Delete is sent as a Replace, in compliance with the final IMS LIS specification.

Cascading Defaults

As with scoping, the targeting mechanism in SAIP has cascading defaults. For example, LMS A can be added as a default target to the PeopleSoft University academic institution and have it cascade down to the biology academic organization and the Biology 101 Fall 2010 class section. However, there are some important differences in the details of how the cascading defaults work:

Because multitarget allows one section (or academic organization) to have more than one target, it is possible to add targets at the academic organization or class section level in addition to the defaults provided at the academic institution level.
Combined sections inherit targets from all of their constituent sections.

If a target has been set for one of the combined sections, then it will apply to all of them.
For performance reasons, defaults set at the academic institution or academic organization level cannot be deleted at the section level.

Instead, they are inactivated.