Understanding CTM
The CTM framework is used for performing Campus Solutions transactions that require staging of the data prior to posting to production tables.
Staging of the data is done with the use of temporary records (staging records) that mimic the production records. Because transactions normally include constituent data, CTM standardizes the handling of that data and offers a framework to process the data that is specific to the transactions. Constituent data includes data related to the person available in the Campus Solutions data models. Examples of constituent data include Name, Gender, Address, Email and Driving Licenses.
The following diagram shows that a CTM transaction contains constituent data and transaction-specific data.
Image: Representation of how CTM separates the data included in a transaction
CTM and transaction data
By staging data into temporary records prior to saving into the appropriate production records, CTM assures consistency for handling and processing the data and offers configurability to adjust to all transactions specificities.
A transaction defined with CTM can be online (web-based transactions performed by a self-service user) or offline (through batch loads). In the case of transactions performed online, temporarily saving the data entered by a self-service user allows for data retrieval when the user returns to complete the transaction. Temporarily saving the data also allows for full completion of a transaction even when the system has not assigned an EMPLID to a person. For example, if an online transaction takes too long to complete, the self-service user can save the data and come back later. The data entered is saved into the staging tables and can be retrieved when the user comes back to complete the transaction. When finally submitting the transaction, all data stays saved inside the staging tables until Search/Match is called to identify an EMPLID. CTM keeps the data in temporary tables, thereby allowing full completion of a transaction.
An external user interface can use CTM with the New User Registration functionality to create a user profile for a guest user or to authenticate a returning user.
See Understanding New User Registration
When a transaction is generated, the system uses Search/Match or External Search/Match to look for constituent data in your production environment (based on the Search/Match parameters) that matches the constituent data in the transaction. Each defined CTM transaction can have its own Search/Match setup. You can therefore determine the rules for creating a new ID, updating an existing ID, suspending or ignoring a record. CTM validates the constituent data entered as well as the data entered for the transaction itself. The system stores the constituent and the transaction-specific data in staging tables. If there are validation errors or if Search/Match determines that the incoming constituent record should be suspended or ignored, use the Constituent Staging and the transaction staging components to correct the data. When the staged data passes all validations, CTM posts both the constituent and the transaction-specific staged data to the predefined production tables. The posting is done based on rules that you define through the Data Update Rule functionality. You can post transactions individually or by batch to the Campus Solutions database.
See Processing Staged CTM Transactions.
CTM offers three ways for processing the staged data and posting to production records:
Realtime: At the time the self-service user saves or submits an online transaction.
Manual: At the time an administrative user individually reviews the staged data using the Constituent Staging component or using the transaction staging component and manually posts the constituent and/or the transaction-specific data to the production table.
Batch: Using the Transaction Management process to post multiple staged rows at the same time. The Transaction Management process can be used for online transactions for which you do not want to do real-time processing or for data loaded through a batch utility such as the File Parser.
CTM uses web services and a number of application classes to facilitate the staging and posting of constituent and related transaction data into appropriate production tables. To do this, CTM takes full advantage of the Entity Registry framework. All constituent and transaction staging records are tied to an Entity Name.
See Setting Up Entity Registry.
The CTM framework can be seen as a provider of processing services and the CTM transactions as consumers. At the time of delivering the CTM framework, the following consumers of CTM are delivered with the system:
Admission Applications Web Service (AAWS) admission transaction.
New User Registration framework.
UCAS batch process transaction used by the United Kingdom customers.
Delegated Access (DA)
Prospect Data Loads (PDL)
Note: The delivered consumers of CTM are fully implemented and with some required setup, they are ready for you to use. They are also referred as CTM transactions. The delivered consumers are documented in their respective sections. To create new consumers of CTM, see Developer Reference for Creating a New CTM Consumer.
CTM Framework
CTM framework enables you to set up your own transactions or create your own consumers, whether they are to be performed online by a guest, a self-service user or an administrative user, or performed by batch. This section explains how to set up CTM, how to create your own transactions by taking full advantage of CTM framework, and how the constituent and the transaction-specific data are processed from staging to production tables.
Examples of transactions that CTM can process:
Batch transactions (offline transactions): Transactions that come from an external file that needs to be staged to first allow data processing specific to Campus Solutions and to trigger Search/Match to avoid entering duplicates into the system. Because you do not necessarily know the quality of the data contained in the file and want to make sure to avoid creating duplicates, keep the file data in the temporary tables, and when ready post to the appropriate production tables.
Self-service transactions (online transactions) that can take too long to complete and therefore should allow the self-service user to Save and come back later to continue and Submit. The saved data, because incomplete and potentially contains erroneous information should be staged and not be posted until the transaction is submitted and free of validation errors. Saving the data into temporary records allows you to display the previously entered information when the self-service user comes back to complete the transaction.
Self-service transactions (online transactions): You created your own web-based online transaction that can be accessed and performed by anybody in the world. Your institution may or may not know these users and they may never complete their transaction. Using CTM, the system stores the entered information into temporary tables and performs Search/Match or External Search/Match to identify an EMPLID. The data is only posted to the production records when the self-service user is serious and confirms the data entered.
Note: For the online transactions, the biggest advantage to use CTM and therefore save data into staging tables is that it allows a self-service user to fully complete an online transaction even though an EMPLID is not yet assigned. Only once the data is saved or submitted (depending on how you configure your CTM transaction) Search/Match or External Search/Match is used to create or identify an ID. The process behind the scenes to assign an EMPLID is completely transparent to the online user.
Warning! Setting up a CTM transaction requires technical knowledge of the record structure used by the transaction.