Return to Navigation

Data Flow

This section discusses how the SOLA pages and the SQL tables exchange application data.

Flow:

  1. The applicant enters data into the SOLA page.

  2. The fields in each SOLA page reflect one or more SQL views. Each view represents the specific type of data that SOLA is collecting (that is, address, emergency contact, academic data and so on.). The views themselves are not traditional database views, but hollow views that exist merely to collect and display the data on the SOLA page.

  3. When the applicant clicks the Save or Submit button, SOLA copies the data within each view to the view's corresponding entity in the Entity Registry. This is how SOLA processes the data into the entity:

    • The method associated with each entity performs any necessary data validation.

    • The toXMLNode method then converts the entity content into an XML representation that the SOAP-based web services require.

    • Once all the data is entered in the SOLA pages and their respective views have been processed, SOLA sends the XML request and invokes the SAD_SAVEAPPL web service operation.

    • The SAD_SAVEAPPL service operation then takes the XML request string and deconstructs it node by node back into an entity.

    • As each node is filled up with data, SAD_SAVEAPPL invokes the corresponding Entity Registry ID.

Note: SOLA may look like any standard component in Campus Solutions, but the key concept to understand is that the data entered on the SOLA pages never directly interact with the SQL table(s) as it does in other Campus Solutions pages.

Flow:

  1. The applicant signs into institution's Admissions Application home page and accesses the SOLA component.

  2. Assuming that this is not the first time the applicant is visiting the Admissions Application page, SOLA invokes the SAD_GETAPPLS web service operation. The SAD_GETAPPLS_RESP XML message contains all the key values for the applicant's applications.

  3. This key information is presented in a grid format for the applicant to choose from, the applicant also has the option to create an entirely new application.

  4. The applicant clicks the View button or the Edit button for an existing application and SOLA passes the key values for that specific application to the SAD_GET_APPL web service operation.

  5. The SAD_GETAPPL_RESP XML response message contains all the data (both constituent and academic) associated with that specific application.

  6. SOLA deconstructs the XML response message node by node and moves this deconstructed message to the corresponding SQL Views within the application page(s) in SOLA.

  7. Once the XML response has been deconstructed, SOLA displays the page(s) to the applicant.