Back-end Application Structure

Overview

The back-end Subject Management code is encapsulated in a single application: mit-subjects. This is a Mule application hosted on CloudHub. (CloudHub is a part of Anypoint Platform which is a product of MuleSoft. CloudHub ensures availability and security and also manages the security and configuration of the applications hosted on it. More details on Mule CloudHub can be found at https://docs.mulesoft.com/runtime-manager/cloudhub-architecture.  Through the Runtime Manager, it allows you to deploy sophisticated cross-cloud integration applications in the cloud.)

mit-subjects contains the following distinct components:

• Subject Management API
• CIM Courses Inbound Feed
• CIM Courses Outbound Feed
• User Provisioning Feed
• Backfill

Although they reside in the same application, the components were implemented as separate, independent processes.

mit-subjects API vs Subject Management API

IS&T typically refers to all of the endpoints exposed by a mule application as the <name of mule application> API. Hence, the IS&T Developers' Portal lists the MIT Subjects API.

For the purposes of this documentation, we wanted to draw a clear distinction between those endpoints that read and write from the CTSS and the other endpoints and processes that live in mit-subjects. We are using Subject Management API to refer specifically to the set of endpoints that read and write from the CTSS.

Thus, the Subject Management API is a subset of the MIT Subjects API. The latter includes other endpoints, such as the on-demand MITSIS backfill endpoint and the endpoint for generating the CIM outbound feed.

"Calling" endpoints

Conceptually, the CIM Inbound Feed Processing is interacting with the CTSS the same way that a client that does not reside in mit-subjects would: by calling endpoints in the Subject Management API. Similarly the Subject Management API uses the same "on-demand" endpoint provided by the MITSIS backfill code to backfill cross-registration subjects immediately.

For performance reasons, we elected not to incur the overhead of an http call when the endpoints are being called from within the mit-subjects application. Instead, the calling code creates flowVars for any URI or query parameters and then calls the flow that is mapped to the endpoint in the APIKit router. Note: the endpoint flow uses a separate database transaction from the calling flow.

The following diagram illustrates both an external client and the CIM Inbound Feed processing using the Subject Mangement API "search by container id" endpoint.

[Image source: https://wikis.mit.edu/confluence/pages/viewpage.action?pageId=133695562]

Batch process authorization

Any authorization checks occur after the APIKit Router directs the message to the endpoint flow. This means that the authorization check will occur when any of the components in mit-subjects "calls" the flow. When the calling component itself was invoked with an HTTP request, the authorization flowVar created by the Roles Policy for the incoming request will be used in the "called" flow's authorization check. (See MIT Subject Management API - System rules for Security for more info on Roles Policy usage and the authorization checks used by the Subject Management API.

In the case of a batch process, the calling process creates its own authorization object and sets it as a flowVar. The flowVar name and data type must match what is produced by Roles Policy so it will work with the same authorization check code.

Running mit-subjects locally

Instructions can be found at https://www.dropbox.com/s/1b4ctpdix7lnj68/MIT_SUBJECTS%20_%20Setup_Dev_Environment.docx?dl=0

Subject Management Documentation Index

The Subject Management Documentation Index is the central listing for documentation pertaining to Subject Management.