Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

District Database Identification

For Classic USAS a single SOAP service endpoint is used to access all district databases at an ITC. Each unique database is identified by a "district code" or IRN. Some ITC's also support the use of NCES codes to identify district databases. After a SOAP client authenticates with the SOAP service, it must declare the district database on which it intends to operate. Alternatively, the SOAP client may query the service for the databases the user has access to and allow the user to select the district code.

For Redesign USAS, a separate endpoint is used for each district.   In Redesign implementations of the SOAP service, the setDistrictAccess operation is a NOOP and is not necessary.

SOAP Service Endpoints

Each ITC that supports the Classic USAS SOAP service will provide one or more “SOAP endpoint” URL's for accessing the service for their districts. In most cases, a single endpoint will be used for all districts hosted by a given DA ITC Site. However, in some cases, an ITC may provide a different endpoint for specific districts.

For Redesign USAS SOAP, a separate endpoint will be provided for each school district.

Most ITC's will provide an HTTPS (SSL) end-point can be used to encrypt SOAP messages on the wire. Developers are encouraged required to use HTTPS when available. Each ITC decides whether HTTPS is available or required and may have other local security policies regarding from what networks SOAP connections are availablefor production instances.

Authentication and Authorization

...

  1. Invoke _login _operation with credentials for an account on the USAS server
  2. Optional: Invoke _getDistrictList _to return a list of districts the user as access to
  3. Optional for Redesign: Invoke _setDistrictAccess _to bind the session to a given district database
  4. Optional: Invoke assumeUserProfile to assume the profile of another user

After these steps are completed, the client may invoke any other USAS operation. The client may perform as many operations as necessary to perform its work. When the client is finished using the service, it should invoke the _logout _operation to cleanly close down the session.

It For Classic instances, it is important that the client invoke setDistrictAccess code to establish the district database to which the session is bound. This must be done exactly once after login and prior to any other USAS operation.

...

For faults that contain response-msgs _elements, each message (_fatal, error or _warning _element) may contain a _code _element. Developers may use these codes to programmatically test for specific types of USAS errors.

Note

The code element is a feature only of the Classic USAS SOAP implementation. Redesign does not provide the more specific code. Therefore, developers are discouraged from using the code in clients intended to work with both Classic and Redesign.


Info

The codes in this table are the complete set of codes that can theoretically be produced by the current OpenVMS back-end implementation of USAS. However, in practice, some codes could never be returned by the USAS SOAP service. For example, “INVALIDXMLDATA” could not be returned in a USAS fault since the SOAP service would reject XML documents that do not conform to the USAS XML Schema.

...