User Interface Considerations

Essentially all applicant users start in this state.

The user interface could use the SCC_USERREG_CREATEACCT service operation. NUR is a delivered CTM transaction.

The user interface could use the delivered SCC_USERREG_AUTHENTICATE service operation.

Once the user has been authenticated, it is likely that the user would then expect to see some form of online application launch page. It is also likely that returning users would expect to view or update any applications they have saved or submitted previously. To implement this kind of scenario, the online application user interface can request from AAWS the application summary information for the logged in user and then display this information on the launch page.

For first time users, the online application does not display saved or submitted application information. For these users, the online application can display options for creating a new application or for logging out.

A typical self-service, online-application user interface might perform the following actions:

• Formulate a request message.

• Submit the request message to the SAD_GETAPPLS service operation.

• Receive the application summary response message from AAWS.

• Based on the application status, present each application to the user in a grid style format for subsequent actions.

• Typically, applications which are in a Submitted status are not eligible for update and a user interface would need to enforce this rule depending on the institution's requirements.

From the online application launch page, a user may choose to start the application process by creating a new application.

A typical self-service, online-application user interface might perform the following actions:

• Present an Apply hyperlink that the user can click to initiate the application process.

• Present an initial Academic Learning Area page where the user can choose a field of study. For example, on this page the user supplies the required values to the SAD_CREATEAPPL service operation. The required values that the user enters might include academic program, plan, and sub plan.

• Formulate a request message.

• Submit the request message to the SAD_CREATEAPPL service operation.

• Receive one or more admission application templates with default values from AAWS.

• Present the one or more applications with the default values to the user through one or more user interface pages.

• Allow the user to enter in all required application details.

Collecting application fees, while optional, is likely a common scenario that needs to be supported by the user interface. At some point after application creation (where the application center assigned to the application will be known to the user interface) but prior to application submission (when fees may be payable) the user interface needs to obtain the application fee configuration options. The fee options dictate what fee payment preferences should be presented to the self service applicant by the user interface. Options related to fee payment include whether:

• An application fee is required.

• The applicant is given the option to Pay Later.

• The applicant can be given the option to request a Waiver for the fee.

Based on which fee options are configured, the user interface needs to react appropriately and present the applicant with only the valid options. This will in some cases alter the user interface page flow presented to the applicant.

A typical self-service, online-application user interface might perform the following actions:

• Collect the Academic Learning Area preferences that the applicant enters during the Create Application step. For example, the applicants are required to enter the academic career and program for which they wish to create an application.

• Use the preferences to create a request message for the SCC_LOV service, the request must include a look up of:

  • The SAD_LISTVAL_VW record to retrieve the application fee options.

  • The SSF_ADM_TND_VW record to retrieve the tendering options.

• Submit the request message to the SCC_LOV service.

• Receive the application fee configuration options.

• Act on the application fee configuration options in the following way:

  • If the Pay Later option is activated, then present the applicant with the choice to pay later (the applicant's choice is then used in the subsequent Submit Application step).

  • Store all the application fee and tendering configuration options in user interface storage for use in the subsequent Present Fee Options step.

The online application's launch page may show applications that the user has previously saved or submitted. The user may wish to submit a previously saved application.

A typical self-service, online-application user interface might perform the following actions:

• Present an Update hyperlink that the user can click to initiate the application update process.

• Formulate a request message.

• Submit the request message to the SAD_GETAPPL service operation.

• Receive an in-process or draft application from AAWS.

• Present the application to the user through one or more user interface pages.

• Allow the user to modify or enter the application details.

This activity represents the user completing details on one or more pages in the online application. This activity mostly involves the user interface presenting the page flow and collecting data from the user. If your institution has implemented attachments, then the returning user may wish to view any existing attachments associated with an application.

When the user edits the application data, the online application user interface may present dynamically generated prompts and dropdown list boxes. The online application may need to populate the values for these prompts and list boxes through calls to the SCC_GET_LOV service operation. Dynamic prompting occurs in situations where the system uses the user input to display the user interface dynamically. An example of dynamic prompting is when the user selects an undergraduate career; the Program field on the online application displays only undergraduate programs for the user to select.

A typical self-service, online-application user interface might perform the following actions:

• Present a series of pages for the user to interact with.

• Optionally, formulate a dynamic List-Of-Values request message.

• Submit the request message to the SCC_GET_LOV service operation.

• Present the List-Of-Value results in the online application page fields.

• Optionally, formulate an attachment request message.

• Submit the request message to the SAD_GET_ATTACH service operation.

• Decode the response from AAWS and present the binary content of the attachment in a suitable viewer.

When the user is creating or updating an application, he or she may want to pause and save the application for later modification or submission. The saved application is an in-process or draft application and AAWS places this draft application in a staging area. Subsequently, the user may submit this application or the system administrator may delete this application.

A typical self-service, online-application user interface might perform the following actions:

• Present a Save For Later hyperlink on any page in the page sequence. Generally, any page after the user starts creating the application may display this link. The user clicks this link to save the application.

• Prompt the user that the application is saved and the academic institution might use the applicant information for marketing purposes (if prospect creation is configured to occur on save).

• Formulate a request message.

• Submit the request message to the SAD_SAVEAPPL service operation.

• Receive and process the response from AAWS:

  • On a Success response there are various options:

    Present the user with a confirmation page. The confirmation page confirms that the application has been saved.

    Take the user back to the Get Application Summary page.

    Log out the user from the online application.

  • On an Error response:

    Based on the error codes that AAWS returns, position the user at an appropriate page of the user interface to allow data correction.

    Present validation error messages to the user.

    Present system error messages to the user.

After a user completes the application, the user interface should present a Submit Application option. Also, at submission time, the interface can present any number of disclaimer pages to the user. Generally, after a user submits the application, the user cannot update the application and the user interface would need to enforce this rule using the application status value. The user interface can retrieve this value using the SAD_GETAPPLS service operation.

A typical self-service, online-application user interface might perform the following actions:

• Present a Submit button on the final online application page.

• Prompt the user with any required disclaimers.

• Formulate a request message. Note that if a fee is due and the applicant has opted to Pay Later during the Get Fee Configuration step, then this intent must be indicated in the request message.

• Submit the request message to the SAD_SUBMITAPPL service operation.

• Receive and process a response from AAWS. There are three alternative responses that the user interface needs to cater for:

  • A Success response and fee payment is not required:

    Present the user with a confirmation page. The confirmation page confirms that the application has been submitted.

    Take the user back to the Get Application Summary page.

    Log out the user from the online application.

  • A Success response and fee payment is required:

    Extract the fee amount and currency code from the response.

    Proceed to the Present Fee Options page.

  • An Error response:

    Based on the error codes that AAWS returns, position the user at an appropriate page of the user interface to allow data correction.

    Present validation error messages to the user.

    Present system error messages to the user.

If the Get Fee Configuration step determines that there is a fee payable at submission time, then this page flow must be presented to the applicant. Fees are calculated by Student Financials according to the Fee Code attached to the application center. This page flow needs to present the applicant with his or her payment options based on the values returned in the earlier Get Fee Configuration step. The options here will include the ability to specify the tender category (for example, CC and check) and optionally the ability to request a waiver if that is allowed. Partial payments are not allowed. Therefore, the self service online application must not allow the applicant to change amount presented for payment.

A typical self-service, online-application user interface might perform the following actions:

• Present a page showing the:

  1. Amount payable.

  2. Currency code of the fee amount.

  3. Optionally, the ability to request a waiver.

  4. Optionally, the ability to specify a Waiver Basis code to be associated with the waiver request.

  5. Optionally, the ability for the applicant to attach one or more attachments to be used as supporting documentation for the waiver request.

• Formulate a request message based on the choice of the applicant:

  1. If the applicant requests a waiver then:

     - Add waiver details to the request.

     - Submit the request to the SAD_SUBMITAPPL service operation.

     - Process the response as in the Submit Application flow.

  2. If the applicant chooses to proceed with payment:

     -Submit the request message to the SSF_INITIATE_EPAYMENT web service operation.

     -Receive and process the response from the payment service operation.

     -The response may be either a HTTP redirect or a HTML string (this is determined by the hosted payment configuration).

     -In the case of a redirect, the user interface needs to respect the HTTP redirect and it will also need to store state of the current logged on userid/password in persistent client storage (for example, a database table).

     -In the case of a HTML string response, the user interface can handle this in a number of ways. Some examples are:

     — Spawn a new child window to display the HTML string response.

     — Incorporate the HTML response into a parent window frame.

  3. The response style is configurable and customizable by use of dynamic HTML. There is sufficient flexibility for the user interface to initiate the Payment Processing flow in either a new or an existing browser window. The decision will hinge entirely on the desired user experience and the technical capabilities of the user interface technology being employed.

• The end result of this activity is that the user will be presented with a browser page provided by the third party hosted payment processor from where the applicant can proceed with payment as given in the Payment Processing flow.

At this point the applicant has indicated that they wish to proceed with payment of a fee and they will have been presented with a browser window which contains a HTML page provided by the third party hosted payment provider (for example, the applicant will have been redirected to the third party site).

The applicant would then proceed to enter payment options and submit or cancel the payment. The third party provider would then redirect the applicant’s browser to one of the three configured URLs:

• CANCEL – the URL destination for when the applicant cancels the payment.

• SUCCESS – the URL destination for when the payment is completed successfully.

• FAIL - the URL destination for when the payment is not completed successfully.

In the event of a successful payment, then one final step needs to occur in order to complete the payment cycle. The Complete ePayment web service needs to be invoked to finalize the payment and submit the application. The self service online application user interface should display the appropriate message to the applicant based on the Complete ePayment (SSF_COMPLETE_EPAYMENT) response message.

A typical self-service, online-application user interface might perform the following actions:

• Formulate a request message.

• Submit the request to the SSF_COMPLETE_EPAYMENT web service.

• Present a page to notify the applicant of successful payment.

• Optionally transfer the applicant back to the Online Application home page and initiate the Get Application Summary flow to show the latest status.

When the system validates the data during save and submit, if validation errors occur, the error handling feature returns a list of textual descriptions of those errors along with error IDs and the field names related to the errors. As much information as possible is returned to the user interface to present the errors to the user and allow correction of the errors.

The user interface must perform the following steps to use the error handling feature:

• The user interface must populate a unique ID into the tag called SCC_ENTITY_INST_ID in the request xml for each entity. In the event of error during data validation, error handling returns to the user interface the unique ID (that is obtained from the request message) and the field name related to the error along with the error message text.

• The user interface can use this unique error ID, the field name, and the error message to know what fields on what pages are in error. This allows the user interface to highlight the fields with errors and allows the user to correct the data.

The unique ID is optional in the request schema. Therefore, institutions should populate the unique ID only if they want to uptake the error handling feature.

Institutions are free to populate the SCC_ENTITY_INST_ID in any format they please, but it is recommended that they use the official Universally Unique Identifier (UUID) format, 36 character ISO standard.

An option to leave the online application could potentially be provided from any page in the online application. Clicking the Logout hyperlink is a signal from the users that they intend to leave the system and that any sensitive information managed by the user interface should now be cleared.

A typical self-service, online application user interface might perform the following actions:

• Present a Logout hyperlink that the user can click to log out of the online application.

• Clear the username and password combination from the local user interface temporary storage area.

• Present the user with a logged off confirmation page.

For more information about the hosted payment feature, refer to the Electronic Payment Integration Developers Reference Guide. This guide is available on My Oracle Support for PeopleSoft Enterprise Campus Solutions 9.0 Feature Pack 2.

The HTML object is provided as a flexible means to allow a diverse range of user interface technologies to interact with the hosted payment feature. The concept is that the HTML object can be constructed using dynamic HTML. The HTML object can then be presented in a browser window to allow seamless flow between the admissions online application and the third party payment provider. In theory there should be no page flow or user experience which cannot be achieved using a JavaScript based HTML object. Note that the HTML object is not limited to JavaScript and can contain any proprietary client side scripting language as is dictated by the user interface technology in use by the institution.

As a simple example the following HTML object could be used to auto-redirect the applicant’s browser to a third party payment provider:

<BODY onload="submitForm()">
 <form name=”myform” action="https://someserver/upay/web/index.jsp" method="post">
<input type="hidden" name="UPAY_SITE_ID" value="3">
<input type="hidden" name="TICKET" value="12345">
<input type="hidden" name="TICKET_NAME" value="12345">
</form>
<SCRIPT LANGUAGE="JavaScript">function submitForm()
{document.myform.submit();}
</SCRIPT>
</BODY>