HEIMS Applications and Offers Web Service Interface
Technical Specification
HIGHER EDUCATION INFORMATION
MANAGEMENT SYSTEM (HEIMS)
HEIMS WEB SERVICES INTERFACE
TECHNICAL SPECIFICATION
APPLICATIONS AND OFFERS FUNCTIONS
Version 1.8
Page 1 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
Table of Contents
1
Introduction ................................................................................................................................................ 3
1.1
Purpose of this document................................................................................................................. 3
1.2
Out of Scope .................................................................................................................................... 3
1.3
Target Audience ............................................................................................................................... 3
1.4
Disclaimer ......................................................................................................................................... 3
1.5
Version Control ................................................................................................................................. 3
3
HEIMS Technical Architecture ................................................................................................................... 4
3.1
Web Services Architecture Overview ............................................................................................... 4
3.2
Technical Requirements................................................................................................................... 4
3.3
Compression .................................................................................................................................... 5
3.4
Security............................................................................................................................................. 7
3.5
Transactions Overview ..................................................................................................................... 7
3.5.1
Batch Transactions ...................................................................................................................... 7
3.6
Service Agreements and Availability ................................................................................................ 9
3.7
XML Schemas ................................................................................................................................ 10
3.7.1
LoadApplicationsAndOffersSubmissionIn .................................................................................. 11
3.7.2
LoadSubmissionOut ................................................................................................................... 12
3.7.3
RequestControlTable ................................................................................................................. 12
3.7.4
ResponseControlTable .............................................................................................................. 13
3.8
Request and Response Definitions ................................................................................................ 13
3.8.1
Request Identifiers ..................................................................................................................... 13
3.8.2
Request Object Schema ............................................................................................................ 13
3.8.3
Response Schema ..................................................................................................................... 14
3.8.4
Control Data ............................................................................................................................... 15
3.8.5
Transaction Data ........................................................................................................................ 16
3.8.6
Messages ................................................................................................................................... 17
3.9
Error Handling ................................................................................................................................ 18
3.9.1
Schema Errors ........................................................................................................................... 18
3.9.2
Business Errors .......................................................................................................................... 19
4
Interfaces ................................................................................................................................................. 20
4.1
General Information........................................................................................................................ 20
4.2
LoadApplicationsAndOffersSubmission method (for submission of Applications and Offers data
for batch processing) ................................................................................................................................... 20
4.3
GetApplicationsAndOffersSubmissionResults method (for retrieving the results of a processed
submission of Applications and Offers data) ............................................................................................... 20
4.4
Ping method ................................................................................................................................... 21
5
Security – Change Password .................................................................................................................. 22
6
Environments ........................................................................................................................................... 23
6.1
Production ...................................................................................................................................... 23
6.2
Next Production Release................................................................................................................ 23
7
Certificate ................................................................................................................................................. 23
8
Troubleshooting ....................................................................................................................................... 24
A. Appendix A – References and Other Relevant Documents .................................................................... 25
A.1
References ..................................................................................................................................... 25
A.2
Other Relevant Documents ............................................................................................................ 25
B. Appendix B – Glossary ............................................................................................................................ 26
C. Appendix C - Data Element Map ............................................................................................................. 28
D. Applications and Offers Web Service Requests and Responses............................................................ 32
D.1
LoadApplicationsAndOffersSubmission ......................................................................................... 32
D.2
GetApplicationsAndOffersSubmissionResultsRequest .................................................................. 33
Version 1.8
Page 2 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
1 Introduction
1.1
Purpose of this document
The purpose of this document is to provide technical information required to make Web Service calls from
Tertiary Admissions Centres (TACs) systems to the department’s Higher Education Information Management
System (HEIMS). The scope of the document includes technical specifications of the Web Services for
Applications and Offers submissions, descriptions of the available web methods, details of the schemas used
and troubleshooting information.
Due to the flexibility of Web Services and the large number of systems that can consume them, it is not
feasible to provide detailed implementation instructions for specific platforms and systems. This document
will however, provide what technical information is needed in order to configure and use a Web Services
toolkit.
1.2
Out of Scope
The following are out of scope for this document:
 Detailed business rules used to validate Tertiary Admissions Centre submission data; and
 Technical specification for any of the W3C standards used in HEIMS.
A list of documentation that addresses W3C standards and context information for HEIMS Web Services
(such as business requirements) can be found in Appendix A.
1.3
Target Audience
This is a technical document for use by Tertiary Admissions Centres (TAC Developers).
1.4
Disclaimer
These specifications give information about how to use the HEIMS Applications and Offers Web Services.
These specifications are not intended to provide implementation instructions for individual systems. The
department accepts no responsibility for any loss or damage to any system resulting from the use of these
specifications.
These specifications may be changed from time to time. It is the responsibility of TACs and others using
these specifications to ensure they are using the latest version.
Technical enquiries relating to these specifications can be initially directed to the HEIMS Data Collections at
heims.datacollections@education.gov.au or phone on (02) 6240 7487.
1.5
Version Control
Documenting changes to this document will be managed through controlled versioning. Updated versions of
this document can be obtained by contacting the HEIMS Data Collections at
heims.datacollections@education.gov.au or phone on (02) 6240 7487.
Version 1.8
Page 3 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
3 HEIMS Technical Architecture
3.1
Web Services Architecture Overview
XML Web Services provide a mechanism for applications to exchange information over a network. By
providing a standard interface and communicating using international standard protocols, all Web Service
implementations operate in the same manner making communicating using Web Services a simple, open
and platform independent process.
Web Service interfaces are described by the Web Services Definition Language (WSDL) and Web Service
communication relies on protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP),
Hypertext Transfer Protocol (HTTP), and Simple Object Access Protocol (SOAP). These standards are
developed and maintained by the World Wide Web Consortium (W3C), a member organisation consisting of
leading technology vendors, corporate users, standards bodies and government organisations. As such, this
provides a set of rich standards which are not tied to a specific vendor or system. For these reasons, XML
Web Services are suitable as a means for HEIMS to communicate with external systems.
3.2
Technical Requirements
HEIMS Web Services will only cater for requests using SOAP 1.1. Web Service calls using HTTP-GET and
HTTP-POST will not be supported. This is because using SOAP provides XML schema support for more
complex data types. The transport method supported is SSL-encrypted HTTP.
In order to call the HEIMS Web Services, an application or SDK capable of calling XML Web Services is
required. The application or SDK must support the following:
 XML 1.0;
 SOAP 1.1;
 HTTP 1.1; and
 Basic Authentication.
When implementing a responsive application, bandwidth requirements must be taken into consideration.
Bandwidth requirements depend on many factors. These include:
 Size of the payload sent to HEIMS for processing;
 Frequency of the requests; and
 Data compression.
HEIMS Applications and Offers Web Services have been designed to minimise the network traffic payload as
much as possible. The services provided by HEIMS are therefore not bandwidth intensive. However, to
ensure best performance, the department recommends a broadband connection for both upstream and
downstream traffic.
Version 1.8
Page 4 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.3
Technical Specification
Compression
Compression is a standard feature in HEIMS Web Services. All HEIMS Applications and Offers Web Service
requests and responses will be compressed. For clients with small bandwidth capabilities or those that
process large volumes of requests, this will be a useful feature as the bandwidth savings can be quite large.
Using compression reduces not only bandwidth requirements, but other side effects of large requests such
as timeouts. The compression algorithm supported by all HEIMS Web Services is gzip.
In order to use compression, the tools used to call HEIMS Applications and Offers Web Services must be
able to control how and when SOAP messages are created and sent. Compression of the stream must take
place in the SOAP layer. That is, after the SOAP envelope has been properly constructed, the body of the
SOAP envelope must be compressed and then sent over HTTP to the server.
To inform the server that the request is compressed:
 The following Compression header must be added to the SOAP header
<Compression
s:mustUnderstand="1"
Algorithm="http://dest.gov.au/Heims/compression/gzip"
xmlns="http://dest.gov.au/Heims/compression"/>
Compression Header Attribute
Value Required
Algorithm
xmlns
http://dest.gov.au/Heims/compression/gzip
http://dest.gov.au/Heims/compression

And the compressed content of the Soap Message Body must be enclosed within these elements:
<SC:CompressedData xmlns:SC="http://dest.gov.au/Heims/compression">
</SC:CompressedData>
Compression Example (Please note that abbreviated dummy data has been used and the schema may not
be accurate):
Before Compression:
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<LoadApplicationsAndOffersSubmission
xmlns="http://dest.gov.au/Heims/Service">
<request
xmlns:a="http://dest.gov.au/Heims/"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<a:RequestControlData>
<a:RequestId>128695597818308750</a:RequestId>
<a:ClientOrganisationCode>5003</a:ClientOrganisationCode>
<a:RequestLocalDateTime>2008-1027T16:43:01.830875+11:00</a:RequestLocalDateTime>
</a:RequestControlData>
<a:TransactionData>
<a:LoadApplicationsAndOffersSubmissionIn>
<a:RecordId>0</a:RecordId>
<a:Application>
<a:ApplicationIdentificationCode>APP0</a:ApplicationIdentificationCode>
<a:ApplicationStatusCode>1</a:ApplicationStatusCode>
<a:ApplicantName>
<a:FamilyName>Aaaaaaa</a:FamilyName>
...
</a:ApplicantName>
<a:Offers>
<a:Offer>
<a:SectorCode>1</a:SectorCode>
<a:PreferenceOrdinalPosition>00</a:PreferenceOrdinalPosition>
Version 1.8
Page 5 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
<a:HigherEducationProviderCode>9999</a:HigherEducationProviderCode>
<a:CourseOfStudyTypeCode>21</a:CourseOfStudyTypeCode>
...
</a:Offer>
</a:Offers>
<a:YearOfArrival>1970</a:YearOfArrival>
...
</a:Application>
</a:LoadApplicationsAndOffersSubmissionIn>
</a:TransactionData>
</request>
</LoadApplicationsAndOffersSubmission>
</s:Body>
</s:Envelope>
After Compression:
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Compression
s:mustUnderstand="1"
Algorithm="http://dest.gov.au/Heims/compression/gzip"
xmlns="http://dest.gov.au/Heims/compression"/>
</s:Header>
<s:Body>
<SC:CompressedData
xmlns:SC="http://dest.gov.au/Heims/compression">
H4sIAAAAAAAEAO29BSvVK1+B0o... ...G24Z2PtE1
</SC:CompressedData>
</s:Body>
</s:Envelope>
If the server detects the SOAP Message header with Compression element with correct associated attributes
(as specified above), it will treat the request stream as being compressed. The server will then uncompress
the body stream enclosed within the <SC:CompressedData> </SC:CompressedData> tags into the original
SOAP message body and process it as normal. If the server can not find the SOAP Message HTTP header
with Compression element with correct associated attributes, an exception will be thrown to the client.
To inform the Client that the response is compressed:
 The following Compression header will be added to the SOAP header
<Compression
s:mustUnderstand="1"
Algorithm="http://dest.gov.au/Heims/compression/gzip"
xmlns="http://dest.gov.au/Heims/compression"/>
Compression Header Attribute
Value Required
Algorithm
xmlns
http://dest.gov.au/Heims/compression/gzip
http://dest.gov.au/Heims/compression

And the compressed content of the Soap Message Body will be enclosed within these elements:
<SC:CompressedData xmlns:SC="http://dest.gov.au/Heims/compression">
</SC:CompressedData
The client will have to intercept the response from the Server and will have to uncompress the stream with in
the <SC:CompressedData> </SC:CompressedData> into the original SOAP message body and process it as
normal.
Version 1.8
Page 6 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.4
Technical Specification
Security
HEIMS Applications and Offers Web Services use Basic Authentication over SSL for secure communication.
Basic Authentication is widely supported and part of the HTTP 1.1 standard. In Basic Authentication, the
client provides the username and password, which are Base64 encoded and sent directly to the server.
Encryption of the communication channel is then handled by the SSL protocol.
The following security rules apply to login passwords for HEIMS Web Services:








3.5
Passwords will expire after 30 days;
The last 10 passwords are recorded so that passwords cannot be reused;
Strong passwords will be used – They must contain a combination of upper and lowercase
characters, numbers and special characters (eg. #, @, $);
Password must be between 7 and 15 characters long;
After a password has been successfully changed by a user, it cannot be changed again within a 24hour period except by the HEIMS IT Liaison officer.
The maximum number of failed logon attempts before the account will be locked is 3;
If the account is locked, the HEIMS Help Desk (heims.datacollections@education.gov.au or phone
on (02) 6240 7487 must be contacted to reset the password.
After a password has been reset, it must be changed by calling the ChangePassword method before
any other HEIMS Web methods are called. The number of days elapsed since the password was
changed is then reset to zero
Transactions Overview
The LoadApplicationsAndOffersSubmission method of the Applications and Offers Web Service has only a
batch implementation. Any LoadApplicationsAndOffersSubmission request will be placed in the batch queue
on the server to be processed when resources become available on the server.
3.5.1
Batch Transactions
Batch transactions are submissions that are placed in a queue for later processing. Batch methods can
contain requests for multiple transactions and therefore can be very large in size.
An invocation of a batch transaction will usually comprise of two method calls: The first call contains any
request-specific information plus any transaction data. The server accepts the request and marks it for
processing. The second (and optional) call polls the server and checks for the results of the job. If the job has
completed, the results are returned back to the caller. Otherwise, the server will inform the client that the
original request is still being processed.
Version 1.8
Page 7 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
HEIMS Applications and
Offers Web Service
TAC System
(1a) TAC calls HEIMS Passing a unique RequestId
(1b) HEIMS replies acknowledgement
(2a) TAC requests results using original RequestId
(2b) HEIMS sends results for transaction
Figure 1: Message Flow in Batch Transactions
Version 1.8
Page 8 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.6
Technical Specification
Service Agreements and Availability
The department is committed to providing a high performance, reliable, available and fully supported HEIMS
production environment. The department will endeavour to provide the following response times to all
approved HEIMS users:

Batch Transactions – 95% of all batch submissions will be processed within 24 hours after receipt
by the department.
These response figures do not include network transport times. In other words, the response times given are
from the time the department servers receive the request to the time the results are sent back from the the
department servers.
The daily limits start at 12 midnight HEIMS server time (Canberra) and apply for the following 24 hours,
rather than conforming to a 24 hour rolling window.
It is intended that HEIMS Applications and Offers Web Services will be available 24 hours a day, 7 days a
week with the following possible exceptions:


A weekly infrastructure maintenance window on Thursday evenings, 7.00pm-12.00am AEST/AEDT.
HEIMS Applications and Offers Web Services will generally be available during this period but
interruptions to service availability may occur;
A HEIMS system maintenance window as required but on Saturdays with 1 week notification by the
department. System availability in this period will depend on the amount of production maintenance
required.
The department will endeavour to minimise all system maintenance during peak enrolment periods and keep
unscheduled down-times to an absolute minimum.
Version 1.8
Page 9 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.7
Technical Specification
XML Schemas
This section describes the top level XML Schema complex types used in Applications and Offers Web
Service Request and Responses.
The actual request and response types are described in section 3.8. This section will be used to show the
high-level business objects that can be modified directly through Applications and Offers Web Services. Full
schema definitions for all HEIMS data types can be found in the WSDL (See section 4.1). Types referenced
in this section that are not represented by complex types are actually simple types.
XSD elements are used everywhere instead of attributes for compatibility reasons with older SDKs that will
be used to bind data serialisation code to the schemas.
Version 1.8
Page 10 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.7.1
Technical Specification
LoadApplicationsAndOffersSubmissionIn
LoadApplicationsAndOffersSubmissionIn refers to transaction data that contains information about
applications for admission to a higer education undergraduate award course submitted through a Tertiary
Admissions Centre (TAC). It includes details about the applicants, preferences and offers made.
LoadApplicationsAndOffersSubmissionIn is part of the LoadApplicationsAndOffersSubmissionInRequest
Figure 2: LoadApplicationsAndOffersSubmissionIn XSD complex type
Version 1.8
Page 11 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.7.2
Technical Specification
LoadSubmissionOut
LoadSubmissionOut contains the input transaction data as a stream and the status of the transaction data.
LoadSubmissionOut is part of the LoadApplicationsAndOffersSubmissionResponse.
Figure 4: LoadSubmissionOut XSD complex type
Note: Input Stream is a base64binary stream. Input Stream contains input transaction data of type
LoadApplicationsAndOffersSubmissionIn which is used for providing Applications and Offers details. Refer to
section 3.7.1 for more information on LoadApplicationsAndOffersSubmissionIn.
3.7.3
RequestControlTable
RequestControlTable is a container for all request control data. For every call to an Applications and Offers
Web Service, a RequestControlTable must always be sent. The RequestControlTable is sent wrapped
within a Request object
Figure 9: RequestControlTable XSD complex type
Version 1.8
Page 12 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.7.4
Technical Specification
ResponseControlTable
ResponseControlTable is a container for all response control data. When a client receives a response from
an Applications and Offers Web Service, a ResponseControlTable is always present. The
ResponseControlTable is sent wrapped in a response object
Figure 10: ResponseControlTable XSD complex type
3.8
Request and Response Definitions
The following object types are used generally in all HEIMS Web Service calls:
 Response objects and request objects;
 Response control tables and Request control tables; and
 Response transaction data and request transaction data.
Note: In this and following sections, element fields will be defined in terms of XML data types. If an XML data
type has a prefix of xs, it refers to a built-in XML data type that is part of the
http://www.w3.org/2001/XMLSchema namespace. If the data type has a heims prefix, it refers to elements that
are part of the http://dest.gov.au/Heims/ namespace. Full schema definitions for all HEIMS data types can be
found in the WSDL (see section 4.1).
3.8.1
Request Identifiers
Request identifiers (RequestIds) are an important part of HEIMS Applications and Offers Web Services.
They are included in every web method call to identify an individual request. The length of the RequestId
must be between 1 and 36 characters. The suggested format of the RequestId is "HHHHAO YYYYMMDD
HH:MM:SS:NN" where:
 "HHHH" is your TAC Client Organisation Code
 "AO" is the literal text "AO"
 "YYYY" is the four digit current year
 "MM" is the two digit current month
 "DD" is the two digit current day
 "HH" is the two digit current hour
 "MM" is the two digit current minute
 "SS" is the two digit current second
 "NN" is the two digit current millisecond
The value of the RequestId must only be unique within a particular TAC and it must retain uniqueness over
time. It is the responsibility of the TAC to ensure that all its client systems internally keep track of all previous
RequestIds and to synchronise generation of unique RequestIds for new calls.
Every time a method is called, a new RequestId must be sent to the server. When returning the processing
results of the request, the server response will include the same RequestId. In order to guarantee that the
server does not process the same request twice due to a communication failure, calls to a web method
providing an old RequestId will return the results of the old request. No new processing will be performed.
3.8.2
Request Object Schema
The request object is a generic container that holds all the information a client needs to send to a HEIMS
Applications and Offers Web Service. It contains request control data (one RequestControlTable) plus
Version 1.8
Page 13 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
multiple request transaction data elements. For batch methods, there is no limit on the number of
transactions allowed per request.
The classes shown in Figure below represent all of the request classes.
Figure 11: General Request Class Diagram
The classes in the diagram above represent complex types in the XML Schema. Other types have a simple
mapping to XSD simple types, such as DateTime (xs:dateTime) and string (xs:string). Enumerations map
trivially to XSD enumerations. Note that the List<T> type (used in each request class) will be mapped to
ArrayOf{T} as a SOAP operation parameter.
3.8.3
Response Schema
Similarly, the response schema is a container for all information an Applications and Offers Web Service
sends to a client. It contains response control data (one ResponseControlTable) plus one or more response
transaction data elements.
The classes shown in the diagram below represent all of the response classes.
Version 1.8
Page 14 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
Figure 12: General Response Class Diagram
The classes in Figure above represent complex types in the XML Schema. Other types have a simple
mapping to XSD simple types, such as DateTime (xs:dateTime) and string (xs:string). Enumerations map
trivially to XSD enumerations. Note that the List<T> type (used in each response class) will be mapped to
ArrayOf{T} as a SOAP operation parameter.
3.8.4
Control Data
Control data is present in all communication between clients and HEIMS Applications and Offers Web
Services. It provides information concerned with the HEIMS Applications and Offers Web Service
infrastructure and as such, is essential to every HEIMS Applications and Offers Web method. There are two
control data structures: RequestControlTable and ResponseControlTable.
RequestControlTable
RequestControlTable is a container for all request control data. For every call to a HEIMS Applications and
Offers Web Service, a RequestControlTable must always be sent. It must be sent wrapped within a request
object. The RequestControlTable contains the following fields:
Field Name
XML Type
Description
RequestId
ClientOrganisationCode
RequestLocalDateTime
heims:RequestId
heims: ClientOrganisationCode
xs:dateTime
The request identifier.
The client’s 4-digit identifying code.
Date and time on the client at the time of the
call.
ResponseControlTable
Similarly, the ResponseControlTable is a container for all response control data. When a client receives a
response from a HEIMS Applications and Offers Web Service, a ResponseControlTable is always present. It
must be sent wrapped in a response object. A ResponseControlTable object contains the following fields:
Field Name
XML Type
Description
RequestId
heims:RequestId
ClientOrganisationCode
heims: ClientOrganisationCode
CurrentDateTime
xs:dateTime
ReceivedDateTime
xs:dateTime
RequestStatus
heims:RequestStatus
The same request identifier of the original
request.
The 4-digit identifying code of the client that
issued the original request.
Date and time on the server at the time the
response was sent.
Date and time on the server when the server
first received the request.
Contains a RequestStatusCode – the current
status of the request, and Messages – a list
of messages associated with the request.
The RequestStatus element contains two fields, RequestStatusCode and Messages. RequestStatusCode
contains information on the status of the request itself. It is not related to the status of the individual
transactions. For example, a request can have a RequestStatusCode equal to ‘SUCCESS’, but all of its
individual transactions can fail business processing. RequestStatusCode can take the following values:
Version 1.8
Page 15 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
RequestStatusCode
Conditions
DUPLICATE
The RequestId of the current request has already been used. Request transaction
data will contain the results of the original request. No new processing was
performed on the server.
An error occurred with the request. Request transaction data will not contain results.
The request is currently being processed or is queued for processing. Request
transaction data will not contain results.
The RequestId of the current request has already been used more than 30 days
ago. The server has since then archived the processing results. Request
transaction data will not contain results.
The request has been processed successfully. Request transaction data will
contain processing results.
The request has been successfully submitted for batch processing.
FAILURE
PROCESS
ARCHIVE
SUCCESS
SUBMITTED
The Messages element contains a list of messages concerned with the request. For example, if
RequestStatusCode has a value of ‘FAILURE’, Messages will contain descriptions as to why the original
request was invalid.
3.8.5
Transaction Data
Transaction Data contains business information specific to the method being called. Request Transaction
Data contains data required to perform the required business service, while SubmissionResults (Response
Transaction Data) contains the results of processing the request.
Request TransactionData is currently being used in LoadApplicationsAndOffersSubmissionRequest only.
SubmissionResults (Response Transaction Data) is only used in DataSubmissionResponse.
Because each method has different input and output fields, each method defines different request and
response transaction data schemas. There are however, two fields that are common across transaction
schemas, RecordId and TransactionStatus.
Record Identifier
The record identifier (RecordId) is an element common to both request and response transaction data
elements. When a batch request contains more than one transaction, the RecordId is used to distinguish
between each transaction data element.
The RecordId is an integer. For any request, the value of the RecordId must be unique across all
transactions in the request.
In the context of a response transaction data element, the RecordId will match that of the corresponding
request transaction data element. This allows the client to identify which output record matches up with
which input record.
TransactionStatus
TransactionStatus is an element common only to response transaction schemas. It provides information
about the results of business processing for an individual transaction. TransactionStatus contains three
fields: TransactionStatusCode, RequestId and Messages. TransactionStatusCode indicates the processing
status of the transaction, RequestId indicates which request this transaction belongs to and Messages is an
array of Message elements. Within the context of TransactionStatus, each Message element holds business
validation or business error messages for that transaction.
TransactionStatusCode can take on the following values:
Version 1.8
Page 16 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
TransactionStatusCode
Description
SUCCESS
The individual transaction processed correctly according to its respective business
rules. Other response transaction data fields will contain valid output.
The individual transaction failed processing according to business rules. Other
response transaction data fields will not contain valid output.
The individual transaction processed correctly but with warnings. Other response
transaction data fields will contain valid output; however the Messages element
will contain warning messages which should be investigated by the client in order
to maintain data and processing integrity.
The individual transaction has been ignored. A transaction may be ignored if it
matches various operation specific business rules.
FAILURE
WARNING
IGNORED
3.8.6
Messages
As mentioned in the previous sections, both the RequestStatus and TransactionStatus fields contain the
Messages element. This element is used to hold any messages concerned with either the request or its
constituent transactions. The Messages element itself only contains an array of individual Message
elements. Each Message element contains three fields: Code, Description and MessageSeverity.
MessageSeverity can take on the following values:
MessageSeverity
Description
INFORMATION
WARNING
The message is of an informational nature.
The message provides a warning which should be investigated. When a warning
message is produced, it usually means that the request or transaction was successful,
but with caveats.
The message is produced when the request or transaction has failed. It contains
reasons as to why it failed and what caused the error.
ERROR
Version 1.8
Page 17 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
3.9
Technical Specification
Error Handling
3.9.1
Schema Errors
Every request received by a HEIMS Applications and Offers Web Service is validated against the respective
schema for that method. The validation performs checks to do with the format and structure of the request
fields. If the request does not comply with the schema, the returning SOAP message will not contain any
response data, only a SOAP fault. An example of a server response to an invalid request would look like:
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring
xml:lang="en-AU">Xml Schema Validation Error(s)</faultstring>
<detail>
<SchemaValidationFault
xmlns="http://dest.gov.au/Heims/"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<ValidationErrors>
<SchemaValidationFaultItem>
<TransactionIdentifier>0</TransactionIdentifier>
<ElementName>FamilyName</ElementName>
<LineNumber>1</LineNumber>
<ColumnNumber>1240</ColumnNumber>
<Description>
The 'http://dest.gov.au/Heims/:FamilyName' element is invalid - The
value '' is invalid according to its datatype
'http://dest.gov.au/Heims/:FamilyName' - The actual length is less
than the MinLength value.
</Description>
</SchemaValidationFaultItem>
</ValidationErrors>
</SchemaValidationFault>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>
Within the detail element, HEIMS Applications and Offers Web Service will place a SchemaValidationFault
element containing a ValidationErrors element. ValidationErrors element will contain a
SchemaValidationFaultItem element for each error encountered. The SchemaValidationFaultItem element
contains the following fields:
SOAP Fault Element Name
Description
TransactionIdentifier
This refers to the RecordId of the transaction data element that contains the
error. This field applies to errors with transaction data only. Errors concerned
with control data or errors to do with the entire request (eg. duplicate RecordId
values) will result in an empty RecordId value.
The element in which the error occurred.
The line number of the incoming request where the error occurred.
The column number of the incoming request where the error occurred.
A brief description of why the element was invalid.
ElementName
LineNumber
ColumnNumber
Description
Line and column number will only be useful if the tools used to call Web Services allow access to view the
raw SOAP request sent over the wire. In any case, the other fields (RecordId, Element and Description)
should be sufficient to pinpoint where the error occurred in the request.
Version 1.8
Page 18 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
Errors in the request control data (RequestControlTable) will return a SOAP fault immediately and no input
transaction data will be validated. If any schema validation errors are detected, HEIMS Applications and
Offers Web Service will not store the request which means the same RequestId can be re-used.
3.9.2
Business Errors
Once the incoming request has validated successfully against the schema, the server will process each
transaction according to the respective business rules. Any errors or messages for a transaction data
element arising from this validation are stored in the TransactionStatus field.
Version 1.8
Page 19 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
4 Interfaces
4.1
General Information
This section provides a list of all available Applications and Offers Web Services methods.
NOTE (1): It is necessary to use Basic Authentication via SSL to call any Applications and Offers web
methods and the account used for calling the methods must be authorized to perform the business function
implemented by the method.
End point URL:
https://app.heims.education.gov.au/WCFServices/ApplicationsAndOffersSubmissionService.svc
WSDL Location
https://app.heims.education.gov.au/WCFServices/ApplicationsAndOffersSubmissionService.svc?wsdl
The available interface methods are:
Section4.2
LoadApplicationsAndOffersSubmission
To submit an Applications and Offers
submission.
Section 4.3
GetApplicationsAndOffersSubmissionResults
To retrieve the results of an Applications
and Offers submission.
Section 4.4
Ping
To test Web Service connectivity
4.2
LoadApplicationsAndOffersSubmission method (for submission of
Applications and Offers data for batch processing)
Method Signature
LoadSubmissionOutResponse LoadApplicationsAndOffersSubmission
(LoadApplicationsAndOffersSubmissionInRequest request)
Description
The LoadApplicationsAndOffersSubmission method can be used to load Applications and Offers data for
new or updated submissions.
HEIMS Applications and Offers Web Service will validate the data against formatting rules. If the formatting
rules are validated successfully, the submission will be placed in a batch queue. Any business rules defined
in the Data Element Definitions (Appendix C) will be validated during the batch processing of the submission.
Requires Compression
Yes
4.3
GetApplicationsAndOffersSubmissionResults method (for retrieving the
results of a processed submission of Applications and Offers data)
Method Signature
LoadSubmissionOutResponse GetApplicationsAndOffersSubmissionResults
(GetSubmissionResultRequest request)
Description
This method retrieves the results of a submission that was previously submitted for batch processing.
Version 1.8
Page 20 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
Requires Compression
Yes
4.4
Ping method
Method Signature
string Ping()
Description
This method allows a client application to ping the server. It returns a string containing the date and time on
the server.
Requires Compression
Yes
Version 1.8
Page 21 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
5 Security – Change Password
End point URL: https://app.heims.education.gov.au/Webservices.CHESSN/Security.asmx
Note: End Point URL is different for Change Password method, and does not use compression.
Method Signature
void ChangePassword(string logonId, string currentPassword, string newPassword)
Description
This method allows a user to change their password used to authenticate themselves on HEIMS web
services. The following rules apply when changing passwords



The logonId given as the first parameter to the method must match the logon ID used to authenticate
with HEIMS.
The currentPassword must be valid for the logon ID.
The newPassword must conform to the HEIMS password security rules.
Soap envelope for change password should look like:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ChangePassword>
<logonId>testuser</logonId>
<currentPassword>Password1</currentPassword>
<newPassword>Password2</newPassword>
</ChangePassword>
</soap:Body>
</soap:Envelope>
If any of the above rules are not met, a SOAP exception will be thrown. Within the SOAP fault, the faultstring
tag will contain the error message. For example:
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>New Password must be between 7 and 15 characters
long.</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Once this method has been successfully called to change a password, it cannot be called again within a 24
hour period.
Requires Compression
No
Version 1.8
Page 22 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
6 Environments
There are two environments available to users of HEIMS Applications and Offers Web Services:


Production; and
Next Production Release (NPR).
The NPR environment is available to external departmental clients to enable them to develop or maintain
their in-house systems that interface with the department’s web services. Up-and-coming changes to the
department’s web services are made available in NPR as soon as is practicable.
6.1
Production
See section 3 of this document for functionality available for HEIMS Applications and Offers Web Services
live production environment.
The production end point is:
https://app.heims.education.gov.au/WCFServices/ApplicationsAndOffersSubmissionService.svc
6.2
Next Production Release
An NPR environment will be made available to TACs to allow them to test functionality against the HEIMS
Applications and Offers Web Services. Further details will be provided directly to TACs as they become
available.
The NPR end point is:
https://extranet.education.gov.au/appheimsnpr/WCFServices/ApplicationsAndOffersSubmissionService.svc
7 Certificate
Application and Offers web service Certificate Authoritie (CA) has been changed from
sanExternalSite.ssc.gov.au to san.education.gov.au (Baltimore CyberTrust Root). The update in certificate
will encrypt all transmitted data between client machine and HEIMS web service server. The change in
certificate has been implemented from July 2014. The sanExternalSite.ssc.gov.au certificate will be
decommissioned on 27/02/2016. You will need to ensure that the latest certification is installed by
27/02/2016.
The san.education.gov.au (Baltimore CyberTrustRoot) certificate can be downloaded from
https://app.heims.education.gov.au/WCFServices/ApplicationsAndOffersSubmissionService.svc
Additional information to assist IT administrator with install the CA onto client system can be found at the
following links.
 Exporting Certificate Authorities (CAs) from a Website

How to call a Web service by using a client certificate for authentication in an ASP.NET Web
application
Version 1.8
Page 23 of 33
9/02/2016
HEIMS Applications and Offers Web Service Interface
Technical Specification
8 Troubleshooting
If any problems are encountered with HEIMS Web Services, the first point of contact should be the HEIMS
Helpdesk at heims.datacollections@education.gov.au or phone on (02) 6240 7487.
Version 1.8
Page 24 of 33
9/02/2016
HEIMS Web Service Interface
Technical Specification
A. Appendix A – References and Other Relevant Documents
A.1
References
The table below lists all external documents, web sites and other information sources that are referenced in
this document or have been used in the gathering of requirements.
Id
References
1
Web Services Architecture
W3C Working Group Note 11 February 2004
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
2
Extensible Markup Language (XML) 1.0 (Third Edition)
W3C Recommendation 04 February 2004
http://www.w3.org/TR/2004/REC-xml-20040204/
3
XML Schema Part 1: Structures
W3C Recommendation 2 May 2001
http://www.w3.org/TR/xmlschema-1/
4
XML Schema Part 2: DataTypes
W3C Recommendation 02 May 2001
http://www.w3.org/TR/xmlschema-2/
5
SOAP Version 1.2 Part 1: Messaging Framework
W3C Recommendation 24 June 2003
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
6
7
8
A.2
AS 4590-1999 Interchange of Client Information
Standards Australia
ISO/IEC 11179 Information Technology – Specification and Standardization of Data Elements
ISO/IEC 7064 Information Technology – Security techniques – Check character systems
Other Relevant Documents
Other technical documentation may be sent to stakeholders to provide additional advice on integration with
the HEIMS Applications and Offers Web Services if new issues or requirements arise.
Version 1.8
Page 25 of 33
9/02/2016
HEIMS Web Service Interface
Technical Specification
B. Appendix B – Glossary
Term
Description
Authorisation
Determining a user’s access to a resource. Authorisation almost always relies
on the user having been authenticated.
Authorised user
Authorised users are users authorised by the department.
Basic Authentication
A standard HTTP authentication protocol supported by most browsers where
username and password is transmitted as Base-64 encoded text.
GUID
Globally Unique Identifier:
A special type of identifier used in software applications in order to provide a
reference number that is unique in the context for which it is used.
HTTP
HyperText Transfer Protocol:
An application layer protocol that provides a standard for Web browsers and
Web servers to communicate.
HTTPS
HyperText Transfer Protocol (Secure):
HTTP exchanged over an SSL encrypted session.
MegaByte
1,048,576 Bytes
SDK
Software Development Kit:
A software development kit (SDK) is typically a set of development tools that
allows a software engineer to create applications for a certain software
package, software framework, hardware platform, computer system, video
game console, operating system, or similar.
SOAP
Simple Objects Access Protocol:
An XML based lightweight protocol for exchange of information in a
decentralised, distributed environment.
SSL
Secure Sockets Layer:
A protocol developed by Netscape for transmitting private documents via the
Internet. SSL works by using a private key to encrypt data that's transferred
over the SSL connection. Both Netscape Navigator and Internet Explorer
support SSL and many Web sites use the protocol to obtain confidential user
information, such as credit card numbers. By convention, URLs that require an
SSL connection start with https: instead of http:.
TCP/IP
Transmission Control Protocol/Internet Protocol:
A suite of protocols that computers use to exchange information over the
Internet.
URL
Uniform Resource Locator
A global identifier for a network-retrievable document.
UTF-8
8-bit UCS/Unicode Transformation Format
A variable-length character encoding for Unicode. It is able to represent any
character in the Unicode standard. UTF-8 is the standard encoding method for
Email, web pages and XML documents.
W3C
World Wide Web Consortium:
An international consortium of companies involved with developing standards
for the Internet and the Web.
Web Services
Web Services are designed to support interoperable machine-to-machine
interaction over a network through the use of open standards that enable
systems built on different technologies to exchange data and supply services.
The modern definition that Web Services always use the W3C Simple Object
Access Protocol (SOAP) specification to format messages (regardless of
transport) is used here.
Version 1.8
Page 26 of 33
9/02/2016
HEIMS Web Service Interface
Technical Specification
WSDL
Web Services Definition Language
The standard format for describing a Web Service. Written in XML, it defines
how to access a Web Service and what operations it will perform.
XML
eXstensible Markup Language:
A text based specification used to promote interoperable exchange of data
through standardised validation mechanisms and expression of data in a
human-readable, self-describing manner.
XSD
XML Schema Definition
XML schema, published as a W3C Recommendation in May 2001, can be used
to express a scheme: a set of rules to which an XML document must conform in
order to be considered ‘valid’ according to that schema. However, unlike most
other schema languages, XML Schema was also designed with the intent of
validation resulting in a collection of information adhering to specific data-types,
which can be useful in the development of XML document processing software.
Version 1.8
Page 27 of 33
9/02/2016
HEIMS Web Service Interface
Technical Specification
C. Appendix C - Data Element Map
The Applications and Offers Data Element Map for the Tertirary Admissions Centres lists the data fields
identified for the HEIMS Tertiary Admissions Centre submission process. This list provides a link between
the business requirements in this document and the Applications and Offers Scope and Structure
documents.
A summary description of the data elements is included on HEIMSHELP.
The rows of the Data Element Map are ordered by Data Grouping and by Data Element and includes the
following columns.
Column Heading
Meaning and Usage
Element Name
A unique name for each piece of data that is being collected.
Element Number
The element number in the Applications and Offers Submission
Specifications.
Width
The maximum number of characters that each text field can contain.
Data Type
The type of the individual fields and information on the values that will
be stored. The possible types are:
Mandatory (Y or N)

Numeric – a number either integer or where required fractional.

Text - a variable length text string.

Date – a string representing a valid date.
Whether or not the individual field is mandatory or optional.

Y - the data item is Mandatory, it must be provided before the
set of information of which this field is a part can be successfully
transferred into the Department.

N - the data item is Optional, it does not have to be provided
before the set of information that this field is a part of can be
successfully transferred into the Department.
NOTE: Independent of whether or not a data item is mandatory or
optional for the purpose of transferring the data into the Department,
other business rule cross checking that is applied during batch
processing of the submission may require particular fields to contain
particular values.
Parent Schema Entity
The XSD Complex Type that contains this data element.
Schema Element
The XSD Element in the Schema Entity that will be populated by this
data element.
Version 1.8
Page 28 of 33
9/02/2016
Element Name
Higher Education Provider code
Element
Number
306
Width
4
2
Data
type
Parent Schema
Entity
Schema Element Name
Restriction
Y
Preference &
Offer
HigherEducationProviderCode
0000, 1000-9999
Text
Y
Preference &
Offer
CourseOfStudyTypeCode
01, 02, 03, 04, 05, 06, 07, 08, 09,
10, 11, 12, 13,14, 20, 21, 22, 30,
50, 60, 61, 80, 81, 82, 99
Date
Y
AoApplication
BirthDate
YYYY-MM-DD
>= 1879
Text
Mandatory?*
Course of study type code
310
Date of birth
314
Gender code
315
1
Text
Y
AoApplication
GenderCode
M, F, X
Aboriginal and Torres Strait Islander
code
316
1
Text
N
AoApplication
AtsiCode
2, 3, 4, 5, 9
Location code of permanent home
residence
320
5
Text
Y
AoApplication
PermanentHomeAddressLocationCode
99999, A0001-9998, X9999,
X1200-9299
Basis for admission to offered course
327
2
Text
N
Offer
OfferedCourseBasisForAdmissionCode
01, 29, 31, 33, 34, 36, 37, 99
ModeOfAttendance
1, 2, 3
Mode of attendance code
329
1
Text
N
Preference &
Offer
Year of arrival in Australia
347
4
Text
N
AoApplication
YearOfArrival
0000, 0001, A998, A999, 19002099
Language spoken at home code
348
4
Text
N
AoApplication
SpokenHomeLanguageCode
0001, 9998, 9999, 1000-1199,
1300-9799
Citizen/resident indicator
358
1
Text
Y
AoApplication
CitizenshipStatusCode
1, 2, 3, 8
Tertiary Entrance Score
369
3
Text
N
AoApplication
TertiaryEntranceScore
001, 998, 999, 030-100
Surname
402
30
Text
Y
ApplicantName
FamilyName
Can contain any of the following:
A-Z, a-z, 0-9, (space) & ‘ ( ) , - . /
[]_:
First character cannot be blank
Given name – first
403
15
Text
Y
ApplicantName
GivenName
“
Given names – other
404
30
Text
N
ApplicantName
OtherGivenNames
“
Postal address – part 1
406
38
Text
Y
AoAddress
AddressLine1
“
Postal address – part 2
407
38
Text
N
AoAddress
AddressLine2
Postal address – postcode
409
4
Text
N
AoAddress
PostCode
0001-9999
Field of education code
461
6
Text
N - Preference
Y - Offer
Preference &
Offer
FieldOfEducationCode
000000, 010000-129999
Text
N - Preference
Y - Offer
Preference &
Offer
FieldOfEducationCodeSupplementary
000000, 010000-129999
Field of education supplementary
code
462
6
“
Postal address – suburb/town
466
27
Text
Y
AoAddress
LocalityName
Can contain any of the following:
A-Z, a-z, 0-9, (space) & ‘ ( ) , - . /
[]_:
First character cannot be blank
Postal address – state code
467
3
Text
N
AoAddress
StateCode
NSW, VIC, QLD, WA, SA, TAS,
NT, ACT, AAT
Version 1.8
Page 29 of 33
9/02/2016
Element Name
Postal address – country name
Highest educational participation
Course campus postcode
Element
Number
468
493
559
Width
20
6
5
Data
type
Text
Text
Text
Mandatory?*
N
Parent Schema
Entity
AoAddress
Schema Element Name
Restriction
CountryName
Can contain any of the following:
A-Z, a-z, 0-9, (space) & ‘ ( ) , - . /
[]_:
First character cannot be blank
N
AoApplication
HighestEducationalParticipation
First 2 digits must be: 02, 03, 04,
05, 07, 08, 09, 10, 11
If first 2 digits are 09, last 4 digits
must be 0000, otherwise last 4
digits must be in range 19502099, or 9999
N
Preference &
Offer
CourseCampusPostCode
A0001-9998, X1200-9299
Application identification code
700
20
Text
Y
AoApplication
ApplicationIdentificationCode
Can contain any of the following:
A-Z, a-z, 0-9, (space) & ‘ ( ) , - . /
[]_:
First character cannot be blank
Application status
701
1
Text
Y
AoApplication
ApplicationStatusCode
1, 2
Australian Year 12 result type code
702
2
Text
N
AoApplication
AustralianYear12ResultsCode
01, 02, 03, 04, 05, 06, 07, 08, 09,
10
Date offered
705
Date
Y
Offer
DateOffered
YYYY-MM-DD
IntakeDate
Year: 2009-2099
Month: 00-12
Intake date
709
6
Numeric
Y
Preference &
Offer
International Baccalaureate
aggregate score
710
2
Text
N
AoApplication
InternationalBaccalaureateAggregateScore
21-45, 99
Interstate Transfer Index
711
5
Text
N
AoApplication
InterstateTransferIndex
00.00-99.95
PreferenceOrdinalPosition
00-99
Preference ordinal position
713
2
Text
Y
Preference &
Offer
Response code
723
1
Text
N
Offer
ResponseCode
1, 2, 3, 4, 5, 6
Sector code
724
1
Text
Y
Preference &
Offer
SectorCode
1, 2, 3, 4
Postal address – country code
728
4
Text
N
AoAddress
CountryCode
1101-9299
Overall Position
729
2
Text
N
AoApplication
OverallPosition
01-25, 99
First digit: 1, 2, 3
If 1st digit is 1, last 4 must be
0000, otherwise last 4 must be in
range 1900-2099, or 9999
Prior postgraduate course; year
730
5
Text
N
AoApplication
PriorPostGraduateCourseCodeYear
Prior bachelor course; year
731
5
Text
N
AoApplication
PriorBachelorDegreeCourseCodeYear
“
Prior sub-degree course (HE); year
732
5
Text
N
AoApplication
PriorHeSubDegreeCourseCodeYear
“
Prior sub-degree course (VET); year
733
5
Text
N
AoApplication
PriorVetSubDegreeCourseCodeYear
“
Prior VET award course; year
734
5
Text
N
AoApplication
PriorVetAwardCourseCodeYear
“
Version 1.8
Page 30 of 33
9/02/2016
Element Name
Element
Number
Width
Data
type
Mandatory?*
Parent Schema
Entity
Schema Element Name
Restriction
First digit: 1, 2
If 1st digit is 1, last 4 must be
0000, otherwise last 4 must be in
range 1900-2099, or 9999
Prior secondary education course
through VET sector; year
735
5
Text
N
AoApplication
PriorVetSecondaryEducationCourseCodeYear
Prior secondary education course at
school; year
736
5
Text
N
AoApplication
PriorSchoolSecondaryEducationCourseCodeYear
“
Prior other qualification/ certificate;
year
737
5
Text
N
AoApplication
PriorOtherCertificateQualificationCourseCodeYear
“
Y
RequestControl
Table
RequestId
Y
RequestControl
Table
Request ID
36
Client Organisation Code
4
Text
DateTime
Request Local Date Time
Submission Reference Year
4
Submission Reporting Period
1
Submission Number
Commonwealth Higher Education
Student Support Number (CHESSN)
Text
1
488
10
Text
Text
Numeric
Text
ClientOrganisationCode
Must match the client
organisation code of the logged
on user
Y
RequestControl
Table
RequestLocalDateTime
YYYY-MM-DDTHH:mm:SS.s
+zzzz
See
http://www.w3.org/TR/xmlschema
-2/#dateTime
Y
SubmissionMeta
data
SubmissionReferenceYear
Current year or next year
Y
SubmissionMeta
data
SubmissionReportingPeriod
1-5
Y
SubmissionMeta
data
SubmissionNumber
N
AoApplication
CHESSN
* Optional elements that are blank or contain only spaces should not be passed in the XML
Version 1.8
Page 31 of 33
9/02/2016
E488 (CHESSN) if NOT NULL or
ZZZZZZZZZZ must be a valid
string:(1000000000 to
9999999999)
D. Applications and Offers Web Service Requests and Responses
D.1
LoadApplicationsAndOffersSubmission
<xs:element
name="LoadApplicationsAndOffersSubmissionInRequest">
<xs:complexType>
<xs:annotation>
<xs:documentation>A request to the LoadOffersSubmission method.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element
name="RequestControlData"
type="RequestControlTable"
minOccurs="1"
maxOccurs="1"/>
<xs:element
name="SubmissionMetaData"
type="SubmissionMetadata"
minOccurs="1"
maxOccurs="1"/>
<xs:element
name="TransactionData"
type="ArrayOfLoadApplicationsAndOffersSubmissionIn"
minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="LoadSubmissionResponse">
<xs:annotation>
<xs:documentation>A response from Load Submission calls.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="ResponseControlData" type="ResponseControlTable" minOccurs="1" maxOccurs="1" />
<xs:element name="LoadSubmissionResults" type="ArrayOfLoadSubmissionOut" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
Version 1.8
Page 32 of 33
9/02/2016
D.2
GetApplicationsAndOffersSubmissionResultsRequest
<xs:element name="GetApplicationsAndOffersSubmissionResultsRequest">
<xs:annotation>
<xs:documentation>Returns submission results for a request id.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="RequestControlData" type="RequestControlTable" minOccurs="1" maxOccurs="1" />
<xs:element name="SubmissionRequestId" type="RequestId" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element
name="GetApplicationsAndOffersSubmissionResultsResponse">
<xs:annotation>
<xs:documentation>Returns submission results.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element
name="ResponseControlData"
type="ResponseControlTable"
minOccurs="1"
maxOccurs="1"/>
<xs:element
name="GetApplicationsAndOffersSubmissionResults"
type="ArrayOfLoadSubmissionOut"
minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Version 1.8
Page 33 of 33
9/02/2016