AAWS Service Operations

The Create Application service operation call results in one or more admission applications being initialized. The application center settings on the Application Configuration component control whether multiple applications (or preferences) can be created. For example, if you do not have an application center set up for an applicant who selects an Undergraduate career, Liberal Arts program, and History plan, the service operation throws an error.

The service operation populates the admission application fields based on the settings on the User Defaults and Installation - AD components. At application creation time the operation does not physically save the data to the admissions staging tables. The save process does not occur until a later point in time when the user selects a save or submit option on the online application. Therefore, this operation is more concerned with the initialization of an application, driven by configuration, rather than creating a physical application in the database.

• An applicant using an online application.

• An administrator using an online application for creating an application on behalf of an applicant who has or does not have an EMPLID.

The service operation performs the following steps:

1. Validate that the user is authenticated (and is not a Guest)

2. If Administrator mode then:

   • Validate the required input administrator parameters.

   • Validate that the administrator is authorized to access the application center, institution, career, program and plan.

3. Validate the required input parameters for application creation.

4. Determine the transaction that must be used to process the Institution/Academic Career combination. Define transactions on the Transaction Setup page.

5. Begin a new transaction for the request. Assign a new TEMP_ID to the constituent.

6. Using the supplied input parameters, look up the Application configuration component settings to determine how many application preferences should be created for this request.

7. Return response though the output parameters.

After processing, the operation creates an admission application with default data and preferences. The user can subsequently update and submit this application through the Save and Submit service operations.

The following conditions result in a service error:

• User is not authenticated (for example, if an anonymous Guest tries to sign into the online application, the service throws an error message).

• Administrative user is not authorized to access the application center, institution, career, program or plan.

• Required input parameters have not been supplied by the user (see the graphic titled SAD_CREATEAPPL_REQ Message Parameters and the "AAWS and Entity Registry" section).

The Save Application service operation call results in the given admissions application being saved to the Campus Solutions system. The application may be partially complete when the online application user decides to use a Save option that triggers a call to this service operation. The service operation saves the application using an Update Via Replacement approach; in other words, the SAD_SAVEAPPL operation deletes any pre-existing application (based on a unique key) for the applicant and then saves the new (or current) version of the application.

When saving an application, the operation assigns an application number (ADM_APPL_NBR) to the application for tracking.

The application must pass through validation checks before it gets saved.

The service operation validates all aspects of the application data including data entered and translate values selected by the user on the online application, and custom business validation rules that the institution has incorporated into the online application.

The service operation saves the valid applications to the admissions staging tables. If the constituent (person) who initiated the application save process is known (for example, the constituent has an EMPLID), then the constituent portion of the application is immediately eligible to be posted to the Campus Solutions and HCM person production tables. Otherwise, the constituent data remains in the staging tables until addressed by an administrator. In any case, the application data itself is saved to the staging tables and is not posted to admissions production tables until a later submit occurs.

Applications may include attachments. The online application must encode the attachment in Base64 format before passing the attachment to Campus Solutions.

• An applicant using an online application.

• An administrator using an online application for creating an application on behalf of an applicant or a student.

The service operation performs the following steps:

1. Validate that the user is authenticated (and is not a Guest)

2. If administrator mode, then:

   1. Validate the required input administrator parameters.

   2. Validate that the administrator is authorized to access the application center, institution, career, program and plan.

   3. Use the EMPLID supplied by the administrator for the transaction.

3. Validate that the applicant is authorized to save the application (for example, verify whether the applicant is the same person who created the application in the call to the SAD_CREATEAPPL service operation).

4. If administrator mode, then use the input parameter Application Center value for the application.

5. If applicant mode, then use the input parameters and the settings on the Application Configuration component to assign an application center to the application.

6. To enter the Application Citizenship details, use the applicant details in the input parameters, if necessary.

7. To enter the Constituent Institution (needed for Data Update Rules), use the Admissions Application Institution input parameter value.

8. Validate the constituent and application data using the Constituent and Application entity schemas.

9. Associate the TEMP_ID (assigned during the SAD_CREATEAPPL processing) with the application.

10. Save the validated constituent and application data to the staging tables.

11. Add the assigned ADM_APPL_NBR to the response message.

12. If the constituent is not known to the Campus Solutions system (for example, the applicant does not have an EMPLID):

    1. Run the Search Match process according to the Search Match settings on the Transaction Setup component.

    2. Add or update a HCM person record according to Search Match configuration and apply the necessary data update rules during this processing.

13. Create or update a prospect record in the production tables according to the settings on the Application Configuration component.

After completing the processing steps, the service operation:

1. Posts the valid application data to the Campus Solutions admissions staging tables.

2. Posts the valid constituent data to the Transaction Manager constituent staging tables.

3. Optionally, creates or updates a HCM person record for a valid application.

4. Optionally, creates a prospect record for a known applicant.

The following conditions result in a service error:

• User is not authenticated (for example, if an anonymous Guest tries to sign into the online application, the service throws an error message).

• User is not authorized to access the application (for example, if the applicant is trying to access an application created by another applicant).

• Application is invalid (that is, the application fails validation processing).

• Required input parameters have not been supplied by the user (see the graphic titled SAD_SAVEAPPL_REQ Message Parameters and the "AAWS and Entity Registry" section).

The Submit Application service call results in the given admissions application being submitted to the Campus Solutions system. The application must be complete (according to the institution's data capture requirements). The online application user interface and the underlying Campus Solutions data model ensure that the submitted admission application is complete.

The application submit process involves first validating the data, then saving the data to the admissions staging tables, and finally transferring the staged data into the admissions production tables.

When initially saving the application to the staging tables, if the application does not have an application number, the service operation assigns an application number (ADM_APPL_NBR) to the application for tracking purpose. The operation does not assign an application number if another operation (for example, the SAD_SAVEAPPL operation) has already assigned an application number.

The admission application must pass through validation checks before it gets submitted. The service operation validates all aspects of application data including data entered and translate values selected by the user on the online application and custom business validation rules that the institution has incorporated into the online application.

If the constituent who initiated the application submit process is known to the Campus Solutions system (for example, the constituent has an EMPLID), then the constituent and application data is eligible to be posted to the Campus Solutions admissions and person production tables. Otherwise, the application remains in the staging tables until addressed by an administrator.

When configured to do so, the constituent can pay an application fee and/or request an application fee waiver.

Applications may include attachments. The online application must encode the attachment in Base64 format before passing the attachment to Campus Solutions.

• An applicant using an online application.

• An administrator using an online application for creating an application on behalf of an applicant or a student.

This service operation performs the following steps:

1. Validate that the user is authenticated (and is not a Guest).

2. If administrator mode then:

   1. Validate the required input administrator parameters.

   2. Validate that the administrator is authorized to access the application center, institution, career, program and plan.

   3. Use the EMPLID supplied by the administrator for the transaction.

3. Validate that the applicant is authorized to submit the application (for example, verify whether the applicant is the same person who created the application in a call to the SAD_CREATEAPPL service operation.)

4. If administrator mode, then use the input parameter Application Center value for the application.

5. If applicant mode, then use the input parameters and the settings on the Application Configuration component to assign an application center to the application.

6. To enter the Application Citizenship details use the applicant details in the input parameters, if necessary.

7. To enter the Constituent Institution (needed for data update rules) use the Admissions Application Institution input parameter value.

8. Validate the constituent and application data using the Constituent and Applicant entity schemas.

9. Associate the TEMP_ID (assigned during the SAD_CREATEAPPL processing) with the application.

10. Save the validated constituent and application data to the staging tables.

11. If the constituent is not known to the Campus Solutions system (for example, the applicant does not have an EMPLID):

    1. Run the Search Match process according to the Search Match settings on the Transaction Setup component.

    2. Add or update a HCM Person record according to Search Match configuration and apply the necessary data update rules during this processing.

12. If Fee payment is required but has not yet been paid:

    1. Call the Student Financials Fee Calculation API to calculate the fee amount.

    2. If Fee Waivers are allowed then allow the application to progress to submitted status.

    3. If Fee Waivers are Not allowed then:

       1. Set the application data to Saved Status.

       2. Add the Fee details to the response message.

       The caller must handle this response by initiating the payment services. Note it is possible for Fee calculation to result in a zero (0) amount in which case the caller should not initiate the payment service.

13. Create or update a prospect record in the production tables according to settings on the Application Configuration component.

    If the constituent is known (for example, the applicant has an EMPLID), post the application data into the admissions production tables and apply the necessary data update rules during this processing.

After completing the processing steps, the service operation:

1. Posts the valid application data to the Campus Solutions admissions staging tables.

2. Posts the valid constituent data to the Transaction Manager constituent staging tables.

3. Transfers the application and constituent data from the staging tables to the Campus Solutions person and admissions production tables.

4. Optionally, creates or updates a HCM person record for a valid application.

5. Optionally, creates a prospect record for a known applicant.

The following conditions result in a service error:

• User is not authenticated (for example, if an anonymous Guest user tries to sign into the online application, the service operation throws an error message.)

• User is not authorized to access the application (for example, the applicant is trying to access an application created by another applicant).

• Application is invalid (that is, the application fails validation processing).

• Required input parameters have not been supplied by the user (see the graphic titled SAD_SUBMITAPPL_REQ Message Parameters and the "AAWS and Entity Registry" section).

Use this service operation to retrieve a summary of all the applications that reside in the Campus Solutions staging and production tables. The service operation retrieves only those applications that the authenticated user is authorized to access.

SAD_GETAPPLS can operate under applicant or administrative modes. When using administrator mode, the application data returned from the Admissions production tables is subject to application center row level security. When using applicant mode, the application data returned is restricted to those applications entered previously by the authenticated online application user.

• An applicant using an online application.

• An administrator using an online application to retrieve data that he or she previously saved or submitted. The administrator can retrieve an application for an applicant who has or does not have an EMPLID.

This service operation performs the following steps:

1. Validate that the user is authenticated (and is not a Guest).

2. If administrator mode then:

   1. Validate the required input administrator parameters.

   2. Validate that the administrator is authorized to access the application center.

   3. Use the EMPLID supplied by the administrator for the transaction.

3. Determine the list of configured application transactions from the Transaction Setup component.

4. Retrieve all the application transactions for all the configured application transactions.

5. Retrieve all admission applications from the Admissions staging tables that the authenticated user is authorized to access.

6. If applicant mode, then retrieve all the applications associated with the authenticated EMPLID from the production tables.

7. To retrieve the application based on the ADM_APPL_NBR key:

   1. First, check whether the application exists in the admissions staging tables using the SCC_TEMP_ID key.

   2. If the application does not exist in the staging tables, check the admissions production tables using the EMPLID key.

8. Return the Application Summary, which indicates ID (EMPLID or SCC_TEMP_ID), Application Number, Institution, Academic Career and Application Status (SAVED, SUBMITTED, ERROR, or POSTED).

After processing the steps, a summary of all active applications is returned.

The following conditions result in a service error:

• User is not authenticated (for example, if an anonymous Guest user tries to sign into the online application, the service operation throws an error message).

• Required input parameters have not been supplied by the user (see the graphic titled SAD_GETAPPLS_REQ Message Parameters).

Use this service operation to retrieve a saved or submitted application using the ADM_APPL_NBR key.

An online application can obtain the ADM_APPL_NBR application key by calling the SAD_GETAPPLS service, which retrieves a summary of all the applications associated with the current authenticated user.

The SAD_GETAPPL operation can operate under applicant or administrative modes. When using applicant mode, the application data returned is restricted to those applications entered previously by the authenticated online application user. When using administrator mode, the application data returned from the admissions production tables is subject to application center row level security.

• An applicant using an online application.

• An administrator using an online application to retrieve data that they previously saved or submitted. The administrator can retrieve an application for an applicant who has or does not have an EMPLID.

This service operation performs the following steps:

1. Validate that the user is authenticated (and is not a Guest).

2. If administrator mode, then:

   1. Validate the required input administrator parameters.

   2. Validate that the administrator is authorized to access the application center.

   3. Use the EMPLID supplied by the administrator for the transaction.

3. Validate that the applicant is authorized to retrieve the application (for example, verify whether the applicant is the same person who created the application).

4. If administrator mode, then use the EMPLID input parameter to retrieve the application.

5. If applicant mode, then use the EMPLID input parameter associated with the authenticated user profile to retrieve the application.

6. To retrieve the application based on the ADM_APPL_NBR key:

   1. First, check whether the application exists in the admissions staging tables using the SCC_TEMP_ID key.

   2. If the application does not exist in the staging tables, check the admissions production tables using the EMPLID key.

7. Return the application data, if found.

After completing the processing steps, the service operation returns a single application if it exists in the staging or production tables. All the application details along with constituent details are returned, if the application exists.

The following conditions result in a service error:

• User is not authenticated (for example, if an anonymous Guest user tries to sign into the online application, the service operation throws an error message).

• User is not authorized to access the application (for example, the applicant is trying to access an application created by another user).

• Required input parameters have not been supplied by the user (see the graphic titled SAD_GETAPPL_REQ Message Parameters).

• Administrative user is not authorized to access the application due to the application center security configuration.

Use this service operation to retrieve an attachment associated with the admission application.

The online application must encode the attachment byte content in Base64 format when a user saves or submits the application data through AAWS. Subsequently, the online application can use SAD_GETATTACH to retrieve the attachment. After retrieval, the online application must decode the attachment. The applicant or administrator can then use the appropriate file type viewer to view the attachment.

The attachment is stored within the Campus Solutions attachment framework in a database table.

You can use the Application Transactions or Maintain Applications components to access the application attachments.

• An applicant using an online application.

• An administrator using an online application to retrieve data that he or she previously saved or submitted. The administrator can retrieve an application (and the associated attachments) for an applicant who has or does not have an EMPLID.

This service operation performs the following steps:

1. Validate that the user is authenticated (and is not a Guest).

2. If administrator mode, then:

   1. Validate the required input administrator parameters.

   2. Validate that the administrator is authorized to access the application center.

   3. Use the EMPLID supplied by the administrator for the transaction.

3. Verify whether the applicant is authorized to retrieve the attachment (for example, verify whether the applicant is the same person who originally created the attachment through AAWS).

4. If administrator mode, then use the EMPLID input parameter to retrieve the attachment.

5. If applicant mode, then use the EMPLID input parameter associated with the authenticated User Profile to retrieve the attachment.

6. To retrieve the attachment:

   1. First, check whether the attachment exists in the staging tables using the SCC_TEMP_ID key.

   2. If the attachment does not exist in the staging tables, check the production tables using the EMPLID key.

7. Return the attachment, if found.

After completing the processing steps, if the attachment exists, the service operation returns the attachment data to the online application.

The following conditions result in a service error:

• User is not authenticated (for example, if an anonymous Guest user tries to sign into the online application, the service operation throws an error message).

• User is not authorized to retrieve the attachment (for example, the applicant is trying to access an attachment created by another user).

• Required input parameters have not been supplied by the user (see the graphic titled SAD_GETATTACH_REQ Message Parameters).Administrative user is not authorized to access the attachment due to application center configuration.