state of minnesota documents... · state of minnesota department of public safety bureau of...

STATE OF MINNESOTA

DEPARTMENT OF PUBLIC SAFETY

BUREAU OF CRIMINAL APPREHENSION

Query Motor Registration Information Service

(QMR)

Published On: September, 2010 Service Release Version#: 1.0

Prepared By:

Bureau of Criminal Apprehension Criminal Justice Information Systems

1430 Maryland Avenue East St. Paul, Minnesota 55106

SERVICE SUMMARY Service

Visibility Public Restricted Private

See Glossary for definitions

Service Description

This service provides users with the capability of retrieving information on vehicle registration, the owner’s MN and NCIC hot files and vehicle’s MN and NCIC hot files if any.

Accessibility BCA Criminal Justice Partners

Service Inputs Vehicle Identification Number (VIN) and related information

Vehicle License Plate Number (LIC) and related information

Service Outputs MN DVS Motor Vehicle Registration

MN and NCIC Vehicle and Person Hot Files

Business and Technical Service Description v1.0

11/24/2010 12:18:55 PM

Document Revision History

Date Version Description Author

09/21/2010 1.0 Initial Document BCA MNJIS


11/24/2010 12:18:55 PM

Table of Contents

SERVICE SUMMARY .............................................................................................................................................. 1

BUSINESS SERVICE DEFINITION ...................................................................................................................... 4

QUERY MOTOR REGISTRATION SERVICE ................................................................................................................... 4

SERVICE OVERVIEW .................................................................................................................................................. 4

REAL WORLD EFFECTS .............................................................................................................................................. 4

SUMMARY ................................................................................................................................................................. 4

BUSINESS SCENARIOS ................................................................................................................................................ 5

INPUT DETAIL AND BUSINESS VALIDATION RULES ................................................................................................... 5

SERVICE CONSUMERS AND ACCESS RIGHTS .............................................................................................................. 5

SERVICE-LEVEL EXPECTATIONS ................................................................................................................................ 5

SERVICE LOGGING AND AUDITING REQUIREMENTS .................................................................................................. 7

TRAINING AND CERTIFICATION ................................................................................................................................. 7

POLICIES .................................................................................................................................................................... 8

STATUTES AND RULES ............................................................................................................................................... 9

RULES ........................................................................................................................................................................ 9

STATUTES ................................................................................................................................................................ 10

BUSINESS USE-CASE ............................................................................................................................................... 12

TECHNICAL SERVICE DEFINITION ................................................................................................................ 18

ACCESSING THE SERVICE......................................................................................................................................... 18

PRE-CONDITIONS (TECHNICAL) ............................................................................................................................... 18

POST-CONDITIONS (TECHNICAL) ............................................................................................................................. 18

SERVICE INTERFACE ................................................................................................................................................ 18

MESSAGE FORMAT .................................................................................................................................................. 18

EXCEPTION CONDITIONS AND ERROR HANDLING .................................................................................................... 19

SECURITY PROFILE .................................................................................................................................................. 19

APPENDIX A: GLOSSARY ................................................................................................................................... 20


11/24/2010 12:18:55 PM

Business Service Definition

Query Motor Registration Service

Service Overview

The Query Motor Registration (QMR) information service is a message key in the Law Enforcement Message Switch (LEMS) system that retrieves information on motor vehicle registration, the owner’s hot files and vehicle’s hot files if any. QMR enables law enforcement personnel to discover the identity and criminal status of a vehicle’s owner and the legal status of a vehicle. Specific data retrieved includes MN motor vehicle registration, MNJIS and NCIC Vehicle and Person Hot Files. See the following example:

Real World Effects

The following is a list of effects of using this service:

A BCA criminal justice partner obtains MNJIS and NCIC hot files associated with a vehicle and its owner(s), and the vehicle’s Minnesota vehicle registration.

Summary

A User’s application hub submits a service call to the BCA Enterprise Service Bus (ESB), which authorizes, authenticates, and validates the request. A valid request is then routed through the

Service Inputs: Vehicle License Number (LIC) with options Vehicle License State (LIS) and Vehicle License Year (LIY) or Vehicle Identification Number (VIN)

Service Outputs: MNJIS and NCIC Vehicle and Person Hot Files MN Vehicle Registration

Consumer of Service: BCA Criminal Justice Partner

Provider of Service: BCA MNJIS Hot Files and NCIC Hot Files, DVS


11/24/2010 12:18:55 PM

Law Enforcement Message Switch (LEMS) as a query to the required data sources, the Department of Vehicle Safety (DVS) database, MNJIS Hot Files, and NCIC Hot Files. Either a vehicle registration and hot files or “No Hit” responses are returned to the BCA via the LEMS, is validated, and stored in the SQL Server database until the User Application Hub requests the response. The BCA ESB sends the vehicle registration and hot file responses (if any) or “No Hit” response to the User Application Hub.

Business Scenarios

This service’s resulting vehicle registration and hot file data will be used by courts, law enforcement, and other BCA criminal justice partners in investigations on vehicles and/or individuals in line with officially assigned duties. This may be in conjunction with, but not limited to an investigation of an individual’s or vehicle’s legal status in connection with an actual or alleged crime, confirmation of identity or other cause; often in conjunction with a traffic offense, an incident response, an investigation, et cetera.

Input Detail and Business Validation Rules

Mandatory QMR input includes the following criteria:

Vehicle Identification Number (VIN) or Vehicle License Number (LIC)

Optional criteria for QMR include:

Vehicle License State (LIS)

Vehicle License Year (LIY)

The following validation rules apply to QMR service calls:

Data inputs must be submitted in upper case alphanumeric characters with special characters as required or permitted for each input field.

See Appendix A: Glossary for definitions and business rules.

Service Consumers and Access Rights

The authorized users of the QMR service are select BCA personnel and BCA criminal justice partners including but not limited to law enforcement officials, courts, probation officers, and parole officers. The QMR service is query-only. No updates occur with this service.

Service-Level Expectations

Support Availability

On call support for this service is available Monday through Friday, 8:00 a.m. to 4:30 p.m., except state holidays, through the BCA Service desk at telephone number: 651-793-2500 or 1-888-234-1119.

Service Availability

This service is designed to operate 24 hours a day, 7 days a week, 365 days a year. Though this service is intended to operate 24/7/365, the BCA’s technical support of this service is limited to what has been identified in the “Support” section above.

External Service Dependencies


11/24/2010 12:18:55 PM

The driver’s license image is provided through an interface with MN Driver and Vehicle Services Division (DVS); this service must be available to the BCA ESB via LEMS in order for the service to complete successfully. If DVS services are not available, the call will be repeated until the DVS service is available.

The Law Enforcement Message Switch (LEMS) must be available in order for the service to complete successfully. If LEMS is not available for more than 30 minutes an exception will be returned indicating that the LEMS service was not available for 30 minutes.

Minnesota Hot Files, including Gang File, Predatory Offender File, Impounded Vehicle File, Protection Order File, Wanted Person File, and Keep Our Police Safe (KOPS) File must be available to the BCA ESB via LEMS in order for the service to complete successfully. If MN Hot File services are not available, the call will be repeated to MN Hot Files until the service is available.

NCIC Hot Files data are provided by the FBI and includes the License Plate File, Vehicle File, Vehicle/Boat Part File, Foreign Fugitive File, Gang File, Immigration Violators File, Known or Appropriately Suspected Terrorist File, Missing Person File, Protection Order File, Sexual Offender File, Supervised Release File, U.S. Secret Service Protective Order File, and Wanted Person File. NCIC Hot Files must be available to the BCA ESB via LEMS in order for the service to complete successfully. If NCIC Hot File services are not available, the BCA ESB will continue to attempt to access the NCIC Hot Files until the service is available.

Service Maintenance Window

The LEMS and the ESB are designed to function 24 hour per day, seven days per week. When LEMS is down, it is for patches or upgrades, usually occurring on Tuesdays or Wednesdays at 11:00 AM and lasting five to ten minutes or longer, depending on the activity. These downtimes are announced and occur on an as-needed basis.

Service Downtime Notification

The message returned during system downtime and/or unavailability will depend on the source system and the destination system. Messages returned will either indicate the host system is unavailable or the request timed out.

Expected Response Times

Responses from each system queried are delivered separately to ensure the return of information as it becomes available. Average response times vary depending on the responding system as described below.

DVS Responses: within one second

MN Hot Files Responses: within two seconds

NCIC Hot File Responses: within thirty seconds


11/24/2010 12:18:55 PM

Service Logging and Auditing Requirements

Service consuming agencies are responsible for complying with FBI security policies in Criminal Justice Information Services (CJIS) Security Policy, Version 5.0, (CJISD-ITS-DOC-08140-5.0), including but not limited to logging and auditing requirements in section “5.4 Policy Area 4: Auditing and Accountability”.

Log files should be maintained for six years to meet Minnesota state legislature auditor requirements. If a six year retention program is not feasible for the consuming entity, the consuming entity may submit to the BCA a written request for an exemption to the six-year retention policy. The written request must include a detailed explanation describing the reason why the six year retention policy is not feasible and specify an alternative retention period. BCA management will consider each such request on a case by case basis.

Note: Responses from the BCA contain confidential data. Agency staff, including

employees and contractors, that can access logs containing confidential data provided by BCA services must be fingerprinted and have a criminal background check performed. An individual must pass the background check before access to service logs is allowed.

Training and Certification

The BCA shall ensure that security awareness training is provided at least once every three years to all personnel who manage or have access to FBI CJIS systems. All new employees who have access to FBI CJIS systems and all appropriate IT personnel shall receive security awareness training within six (6) months of their appointment or assignment. Documentation pertaining to the materials used and those employees which receive security awareness training shall be maintained in a current status.

The BCA’s responsibilities:

1. Within 6 months of employment or assignment train, functionally test, and affirm the proficiency of terminal (equipment) operators in order to assure compliance with FBI CJIS policy and regulations;

2. Biennially, provide functional retesting and reaffirm the proficiency of terminal

(equipment) operators in order to assure compliance with FBI CJIS policy; 3. Maintain records of all training, testing, and proficiency affirmation; 4. Initially (within 12 months of employment or assignment) provide all sworn law

enforcement personnel with basic training in NCIC 2000 matters to ensure effective use of the System and compliance with FBI CJIS policy regulation;

5. Make available appropriate training on NCIC 2000 System use for criminal

justice practitioners other than sworn personnel;


11/24/2010 12:18:55 PM

6. Provide all sworn law enforcement personnel and other practitioners with continuing access to information concerning NCIC 2000/state Systems using methods such as roll call and in-service training;

7. Provide peer-level training on NCIC 2000 System use, regulations, policy, audits,

sanctions, and related civil liability for criminal justice administrators and upper-level managers;

8. Annually review all curricula for relevancy and effectiveness; 9. Instituted appropriate and reasonable quality assurance procedures for all

federal and state System users; and 10. Ensure reasonably sufficient record management, for electronic and/or hardcopy

case management systems, by ensuring that there are security standards, audit standards, and personnel training standards which allow accurate and up-to-date records and proper/secure dissemination of the same.

The BCA’s Criminal Justice Partners’ responsibilities:

1. The primary responsibility for the entry and maintenance of accurate, timely, up-to-date and complete records lies with the entering agency.

2. Each agency is required to develop system security training that covers appropriate use, dissemination, and security requirements for their agency.

Policies

BCA policy “ADMINISTRATIVE POLICY NO. 6203” for the BCA’s general handling of public, private, and confidential data states the following:

“Data accessible to BCA personnel is often Private or Confidential Data; therefore, it is important to ensure the integrity of that data. BCA Personnel may only access those data sources, systems and storage devices they have authority to access strictly for the purpose of fulfilling their assigned job duties. Accessing a data source, data system or storage device for any other purpose is a violation of this policy and may also be a violation of the data practices act and/or federal law. “To clarify this policy further, one may not access data on individuals known to the employee (e.g. family members, friends, daughter’s boyfriend, etc.). If during the course of your duties you encounter information or a need to access information on any such individual, you should immediately report it to your supervisor so the task may be reassigned. “Violation of this policy will result in discipline, which may include dismissal from employment, and may result in criminal prosecution.”

Please see the BCA’s General Policies for complete text.

The following statements are drawn from the “Data Practices Assessment Checklist” and provide additional details regarding how to execute the following rules and statutes.


11/24/2010 12:18:55 PM

A clearly defined and stated purpose for a service is necessary to help a government entity decide what data it needs to collect. It can also help it determine if providing the data is mandatory or voluntary by data subjects.

Copies of data on individuals taken for backup and recovery purposes, as well as those used for development, testing, training and certification, should be protected electronically (via encryption) and physically. Consider opportunities for loss, theft, or disclosure of data on individuals through premeditated, opportunistic and accidental means.

A data subject can challenge data wherever it is maintained, even if the data did not originate in that agency. While not required, coordinating data challenges with the originating agency would be the most effective way for an entity to reach a determination as to data that didn’t originate with their agency. Additionally, providing assistance to a data subject in locating inaccurate/incomplete wherever it is maintained would be a valuable customer service and best practice.

Training and certification activities, while necessary for “administration and management of programs,” can be accomplished without the aid of private or confidential data on individuals.

As a responsible business practice, private/confidential data on individuals should not be used by or disseminated to employees or contractors if their work assignments could be completed using surrogate data that is not private or confidential data on individuals.

Development and testing activities, while necessary for “administration and management of programs,” can be accomplished without the aid of private or confidential data on individuals.

If data elements or records are removed, hidden or altered to prevent the identification of individuals, it must be evident that: 1) the resulting data set does not contain private or confidential data on individuals, and 2) one could not easily reverse these alterations to reveal the original data.

If a data subject successfully challenges the accuracy and/or completeness of data, the responsible authority must make every reasonable effort to notify those who accessed the challenged data.

Knowing the classification of data determines who has access and for what purpose(s). Security measures are also based on the sensitivity / classification of the data. Therefore, anyone can have access to public data and can’t be required to explain how it will be used.

Statutes and Rules

Rules

1205.0300 – Access to Public Data: procedures regarding data collection must be easily accessible to the public with free copies available.

1205.0400 – Access to Private Data, subp. 2: only individuals within an entity whose work assignments reasonably require it can have access to private/confidential data. Individuals can include employees in an entity as well as contractors. Subp. 3:


11/24/2010 12:18:55 PM

safeguards are in place to ensure individuals given access to data are the correct individuals.

1205.0500 - Access to Private Data Concerning Data Subjects Who are Minors; a government entity must have a plan for reviewing the administration of their data collection and storage. Subpart 5, provides direction for the treatment of any unnecessary data. Subp. 3: procedures must be in place for parents to access information about their minor children.

1205.0600 – Access to Confidential Data, subd. 2(A): only individuals within an entity whose work assignments reasonably require it can have access to private/confidential data. Individuals can include employees in an entity as well as contractors.

1205.1300 - Duties of the Responsible Authority in Administering Private and Confidential Data, subp. 5: state and federal law may require certification or baseline training of users for a particular data system before data may be accessed.

1205.1500 – Duties of Responsible Authority in Administering All Entity Data: the responsible authority is required to establish procedures to ensure that data are accurate, complete and current.

Statutes

MSS 13.03 – Access to Government Data, subd. 1, all government data is public unless it is otherwise classified by state or federal law. Subd. 2(b): procedures regarding data collection must be easily accessible to the public with free copies available. Subd. 4: data classification “travels” from one government entity to another. Unlike the general rule, criminal justice data often remains public at a local level and changes to private/confidential classification at the state level. Ex: arrest data is private at BCA, public at local law enforcement agency.

MSS 13.04 – Rights of Subjects of Data, subd. 2: a data subject is entitled to a warning before private or confidential data are collected from them. Subd. 3: the responsible authority must prepare data subject access procedures. Subd. 4: procedures must be in place to allow data subjects to challenge the accuracy and/or completeness of data about him or her, to flag any data being challenged, and to post the subject’s statement of disagreement.

MSS 13.05 – Duties of Responsible Authority, subd. 3, a government entity can only collect private or confidential data on individuals that are necessary “for the administration and management of programs specifically authorized by legislature or local governing body or mandated by the federal government.” Subd. 4: “Private or confidential data on an individual shall not be collected, stored, used, or disseminated by government entities for any purposes other than those stated to the individual at the time of collection,” therefore, private or confidential data on an individual can only be collected from that individual if the individual is given a Tennessen warning. Subd. 2, provides an exception “when an individual is asked to supply investigative data pursuant to 13.82, subd. 7, to a law enforcement officer.” Subd. 5(2): the responsible authority is required to establish appropriate security safeguards for data on individuals. Subd. The BCA must maintain a contract with Dakota County requiring compliance to data practices. Subd. 8: the responsible authority must prepare data subject access


11/24/2010 12:18:55 PM

procedures. Subd. 13: the names of the responsible authority/designees/data practices official for an agency must be publicized.

When private or confidential data on an individual is collected from a third party, a Tennessen warning is not given to the individual. If a Tennessen warning was required but was not given, the statute provides that the government agency cannot use the data at all. Subd. 5(1): the responsible authority is required to establish procedures to ensure that data are accurate, complete and current. Subd. 9: not public data can only be shared with another government entity if a state or federal law requires it.

MSS 13.82 – Comprehensive Law Enforcement Data, subd. 2; Private/confidential data are not available to the public. Data related to arrest/deprivation of liberty are public at the originating law enforcement agency but become private as part of “criminal history” data at the BCA.

MSS 13.87 – Criminal Justice Data, subd. 1; Private/confidential data are not available to the public. Data related to arrest/deprivation of liberty are public at the originating law enforcement agency but become private as part of “criminal history” data at the BCA.

MSS 138.17 – Government Records Administration: Data must be maintained according to an approved retention schedule. A specific individual is assigned the task of assuring compliance to records management laws and procedures.

MSS 171.07, subdivision 1A establishes access to driver photo information from Driver and Vehicle Services.

MSS 171.12, subdivision 7(d) establishes access to driver license address data.

MSS 260B.171 – Records, subd. 5; peace officer records on juvenile offenders must be kept separately from records on individuals 18 yrs and over.

MSS 299C.095, 299C.10, 299C.11, 299C.13, 299C.14: a government entity can only collect private or confidential data on individuals that are necessary “for the administration and management of programs specifically authorized by legislature or local governing body or mandated by the federal government” (See MN Stat. 13.05, subd. 3).

MSS 299C.15 – Cooperation; Criminal Identification Organizations: provides access to required data.

MSS 299C.46 – Criminal Justice Data Communications Network: provides access to required data.


11/24/2010 12:18:55 PM

Business Use-Case

Main Flow – Query The Main Flow for this use case is described below.

Pre-Conditions

The following must occur before the flow begins:

1. The following inputs are known and provided: Vehicle License Number (LIC) with optional Vehicle License State (LIS) and Vehicle License Year (LYR), or Vehicle Identification Number (VIN) for a motor vehicle is known.

Post-Conditions Success End-Conditions The following have occurred as a result of the successful completion of the main flow:

1. The query results in a hit or “NOT ON FILE” for MN DVS, a hit or “NO

HIT” for MN hot files, and a hit or “NO RECORD” for NCIC hot files.

2. Hits collectively reveal the past and present owner(s) of the vehicle, whether the vehicle is stolen or involved in a felony, whether the owner(s) are missing persons, whether any warrants are on file for the owner(s), and all other results possible per information stored in MN hot file and NCIC hot files data sources.

3. Non-hits reveal that the data sources queried have no information on the

vehicle in question. Failed End-Conditions The following have occurred as a result of the main flow failing:

1. One or more of the databases queried return an error message indicating

information submitted was in some way erroneous. This may be due to a syntax error, missing data, a system failure, or a system being down.

2. The ESB security or archive service returns an error message to the agency hub reporting an error with authentication, authorization, or validation.


11/24/2010 12:18:55 PM

QUERY MOTOR REGISTRATION (QMR) REQUEST INSTANCE

Consumer

Application HUB

ESB

LEMS Request Service

LEMS,

Data SourceData Server

M9. LEMS Queue

Pass?N

M10. Translate

Y

M1. Submit

Request

M2. Authorize,

Authenticate,

Validate

M3. Translate

M6. Receive

Message

Receipt

M5. Archive

Req. Msg.

Receipt

M7. LEMS Queue

M8. Query

Data Sources

Request

Response

M2.A. Receive

Error Message

M4. Place

hold in data

store

M11. Hold

in data

store

M1. Submit Request A law enforcement agent (user) initiates a query from the Consumer Application Hub, or “hub”. His or her system puts the request in XML format encased in a SOAP envelope, which is sent to the BCA.

M2. Authorize, Authenticate, Validate

The security service performs an authentication and authorization of the hub’s ID and password to confirm whether the consumer application hub may request a QMR query. The message SOAP format is validated against the schema.

Pass? If the authentication, authorization, and validation are successful, then the flow continues to M3. Translate. If the authentication, authorization, or validation is unsuccessful, then the flow continues to M2.A. Receive Error Message. M2.A. Receive Error Message

The ESB sends an error message to the user, indicating either a failure to authenticate, pass authorization, or validate the schema.


11/24/2010 12:18:55 PM

The user’s hub receives the response message including the correlation ID.

M3. Translate

The XML message is translated to SIF format.

M4. Place hold in data store

A placeholder is placed in the data store. In this way, the data store is prepared to receive responses.

M5. Archive Request Message Receipt

The archive service archives the response message with correlation ID being sent to the hub. The full response to the client is archived, including the correlation ID for the request.

M6. Receive Message Receipt The Consumer Application Hub receives a message confirming the query has been received, which includes a correlation ID.

M7. LEMS Queue

The query is placed in the LEMS Queue, where it waits until LEMS is able to process it. LEMS removes the query from its queue and directs it the required data sources.

M8. Query Data Source

DVS Database. The inquiry is received by Minnesota Drivers and Vehicle Services (DVS) data source. This data source returns vehicle registration information including the identity of its owner(s), past and present. A hit produces the desired information; a no hit produces a “NOT ON FILE” response. The response “NO HIT D.L.REG. BUT M.V.REG ON FILE” reveals a person owns a registered motor vehicle but does not have a driver’s license.

MNJIS Hot Files. The inquiry is received by Minnesota Hot Files data source. This data source returns information on the vehicle and its owner(s) per its databases. A hit generates a hit response with information. A no-hit generates a “NO HIT” response. MNJIS Hot Files queried include the Gang File, Predatory Offender File, Impounded Vehicle File, Protection Oder File, Wanted Person File, and Keep Our Police Safe (KOPS) File.

NCIC Hot Files. The inquiry is received by National Crime Information Center (NCIC) Hot Files data source. Its databases return information on the vehicle and its owner(s). A hit generates a hit response with information. A no-hit generates a “NO RECORD” response. NCIC Hot Files queried include the License Plate File, Vehicle File, Vehicle/Boat Part File, Foreign Fugitive File, Gang File, Immigration Violators File, Known or Appropriately Suspected Terrorist File, Missing Person File, Protection Order File, Sexual Offender File, Supervised Release File, U.S. Secret Service Protective Order File, and Wanted Person File.


11/24/2010 12:18:55 PM

M9. LEMS Queue

The query is placed in the LEMS Queue, where it waits until LEMS is able to process it. ESB removes the query result from its queue and directs them to SQL Database.

M10. Translate

The SIF message is translated into XML.

M11. Hold in data store

The separate responses received through LEMS from the data sources are held separately, until the user hub retrieves them by correlation ID.

Main Flow – Request Response

The Main Flow for this use case is described below.

Pre-Conditions The following must occur before the flow begins:

1. The response from the data source is received, translated to XML, validated, and stored in the data store.

Post-Conditions

Success End-Conditions The following have occurred as a result of the successful completion of the main flow:

1. Parsed XML is returned to the client.

2. The consumer of the service has a drivers’ license image for the person in question.

Failed End-Conditions

The following have occurred as a result of the main flow failing:

1. The database queried returns an error message indicating information submitted was in some way erroneous. This may be due to a syntax error, missing data, a system failure, or a system being down.

2. The ESB security or archive service returns an error message to the consumer application hub reporting an error with authentication, authorization, or validation.


11/24/2010 12:18:55 PM

M12. Request

Response

M13. Authorize,

Authenticate,

Validate

N

Y

Pass?

M15. Create

Response

M18. Receive

Response

Message

M17. Archive

Request and

Response

M16.

Validate

M13.A. Receive

Error Message

QUERY MOTOR REGISTRATION (QMR) RESPONSE INSTANCE

All anticipated

responses in?Y

N

Consumer

Application HUB

ESB

LEMS Request ServiceData Server

Query

Request

M14.

Retrieve

from data

store

M12. Request Response The consumer application hub requests responses for the query, sending the correlation ID as the transaction identifier.

M13. Authorize, Authenticate, Validate

The ESB authenticates the hub’s identity and whether the hub is authorized to request the query results.

Pass?

If the authentication and authorization is successful, then the flow continues to M14. Retrieve from data store. If the authentication and authorization are not successful, then the results of the inquiry are withheld and an error message is sent to the hub; the flow continues to M13.A. Receive Error Message.

M13.A. Receive Error Message

The hub receives an error message indicating the ESB rejected the request due to a problem with authorization, authentication, or validation.

M14. Retrieve from data store

The query results are identified by correlation ID, copied from the data store, and brought into the ESB.

M15. Create Response

The various responses from the SQL database are formatted into a Response Message instance document.


11/24/2010 12:18:55 PM

M16. Validate

The Response Message instance is validated.

Pass?

If the response message is valid, then the flow continues to M17. Archive Request and Response. If the message is invalid, the results of the inquiry are withheld and an error response message is generated; the flow continues to M17. Archive Request and Response.

M17. Archive Request and Response

The valid response or error message response is sent to Archive Services. Either response is sent to the hub.

M18. Receive Response Message

The consumer application hub receives the response from the ESB in XML, in a SOAP envelope.

All anticipated responses in?

If one or more responses have not been received, the hub will repeat its request. This will continue until each of the message keys and their three data sources have given a valid response.

The following fault conditions could exist: 1. One or more systems involved in this service is unavailable. 2. The service query request is unauthorized, fails to authenticate, or is invalid. 3. The data source returns an invalid response. 4. The service results request is unauthorized, fails to authenticate, or is invalid.

Alternative Flows

No alternative flows exist for this service.


11/24/2010 12:18:55 PM

Technical Service Definition

Accessing the Service

Accessing the Query Motor Registration Information service is restricted to systems on the CJDN network that have access to the BCA’s ESB. The Query Motor Registration Information Service interface is not discoverable.

Once an agency is approved for access to this service, BCA will provide a document that includes access details.

Pre-Conditions (Technical)

MCJE compliant request

Request is valid

Request contains a valid instance of the BCA Header

Access to this service is secured. The agency must have a valid MNJIS System user ID and password

Post-Conditions (Technical)

This is a read only service; therefore this service will not change the state or data

All requests to and responses from this service will be archived

Service Interface

Provide Justice Partners the ability to submit Query Motor Registration requests. Responses from this service are retrieved using the BCA Asynchronous Messaging pattern as follows:

1. Upon submitting a Query Motor Registration request operation, the service returns a “MessageReceipt” that contains a unique correlation ID synchronously.

2. The service consumer will then make a “RequestMessage” request operation passing in the correlation ID obtained from the initial request. If the responses are available, an MCJE compliant “ResponseMessage” will be returned. If the responses are not available, an empty response will be returned by the service and the service consumer needs to make another “RequestMessage” request at a later time.

Once an agency is approved for access to this service, BCA will provide a document that includes the WSDL.

Message Format

Communication to and from this service is handled using Simple Object Access protocol (SOAP). Request and Response messages are XML instances that are embedded in the header and body of the SOAP envelope.

Both the Request and Response XML messages conform to the BCA’s Schema standards. There are multiple Schema files that define the request and response formats. The sample exchanges


11/24/2010 12:18:55 PM

are meant to demonstrate several but not all possible query/response scenarios and can be used as a basis for understanding how to use this service.

Once an agency is approved for access to this service, BCA will provide a document that includes the schemas and sample messages.

Submission Request/Response Messages

The following is a list of the supported request operations (refer to the request message schemas):

o QueryMotorVehicleRegistrationRequest

The response to the above requests is a “MessageReceipt” (refer to the MessageReceipt schema) that contains a unique correlation ID

Retrieve Request/Response Messages

The request for retrieving the responses is a RequestMessage (refer to the RequestMessage schema)

The following is a list of the responses (refer to the response message schemas) that are wrapped in a ResponseMessage (refer to the ResponseMessage schema):

o QueryMotorVehicleRegistrationResponse

Exception Conditions and Error Handling

This service will return a SOAP Fault if there is an error with the Service Consumer initiated calls

If the consumer’s request contains improper data in the BCA Header or service request, the XML response will contain a FailureReason that describes the error

During processing unhandled exceptions happen for unknown and unpredicted reasons. When an unhandled exception occurs, a Fault is returned to the consumer of this service. The Fault element will contain any known information about the unhandled exception.

Security Profile

Access to this service is limited to criminal justice agencies that are connected to the State of Minnesota Criminal Justice Data Network (CJDN). Workstations and servers that access the services must be granted access by IP address through the BCA’s firewall in order to reach the servers where the service is running. The IP addresses of all computers directly accessing the services must be provided to the BCA so that firewall rules can be created.

This service operates over HTTPS on TCP/IP port 443. An SSL certificate is required to be installed on any workstation or server consuming this service. SSL certificates can be obtained from the BCA.

When configuring the endpoint in a consuming client or service, make sure that “https” is specified.


11/24/2010 12:18:55 PM

Appendix A: Glossary

LIC (License Plate Number) – license plate number of vehicle that is the subject of the query.

FORMAT: Format: alphanumeric, maximum 10 characters. BUSINESS RULES:

Prohibited for RQ transactions using VIN.

The values "UNK", "UNKN", "UNKNOWN" may be used in inquiry transactions. For entry of a record with those values, contact the FBI CJIS staff.

If the license plate number exceeds ten characters, only the first ten characters should be entered in the LIC Field.

LIS (Vehicle License State) – state, country or Indian Nation that issued the license plate. Format: alphabetic, two characters. For a list of state codes, see “state codes”. Mandatory for QMR if the vehicle LIC is not from Minnesota.

Code Definition Code Definition

AL AK AZ AR CA CO CT DE DC FL GA HI ID IL IN IA KS KY LA ME MD MA MI MN MS MO MT

Alabama Alaska Arizona Arkansas California Colorado Connecticut Delaware District of Columbia Florida Georgia Hawaii Idaho Illinois Indiana Iowa Kansas Kentucky Louisiana Maine Maryland Massachusetts Michigan Minnesota Mississippi Missouri Montana

NB NV NH NJ NM NY NC ND OH OK OR PA PR RI SC SD TN TX US UT VT VA WA WV WI WY

Nebraska (also see NE) Nevada New Hampshire New Jersey New Mexico New York North Carolina North Dakota Ohio Oklahoma Oregon Pennsylvania Puerto Rico Rhode Island South Carolina South Dakota Tennessee Texas Diplomatic Plates/United States Government Utah Vermont Virginia Washington State West Virginia Wisconsin Wyoming


11/24/2010 12:18:55 PM

Code Definition Code Definition

EE AX XC XP XD XE DA DW DW DP XF DL XG FC XO IW KK KW LP LL

Absentee Shawnee Apache Tribe Bad River Band of Lake Superior Tribe of Chippewa Indians Bois Forte Band of Chippewa Caddo Tribe Cherokee Nation Cheyenne & Arapaho Tribes Citizen Band Pottawatomie Tribe Citizen Pottawatomie Nation Comanche Nation Delaware Nation Devil’s Lake Sioux Tribe Eastern Shawnee Tribe Fond du Lac Grand Portage Band of Lake Superior Chippewa Iowa Tribe Kickapoo Tribe Kiowa Lac du Flambeau – Band of Superior Chippewa Leech Lake band of Chippewa

IX DS LC XH DT OS OT OG OO XI PW XJ PN XK RL RL FX SK DV KP UC XL XM WE WE WT WD

Menominee Miami Tribe Mille Lacs Modoc Tribe Muscogee (Creek) Tribe Oglala Sioux Oneida Tribe of Indians of Wisconsin Osage Nation Otoe-Missouria Tribe Ottawa Tribe Pawnee Tribe Peoria Tribe Ponca Tribe Quapaw Tribe Red Lake Red Lake Band of Chippewa Sac & Fox Seminole Nation Seneca-Cayuga Tribes Shakopee Turtle Mountain Band of Chippewa United Keetoowah Band of Cherokee Indians Western Delaware Tribe White Earth White Earth Band of Chippewa Wichita Tribe Wyandotte Tribe

LIY (License Year) – License plate year of expiration; the highest year for which the license plate

is valid.

FORMAT: numeric or “NX” for Non-Expiring, two or four characters. BUSINESS RULES:

Must be a valid four-character year (YYYY) or the alphabetic NX to represent a non-expiring registration.

Must be greater than equal to the current year minus one and less than 9999.

For stolen plates the value can be current year, current year minus one, or later than current year.

Private Service - A service that is only available internal to the BCA. That is, can only be

consumed by other BCA services.

Public Service - A service that it is available for anyone to consume. This includes anyone with access to a computer and the World Wide Web.


11/24/2010 12:18:55 PM

Restricted Service - A service that can only be consumed after authorization and configuration

by the BCA.

VIN (Vehicle Identification Number) - a unique serial number used by the automotive industry to identify individual motor vehicles.

FORMAT: alphanumeric, A-Z excluding the letters I, O, and Q; 0-9, 20 characters maximum. BUSINESS RULES:

A single zero only, run of zeros only, single alphabetic only, all alphabetic characters only, or spaces, are prohibited.

Vehicles manufactured prior to 1981 may have an alternate format.

If the vehicle identification number exceeds 20 characters, only the last 20 characters should be entered in the VIN Field.

Connecticut and Michigan acknowledge only 17 characters.

Kansas limits VIN to 18 characters.

state of minnesota documents... · state of minnesota department of public safety bureau of...

Documents