detail system design - ded - dhs: illinois department · web viewthe ccms presentation layer...

Detail System Design - DED

5 SOLUTION ARCHITECTURE

5.1 SOLUTION COMPONENTS

The CCMS will be predominantly developed using Adobe LiveCycle ES2 and supporting Adobe technology such as Adobe Flex, Flash, and Adobe connector to IBM Content Manager repository. The solution also involves the integration of additional Commercial Off the Shelf (COTS) software such as Kofax and RightFax for managing document capture and processing via scan and fax, IBM Content Manager repository to store scanned images and other CCMS documents, as well as Crystal Report for producing Federal, State, management and ad hoc reports. Furthermore, technology and tools already in use at DHS will be leveraged by the CCMS solution. These technologies include DB2 database, IBM WebSphere application server, J2EE-based Fast4J for Java-based development and IBM Rational tools for managing the software development life cycle. The CCMS architecture builds upon the fundamentals of a robust, service-oriented, n-Tier solution, with the explicit separation of presentation content, business logic, and data objects. The remainder of this section describes the various layers of the CCMS n-tier architecture and presents design patterns for dynamic interaction amongst components in these layers that collaboratively solve CCMS business problems. Specifically, the remainder of this section is organized as follows:

1. CCMS n-tier architecturea) Overviewb) Client layerc) Presentation layerd) Business layere) Persistence layerf) Data layerg) Complete architecture

2. Protocols for system component interactions3. CCMS design patterns

CCMS n-tier architectureOverviewThe CCMS architecture provides a flexible model that logically separates the presentation, application processing and data management and allows for changes to be incorporated in specific sections of the architecture rather than the entire solution. This permits any of these tiers to be upgraded or replaced independently as requirements and technology changes. This architectural approach also improves system scalability and performance. The separate CCMS architectural layers are shown in the following diagram.

Solution Architecture Child Care Management Systemdocument.doc


Client

Presentation Layer

Business Layer

Persistence Layer

Data Layer

Figure 5-1. CCMS n-tier architecture

Client LayerThe client layer constitutes software components residing on user desktops. All users are expected to have a browser that is used to access the CCMS application. The browser runs Flash for executing Flex-based application software and a separate browser for viewing PDF documents. Scanning desktops will contain KOFAX Capture Client for processing scanned documents and VRS client for cleaning and optimizing scanned documents. Scanned documents are first passed through VRS before being sent to the Kofax Capture Client for further processing. Power users are expected to have Crystal Developer software for creating ad hoc reports. The diagram below depicts the client layer of the CCMS n-tier architecture.



Client

Browser (HTML)

Flex 3.5 (SWF) iFrame

View MXML

Domain Model

Presentation Model Commands/Controller

Workspace Components

Delegates

KOFAX Capture Client

PDFVRS Client

Crystal for Ad Hoc Reporting

*

* Applies only to scanned documents. Depends on scanner decision. VRS client comes packaged with particular Fujitsu scanners.

Figure 5-2. Client Layer

Presentation LayerThe presentation layer communicates with other tiers and outputs results to the client/browser tier. The CCMS presentation layer consists of Adobe Flex-based SWF file embedded within HTML wrappers and is depicted in the diagram below.

Presentation Layer

CCMS HTML Wrapper on embedded SWF

Figure 5-3. Presentation LayerBusiness LayerThis layer controls the application’s functionality by performing detailed processing. Functional algorithms that handle information exchange between the database and the user interface are embedded in this layer. This layer enforces the routes and methods by which business objects are accessed. Specifically, this layer constitutes the following components:

a) LiveCycle Data Service or Fast4J for Database Interactions– Facilitates data management and enables development of CCMS as a Rich Internet Applications (RIA) using Adobe Flex by connecting to required data sources.

b) LiveCycle ES2 – Provides an integrated set of technologies to engage CCMS users through RIA user interface, forms, and streamlined business processes.

c) LiveCycle IBM Content Manager Connector – Facilitates interactions with CMS IBM Content Manager Repository.



d) Fast4J – This component also provides a simple Java-based framework to accelerate development of custom CCMS components such as batch programs and interfaces.

e) Kofax Capture Server – Manages collection of documents and forms via a scanning process and makes them available to Adobe LiveCycle ES2 for processing and storage in the IBM Content Manager repository.

f) Crystal Server – Facilitates delivery of CCMS reports through Info View.g) Watched Folders – Provides a conduit for Adobe LiveCycle, where required by the

design.h) RightFax Server – Provides a channel for capturing faxed documents that are

delivered to Kofax using the Kofax-RightFax connector.i) Email Server – Provides CCMS with an SMTP channel for email communications.j) Batch programs – Enables execution of CCMS programs that are scheduled at pre-

determined frequency to execute rules-based data manipulation.



The diagram below depicts the business layer of the CCMS solution architecture.

Business Layer

CCMS Integrated/LiveCycle Data Service

Service Remote Object

Fast4J Assembler

Fast4J Common Business Objects

LiveCycle ES2

Invocation Layer

Forms

Reader Extensions

Digital Signatures Output

KOFAX Capture

Crystal Server

Process Management

LiveCycle Content Manager Connector User Manager

Watched Folders

RightFaxServer

Email Server

Batch

Figure 5-4. Business Layer

Persistence LayerThis layer manages database persistence operations such as Create, Read, Update and Delete (CRUD) actions. This layer abstracts out most of the complexities involved in Java database programming using JDBC, letting the CCMS developer focus on the business logic. Fast4J provides a Java framework for CCMS to accelerate custom development of components such as interfaces and batch programs. Fast4J reduces the time required to start the development process by providing pre-built Java application development components to development team activities during the construction phase. Fast4J is available free of cost and is not licensed or proprietary. All source code and supporting documentation will be provided to DHS upon project completion. For all intents and purposes, Fast4J will be treated by CCMS as one of the custom-developed code components that will be handed over to DHS for maintenance.

Persistence Layer

Fast4J Data Access Objects

Figure 5-5. Persistence Layer



Data LayerThis layer consists of database servers, storage repositories and Active Directory instances that support CCMS. This tier keeps the data independent from the business logic and the presentation of the data to the user. DHS made the decision of requiring the co-location of CCMS tables along with CCTS tables that MIS plans to modify from IMS to DB2. Both these table sets will reside in the same DB2 repository.

Figure 5-6. Data Layer



Complete CCMS architectureThe complete n-tier CCMS architecture is presented in the diagram below for ease of reference.

Client

Browser (HTML)

Flex 3.5 (SWF) iFrame

View MXML

Domain Model

Presentation Model Commands/Controller

Workspace Components

Delegates

KOFAX Capture Client

PDFVRS Client

Crystal for Ad Hoc Reporting

Presentation Layer

CCMS HTML Wrapper on embedded SWF

Business Layer

CCMS Integrated/LiveCycle Data Service

Service Remote Object

Fast4J Assembler

Fast4J Common Business Objects

LiveCycle ES2

Invocation Layer

Forms

Reader Extensions

Digital Signatures Output

KOFAX Capture

Crystal Server

Process Management

LiveCycle Content Manager Connector User Manager

Watched Folders

RightFaxServer

Email Server

Batch

Persistence Layer

Fast4J Data Access Objects

Figure 5-7. Complete CCMS Architecture

Protocols for CCMS system component interactions



Protocols define message formats and rules for interaction between system components as they collaborate to perform business functions. The protocols employed by CCMS system components are depicted in the chart below.

Communicating Parties ProtocolClient and Presentation Layer HTTP/HTTPS

Presentation Layer and LiveCycle ES2 Action Message Format (AMF)

Client to Business Service via Presentation Layer

Simple Object Access Protocol (SOAP) over HTTP/HTTPS

LiveCycle ES2 to Business Services SOAP over HTTP/HTTPS

KOFAX/RightFax/LiveCycle ES2 to IBM Content Manager

IBM Content Manager Connector*

LiveCycle ES2 and Email Server Simple Mail Transfer Protocol (SMTP)

LiveCycle ES2 and CCMS Database via Persistence Layer

Java Database Connectivity (JDBC)

Business Service Layer and Active Directory

Lightweight Directory Access Protocol (LDAP)

* Not a protocol, but acts as an intermediary.

Figure 5-8. CCMS System Component Protocols



CCMS Design PatternsDesign patterns are software solutions and development standards to commonly occurring business problems in a software system. CCMS design patterns provide a template for how to solve a problem and can be used as reference for implementation of appropriate use cases. These design patterns are depicted as interactions among CCMS system components that have been previously described. Actual implementations may vary from design patterns to support specific features or to accommodate specific programming challenges, as necessary. The design patterns depicted in this section and the applicable CCMS use cases are identified in the table below.

Table 5-1. CCMS Design Patterns and Use Case Mapping

Design Pattern Applicable Scenarios

User views online listing All interactions between Flex-based CCMS application and the underlying database

User views form online All interactions where user retrieves a form for viewingUser updates and submits form All interactions where a form is filled in and submittedBatch processing – rules All scenarios where a scheduled batch process retrieves and

processes data from the CCMS databaseUser saves data through Flex User Interface

All insert and update interactions with the CCMS database via the Flex-based CCMS application

Opening Info View from Flex ReportsViewing a static report ReportsViewing a parameterized report ReportsViewing a drill down report ReportsUser views blank form All interactions where user creates a new blank form using the

Flex-based CCMS applicationOn Blur processing (processing as soon as user hits the TAB key to get out of a field)

All Flex or PDF-based interactions where a field is validated when the user tabs out of the field

Mass Mailing Batch process for creating mass mailing print strings which are sent to the printing subsystem for further processing

City of Chicago batch upload Pattern for uploading City of Chicago data into a CCMS data store

City of Chicago search Using XQuery to search City of Chicago XML data and produce search results. Optionally, the City of Chicago XML data will be indexed in a relational database (i.e., primary data elements will be captured in a table and the XML will be stored as part of that row of data). This will allow for SQL searches and XQuery will not be needed.

Finalist interface Using a batch based approach to validate CCMS addresses

Each of the design patterns is illustrated in the subsections that follow.



User views online listingThe following design pattern describes how a user views an online listing on the CCMS Flex-based user interface. Examples of online listings include any database inquiries such as CCMS case search. In this pattern, the browser runs an embedded Flash player that hosts the Flex application. The Flex application invokes a Java-based transaction through either a Java Service or a Web Service implementation. Fast4J is leveraged to implement the Java-based database services. Based on user inquiry, data is retrieved from the CCMS database and passed to Flex in a format that can be appropriately displayed to the user in a Flex control like a Data Grid.

Browser Flex User Interface

CCMS DB2 Database

1) User Selects List View

2) Flex UI invokes Fast4J business object layer

3) The business object calls the appropriate Fast4J Data Access Object

4) Fast4J uses JDBC to fetch the customer listing data record set from the DB2 database

5) The data is returned as XML or other appropriate format

6) Data is filled into the bound object

Process Steps

Java Methode.g. getData()

JDBC call

Data

Client Presentation Layer Business Layer Persistence Layer Data Layer

Fast4J Data Access Object

Record Set

Fast4J Business Object

Figure 5-9. Design Pattern – User views online listing



User views Form OnlineThe CCMS software allows users to generate several kinds of forms. Many of these forms are pre-populated with CCMS data. The following design pattern describes the process by which a user views a form online. Whereas, the depiction is one where data is pulled from the CCMS database and displayed as part of a fillable PDF form, this kind of interaction could also be one where the Flex user interface retrieves an image from the IBM Content Manager. When the retrieved image is in TIFF format, the image is viewable in any freely downloadable Tiff Viewer applications or the TIFF viewer that comes packaged with the Windows operating system.In the pattern shown below, the Flex user interface invokes LiveCycle Form Generator (not PDFg or PDF generator – LiveCycle Form Generator is part of standard LiveCycle ES2) which in turn invokes Java-based services to fetch data, pre-populate a form template and send it to the user interface for display. The resultant PDF is opened in a separate browser window.

BrowserFlex User Interface

Fast4J BusinessObject

CCMS DB2 Database

LiveCycle Form Generator

1) User Requests Form

2) Flex UI invokes LiveCycle Form Generator

3) LC Form Generator invokes appropriate Fast4J Data Access Object

4) Fast4J uses JDBC to fetch the data required for the Form from the DB2 database

5) The data is returned in the form of XML or other appropriate format

6) Fast4J returns the data to LiveCycle Form Generator which generates the Form

7) The Form is displayed on the Flex UI

Process Steps

Invoke

e.g., getData()

JDBC call

XML

PDF Generation

PDF

Client Presentation Layer Business Layer Data Layer

PDF


Persistence Layer

Record SetXML or other format

Figure 5-10. Design Pattern – User views form online



User Updates and Submits FormThe following design pattern describes how a user who viewing a form is able to update and submit the form for further processing from within the CCMS Flex-based user interface. In this case Fast4J business layer is leveraged in the form of web services, where appropriate, to channelize the user’s update request to the specific set of CCMS database tables. Once an update is committed to the database, a return code is sent back.

Browser Acrobat/ReaderInterface


CCMS DB2 Database

1) User completes form

2) Presses submit button

3) From runs pre-submit validations on form

4) Post PDF or XML to processing endpoint

5) Form document /XML received and data extracted (PDF only)

6) Reformat input data if needed via XSLT

7) Appropriate data access objects are invoked

8) Fast4J uses JDBC to insert/ update the data from the Form to the DB2 database

9) Response code received

Process Steps

JDBC call

Response


Java API call

XML


XSLT

XML

Figure 5-11. Design Pattern - User updates and submits form



Rule-based Batch ProcessingThe CCMS software requires batch based processing in several areas. For example, a batch process evaluates CCMS data to verify if an application approval or denial action due date is approaching and generates a reminder for the user. The following design pattern depicts the process of using a scheduler to initiate a batch program that manipulates CCMS data.


CCMS DB2 DatabaseJava Program

1) System scheduler kicks off a Java-based batch program

2) Java program accesses CCMS tables through the Fast4J Business Objects and Data Access Object layers

3) Java program processes record sets and applies rules to formulate transactions that need to be written to CCMS tables

4) Java program writes transactions to the CCMS tables

Process Steps

JDBC call

Record Set

Business Layer Persistence Layer Data Layer

Fast4J Business Objects

Business Layer

Scheduler

Operating System

Initiate

Process records

JDBC call

Figure 5-12. Design Pattern - Batch Processing – Rules



User saves data through Flex user interfaceFilling out application data within the CCMS application is an example of a scenario where the user inputs and saves data to the CCMS database using the Flex-based application. The following design pattern depicts the process of sending data to interface tables using a batch program.


CCMS DB2 Database

1) User inputs data into Flex screens and hits the save button

2) Flex UI invokes Fast4J business object layer

3) The business object calls the appropriate Fast4J Data Access Object

4) Fast4J uses JDBC to insert/update the customer listing data record set from the DB2 database

Process Steps

Java Methode.g. editData()

JDBC call




Data changes committed

Figure 5-13. Design Pattern – User saves data through Flex UI



Viewing a static report using InfoViewAll CCMS reports are viewable using InfoView which offers a browser-based user interface for navigating reports. The following swim lane diagram describes the process of opening Crystal Info View from CCMS Flex-based user interface to view reports.

Info View Business ObjectsServer

1) User Logs on to Infoview and schedules a report by entering database credentials

2) Bo server calls database sever with a sql

3) Bo server fetches the required data from the DB2 database

4) The data is returned in the prescribed Business Objects report format

Process Steps

SQL Query

Query Result

Client

CCMS DB2 Database

Business Layer Data Layer

Calls BO server

Report in the required format

Formats the Report

Figure 5-14. Viewing a static report



Viewing a parameterized reportThe following design pattern shows the process of interacting with a parameterized Crystal Report where a user enters parameters for viewing a report that filters the viewed data based on specified parameters.


1) User Logs on to Infoview and schedules a report by entering database credentials and parameters



4) The data is returned in the prescribed format

Process Steps

SQL Query

Query Result

Client

CCMS DB2 Database


Calls BO server


Filters the data and format the report

Figure 5-15. Viewing a parameterized report



Viewing a drill down reportThe following design pattern depicts the interaction with a Crystal drill down report where the user will be able to drill down on specific data elements for more details.


1) User Logs on to Info View and schedules a report by entering database credentials and parameters



4) The data is returned in the prescribed format

5) User drills down

6) User can view the details

Process Steps

SQL Query

Query Result

Client

CCMS DB2 Database


Calls BO server


Filters the data and format the report

Calls BO server

Responds with drill down format

Figure 5-16. Viewing a drill-down report



User generates a blank formIn certain scenarios like generation of PIQA forms, the CCMS software allows users to create a form with no pre-populated data. This interaction involves communication between Flex and LiveCycle Form Generator (not PDFg) without a subsequent database interaction. The design pattern is depicted below.

Browser Flex User Interface LiveCycle Forms


2) Flex UI invokes LiveCycle Form Generator

3) LC Forms generates a PDF and the data is returned in PDF

4) The form is displayed in Flex UI

Process Steps

Invoke

LiveCycle Form Creation

PDF

Client Presentation Layer Business Layer

PDF

Figure 5-17. User generates a blank form

On Blur ProcessingThe following design pattern depicts the process by which the Flex user interface validates user entry when the person tabs out of a text box or moves away from a control. This interaction also applies for PDF forms based interactions.





2) User gets a blur Screen

Process Steps

Client Presentation Layer

Validates the data after tableaves

Display If entered incorrect data

Figure 5-18. Design Pattern - On Blur Processing

Mass MailingThe CCMS mass mailing process is described in detail in the Interfaces section. Mass Mailing involves execution of daily or monthly batch programs that evaluate CCMS data to determine if conditions are met for generation and mailing of a particular type of form. For example, a Rede is mailed out if the person’s eligibility is set to expire at the end of next month. The mass mailing batch picks up the output form’s variable content from the CCMS tables and creates print strings. These print strings are stored in a flat file for distribution to a print subsystem. The print subsystem is a DHS MIS software that interacts with Mobius, another DHS MIS software, to merge the data with Elixir form templates and send the output to the printer. The design pattern below depicts the CCMS mass mailing batch program preparing the print strings flat file. The processing by DHS MIS print subsystem and Mobius are not depicted.






2) Java program accesses transaction details from CCMS tables using Fast4J Business Object and DAO.

2) Fast4J picks additional data from CCMS tables

3) The data is returned to the Java program which prepares print strings and stores it in a flat file for processing by MIS print subsystem

Process Steps

JDBC call

Read data from Database into appropriatedata structure



Business Layer

Scheduler

Operating System

Initiate

Prepare and write print strings into flat file

Figure 5-19. Design Pattern – Mass Mailing

City of Chicago Data UploadThe City of Chicago interface is described in detail in the Interfaces section. The City plans to provide data for CCMS retrieval on a daily basis. This data is expected to be in XML format. A CCMS batch program would pick up the XML and store it in the CCMS database with little to no change to the structure or contact of the received XML. Storing the data in XML format facilitates future search and retrieval of records. Optionally, the City of Chicago XML data will be indexed in a relational database (i.e., primary data elements will be captured in a table and the XML will be stored as part of that row of data). This will allow for SQL searches and XQuery will not be needed.






2) Java program reads XML data from file system and passes it to Fast4J Business Object.

3) Fast4J Business Object leverages the data access object layer.

4) The XML is written to the appropriate CCMS database table

Process Steps

JDBC call



Business Layer

Scheduler

Operating System

Initiate

Insert data into CCMS database

XML data

File System

Figure 5-20. Design Pattern – Importing City of Chicago data



City of Chicago SearchOnce the City’s data is stored within the CCMS repository as XML data then XQuery technology can be leveraged to search the data based on user inquiry and provide appropriate search results.



CCMSDB2 Database

1) User enters a CCMS inquery

2) Flex invokes Java business layer which in turn leverages the data access layer

3) Java business layer uses Fast4J and JDBC to fetch the xml data

4) The XML data is searche3d using Xquery and the results are sent back to the Flex application

Process Steps

JDBC call to fetch XML data

Fetched Xml data


Java Business layer

Inquiry

Data search using Xquery

Figure 5-21. Design Pattern – Searching City of Chicago data

Finalist Batch InterfaceThe Interfaces section describes the CCMS-Finalist batch interface in detail. In general, CCMS interacts indirectly with Finalist. DHS MIS IMS batch program takes CCMS addresses that require Finalist validation as input in the form of a positional flat file, interacts with Finalist and produces a positional response file as output. This design patterns have been depicted below.






2) Java program accesses transaction details from CCMS tables using Fast4J Business Object and DAO.

2) Fast4J picks additional data from CCMS tables

3) The data is returned to the Java program which prepares a flat file for processing by DHS MIS IMS batch

Process Steps

JDBC call

Read address data From Database into appropriatedata structure



Business Layer

Scheduler

Operating System

Initiate

Prepare and write a positional flat file that serves as input to DHS MIS IMS batch program

Figure 5-22. Design Pattern – CCMS-Finalist Interaction via DHS MIS IMS batch program (part I)






2) Java program reads response file from the file system

3) Fast4J Business Object leverages the data access object layer to process the file

4) The Finalist result is written to the appropriate CCMS records

Process Steps

JDBC call



Business Layer

Scheduler

Operating System

Initiate

Insert data into CCMS database

Positional flat file

File System

Figure 5-23. Design Pattern – CCMS-Finalist Interaction via DHS MIS IMS batch program (part II)

5.2 SECURITY

The CCMS security architecture addresses security enforcement and administration for the following components of the system:

a) Flex-based CCMS application and underlying LiveCycle and Java interactionb) Crystal Reportc) Kofax Capture Workstationd) RightFax Servere) IBM Content Managerf) Electronic signatures

Flex-based CCMS application and underlying LiveCycle and Java interactionDHS currently has an enrollment process for both internal users (DHS staff) and Providers. The enrollment process provides access to specific DHS applications. This enrollment process will need to be expanded to include access to CCMS. .BCCD, R&R and Site Providers will each have different subsets of functionality available to them based on “need to know”. All of these participants will be in Active Directory. Providers and R&R employees will be expected to have AD profile and password. Solution Architecture Child Care Management System

document.doc


Internal users and external users are currently distinguished by the user id (“Illinois.gov” for internal users and “external.illinois.gov” for external users). CMS provides a separate Active Directory repository for internal users and external users. CCMS will utilize these separate repositories to authenticate and authorize application access based on the user’s id and password.Once authenticated and logged in, CCMS will control access to specific functionality within the application.The CCMS user would provide a user ID and password to attempt a login to the system. CCMS will use the DHS standard “reverse proxy” method based on Microsoft Internet Security and Acceleration (ISA) for authentication in HTTP BASIC mode. This means that the user will be provided a URL for the CCMS application (for example, domain.dhs.illinois.gov/ccms) and when the user accesses the application using the URL, CCMS will direct the user to DHS’ ISA for login. The login screen presented by ISA will not be specific to CCMS but will be a DHS-standard one that applies for all DHS applications using “reverse proxy” method. Once ISA authenticates the user and authorizes him/her to access CCMS, ISA will pass the pre-authenticated user’s login identifier to CCMS for further role-based access control enforcement. DHS password standards will be enforced by ISA. The “reverse proxy” method of authentication applies to both internal (e.g., DHS staff) and external CCMS users (e.g., providers). Any user that needs to reset password will have to call the CMS service desk. CMS service desk is built to handle the volume of password resets and related requests. The CCMS will not provide a password reset functionality. The “forgot password” functionality will be implemented by DHS as part of the ISA implementation. Application-level access control will be provided using user access control information stored within the CCMS DB2 database. The CCMS Admin tool will allow the ability to move users from one group to another. However, creation of new groups is a manual process that will be implemented by CMS and MIS. This is because groups have to be created in both Active Directory and in CCMS database. Moreover, MIS will develop the mechanism for synchronization of users between Active Directory and CCMS database. This mechanism will most likely be implemented by enhancing the functionality of MIS’ Worker Admin tool.

Crystal Report security enforcement and administrationCCMS reports will be accessed using Info View (a browser-based interaction separate from the application). DHS is working on providing a single logon between CCMS and InfoView using the Business Objects version provided for the CCMS project. If feasible, the Flex User Interface will pass user credentials to Info View so that a separate login will not be required. However, DHS confirmed that in case Flex does not have the functionality to pass credentials to Info View then a separate login within Info View will be acceptable. In the event that Flex passes user credentials to Info View, the user is assumed to be pre-authenticated since the pre-authenticated user was passed to the CCMS Flex-based application by DHS’ Microsoft ISA server. In the event that user credentials are not passed to Info View then DHS will configure Info View to “reverse proxy” to Microsoft ISA for identification and re-authentication against Active Directory. Once the identification and authentication process has been completed by ISA, the user id will be passed to Crystal Server. Crystal enforces role based access control within the Crystal Server by importing Active Directory LDAP entries. One group will be defined within DB2 to enable a user to access Info View through the CCMS Flex user interface. Additional groups for enabling access control of groups of reports will be defined and administered within Crystal Server. Kofax Capture Workstation and ServerSolution Architecture Child Care Management System

document.doc


Identification, authentication and authorization of individual DHS staff users on the Kofax Capture Workstation will be implemented by DHS through integration with their Active Directory installation. CMS will be responsible for installing and administering the Kofax Server that also uses Active Directory based authentication. The Kofax-RightFax connector will be configured and administered by CMS to use Active Directory, if applicable.RightFax Client and ServerRightFax software (both client and server) will be installed, configured and administered by CMS and will also use Active Directory based authentication. IBM Content ManagerCMS will provide a single user id and password access into the IBM Content Manager environment. This user id and password will be used by the Adobe LiveCycle IBM Content Manager connector to establish an authenticated connection. CMS will administer security of the IBM Content Manager using existing tools.Electronic signatures – Electronic signatures will be captured through signature pads provided by DHS.Parent interaction with application form over the Internet – Identification, authentication and authorization is not required for this interaction with an offline form.City of Chicago Interface – secure FTP will be utilized for transfer of City of Chicago data to a MIS file server.Batch Interfaces – These interfaces will rely on user id and password based authentication with the data source.Web links security – CCR&Rs, BCCD and Site Providers as well as Chicago participants who have RACF ID will be able to access. Once CCMS takes the participant to the website, the person is outside the CCMS security jurisdiction. This interaction will require a separate login. The attached spreadsheet contains default security roles that will be setup initially. Users with administrative rights will be able to associate different permissions with groups.

5.3 AUDIT

The CCMS system user identification and authentication is controlled and managed by DHS’ Microsoft ISA server. Security audit associated with ISA logon will be captured by Microsoft ISA server outside CCMS domain.Data level audit tracks will be captured by CCMS by using an audit_id on the record that has been updated. For example, when a record that requires audit tracks is updated then the CCMS will update the closed_timestamp and closed_audit_id for the old record and insert a new record with a posted_timestamp and posted_audit_id. This process will help ensure that every record has an audit trail.



Scanning staff user id will be captured and passed along as metadata associated with scanned documents. The scanning staff user id will be stored in association with the document and any data extracted from scanned documents for audit purposes. Audit log information for Cystal report access be captured and maintained within Crystal server.Kofax and RightFax environments are expected to be linked to the CMS Active Directory environment and will use built-in features for audit purposes.Since the CMS IBM Content Manager will be accessed by Adobe LiveCycle IBM Content Manager Connector using a single user id and password, an audit log of who accessed a document and at what time and date will be stored in the CCMS DB2 database.

5.4 STATE OF ILLINOIS INFORMATION TECHNOLOGY STANDARDS COMPLIANCE

DHS MIS and Deloitte reviewed CCMS system components for conformance to State technical standards applicable to the system. The review established that the components are compliant and that there are no deviations. Additionally, during the review it was confirmed that the State does not consider open source components being used in the system to be deviations. The following table provides a list of software components and confirms their compliance to State technical standards.

Table 5-1. CCMS Software is compliant with Illinois Standards

Name/Version

Ope

n So

urce

New

So

ftw

are

Exis

ting

So

ftw

are

Conf

orm

s to

St

ate

Tech

nica

Not

a

Mat

eria

l D

evia

tio

n

Server Software

IBM HTTP Server 7

Based on Apache HTTP Server

IBM DB2 9.7

IBM WebSphere Application Server V6.1

SAP Business Objects Crystal Reports XI Server 3.1

Microsoft Windows Server 2008

Microsoft Windows Server 2008 Active Directory

Adobe LiveCycle ES2 (incl. Output)




Name/Version

Ope

n So

urce

New

So

ftw

are

Exis

ting

So

ftw

are

Conf

orm

s to

St

ate

Tech

nica

Not

a

Mat

eria

l D

evia

tio

n

Adobe LiveCycle Data Services ES2

Adobe LiveCycle ES IBM Content Manager Connector

IBM Content Manager Enterprise Edition Version 8.4

Kofax Capture 9.0, Service Pack 1 incl. II4C and DB2 Client

Kofax Rightfax Adapter V2

Right Fax Server 9.4

JDK 1.5

V 1.5 needed for WebSphere Compatibility in CMS environment

Fast4J

JDBC 4.0

Software Development Tools

IBM Rational Application Developer 6.0.1

IBM Rational ClearCase 7.0.1.0

Adobe LiveCycle Workbench ES 2

IBM Rational ClearQuest 7.0.1.0

Microsoft Internet Explorer 6.0 or higher

SAP BusinessObjects Crystal Reports XI Development Suite, including InfoView




Name/Version

Ope

n So

urce

New

So

ftw

are

Exis

ting

So

ftw

are

Conf

orm

s to

St

ate

Tech

nica

Not

a

Mat

eria

l D

evia

tio

n

Adobe Flash Builder 4

Adobe FlexUnit 4

Gorilla Logic FlexMonkey 4.1.2 – Flex UI testing tool

Adobe Acrobat 9.3.2 and Reader 9.3.2 or higher

Adobe Flash Player 10.1 (latest version) or higher

Adobe Flash Player 10.1 (debug version) or higher

CA ERWIN Data Modeler r7.3

JUnit 4.5

Apache ANT 1.8.1

Rational Performance Tester to support 1500 virtual users

Log4J

VMWare Player 3.1.3

Altova xmlspy 2011 Standard Edition

JAWS 12 (or State standard) for Windows Screen Reading

Fiddler Web Debugger

SQL Squirrel

Apache Log4J

Spring

Apache Struts




Name/Version

Ope

n So

urce

New

So

ftw

are

Exis

ting

So

ftw

are

Conf

orm

s to

St

ate

Tech

nica

Not

a

Mat

eria

l D

evia

tio

n

Hudson – Continuous integration software

Project Management

Microsoft Office 2007 – Word, Excel, PowerPoint

Microsoft Visio 2007

Microsoft Project 2007

Training Development

Adobe Captivate 5

Adobe RoboHelp 8

Dragon Naturally Speaking

5.5 IMPACT ON EXISTING APPLICATIONS

The CCMS system is a collection of various software components:1) CCMS online application2) Batch programs3) CCMS database4) Reports5) Document scan, fax, email components6) External interfaces like City of Chicago and Finalist7) Mass mailing process

As a result, implementing the CCMS system is expected to have an impact on various components of the existing legacy application environment. Entire systems or specific functionality may be retired. Legacy reports may no longer be used. Existing programs may have been modified and therefore used differently. Specifically, the impact of implementing CCMS is provided below.The following functionality, if already in CCTS, will need to be retired since the functionality will be provided by CCMS.Functionality in CCMS – retired from CCTS, if presentSolution Architecture Child Care Management System

document.doc


Task/Workflow ManagementDocument ManagementAdministration - Setting CCMS Site/R&R security - CCMS message broadcastCustomer Service - Overpayments - Service Requests - AppealsPIQA - Overpayments - Field reviewCase and Client Management - Child Care applications and rede - Case/Client setup - Data collection - Case review/evaluation - Co-pay calculationProvider Enrollment - Provider section of child care application - Provider approval tracking (W9, background check, etc.)

All other functionality is expected to remain in CCTS as a result of implementing CCMS as envisioned and articulated in this document.Since the CCMS database is expected to be shared data source for CCMS and CCTS, it is expected that legacy CCTS IMS transactions and programs will be retired as a result of DHS MIS converting those transactions and programs to use CCMS as the data source. As a result of such conversion, any interfaces in and out of CCTS would be retired and replaced by interfaces modified by DHS MIS to use CCMS as the data source.Existing Elixir form templates will be updated and new Elixir form templates will be developed by DHS MIS to support the CCMS Mass Mailing process. Additionally, existing print subsystem and Mobius processes will be enhanced to support the CCMS Mass Mailing process.DHS MIS’ existing Finalist batch programs will be enhanced to support CCMS batch-based Finalist checks.The child care application and Rede forms as used in CCTS will be retired and the user will be transitioned to use the functionality within CCMS. All other CCMS forms that are currently used by CCTS in some form and reside as downloadable PDFs, Excel spreadsheets, and Word documents will be retired and the user will be switched to using those forms from within CCMS.Solution Architecture Child Care Management System

document.doc


DHS MIS CDB programs will be enhanced to provide CDB data within the CCMS database for search and retrieval purpose.The following legacy reports are expected to be retired as well:

Report # Title Staff or Admin Report

SBPLM381 Active Cases by Income and Family Size Admin

SBPLM382 Active Cases by Income and Family Size Admin5029C901 Child Care Application Listing Staff5029E21-01 Providers With No CANTS Staff5029E361 Multiple Providers With Same Address StaffSBPLM1A1 Clients Who Are Also ProvidersSBPLM271 Active Clients Turning 20 StaffSBPLM281 Active Cases With Multiple Children With Same Date Of

BirthStaff

SBPLM291 Active Cases With 5 Or More Active Children StaffSBPLM621 Providers Who Need CANTS Recheck Staff2BPLM751 TANF Teen Parent Child Care Cases Staff2BPLM752 Non-TANF Teen Parent Child Care Cases Staff2BPLM791 Head of Household Multiple Case Report Staff2BPLM831 RPY Cases Staff2BPLM841 Non-TANF Cases Age 20 or Older With Reason 2 Staff2BPLM861 Client on Multiple Case Report by Case Name and Date of

BirthStaff

2BPLMC41 Providers That Did Not Clear CANTS StaffSBPLMK23** Clients with SSN Not Matching Name/DOB StaffSBPLMN51 Cases Sent Cancellation For Child Age 13 StaffSBPLM411 Case Transfer Report Staff2BPLM871 List of Licensed-Exempt Providers Overcapacity Staff2BPLM881 Report for Licensed Center Staff2BPLM882 Report for Licensed-Exempt Centers Staff2BPLM883 Listing of licensed home providers active at the time prior

to batch run.Staff



2BPLM884 Report for Licensed Group Homes Staff2BPLM201 Certificates with Zip Code Errors Staff2BPLM371 Addresses with Zip Code Errors Staff

2BPLM981 Redeterminations with Zip Code Errors StaffSBPLM721 List of Cases Sent Cancellation Forms For Eligibility

Ending. Should be replaced by CCMS Ad Hoc report listing cases by eligibility ending date and retired from CCTS.

Ad Hoc

5029C501 Active Child Care Case Listing. Should now be on CCMS ad hoc report to list cases by reason for child care and/or by county and totals. Should be retired from CCTS.

Ad Hoc

SBPLM261 Active Clients Who Are Also CCR&R Employees. Should now be included in CCMS ad hoc report to list cases if they have an employee flag. Should be retired from CCTS.

Ad Hoc

SBPLM991 Active Headstart Cases. Should now be included in CCMS ad hoc report to list cases if they have a collaboration indicator. Should be retired from CCTS.

Ad Hoc

SBPLMB11 Active Shared Cases. Should now be included in CCMS ad hoc report to list shared cases. Should be retired from CCTS.

Ad Hoc

2BPLMB91 List of Cases Sent Redetermination Forms. Should be replaced by CCMS Ad Hoc report listing cases by eligibility ending date and retired from CCTS.

Ad Hoc

SBPLMK21 Clients With System Assigned SSN. This report is no longer needed since we're eliminating system assigned z case ids in CCMS and adding RIN. Should be retired from CCTS.

N/A

SBPLMK41 RACF ID Production Report. This report will need to be modified on CCTS to only include payment entered.

N/A

SBPLM8E1 Number of Licensed Exempt Providers. Should now be included as part of CCMS ad hoc report to list providers. Should be retired from CCTS.

Ad Hoc

2BPLM821 Cases in Non-TANF Education/Training. Should now be replaced with alerts (tasks) in CCMS and Ad Hoc report. Should be retired from CCTS.

Ad Hoc

SBPLM842 Non-TANF Cases Age 20 or Older With Reason 3. Should now be replaced with alerts (tasks) in CCMS. Should be retired from CCTS.

Alert

SBPLMK22 Active Clients With Invalid SSNs. Should now be replaced with edit in CCMS. Should be retired from CCTS.

CCMS Edit

2BPLMH31 Z Case Transfers. This report is no longer needed since we're eliminating system assigned z case ids in CCMS. Should be retired from CCTS.

N/A



2BPLME31 Purged Applications. This information about purge applns should now be available in CCMS since the data is being purged from CCMS. Should be retired from CCTS.

SBPLMC71 Shared Cases With Cancellations. This report will be replaced by new shared case functionality in CCMS. Should be retired from CCTS.

Ad Hoc

SBPLM041 Cases and Children for Site Providers. Should now be included as part of CCMS ad hoc report. Should be retired from CCTS.

Ad Hoc

SBPLM611 Site Administered Providers With Cases Sent Redetermination Forms. Should be replaced by CCMS Ad Hoc report listing cases by eligibility ending date and retired from CCTS.

Ad Hoc

2BPLM753 TANF Teen Parent Child Care Cases. This report should be replaced with Alert in CCMS. Should be retired from CCTS.

Ad Hoc

2BPLM754 Non-TANF Teen Parent Child Care Cases. This report should be replaced with Alert in CCMS. Should be retired from CCTS.

Ad Hoc

2BPLMF11 Site Cases by Provider Report. Should now be included as part of CCMS ad hoc report. Should be retired from CCTS.

Ad Hoc

SBPLMT01 Daily Pending Web-Entered Site Applications and Redeterminations. This report will no longer be needed since SPARE website will be replace by CCMS. Should be retired from CCTS.

Tasks Report

5029E231 Web Applications and Redeterminations. This report will no longer be needed since SPARE website will be replace by CCMS. Should be retired from CCTS.

Tasks Report

SBPLM601 Site Administered Cases With Multiple Providers Sent Redetermination Forms. This report will be replaced by new shared case functionality in CCMS. Should be retired from CCTS.

CCMS Report

SBPLM771 Site Administered Providers With Cases Sent Cancellation Forms. Should be replaced by CCMS Ad Hoc report listing cases by eligibility ending date and retired from CCTS.

CCMS Report

2BPLMG61 Active Cases with Provider Changes Pending. This should now be included in CCMS either as report or alert based on Change Order. Should be retired from CCTS.

CCMS Report

SBPLMD41 Providers Who Need Documentation. Should now be replaced with alerts (tasks) in CCMS. Should be retired from CCTS.

CCMS Report



5.6 DATA MODEL AND DATA DICTIONARY

The logical and physical data models as well as the data dictionary for the CCMS system are provided below.


detail system design - ded - dhs: illinois department · web viewthe ccms presentation layer...

Documents