LIS translators are a way to translate LIS requests into generic IPSIS requests. This allows IPSIS to always use a common language to communicate with Brightspace instead of having LIS (and other standards and proprietary solutions) directly interact Brightspace. This also allows a single set of handlers that can be used regardless of the SIS Integration solution (LIS, SIF, Proprietary).
In most cases a collection of translators are used together (referred to as a configuration list), each doing their part to complete a task. Since each translator does a small part they can be easily configured in different ways to provide a very flexible range of alternatives depending on a specific institution's business need.
Translators are implemented using LIS translator conventions, which will help organizations understand the many translator options that are available.
The LIS adapter defines a collection of translator interfaces that are specific to the types of objects being sent from the SIS via LIS requests. Each interface has a set of translators that implement the interface in order to apply a specific translation/mapping rule. In most cases, there are not a lot of translators to choose from because the mapping rules are generic and re-usable (for example, Course Start Date), however in other cases, there are many translators because the LIS message contains many fields that may be appropriate to map to a Brightspace field (for example, Course Title).
The translator interfaces are defined within the LIS adapter, and are used by the individual LIS Services. Each of them has their own documentation containing descriptions of the available translators for the interface, as well as some template configuration lists for the translators which represent common configuration scenarios.
LIS translator naming conventions
Translator names are intended to be descriptive and include enough detail to indicate what fields are being translated, as well as whether the translator is required or optional. In most cases the translators to do only the minimal amount of work so that they are as re-usable as possible.
Only one of the following terms is used in the name of a translator:
- Use Base in the name to indicate it's a base translator (also implies that it or an alternative base translator is required)
- Use Required in the name for required fields
- Use Optional in the name for optional fields
The overall structure of the name of a translator is as follows:
<request name><mapped to (sometimes used)><fields translated><base, required, or optional>Translator
Examples
- CourseSectionRequestBaseTranslator:
- This is for a CourseSectionRequest.
- This is the Base translator.
- CourseSectionRequestDepartmentRequiredTranslator:
- This is for a CourseSectionRequest.
- This translator will attempt to grab the Department field from the LIS request.
- This is a Required translator (it will throw an exception if the Department field was not populated in the LIS request).
- CourseSectionRequestSemesterOptionalTranslator:
- This is for a CourseSectionRequest.
- This translator will attempt to grab the Semester field from the LIS request.
- This is an Optional translator (it will not throw an exception if the Semester field was not populated in the LIS request).
- CourseOfferingRequestDepOrgNameOptionalTranslator:
- This is for a CourseOfferingRequest.
- This translator will attempt to grab the OrgName field from the LIS request, and map it to the Department field in IPSIS.
- This is an Optional translator (it will not throw an exception if the Semester field was not populated in the LIS request).
LIS translator design pattern conventions
LIS translators follow a simple separation of concerns design pattern. Any given translator should only map its desired field. A translator that maps names, should not also map addresses. Most requests will have a series of translators that run in succession, each mapping a different area of fields. The first translator in the series is a Base translator that initializes the translated result object, and populates it with base elements of the request.
Any following translators must be either Required or Optional. This indicates whether the translator throws an error if a field is missing. For example, the CourseSectionRequestDepartmentRequiredTranslator returns an error if no Department is passed in the request. On the other hand, the CourseSectionRequestSemesterOptionalTranslator0 just keeps moving along if no Semester is passed in the request (the field on the result remains uninitialized).