INICHECK ID PRO+
Version: 2.0
By
Akshay Balasubramanian
Ashutosh Raval
Siddharth Agashe
Vaibhav Karvir
Guided by
Dr. Kwok Bun Yue (Instructor)
Mr. Bruce Brenner (Mentor)
Fall 2008
Date: 12/08/08
-i-
iniCheckID Pro+
Acknowledgement
With affection and deep appreciation, we acknowledge our indebtedness to our instructor Dr.
Kwok Bun Yue for giving us an opportunity to explore our skills and innovations beyond the
prescribed syllabi of our coursework by granting us the permission to work on an external
project. We further extend our gratitude to our mentor Mr. Bruce Brenner, President of
MiniCheck-OCR, Inc, who has been continuously guiding us throughout the course of our
project. We would also like to thank previous capstone team (summer 2008 Team #2) for
providing us with the required information and details which helped us in solving the critical
issues. We would also like to thank the Mr. Daniel C Holdgreiwe (Computer Sciences
Corporation), USCIS VIS technical support at the Department of Homeland Security for
continuously helping us with our queries.
University of Houston Clear Lake-Fall 08 -1-
iniCheckID Pro+
Abstract
MiniCheck ID Pro+TM is an extension to the existing functionalities of the application
MiniCheck IDTM and MiniCheck ID ProTM. MiniCheck IDTM mainly focused on enabling
vendors to process and validate identity cards, checks, driver licenses, barcodes and credit cards
using magnetic and optical scanners while MiniCheck ID ProTM allowed processing of credit
card transactions through the Authorize.Net payment gateway. MiniCheck ID Pro+TM
application incorporates a new functionality of E-Verify facilitating users to verify an
individual‟s employment eligibility at United States. The application allows the user to login at
E-Verify using the credentials provided by the Department of Homeland Security. The user can
verify the legal work status of the newly hired employees by providing the necessary
information. The application aims at refining the existing implementation to achieve a
production level code, thus making the application clean, user friendly and reliable. The
application merged multiple databases used in different versions of the applications, resolved
errors in supporting the RDM 7000i device, integrated Vivo Tech reader the module for the Vivo
tech reader to the MiniCheckID Pro+ application based on the documentation and module
provided by Mr. Steve Lucord, a student under Dr. Perez-Davila, UH-Clear Lake.
University of Houston Clear Lake-Fall 08 -2-
iniCheckID Pro+
Table of Contents
Acknowledgements ........................................................................................................................1
Abstract ...........................................................................................................................................2
1. Introduction .......................................................................................................................... 4-5
1.1 Purpose.................................................................................................................................4
1.2 Architecture Diagram ..........................................................................................................4
1.3 Intended Audience and Product Applications......................................................................5
2. Background .......................................................................................................................... 5-8
2.1 Product Features...................................................................................................................5
2.2 Project Scope .......................................................................................................................8
3. Project Design and Implementation ................................................................................. 8-15
3.1 Assumptions and Dependencies ..........................................................................................8
3.2 Implementation Details ........................................................................................................9
3.3 Implementation Issues and Lessons Learned .....................................................................13
4. Testing .....................................................................................................................................16
4.1 Integration Testing .............................................................................................................16
5. Conclusion ..............................................................................................................................16
6. References ...............................................................................................................................17
Appendix A……………………………………………………………………………………...18
Detailed Implementation
Appendix B……………………………………………………………………………………...29
Database Design
Appendix C……………………………………………………………………………………...30
Project Timeline
Appendix D……………………………………………………………………………………...31
Final Deliverable
Appendix E……………………………………………………………………………………...32
Team Roles and Contribution
Appendix F……………………………………………………………………………………...34
Screen Shots
Appendix G……………………………………………………………………………………...43
Acronyms and Abbreviation
University of Houston Clear Lake-Fall 08 -3-
iniCheckID Pro+
1. Introduction
1.1 Purpose
MiniCheck ID Pro+TM aims at adding additional functionalities to the existing application
MiniCheckID Pro, thus allowing a single application to be used by a diverse number of users.
The application aims at having the non functional modules to be working properly, develop a
module for E-Verify, integrate the module for the Vivo tech reader, and fine tune the code to
remove redundancy so that the end product is clean, compatible with Windows Vista thereby
taking us a step closer to production level code.
1.2 Architecture Diagram
Fig 1: Architecture of MiniCheckID Pro+
E-verify is used to verify an employee‟s right to work in the United States. The components
magneprint, magnetic ID, barcodes are all used for theft identification. Credit card functionality
allows users to purchase products and the transactions are processed through the Authorize.Net
University of Houston Clear Lake-Fall 08 -4-
iniCheckID Pro+
payment gateway. Veris is a used for SSN and address verification. Public data is used for ID
and driver license validation.
1.3 Intended Audience and Product Applications
The application has diverse users and provides multiple functionalities. The application allows
user to verify identity, execute credit card transactions and verify the federal work eligibility
status of newly hired employees. (Work status is a generic term. Readers may not associate with
federal work eligibility. A technical report should usually be as specific as possible.) Product
applications may include functionalities like age validation for restaurants and bars, gas stations,
casinos, liquor shops, etc.
2. Background
2.1 Product Features
2.1.1 E-Verification
E-verify is a program for employers to check the I-9 Form of their new employees with respect
to the database of DHS and SSA. E-verify provides a SOAP based web service for companies to
submit queries and retrieve verification results.The most important input field is the SSN. The
most important output field is whether the employee is eligible to work. Companies have a stake
in using E-Verify for verification so they can adhere to the law and avoid penalty. E-Verify helps
DHS and SSA to execute immigration and work eligibility laws.
University of Houston Clear Lake-Fall 08 -5-
iniCheckID Pro+
2.1.2 Database Refinement
Database refinement mainly involves removing the redundancy of data stored in the tables of the
database. The application has merged the multiple databases in MS Access that existed
previously to a single database so that the database is available for use in a cleaner format. Each
of the previous teams had deployed a database in MS Access to support their functionality. The
team has duplicated the tables in all the different databases into one database which is also in MS
Access.
2.1.3 Code Cleaning
Code cleaning mainly involves removing the redundancy and improving the efficiency of the
code. The implementation for this project started way back in Fall 06. Since then various teams
have worked on the code and have used their own coding techniques to achieve different
functionalities. Fall-07 team had worked on the GUI, the Spring-08 added various functionalities
such as magnetic strip reading, barcode reading, etc and the Summer-08 team had added the
credit card transaction functionality into the existing code. All these efforts had made the code
more complex to understand and very lengthy to handle. The code looked extremely unorganized
as it also had redundant data items in it. There were several variables and functions which were
never used in any context. It was the responsibility of our team (Fall 08) to structure the code and
remove the redundancy in the code.
2.1.4 Windows Vista Compatibility
As most of the machines come built in with the Windows Vista operating system, it is very
important that the application be compatible with the built in system. The previous teams had
University of Houston Clear Lake-Fall 08 -6-
iniCheckID Pro+
developed the application on the Windows XP operating system. The team made the required
changes to ensure Windows Vista Compatibility and also backward compatibility.
2.1.5 RDM 7000i device
The RDM 7000i device is a multipurpose scanner that reads Magnetic ID‟s, credit cards and
cheques. The team modified the logic of reading ID‟s and credit cards in the RDM 7000i device
to remove the logical error that existed previously.
2.1.6 Adding a Tab to link to Authorize.Net
The team added a single tab to link to Authorize.Net and another tab to link to Public data.com.
This allows the user to verify the transactions performed by him with Authorize.Net.
2.1.7 Integration of the Vivo Tech reader into our application
The team met with Steve Lucord, leader of the team under Dr. Perez-Davila, and discussed the
details of the integration of the Vivotech reader into the application. Steve had documented the
changes to the code and handed a hard copy of the same. The device is manufactured to read just
two tracks out of the three tracks of data. So when we choose to swipe a magnetic ID, not all the
data is displayed on the screen as the data from the third track is missing. Also when the
magnetic option is selected, and a credit card is swiped, the data is parsed and displayed on the
screen which indicates the existence of a logical error. The team has integrated this module
developed by Steve into the MiniCheckID Pro+ application.
University of Houston Clear Lake-Fall 08 -7-
iniCheckID Pro+
2.2 Project Scope
The team has made use of the C#/.NET Framework in building this application. The team has
integrated a module for E-verify which accepts input such as social security numbers and other
details and verifies an employee‟s eligibility to work in the United States. The team has also
merged multiple databases to one so that the data is available for use in a cleaner format. The
module for the RDM 7000i device is fine tuned to remove any logical or functional errors. The
application is cleaned to reduce redundancy and improve consistency. The application ensures
Windows Vista compatibility and is backward compatible. The application also ensures smooth
functioning of the module for the Vivotech reader integrated into our application, built by
another team (Steve).
3. Project Design and Implementation
3.1 Assumptions and Dependencies
The application depends on the government‟s E-Verify information database through
Homeland Security for verifying an employee‟s right to work in the United States. The
working of E-verify requires W3C 3.0 to be installed.
The application requires all the device drivers to be installed.
The application requires Atalasoft to be installed for reading barcodes and parsing them
to raw data.
The set password function for E-verify has been implemented but the webservice method
call has been commented in the Set_Password.cs file. This is done as the application in
running on a test environment. Once the application is certified by the department of
Homeland Security, the comments in the above file can be removed.
University of Houston Clear Lake-Fall 08 -8-
iniCheckID Pro+
3.2 Implementation Details
3.2.1 E-Verify Integration
Working and Implementation:
E-Verify is the new functionality included under the “Advanced” section of the application
MiniCheckID Pro+. E-verify is an internet based system operated by Department of Homeland
Security (DHS) in partnership with Social Security Administration that helps verify legal work
status of newly hired employees in United States. The application uses Web Services provided
by DHS for implementing E-Verify.
E-Verify of MiniCheckID Pro+ have two categories of users, viz. Designated Agent and
Employer. Designated Agent manages and serves several clients (employing companies).
Designated Agent can verify the legal work status of clients newly hired employee. Employer
represents any employment providing company in United States. Employers can verify the legal
work status of their newly hired employee.
The user can login and verify the legal work status of the newly hired employee. The user has to
be registered with DHS for using the application. The user needs to enter the credentials
provided by the DHS for logging to E-Verify in the MiniCheckID Pro+ application. The
application uses Simple Object Access Protocol (SOAP) envelope for transmission of credentials
at DHS for verification. DHS sends back the response to the application in SOAP envelope.
Once the credentials are verified the user can then use the following functionalities.
University of Houston Clear Lake-Fall 08 -9-
iniCheckID Pro+
Fig 1: Use Case of E-verify
Initial Verification
Initial Verification allows employers and designated agents to verify the legal work status of
their newly hired employees. The user can enter the employee‟s necessary information as on
Form-I9 and request for the verification of the employee‟s legal work status. The following can
be the response to the verification request.
1. Employment Authorized: This response indicates that employment eligibility is verified
and the case can be resolved.
University of Houston Clear Lake-Fall 08 - 10 -
iniCheckID Pro+
2. SSA Tentative Nonconfirmation: This response indicates that the information furnished
could not be verified. The employee must be notified of the Tentative Nonconfirmation
response and referred to the SSA if he or she contests. This does not mean that the
employee is not work-authorized and the employee may contest without being dismissed
or suspended.
3. DHS Verification in Process: This response indicates that a DHS Immigration Status
Verifier (ISV) is checking additional DHS data sources to confirm the employment
eligibility of the non-citizen. DHS responds to most of these cases within 24 hours, but
has up to three federal government workdays to respond. You should check the system
daily for a response.
View Case Status
View Case Status allows the user to view updates on the eligibility status of pending case of an
employee. The user can just enter the case number and have an update on the employee‟s present
legal work status.
Change Password
Change Password allows the user to change their password. E-Verify require the users to change
their password every three months. The password automatically expires after three months. The
application reminds the user to change the password each time the user logs in during the last ten
days before the expiration of the password. E-Verify also have the restriction on the password‟s
minimum lifespan to be 5 days. The application also implements the corresponding criteria.
University of Houston Clear Lake-Fall 08 - 11 -
iniCheckID Pro+
3.5.2 Database Merging and Code Cleaning
Database Merging:
The team merged the multiple databases in MS Access to a single database,
MiniCheckIDPro.mdb. The team duplicated the tables in the previous databases and stored it in
the new database.
Data/Code Cleaning:
The following steps were taken to remove the redundancy of the code
Step 1:
Our team observed that there are several files which had several functions which needed
database connectivity. In all these functions, the code for database connection was repeatedly
written thus creating a huge amount of redundancy. Thus in order to make every function less
complex and also reduce the number of lines in each file, the team decided to put all the database
accessing controls in one class file and allow users to access this particular class file when they need to
access database. This results in simpler code, thus reducing the complexity of the entire application.
Step2:
The team also observed that the queries to access the database were written in a manner which allowed
external users to write queries, thereby allowing changes in the database. Even a small change in those
queries would cause inconsistencies in overall working of the application. The team decided to protect
them by storing them in the database itself and later accessing them with their names thus tried achieving
a “stored procedure” kind of a feature observed in SQL databases.
University of Houston Clear Lake-Fall 08 - 12 -
iniCheckID Pro+
3.2.3 Windows Vista Compatibility
One of the crucial requirements early on in the semester was to make MiniCheckID ProTM
Windows Vista compatible. Previous teams had worked on the Windows XP environment. But
the same application does not work in Windows Vista because the file permissions of windows
Vista are different from Windows XP. Windows Vista is strict in terms of file access which
makes Windows Vista is more secure.
Thus to achieve Windows Vista compatibility the team changed the I/O permissions for not only
the file that required the permissions but the entire application folder. The benefit was, if in the
future new files were added to the application they would inherit the same permissions, making
the entire application Windows Vista compatible.
3.5.4 RDM 7000i device
The RDM 7000i device is a multipurpose scanner that allows processing of cheques, validating
ID‟s and processing credit card transactions. The existing code for RDM had some errors. When
the team chose the credit card option and swiped an ID, the application displayed an error
message and told the user to choose the credit card option and swipe again.
When a user chose the magnetic card option and swiped a credit card, the application parsed the
data read by the device and displayed the sensitive credit card information on the screen. This
should have been avoided as user credit card information is sensitive information.
The solution was to separate the functionalities of the magnetic and the credit card transactions.
The team included a message box to display the error message and asked the user to choose the
appropriate option.
University of Houston Clear Lake-Fall 08 - 13 -
iniCheckID Pro+
3.5.5 Adding a Tab to link to Authorize.Net and Public data.com
The team made use of a browser button and a tab to link to Authorize.Net and Public Data.com
respectively so that user can check the transactions made with authorize.Net. Below attached are
snapshots of the same in appendix D.
3.5.6 Integration of the Vivotech reader into our application
The Vivotech Reader is used as a multipurpose scanner and can read RFID‟s and credit cards.
With the integration of this device to the application, users have the flexibility of using their
RFID‟s to process transactions. The user input would be to swipe their credit cards. The
application MiniCheckID Pro+ This module was developed by Mr. Steve Lucord.
3.3 Implementation Issues and Lessons Learned
3.3.1 E-verify Integration
Before getting started with E-verify, the mentor had to sign the memorandum of understanding
(MOU) in order to gain access to the resources. Since the process involved a lot of legal
issues, the process took a significant amount of time to achieve access to resources. The team
learned that certain project may take significant amount of time in achieving required resources
affecting the actual implementation time of the project. This may run the project behind the
estimated schedule.
3.3.2 Code Cleaning
As this application had been worked upon by several teams, the code was quite unstructured to
handle. Cleaning the code helped the application to be more reliable and increased the
readability of the program.While making changes to the existing code, it was important to
University of Houston Clear Lake-Fall 08 - 14 -
iniCheckID Pro+
check the existing built in functionality supported by the application from time to time. The
effort of Code cleaning helped us to make the database more secure, restrict other users to
make unwanted changes, achieve a production level code, resulting in a good product for the
end user.
3.3.3 Windows Vista Compatibility
To achieve Vista compatibility, the team changed the I/O permissions for the file.
XMLuserinfo.xml. A more appropriate solution was to make changes in such way that Vista
compatibility is ensured in the event of adding more files in future. The team learned that for
software projects, sometimes there may be a better solution even if the present implementation
suffices the requirement.
3.3.4 Integration of the Vivotech reader into the MiniCheckID Pro+
The team was able to get the module for the Vivotech reader in time from Steve Lucord. This
gave us enough time to work on the integration of this module and get it working with the
application. The testing of the integrated module helped to ensure that the existing
functionalities were unaffected and functioning smoothly. The team scheduled meetings with
the other team to get the module on time. The two teams spent time understanding each others
requirements to make a decision on who would take the responsibility of integrating the
module. The team discussed the details of changes to the code and working. The coordination
with other teams, collecting the module and its documentation in time was a very important
aspect for the success of the project.
University of Houston Clear Lake-Fall 08 - 15 -
iniCheckID Pro+
4. Testing
4.1 Integration Testing
The type of testing the team used in the project is Integration Testing. There were different
functionalities which had to be built into the already existing application. The team opted for this
method of testing because while adding additional functionalities the team had to regularly check
the existing functionality to ensure consistency and reliability. The team tested the application
with different scanners and checked for consistency in the entire application.
5. Conclusion
The application is an enhancement of the MiniCheckID Pro™ which enables an employer or a
designated agent to verify the employment eligibility of an employee to work in the United
States. The code is cleaned ensuring reduced redundancy and improved reliability making the
application perform better than before. The application also integrates another scanner called the
Vivo Tech reader, which enables the application to support more devices than before. The
project proved to be a very good learning experience for all the team members and taught us to
maintain the team spirit and coordination among the team members.
University of Houston Clear Lake-Fall 08 - 16 -
iniCheckID Pro+
6. References
[1] Department of Homeland Security. (n.d.). Retrieved from
http://www.dhs.gov/xprevprot/programs/gc_1185221678150.shtm
[2] Interface Control Document for Customer Processing System (CPS) Employer Web Service.
(2008, August 29). Department of Homeland Security.
[3] Lucord, S. Documntation for VivoTech Device.
[4] MagTek Inc. (n.d.). Retrieved from http://www.magtek.com/
[5] Mohammad, I. U., Satam, A., & Dubey, M. (Summer 2008). Retrieved from MiniCheck ID
Pro: http://dcm.uhcl.edu/c683808sugp2/index.htm
[6]Sutaria, M., Tran, K., & Mohammed, A. (Fall 2007). Retrieved from Capstone Team # 3:
http://dcm.uhcl.edu/cap683807fagp3/index.html
[7]Voodigi, N., Nagula, S., Bhomi, N., & Surabhi, V. (Spring 2008). Retrieved from MiniCheck
ID: http://dcm.uhcl.edu/cap08spgp2/index.html
University of Houston Clear Lake-Fall 08 - 17 -
iniCheckID Pro+
Appendix A: Implementation Details
E-verify Implementation
Working and Implementation:
E-verify is used to verify the employment eligibility of newly hired employees and is
implemented with the use of web services. DHS provides the web services to implement E-verify
in the application. Web service is a service provided by a third party like DHS and is used by
calling a Web method. Initial user verification and subsequence method invocation are different
for two types of users: companies (regular users) and designed agents (of multiple companies).
When a call to a web method is made from the application, the information on the form is sent in
a SOAP format. SOAP stands for simple object access protocol. In SOAP, XML is converted to
a stream and is sent to DHS where the response also comes in a stream format. The application
then reads the XML file to display the response to the user. The main goal is to check for work
elgibility of new employees. E-Verify provides three kinds of responses: approved,
SSA_Referral (not approved and employee needs to contact SSA) and DHS_Referral (not
approved and employee needs to contact DHS.)
The application MiniCheckID Pro+ includes E-Verification as a dropdown list under the
“Advanced” functionalities. E-Verification is further categorized based on the user as Designated
Agent and Employer. The user can choose one of the categories based on the user‟s
corresponding designation with DHS. The user is then moved to the Login window where the
user can enter his credentials provided by DHS for using Web Service. MiniCheckID Pro+ has
incorporated the Web Services used for employment verification.
University of Houston Clear Lake-Fall 08 - 18 -
iniCheckID Pro+
Login
Once the user enters the Login window, the user can access the services for E-Verification by
logging onto the E-Verify Web Services through the Username and Password provided during
registration at DHS (for Web Services). The Username is an eight-character login ID, whereas
the password can be anywhere between 8 and 14 characters. HTTP is used to make the Web
Service call secure.
MiniCheckID Pro+ encapsulates the credentials in a SOAP envelope as defined in the WS-
Security (Web Services Security) OASIS standard. SOAP envelope is the XML sent from
client to the Web Service Provider. SOAP envelope consists of a SOAP header and SOAP body.
SOAP header encapsulates the Username and Password. SOAP body holds the Web Service
Method name. EmpCPSVerifyConnection is the Web Service method used to verify the
credentials. A SOAP envelope structure is described in the following section.
username
password
nonce
date created
University of Houston Clear Lake-Fall 08 - 19 -
iniCheckID Pro+
MiniCheckID Pro+ serializes the XML and adds the SOAP extension before sending the
Web Service Method Request. The request is processed and the response is sent back in the
SOAP envelope with the Web Service method name EmpCPSVerifyConnectionResp. An XML
is de- serialized after receiving the response. If the request is successful, the application receives
the Return Status as 0 else an exception is raised. Once the user logs in proper credentials, the
user is allowed to verify the employment eligibility of any employee by providing the required
information. In case of an unsuccessful login attempt, the user is allowed to try again.
Initial Verification:
Once the credentials are verified, the application provides the user two option viz., View Cases
or Initial Verification. The user can select Initial verification to verify the employment
eligibility of a user. Based on the type of user, the initial verification form displays the
required fields. The user can fill up the required fields and complete the verification process.
Below attached are snapshots of the same in appendix D.
Designated Agent:
A Designated Agent would need to enter the employee‟s information as given in Form I-9. A
Designated Agent is required to enter the Client Company ID (the client company whose
employee verification is expected) along with the employee information. EmpInitDABPVerify is
a Web Service method used in the application for employee verification by Designated Agents.
The employee information provided in the Initial Verification form is passed as a parameter to
the method. EmpInitDABPVerifyResp is the response method which describes the employee‟s
work eligibility status. Below attached are snapshots of the same in appendix D.
University of Houston Clear Lake-Fall 08 - 20 -
iniCheckID Pro+
Employer:
An employer is only required to enter the employee‟s information as given in Form I-9.
EmpInitBPVerify is a Web Service method used in the application for employee verification by
Employers. The employee information provided in the Initial Verification form is passed as
parameter to the method. EmpInitBPVerifyResp is the response method which describes the
employee work eligibility status. Below attached are snapshots of the same in appendix D.
Figure 1 represents the sequence diagram for Initial Verification.
Employer Web Service
Employer Web Service
Client
EmpInitBPVerif()
EmpInitVerifResp
Client closes case only
if a "SUCCESSFUL" EmpCloseCase()
status is returned. And
case is not sent to EmpCloseCaseResp
secondary.
There are three kinds of responses that a user may receive when a verification request is
processed successfully. Employee Authorized, SSA Referral and DHS Referral is the three
types of responses.
Employee Authorized indicates that the employee is authorized to legally work in the United
States. The user can close the case when the response is Employee Authorized.
SSA Referral indicates that during the verification, there was a problem with the verification of
the employee‟s Social Security at SSA (Social Security Administration). In such case, the
University of Houston Clear Lake-Fall 08 - 21 -
iniCheckID Pro+
employee needs to contact and contest the SSA to resolve the problem. DHS maintains a record
of the corresponding cases if the employee decides to contest.
DHS Referral indicates that a Customer Processing System (CPS) may not be able to resolve
the request through automated checks of local database. In such case, the request is referred to
DHS Immigration Status Verifier (ISV) for special verification. ISV takes 1-3 days to research
and resolve the case. The user will have to periodically poll to pick up status on the case.
View Cases
When the response of Initial Verification is either SSA Referral or DHS Referral, the employee
case is not resolved and is maintained in a database. MiniCheckID Pro+ allows a user to view
any updates to the status of the case by entering the required information along with the Case
Number. The information is passed as a parameter to the Web Service Method.
Set User Password
The password provided for accessing the Web Services expires every three months.
MiniCheckID Pro+ allows the user to set a new password. SetUserPassword is the Web Service
method used by the application to change the existing password and set a new password. Below
attached are snapshots of the same in appendix D.
6.1.1 Windows Vista Compatibility
This application has been under development for the past three semesters. All the previous teams
that had worked on this project had used the Windows XP Operating system for development.
While the summer team had a chance to work on Windows Vista, they did not do so because
University of Houston Clear Lake-Fall 08 - 22 -
iniCheckID Pro+
Vista was new to the market, was still not mature and a lot of bugs were reported during that
time. But now Windows Vista has become mature and is being used on a large scale all over the
world.
Thus one of the crucial requirements early on was to make MiniCheckID ProTM Windows Vista
compatible. Early in the semester the mentor provided the team with the setup package and code
developed by the summer 2008 team. When the team installed the setup package on Windows
Vista and tried to run the application, a small window came up asking the team to enter the
username and password. After entering the credentials and hitting the login button, an error
message is displayed. A snapshot of the error message is shown as below. The application does
not go further and exits.
Fig c: Error display on executing the MiniCheckID Pro application on Windows Vista
The XML file mentioned in the snapshot is accessed when a user logs into the application. The
user login credentials are stored in the XMLUserInfo.xml file in the XML format which acts as
a session while the application is running. Whenever the user logs out, the user credentials are
deleted from the XML file and the session is destroyed.
Thus to achieve Vista compatibility, the I/O permissions for this file XMLUserInfo.xml was
changed, thus enabling the application to access the file and enter/delete user credentials.
University of Houston Clear Lake-Fall 08 - 23 -
iniCheckID Pro+
FileIOPermission f2 = new FileIOPermission(FileIOPermissionAccess.Read |
FileIOPermissionAccess.Write, Application.StartupPath + @"\XMLUserInfo.xml");
Note: This line of code is executed everywhere the XMLUserInfo.xml file is accessed.
After making the required changes in the code the team created a setup package and installed it
on a computer with the Windows Vista operating system. The application ran smoothly and the
compatibility with the windows vista operating system was achieved.
In midterm presentation, the team had discussed the details of resolving the Vista compatibility
issue. The Instructor pointed out that this was not the perfect solution. The instructor suggested
the team to research and find out how the entire application could be made Windows Vista
compatible without making changes to each of the files.
Instead of making changes to each of the files and setting their file permissions, the team
changed the file IO permissions for the entire folder containing all these files. Therefore all the
files of that folder inherit the same permissions, making the entire application Windows Vista
compatible.
The changes in code made are as follows:
FileIOPermission f2 = new FileIOPermission(FileIOPermissionAccess.Read |
FileIOPermissionAccess.Write, Application.StartupPath)
After creating a setup package and installing it, the application runs smothly and without any
errors.
University of Houston Clear Lake-Fall 08 - 24 -
iniCheckID Pro+
Database Merging and Code Cleaning
Database Merging:
There were three databases supported by the MiniCheckID Pro application, Users.mdb,
MiniCheckId.mdb and MiniCheckID Pro.mdb. Each database consisted of tables that were
used in the application to support the different functionalities. The team replicated the tables in
each of the databases and placed it into one, the MiniCheckIDPro.mdb. The team also rewrote
and executed some of the queries written in both the databases Users.mdb, MiniCheckID.mdb
into the MiniCheckIDPro.mdb.
Data/Code Cleaning:
We also changed the connection string from
ConnectionString =
"Provider=Microsoft.Jet.OLEDB.4.0;DataSource=|DataDirectory|\\minicheck.mdb";
and
ConnectionString =
"Provider=Microsoft.Jet.OLEDB.4.0;DataSource=|DataDirectory|\\Users.mdb";
to
ConnectionString =
"Provider=Microsoft.Jet.OLEDB.4.0;DataSource=|DataDirectory|\\MiniCheckIdPro.mdb";
University of Houston Clear Lake-Fall 08 - 25 -
iniCheckID Pro+
Data/Code Cleaning:
The following steps were taken to remove the redundancy of the code
Step 1:
Our team observed that files such as login.cs, setupproduct.cs, FormMiniCheck.cs,
FormMiniCheckLarger.cs, FormProducts.cs, FormDeleteUser.cs, FormImport.cs had several
functions which needed database connectivity. In all these functions, the code for database
connection was written thus creating a huge amount of redundancy. The following piece of code
was repeated in every function in all the files mentioned above:
string ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;DataSource=…”;
OleDbConnection conn = new OleDbConnection(ConnectionString);
conn.Open();
string strSQL;
strSQL = "QUERY TO BE EXECUTED";
OleDbCommand cmSQL = new OleDbCommand(strSQL, conn);
.
Reader execution
.
Conn.close();
Thus in order to make every function less complex and also reduce the number of lines in each
file, the team decided to put all the database accessing controls in one class file and allow users
to access this particular class file when needed.
If the query needed data reader, we would replace all the above lines with following code,
OleDbDataReader reader =(OleDbDataReader)Connection.ExecuteCommand("SELECT Pwd
University of Houston Clear Lake-Fall 08 - 26 -
iniCheckID Pro+
FROM Users WHERE Uname=@username”, 0); Where „pwd‟ is the column in „User‟ table
where passwords are stored after checking the „where‟ clause which verifies the username from
the „Uname‟ column in „User‟ table which stores the related username. Here a reader of type
OleDbDataReader is created. “Connection” is the class file where all the database accessing
controls are stored. 0 is the mode which indicates that this query needs the data reader execution.
Step2:
The team also observed that the queries to access the database were written in a manner which
allowed external users to write queries, thereby allowing changes in the database. Even a small
change in those queries would cause inconsistencies in overall working of the application. The
team decided to protect them by storing them in the database itself and later accessing them with
their names. Thus the above given query can be written as,
int i =(OleDbDataReader)Connection.ExecuteCommand( "Select_password", 0);
Here the query, (“Select Pwd FROM Users WHERE Uname=@username”, 0) is executed and
stored by the name "Select_password" in the database itself. Thus whenever we need to execute
this query we write it as above. Thus the query gets protected from unwanted changes and also
accounts for less number of lines in code.
3.5.6 Integration of the Vivo Tech reader into our application
Our team was given the responsibility of integrating the module for the Vivo Tech reader. Based
on the documentation provided by Steve, the team made changes to the application to have to
working.
University of Houston Clear Lake-Fall 08 - 27 -
iniCheckID Pro+
The following changes are made in each of the following files:
“Program.cs: Logic was added to this file to catch and display diagnostic information about
thread exceptions and any uncaught exceptions from the application. The code is from the
MSDN and is modified to be adapted to the MiniCheckID Pro+ application.
Login.cs: The logic was modified to display the normal front size for the MiniCheckID form
whenever the choice is not “Larger”. This was done to facilitate the debugging of the
configuration modifications. When changing the configuration, the font options may be a value
other than Larger and Normal during the transition. This change picks a reasonable default.
FormMiniCheck.cs: The code to initialize and disable the device was added. The registration
for the Data Event and the actual event processing for the Vivo tech device was added. The
credit card processing logic reuses the existing logic. For magnetic cards, the code from the
RDM device was copied. The timer1_Tick event callback was modified to stop calling the
method getDataStored option. This was causing exception to be thrown in Vivo tech processing
routines. The devices are enabled and on the return from the Configuration screen at
Form_MiniCheck_Load routine.
FormConfiguration.cs: The necessary modifications to pick up the Vivotech device were
added.
FormConfiguration.cs: The Vivo tech device image, checkbox selection and Com port list were
added.
Configuration.cs: The Vivo tech device was added to the scanners Boolean array. The COM
port was also added. The Vivo tech device selection was added by allowing the client to call a
University of Houston Clear Lake-Fall 08 - 28 -
iniCheckID Pro+
property set method for the port as opposed to adding another permutation to the multiple
constructor calls.”[3]
Appendix B: Database Design
Fig b: Database Design of MiniCheckID Pro+
University of Houston Clear Lake-Fall 08 - 29 -
iniCheckID Pro+
Appendix C: Project Timeline
Sep 2008 Oct 2008 Nov 2008 Dec 2008
ID Task Name Start Finish Duration
8/31 9/7 9/14 9/21 9/28 10/5 10/12 10/19 10/26 11/2 11/9 11/16 11/23 11/30 12/7
Team Role Assignment and
1 8/28/2008 9/2/2008 .8w
Analyzing Previous Team’s Work
Code understanding and
2 9/1/2008 10/10/2008 6w
information gathering
BT 90 information gathering and
3 9/1/2008 10/3/2008 5w
research
4 Database Refinement (Merging) 9/22/2008 10/3/2008 2w
E-Verify Information Gathering and
5 9/22/2008 10/31/2008 6w
Research
6 E-Verify Implementation 11/3/2008 12/2/2008 4.4w
7 Code Cleaning 10/13/2008 11/28/2008 7w
8 Windows Vista Compatibility 9/22/2008 10/17/2008 4w
Links (Authorized .Net & Public
9 9/29/2008 10/3/2008 1w
Data)
10 RDM Issue 9/22/2008 10/3/2008 2w
11 Vivo-Tech Integration 11/17/2008 11/28/2008 2w
12 Website Development 8/29/2008 9/5/2008 1.2w
13 Website Maintainance 9/5/2008 12/3/2008 12.8w
14 Mid-term Presentation 10/6/2008 10/9/2008 .8w
15 Technical Paper 10/20/2008 11/26/2008 5.6w
University of Houston Clear Lake-Fall 08 - 30 -
iniCheckID Pro+
Appendix D: Final Deliverable
The final deliverable is an .exe file, a readme file, W3C 3.0 along with the device drivers that are
needed to support the application. The project source code and technical report is submitted
along with the application package as a deliverable.
University of Houston Clear Lake-Fall 08 - 31 -
iniCheckID Pro+
Appendix E: Team Roles and Contribution
Team URL: http://dcm.uhcl.edu/capf08g1/
Name: Akshay Balasubramanian (Team Leader)
Email: balasubramaniana4257@uhcl.edu
Phone No: 832-528-8454
Role: Programmer/User Interface/Documentation
Name: Ashutosh Raval
Email: ravala4172@uhcl.edu
Phone No: 832-531-0327
Major: Computer Science
Role: Programmer/Database
Administrator/Documentation
Name: Siddharth Agashe
Email: agashes4312@uhcl.edu
Phone No: 281-935-3863
Major: Computer Science
Role: Programmer/ Testing/Database Administrator
Name: Vaibhav Karvir
Email: karvirv4194@uhcl.edu
Phone No: 713-371-2150
Major: Computer Science
Role: Programmer/
Webmaster/Researcher
University of Houston Clear Lake-Fall 08 - 32 -
iniCheckID Pro+
Team Contribution
Akshay Ashutosh Siddharth Vaibhav
Research 23% 25% 25% 27%
Documentation 32% 32% 18% 18%
User Interface 27% 27% 23% 23%
Coding
1) Windows Vista 20% 10% 10% 60%
2) E-verify 10% 60% 10% 20%
3) Code Cleaning 10% 20% 60% 10%
4) RDM 7000i 35% 15% 15% 35%
5) Vivotech Integration 60% 10% 20% 10%
6) Modifying GUI and 15% 35% 35% 15%
database merging
Team Website 21% 18% 28% 33%
DB Administration 23% 26% 28% 23%
Testing 24% 22% 28% 26%
Table 1: Contribution in percentage
University of Houston Clear Lake-Fall 08 - 33 -
iniCheckID Pro+
Appendix F: Screen Shots
Fig 1: Minicheck ID Pro changed to Minicheck ID Pro+
University of Houston Clear Lake-Fall 08 - 34 -
iniCheckID Pro+
Fig 2: Scanners supported by MiniCheckID Pro+
University of Houston Clear Lake-Fall 08 - 35 -
iniCheckID Pro+
Fig 3: E-Verification tab added under „advanced‟ drop down list. There are two sub-tabs
added under E-Verification i.e. Designated Agent and Employer.
University of Houston Clear Lake-Fall 08 - 36 -
iniCheckID Pro+
Fig 4: Login window for designated agent and employer
Fig 5: Login page showing that Username or Password is incorrect
University of Houston Clear Lake-Fall 08 - 37 -
iniCheckID Pro+
Fig 6: If user name already exists in database and if number of days left for changing
password is less than 10 days, it would display a message box displaying above message.
University of Houston Clear Lake-Fall 08 - 38 -
iniCheckID Pro+
Fig 7: Initial Verification Form
University of Houston Clear Lake-Fall 08 - 39 -
iniCheckID Pro+
Fig 8: View case status
University of Houston Clear Lake-Fall 08 - 40 -
iniCheckID Pro+
Fig 9: A public data tab under „Advanced‟ drop down list. After clicking on this tab, a
browser window would come up displaying publicdata.com site.
University of Houston Clear Lake-Fall 08 - 41 -
iniCheckID Pro+
Fig 10: Clicking on Authorize.Net button, a browser window would open displaying
authorize.Net official web-site.
University of Houston Clear Lake-Fall 08 - 42 -
iniCheckID Pro+
Appendix G: Acronyms and Abbreviations
1. DHS – Department of Homeland Security
2. SSA – Social Security Administration
3. E-Verify – Employee Verification
4. HTTP – Hyper Text Transfer Protocol
5. SOAP – Simple Object Access Protocol
6. XML – Extensible Markup Language
7. ISV – Immigration Status Verifier
8. CPS – Customer Processing System
9. W3C – World Wide Web Consortium
University of Houston Clear Lake-Fall 08 - 43 -