Integration type restrictions on data management have been removed. It is no longer significant whether data was originally created using the command line tool, the GUI, or another SIS integration. Integration types are now capable of mapping data between integration types. Administrators can create Learn objects using one integration type and manage that data with another.
Before the introduction of the SIS Framework some clients relied on the ‘remove data if not present in file’ capabilities of the command line *_snpsht tool command. This tool in combination with the granular data operation provided through the Data Source was used as a means of removing data from Learn while also creating or updating data. Prior to SP 12 and it’s related enhancements there was no means to provide this function in a way that aligned with client experience and existing data management processes.
This is addressed in SP 12 through the addition of new Snapshot Flat File endpoint URLs supporting the use of DSKs in complete refresh operations. The “-Complete Refresh by Data Source” tag on the Operation name identifies these new endpoints and the “refreshlegacy” on the endpoint URL. For example:
|Course - Complete Refresh by Data Source||https://server.name/webapps/bb-data-integration-flatfile-BBLEARN/endpoint/course/refreshlegacy|
Complete Refresh by Data Source support is achieved by having an integration available for each DSK where complete refresh is needed, and using the new endpoint for that integration to run those refresh operations. Each DSK requiring refresh-based support must be represented as a configured integration. For example: To perform complete refresh by data source operations on data with three DSKs of courses.fall, courses.winter, courses.summer requires the creation of three Snapshot Flat File integrations where the integration DSK is set to one of the three target DSKs in use.
Complete Refresh by Data Source is supported only in the context of the endpoint URLs and not manual feed file uploads.
A new field mapping control for moving cross-listed enrollments allows administrators to tell Learn how to handle conflicts when attempts are made to enroll users in more than one course in a cross-listed set of courses.
Since users can only be enrolled in one course in a cross-listed set of courses at a time, if a SIS integration feed attempts to enroll a user into a course in a cross listed set of courses for which the user is already enrolled, the move cross-listed enrollment setting is used to determine whether the integration will automatically move the student to the other course, or deny the operation and preserve the original enrollment - a warning will be logged in the SIS Integration log in this scenario.
To learn more see Student Information System (SIS).
The SIS Framework Snapshot Flat File integration type now allows the DATA_SOURCE_KEY header for providing the DSK for the record - this replaces NEW_DATA_SOURCE_KEY which previously provided this setting while changing the DSK if different. In SP 12 and later, if you wish to provide the DSK in your data feed use DATA_SOURCE_KEY and if you want to change the record DSK use both DATA_SOURCE_KEY and NEW_DATA_SOURCE_KEY.
To learn more, see Snapshot Flat File Header Descriptions.