Campus Solutions SOLA Pages to SQL Tables

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.