| 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.
...
.
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 current development version of the USAS SOAP service is available at: http://devel.ssdt.nwoca.org/usassoap/. The latest WSDL and Schemas are available on that page. The latest WSDL and Schemas are available at /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 or the USAS System Managers Guide. This . These documents are available on-line at httphttps://ssdtmcoecn.oecn.k12.oh.us/projects/usas .
Developers who have questions or need technical advice on integrating with the USAS webservice are encouraged to join the ssdt-usas-dev-l list. This list is operated by the SSDT to assist developers with integration issues. For subscription options and to view the archives, visit http://listserv.nwoca.org/cgi/wa.exe?A0=ssdt-usas-dev-l.
Status of the USAS SOAP Service
The USAS SOAP service provides a limited subset of USAS functionality via a standards based SOAP service. See the WSDL for business functions supported by the service.
Standards Compliance
The SSDT atlassian.net/wiki/x/6oA2 .
Status of the USAS SOAP Service
The USAS SOAP service provides a limited subset of USAS functionality via a standards based SOAP service. See the WSDL for business functions supported by the service.
Standards Compliance
The SSDT believes that USAS SOAP service complies with the WS-I Basic Profile 1.0a WS-I Basic Profile 1.0a . The artifacts (definitions and messages) of the service have passed all assertions tested by the “WS-I Testing Tools v 1.0.1” provided by WS-I.
...
Developers interesting in a test account , should send mail to becher@ssdt-ohio.org with their request. Please include contact information, company and a brief description of your application and intended use.
...
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.
...
When a client connects to the service, it must provide username and password credentials for an account on the ITC server. Usernames and access rights are administered by the DA Site ITC on behalf of the member district. The access rights and functions the account can perform are limited by rights granted by the ITC and any USAS security profiles established by the 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 |
|---|
...
. 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.
...
Sessions consume resources on both the SOAP server and the back-end USAS server. Therefore, inactivity timeouts apply to the SOAP sessions. The timeout interval is configurable by each DA Site ITC and defaults to approximately 45 minutes. If there is no activity for a session in during the timeout interval, the session will be deleted from the SOAP service. Any subsequent invocations using an expired sessionId will result in a fault being returned. Client applications that attempt to maintain long running connections, must be prepared to handle such faults.
...
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. |
...