| Table of Contents |
|---|
Introduction
...
This guide assumes basic familiarity with USAS and the USAS account coding scheme. It also assumes the reader is familiar with SOAP, XML and other related technologies.
...
...
This documentation applies to both the Classic and Redesign versions of USAS. Except as noted in the document the Redesign and Classic API's of the SOAP services are compatible.
Glossary
- DAS or DA Site - Data Acquisition Sites. This term is obsolete. OECN sites are now refered to as ITC's
- ITC - Information Technology Centers are regional data processing centers that provide computer services to member school districts. Among the services ITC's provide is hosting of the USAS application for school districts.
- OECN - Ohio Education Computer Network
- SSDT - State Software Development Team develops USAS, and other software, for school district on behalf of the Ohio Department of Education.
- USAS - Uniform School Accounting system. USAS refers to both the USAS software developed by the SSDT on behalf of the Ohio Department of Education, and the USAS accounting structure defined by the Ohio Auditors of State and Ohio Department of Education.
...
The WSDL and Schemas are distributed by the SSDT as part of the SOAP service installation kit. Vendors should contact the school district's ITC or the SSDT for the WSDL for currently supported versions. The latest WSDL and Schemas are available at Configuring SOAP Service with USxS-R /wiki/spaces/rtd/pages/2753089.
| Note | ||
|---|---|---|
| ||
The deliver to address lines on the Requisition are limited to 24 characters, not 30 as stated by the schema. The datatype for the deliver to address on the Requisition and the delivery address on the Purchase Order are the same, so we are unable to change the schema. |
...
Developers who need background documentation on USAS may wish to refer to the USAS User and Reference Manuals. These documents are available on-line at https://wikimcoecn.ssdt-ohio.orgatlassian.net/wiki/x/K4Se6oA2 .
Status of the USAS SOAP Service
...
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 “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 ITC Site. However, in some cases, an ITC may provide a different endpoint for specific districts.
For Redesign USAS SOAP, a Separate endpoints are used for each district.
SOAP Service Endpoints
A separate endpoint will be provided for each school district.
...
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.
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.
...
| title | Important |
|---|
...
work. When the client is finished using the service, it should invoke the _logout _operation to cleanly close down the session.
After the database context is established, the client application may optionally invoke assumeUserProfile to impersonate the profile of a different USAS user. This operation will only succeed if the authenticated user is authorized to impersonate other users and if a suitable profile exists on the USAS server. The _assumeUserProfile _operation may be used multiple times for a given session.
...
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.
...
.
| 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. |
...