Department of Homeland Security
Immigration and Customs Enforcement (ICE)
Student and Exchange Visitor Information System (SEVIS) II
Batch User Manual
October 2, 2009
This document is confidential and intended solely for the use and information of the client to whom it is addressed.
SEVIS II Batch User Manual v0.6 Draft
Document Change History
Version Number / Date / Author / Description0.1 / September 23, 2009 / Uday Yallapragada and Delna Williams / Initial draft.
0.2 / September 28, 2009 / Alexandra Holt / Technical writer edits.
0.3 / September 29, 2009 / Uday Yallapragada and Padmapriya Allamsetty / Addressed technical writer comments and made additional update.
0.4 / September 29, 2009 / Alexandra Holt / Technical writer edits.
0.5 / October 1, 2009 / Uday Yallapragada and Delna Williams / Updated schema.
0.6 / October 2, 2009 / Alexandra Holt / Technical writer edits.
This document is confidential and intended solely for the use and information of the client to whom it is addressed.
i October 2, 2009
SEVIS II Batch User Manual v0.6 Draft
Table of Contents
1 INTRODUCTION 1
1.1 Purpose 1
1.2 Background 1
1.3 Scope 1
2 System Details 3
2.1 System Overview 3
2.2 System Description 4
2.3 Batch Workflow 5
3 Security 8
3.1 Transport Level Security 8
3.2 Message Level Security 8
3.2.1 Authentication 8
3.2.2 Authorization 8
3.3 Application Level Security 8
4 Interface Specification 9
4.1 XML Schema Specification 11
4.2 Batch Request Message Structure 11
4.2.1 EVBatchHeader 12
4.2.2 EVBatchTransaction 13
4.3 Batch Response Message Structure 14
4.4 Fault Messages 15
4.5 Service Specification 15
5 Testing 17
6 Batch Registration 18
Appendix A: XSD for Request Messages 19
A.1.1 sevis2_batch.xsd 19
A.1.2 ev_containers.xsd 26
A.1.3 ev_complex_types.xsd 47
A.1.4 sevis2_complex_types.xsd 68
A.1.5 simple_types.xsd 70
Appendix B: Draft XSD for Response Messages 159
Appendix C: Draft WSDL for Batch Exchange visitor service 163
Appendix D: Error Code Tables 165
Appendix E: ACRONYMS AND DEFINITIONS 166
List of Figures
Figure 1: Batch Process Overview 3
Figure 2: Batch System Overview 4
Figure 3: Batch Workflow 6
Figure 4: Structure of Sevis2Batch Envelope 12
Figure 5: Structure of Sevis2TransactionDetail 14
Figure 6: Structure of Sevis2BatchResponse 15
Figure 7: Sevis2Batch Service WSDL 16
Figure 8: Register for Batch Processing 18
List of Tables
Table 1: Exchange Visitor Request Types 9
Table 2: Acronyms and Definitions 166
This document is confidential and intended solely for the use and information of the client to whom it is addressed.
i October 2, 2009
SEVIS II Batch User Manual v0.6 Draft
1 INTRODUCTION
1.1 Purpose
This document will serve as a guide for the Batch user community to interact with the Student and Exchange Visitor Information System (SEVIS) II application. This manual will provide Batch registration, implementation, and testing guidance. This document will capture aspects related to registration, connectivity, security architecture, eXtensible Markup Language (XML) schema, response message handling, and error framework among other topics.
1.2 Background
SEVIS is a key component of the strategy of the Immigration and Customs Enforcement (ICE) to prevent criminals and terrorists from exploiting the U.S. immigration system. Prior to 9/11, few systems were in place to help authorities accurately monitor the immigration status of foreign students and exchange visitors. Through the use of new systems, such as SEVIS I, National Security Entry-Exit Registration System (NSEERS), and United States Visitor and Immigration States Indication Technology (USVISIT), ICE referred more than 6,000 compliance enforcement investigations to ICE field offices in FY06, resulting in more than 1,700 arrests.
SEVIS provides timely information to ICE, Customs and Border Protection (CBP), United States Citizenship and Immigration Services (USCIS), and Department of State (DoS). SEVIS maintains records on more than 116,800 dependents of these students and exchange visitors. In addition to data entered by schools and sponsor officials, SEVIS receives updates from systems such as the CBP Arrival/Departure Information System (ADIS). Academic institutions are notified of nonimmigrant entry. If students fail to enroll at the school, student records are terminated in SEVIS, which triggers an investigation from the ICE Office of Investigations.
ICE seeks to replace the current system (SEVIS) with an updated system (SEVIS II) via a completely different architecture. Primarily, SEVIS limitations stem from the fact that it was designed to track documents instead of individuals, creating the possibility of an individual being identified by numerous different records within the system. This limitation makes it almost impossible to comprehensively track all of an individual’s activities. This weakness, along with other technical and functional issues, drives the need for the SEVIS II effort.
1.3 Scope
The initial draft version of this document will focus primarily on the Exchange Visitor component of the SEVIS II Batch system. Future versions of this document will include the Student component and any updates to the Exchange Visitor. Note that because the XML schemas included in this document as a work in progress, this is a living document that Booz Allen will update as needed. As development progresses, updates will be made to registration, connectivity specifications, security architecture, XML schema and any other framework items.
The following topics will be included in future versions of this living document as the design and development progresses:
· Solution for print of Form DS-2019D
· Solution for print of Form DS-7002
· Complete details on the authentication and authorization connectivity
· Complete details on batch registration
· Completed detail on connectivity testing
· Completed detail on pre-production testing
· Field-level business rules
· Complete list of enumerations for the schema
· Complete list of error codes
2 System Details
2.1 System Overview
Schools and sponsors may use private application systems to manage student, exchange visitor, and dependent records in their own environments. The SEVIS II Batch interface provides the capability to securely send this information from their private application systems to SEVIS II application, obviating the need to enter this information again through the SEVIS II real-time interactive (RTI). Schools and sponsors must be a registered SEVIS II Batch user before they can start using the SEVIS II Batch system. SEVIS II Batch registration is completed through the SEVIS II RTI. Section 6 provides additional information on the Batch registration process (also available on the SEVIS II website).
Figure 1 depicts a high-level overview of the SEVIS II Batch flow.
Figure 1: Batch Process Overview
The following contains concepts associated with the SEVIS II Batch system. Note that Section 2.2 further details these concepts.
- User systems will directly send a Simple Object Access Protocol (SOAP) request message to SEVIS II application. The body of this SOAP message will in turn have a SEVIS II-specific XML payload. This XML payload can contain information of multiple students or exchange visitors. This XML message will be referred to as the Batch-request in this document.
- User systems will invoke a SEVIS II Web Service securely and will then send the Batch-request.
- User systems will receive a synchronous SOAP response message back indicating the status of the transmission.
- SEVIS II will subsequently send back a detailed response message to an FTP server. Schools and sponsors can pull the response messages securely from the FTP server.
- The SEVIS II application will authenticate and authorize the Batch-requests before they are processed.
2.2 System Description
The SEVIS II Batch process will allow user systems to send student and/or exchange visitor management data directly to SEVIS II using XML and Web Services standards and to receive detailed response files (in XML format) back from SEVIS II. This process will rely on secure communication protocols and robust security frameworks. Figure 2 depicts the various steps involved in this process.
Figure 2: Batch System Overview
The following instructions detail the process shown in Figure 2:
1. User systems will extract relevant student or exchange visitor data (along with dependent information) using their internal processes and will create a Batch-request XML that confirms the SEVIS II Batch schemas. Each Batch-request message can contain data corresponding to students or exchange visitors in a single program only. The maximum number of request records that a Batch-request can contain will be determined in a future version of this document.
2. User systems will create a SOAP message with the Batch-request XML in the SOAP Body and will post the SOAP message over Hyptertext Transfer Protocol Secure (HTTPS) to a SEVIS II Batch Web Service. This SOAP message will have appropriate security credentials populated in the SOAP header. Section 3 provides details of the security architecture.
3. SEVIS II Batch Web Service will authenticate and authorize the request before processing the request.
4. After successful authentication and authorization, SEVIS II Batch Web Service will validate the request for well-formed XML and will verify the schema compliance.
5. If the Batch-request fails in either steps 3 or 4, the request will not be processed further and the process ends.
6. SEVIS II Batch Web Service will send a synchronous SOAP/HTTPS response message back to the user system indicating the status of steps 3 and 4.
7. If authentication, authorization, and validation are successfully completed, this Batch-request will be forwarded to the application server for further processing.
8. The SEVIS II Batch Web Service will process each record within the Batch file; therefore, each student, exchange visitor, and/or dependent record will have specific business rules applied based on visa type. A response XML message will be created for each of the records based on the processing results. Any errors with data in a specific record will be reported back within the response message. A consolidated response XML file that confirms the SEVIS II response schema will be created for each Batch message received.
9. The consolidated response XML file will be sent to a File Transfer Protocol (FTP) server. Schools and sponsors can periodically check and retrieve the files from the FTP server.
2.3 Batch Workflow
This section briefly discusses the steps that a sponsor or school will complete before they go live with SEVIS II. Figure 3 depicts a pictorial of this workflow.
Figure 3: Batch Workflow
The following instructions detail the workflow shown in Figure 3:
1. The SEVIS II Batch workflow begins when a school or sponsor decides to participate in SEVIS II Batch.
2. A school/sponsor will sign and submit a Batch registration request.
3. SEVIS II officials will review the request and issue a Batch Registration ID to the school/sponsor after approving the request.
4. The school/sponsor will procure the necessary digital certificate(s) from an approved vendor.
5. After a school/sponsor is issued a digital certificate, they will coordinate with the SEVIS II Help Desk to initiate connectivity testing.
6. After the successful completion of connectivity testing, the school/sponsor will coordinate with the SEVIS II Help Desk to initiate Batch testing in the user acceptance testing (UAT) environment.
7. After successful completion of testing in the UAT environment, the school/sponsor will go live with the SEVIS II Batch.
3 Security
Schools and sponsors will be able to send Batch messages securely to the SEVIS II Batch system. The SEVIS II Batch system employs a multi-layered security model that ensures data integrity and authenticates and authorizes the requests.
3.1 Transport Level Security
Schools and sponsors will send data securely via HTTPS to SEVIS II Batch system, ensuring that the data is encrypted before it is sent and decrypted before it is processed. This transport-level encryption and decryption of data will be based on Transport Level Security (TLS) protocol.
3.2 Message Level Security
Authentication and authorization schemas will be used in the SEVIS II Batch security model. Message-level security will be provided using concepts described in ws-security specification. Applications will send their <wsse:Security> credentials in the SOAP header. A combination of a binary token (digital signature) and a SEVIS II assigned batch registration ID will be used for authentication and authorization.
3.2.1 Authentication
Authentication will be based on the use of non-federal shared service provider (SSP) digital certificates that will be path-validated against the federal bridge and the vendor’s root certificate.
3.2.2 Authorization
After successful authentication, authorization is done using the Batch Registration ID and DNS name (or Common Name) of the server where the digital certificate is installed. Authorization is performed before the message is processed to ensure that the school or sponsor that initiated this activity is registered to do Batch.
3.3 Application Level Security
Booz Allen will provide additional text in a future version of this document.
4 Interface Specification
The SEVIS II Batch service will support the following broad categories of request-types:
· Exchange Visitor Request Types—These request types correspond to all activities related to exchange visitors and their dependents.
· Student Request Types—These request types correspond to all activities related to students and their dependents.
The SEVIS II Exchange Visitor Batch service will support the processing of exchange visitor request types, and SEVIS II Student Batch service will support the processing of student request types. The SEVIS II Batch Web Service Description Language (WSDL) will represents these services as two separate operations.
Table 1 lists all the exchange visitor request types. Booz Allen will include a similar list for student request types in a future version of this document.
Table 1: Exchange Visitor Request Types
Request Type / Short Description /CreateDS2019 / Request to create a new DS-2019
UpdateDS2019 / Request to update a DS-2019
TransferIn / Create Transfer In request
CancelTransferIn / Request to cancel Tranfer In
TransferOut / Request Transfer Out decision
AlternateProfReschScholar / Request to report a change between Professor and Research Scholar categories
ChangeCategory / Request to change J-1’s category
CancelChangeCategory / Request to cancel an existing ‘ChangeCategory’ request for a J-1
Matriculate / Request to matriculate a J-1
EditMatriculation / Request to update an existing ‘CreateMatriculation’ request
CancelMatriculation / Request to cancel an existing ‘CreateMatriculation’ request
ExtendJ1 / Request to extend an J-1’s program
CancelJ1Extension / Request to cancel an existing ‘ExtendJ1’ request
ReinstateJ1 / Request to reinstate a J-1
CancelJ1Reinstatement / Request to cancel J-1 Reinstatement
NoShowJ1 / Request to change J-1 status to No Show
CancelJ1 / Request to change J-1 status to Invalid
ValidateJ1 / Request to validate a J-1
J1CorrectREUPToActive / Request to Correct SEVIS Status or request a Reinstatement –Update SEVIS Status to Active for a J-1
J1CorrectREUPToInitial / Request to Correct SEVIS Status or request a Reinstatement –Update SEVIS Status to Initial for a J-1
CancelJ1REUP / Request to cancel J-1 Reinstatement-Update SEVIS Status
CorrectInfractionActive / Request to correct a minor or technical infraction in Active Status
CorrectInfrationInactive / Request to correct a minor or technical infraction in Inactive status
CreateAcademicTraining / Request to add Academic Training information to an exchange visitor’s record
UpdateAcademicTraining / Request to update an existing ‘AcademicTraining’ record for visitor J-1
DeleteAcademicTraining / Request to delete an existing Academic Training record for a J-1
CreateStudentEmployment / Request to add Student Employment information to a J-1’s record
UpdateStudentEmployment / Request to update an existing ‘StudentEmployment’ record for a J-1
DeleteStudentEmployment / Request to delete an existing ‘Student Employment’ record
CreateOutOfCountry / Request to create an ‘Out of Country’ record for an exchange visitor
UpdateOutOfCountry / Request to update an existing ‘OutOfCountry’ record
DeleteOutOfCountry / Request to delete an existing ‘OutOfCountry’ record for a J-1
CreateTerminateJ1 / Request to terminate a J-1
UpdateTerminateJ1 / Request to update an existing ‘CreateTerminateJ1’ request
CancelTerminateJ1 / Request to cancel an existing ‘CreateTerminateJ1’ request
CreateEndJ1 / Request to end the program for a J-1
UpdateEndJ1 / Request to update an existing ‘CreateEndJ1’ request
CancelEndJ1 / Request to cancel an existing ‘CreateEndJ1’ request
Journal / Request to add free text comments related to a specific J-1
NoShowJ2 / Request to change J-2 status to No Show
CancelJ2 / Request to change J-2 status to Invalid
ValidateJ2 / Request to validate a J-2
ReinstateJ2 / Request to reinstate a J-2
J2CorrectREUPToActive / Request to Correct SEVIS Status or request a Reinstatement –Update SEVIS Status to Active for a J-2
J2CorrectREUPToInitial / Request to Correct SEVIS Status or request a Reinstatement –Update SEVIS Status to Initial for a J-2
CancelJ2REUP / Request to cancel J-2 Reinstatement-Update SEVIS Status
CreateEndJ2 / Request to end a the program of a J-2
UpdateEndJ2 / Request to update an existing ‘CreateEndJ2’ request
CancelEndJ2 / Request to cancel an existing ‘CreateEndJ2’ request
CreateTerminateJ2 / Request to terminate a J-2
UpdateTerminateJ2 / Request to update an existing ‘CreateTerminateJ2’ request
CancelTerminateJ2 / Request to cancel an existing ‘CreateTerminateJ2’ request
4.1 XML Schema Specification
Schools and sponsors will exchange messages with the SEVIS II Batch system using pre-defined XML schema definitions. The SEVIS II Batch system will reject messages that do not comply to these schema definitions. The following list contains a few high-level concepts of XML schema specification: