Florida Department of Agriculture and Consumer Services ... - Syst… · Florida Department of...

Florida Department of Agriculture and Consumer Services – AgCSS Project AGRICULTURE AND CONSUMER SERVICES SYSTEM (AgCSS) PROJECT D7 – SYSTEMS DESIGN DOCUMENT (SDD)

Date: 06/27/2018

Version: 100

Florida Department of Agriculture and Consumer Services – AgCSS Project D7 – Systems Design Document (SDD) Page i

TABLE OF CONTENTS SECTION 1 INTRODUCTION ............................................................................................ 1 SECTION 2 ROLES AND RESPONSIBILITIES .................................................................. 2 SECTION 3 TECHNOLOGY STACK .................................................................................. 3 SECTION 4 SYSTEM ARCHITECTURE ............................................................................ 6

4.1 System Architecture Diagram ..................................................................................... 6 4.2 Narrative for System Architecture Components .......................................................... 6

4.2.1 Customer Portal .............................................................................................. 7 4.2.2 Accela Automation (AA) .................................................................................. 8 4.2.3 Accela Inspector App .................................................................................... 10 4.2.4 Common Services ......................................................................................... 11 4.2.5 Data and Business Integration ...................................................................... 13 4.2.6 Additional Interfaces...................................................................................... 13

SECTION 5 BUSINESS DESIGN COMPONENT ............................................................. 15 5.1 Accela Automation Configuration Data Concepts ..................................................... 15

5.1.1 Agency .......................................................................................................... 15 5.1.2 Module .......................................................................................................... 15 5.1.3 Record .......................................................................................................... 15 5.1.4 Record Components ..................................................................................... 17 5.1.5 Reference Data vs. Transaction Data ........................................................... 18 5.1.6 Accela Global Configuration .......................................................................... 21 5.1.7 Education ...................................................................................................... 21 5.1.8 Accela Configuration Guidelines ................................................................... 24 5.1.9 Accela Automation Data Objects Decision Matrix .......................................... 29 5.1.10 Record Type Configuration ........................................................................... 34 5.1.11 Additional Document ..................................................................................... 34

5.2 Accela Construct API – Customer Portal .................................................................. 34 5.2.1 Solution Architecture ..................................................................................... 35 5.2.2 Integration ..................................................................................................... 38 5.2.3 Security ......................................................................................................... 38 5.2.4 Application Structure ..................................................................................... 39 5.2.5 Framework Services ..................................................................................... 39 5.2.6 Security ......................................................................................................... 40 5.2.7 Cache ........................................................................................................... 40

Florida Department of Agriculture and Consumer Services – AgCSS Project D7 – Systems Design Document (SDD) Page ii

5.2.8 Exception Handler ......................................................................................... 40 5.2.9 Exception Reporter ....................................................................................... 40 5.2.10 Logging ......................................................................................................... 41 5.2.11 Validation ...................................................................................................... 41 5.2.12 Presentation .................................................................................................. 41 5.2.13 Web API Controller ....................................................................................... 41 5.2.14 AgCSS Customer Portal Service ................................................................... 41 5.2.15 Accela Service Client .................................................................................... 41

5.3 Mobile App for Inspectors ......................................................................................... 42 5.4 Common Design Architecture ................................................................................... 44

5.4.1 Overview ....................................................................................................... 44 5.4.2 Batch/Database Interface .............................................................................. 45 5.4.3 Web Service Interface ................................................................................... 49

5.5 Call Center Integration Overview .............................................................................. 52 5.6 OnBase Integration Overview ................................................................................... 53

5.6.1 From Accela to OnBase ................................................................................ 54 5.6.2 From OnBase to Accela ................................................................................ 55

5.7 GCOM Correspondence Management (GCM) .......................................................... 57 5.7.1 Use Case 1 – User-Generated Correspondence ........................................... 58 5.7.2 Use Case 2 – Batch Process ........................................................................ 60

5.8 Additional Interface Inventory ................................................................................... 62 SECTION 6 USER INTERFACE CONTROL .................................................................... 63

6.1 Portal Screen Flow Component ................................................................................ 63 6.1.1 Dashboard with Detail Cards ......................................................................... 64 6.1.2 CW License Application - Qualification .......................................................... 65 6.1.3 CW License Application - Application ............................................................ 66 6.1.4 CW License Application - Application ............................................................ 67 6.1.5 CW License Application - Payment ............................................................... 68 6.1.6 493 Class D - Qualification ............................................................................ 69 6.1.7 493 Class D - Application .............................................................................. 70 6.1.8 493 Class D - Complete Applications ............................................................ 71 6.1.9 493 Class D - Payment ................................................................................. 72

6.2 AA Screen Flow Component ..................................................................................... 73 6.2.1 Login ............................................................................................................. 73 6.2.2 Launchpad .................................................................................................... 74

Florida Department of Agriculture and Consumer Services – AgCSS Project D7 – Systems Design Document (SDD) Page iii

6.2.3 New Applications .......................................................................................... 75 6.3 OnBase Screen Flow Component ............................................................................ 85

SECTION 7 DATABASE ................................................................................................... 86 7.1 Data Structural Tools ................................................................................................ 86 7.2 Data Dictionary ......................................................................................................... 86 7.3 Entity Relationship Diagrams (ERD) ......................................................................... 86

SECTION 8 AGCSS REPORTING TOOLS ...................................................................... 87 8.1 Reporting Components ............................................................................................. 87

8.1.1 Microsoft SQL Server Reporting Service ....................................................... 87 8.1.2 Power BI Dashboard ..................................................................................... 92

SECTION 9 INFRASTRUCTURE REQUIREMENTS ........................................................ 93 SECTION 10 SECURITY REQUIREMENTS ...................................................................... 94

TABLE OF EXHIBITS

Exhibit 4-1: Accela High-Level Components ............................................................................. 6 Exhibit 5-1: Examples of Record Types .................................................................................. 16 Exhibit 5-2: Components of a Record ...................................................................................... 17 Exhibit 5-3: Reference Data Concept ...................................................................................... 20 Exhibit 5-4: Configuration Data Tables .................................................................................... 24 Exhibit 5-5: Individual Contact Type ........................................................................................ 27 Exhibit 5-6: Organization Contact Type ................................................................................... 27 Exhibit 5-7: Object Property .................................................................................................... 34 Exhibit 5-8: Architecture .......................................................................................................... 36 Exhibit 5-9: Presentation Tier .................................................................................................. 37 Exhibit 5-10: HTML5 Compatible Browsers ............................................................................. 37 Exhibit 5-11: Middle Tier – Technology Stack ......................................................................... 38 Exhibit 5-12: Customer Portal Application Structure ................................................................ 39 Exhibit 5-13: Customer Portal Application Structure ................................................................ 40 Exhibit 5-14: Database Interface Flow for Inbound Data ......................................................... 46 Exhibit 5-15: Database Interface Flow for Outbound Data ....................................................... 48 Exhibit 5-16: Web Service Interface Flow ................................................................................ 50 Exhibit 5-17: Technology Stack ............................................................................................... 52 Exhibit 5-18: PureConnect / Unify / Accela Integration ............................................................ 53 Exhibit 5-19: EDMS Communication Flow ............................................................................... 55 Exhibit 5-20: EDMS Translation Flow ...................................................................................... 55 Exhibit 5-21: Intake Process Flow ........................................................................................... 56 Exhibit 5-22: GCM Process Flow – User Generated Correspondence .................................... 58 Exhibit 5-23: GCM Process Flow – Batch Printing ................................................................... 60 Exhibit 5-24: GCM ER Diagram .............................................................................................. 62 Exhibit 6-1: Login and Create Account Screen Flow ............................................................... 63

Florida Department of Agriculture and Consumer Services – AgCSS Project D7 – Systems Design Document (SDD) Page iv

Exhibit 6-2: Dashboard with Detail Cards ................................................................................ 64 Exhibit 6-3: CW License Application - Qualification ................................................................. 65 Exhibit 6-4: CW License Application - Application ................................................................... 66 Exhibit 6-5: CW License Application - Application Summary ................................................... 67 Exhibit 6-6: CW License Application Payment ......................................................................... 68 Exhibit 6-7: 493 Class D - Qualification ................................................................................... 69 Exhibit 6-8: 493 Class D - Application ..................................................................................... 70 Exhibit 6-9: 493 Class D - Application ..................................................................................... 71 Exhibit 6-10: 493 Class D - Payment ....................................................................................... 72 Exhibit 6-11: FDACS Accela Automation Login Page .............................................................. 73 Exhibit 6-12: Launchpad ......................................................................................................... 74 Exhibit 6-13: Sign Out Link ...................................................................................................... 74 Exhibit 6-14: Record Portlet New Button ................................................................................. 75 Exhibit 6-15: Record Type Select ............................................................................................ 75 Exhibit 6-16: Class D Security Officer Applicant Information ................................................... 76 Exhibit 6-17: Class D Security Officer Applicant Address Information ..................................... 76 Exhibit 6-18: Contact Address Information .............................................................................. 76 Exhibit 6-19: Class D Security Officer Application Specific Information 1 ................................ 77 Exhibit 6-20: Class D Security Officer Application Specific Information 2 ................................ 77 Exhibit 6-21: Class D Security Officer Application Specific Information 3 ................................ 78 Exhibit 6-22: Class D Security Officer Document Section ........................................................ 78 Exhibit 6-23: Class D Security Officer Submission Confirmation ............................................. 78 Exhibit 6-24: Class D Security Officer Summary Screen ......................................................... 79 Exhibit 6-25: Workflow ............................................................................................................ 79 Exhibit 6-26: Work Flow Task Detail ........................................................................................ 80 Exhibit 6-27: Work Flow Task Detail ........................................................................................ 80 Exhibit 6-28: Work Flow Task Detail ........................................................................................ 81 Exhibit 6-29: Work Flow Task Detail ........................................................................................ 81 Exhibit 6-30: Work Flow Task Detail ........................................................................................ 82 Exhibit 6-31: Work Flow Task Detail ........................................................................................ 82 Exhibit 6-32: Work Flow Task Detail ........................................................................................ 83 Exhibit 6-33: Work Flow Task Detail ........................................................................................ 83 Exhibit 6-34: Work Flow Task Detail ........................................................................................ 84 Exhibit 6-35: Work Flow Task Detail ........................................................................................ 84 Exhibit 8-1: Accela Admin Screen for Report Manager Setup ................................................. 87 Exhibit 8-2: Create New Report Service .................................................................................. 88 Exhibit 8-3: Report Service Form ............................................................................................ 88 Exhibit 8-4: Report Service URL Setup ................................................................................... 89 Exhibit 8-5: Report Service URL Setup ................................................................................... 90 Exhibit 8-6: Report Service URL Setup ................................................................................... 90 Exhibit 8-7: Report Link ........................................................................................................... 91 Exhibit 8-8: Report File List ..................................................................................................... 91 Exhibit 8-9: Report File List ..................................................................................................... 92

Florida Department of Agriculture and Consumer Services – AgCSS Project D7 – Systems Design Document (SDD) Page v

Revision History

DATE AUTHOR VERSION CHANGE REFERENCE

04/04/2018 Rahul Bhosle 001 Initial draft.

05/29/2018 Rahul Bhosle 002 Updated all comments with additional information and added reporting section.

06/27/2018 Carol Williams 100 Approved baseline.

Quality Review

NAME ROLE DATE

Robert Pacheco Technical Writer 04/12/2018

Robert Pacheco Technical Writer 04/17/2018 Robert Pacheco Technical Writer 04/20/2018



Florida Department of Agriculture and Consumer Services – AgCSS Project D7 – Systems Design Document (SDD) Page 1

SECTION 1 INTRODUCTION

Agriculture and Consumer Services System (AgCSS), formerly known as the Regulatory Lifecycle Management System (RLMS), is the system that will transform how the department conducts its regulatory services. FDACS is responsible for a broad range of services and regulatory responsibilities across its divisions and offices. Innovation is one of the department's core values and aligns with the Commissioner's objective to leverage new and innovative technologies.

As part of the department's Culture of Service, AgCSS will enhance delivery of services to customers as well as constituents. After due diligence in the procurement phase, the evaluation and negotiation teams recommended the best overall value to the department, resulting in a June 2017 contract award to GCOM Software as the enterprise regulatory solution Systems Integrator. After implemented, the AgCSS system will provide the department and its constituents with a trustworthy system that is modern and customer-friendly.

The Systems Design Document (SDD) deliverable defines the security protocols, controls, approaches, and verifications that will be implemented during the delivery of the project. The SDD includes detailed description of system architecture including various technology components that constitute the solution. The AgCSS solution components includes Accela Automation, Accela Construct API portal, OnBase Intake solution, Common Framework for various AgCSS interfaces, Genesys Call Center solution, Reporting solution, GCOM Correspondence Management (GCM) and AgCSS Database components.


SECTION 2 ROLES AND RESPONSIBILITIES

Role  Responsibilities 

System Manager  Responsible for the hardware and virtualized environment. 

Applications Manager  Responsible for COTS products installation and configuration. 

Database Manager  Responsible for database policies, procedures, and controls. 

Exhibit 2-1: Role and Responsibilty


SECTION 3 TECHNOLOGY STACK

Software Description Version

Windows Server Operating System for all VMs. 2012 R2

Microsoft IIS Webserver that supports the Accela Mobile Gateway, Accela Ad-Hoc Reports, Accela GIS software and OnBase.

8.5.9600.16384

Microsoft .NET Framework Supports the Accela Mobile Gateway, Accela Ad-Hoc Reports, Accela GIS software and OnBase.

4.5

Accela GIS (Silverlight and JavaScript)

The Accela Civic Platform GIS JavaScript map viewer is an embedded map component that integrates the latest mapping functionality with the Civic Platform data and workflow process. Features of the GIS component include place locator, bookmarks, a variety of base maps, redlining, editing and display options when viewing locations passed from a list, such as a cluster marker or heat map. The JavaScript GIS viewer supports the Civic Platform new user interface, while the Silverlight GIS viewer supports v360.

9.1.0

Accela Mobile Gateway The Accela Gateway server for mobile users. Through this gateway, Accela Civic Cloud Platform integrates with Accela Automation instances. It must be accessible from the public Internet and have access to the internal Accela Civic Platform Application server.

9.1.3

Accela Ad-Hoc Reports The Accela Ad-Hoc reporting tool allows configuration and running of simple reports. It communicates with Accela Civic Platform components.

9.0.4

Accela Civic Platform Accela Civic Platform is comprised of the following software components:

Web Server Civic Platform packages JBoss with Civic Platform components and deploys these to the web server. The web server receives instructions to construct and deliver web pages to a Civic Platform browser-based client and provides information from the browser-based client to the application server for processing.

ColdFusion MX Web Server

9.1.3



Civic Platform deploys the third-party tool ColdFusion MX to a web server. The ColdFusion MX web server provides the user interface environment for the Classic Admin pages.

Application Server Civic Platform packages JBoss with Civic Platform components and deploys these to the application server. The application server executes the main functionality of Civic Platform. The application server retrieves and writes record content to the database and integrates with the web server to send and receive information to and from the client.

Index Server The index server provides Civic Platform with the ability to perform global searches across Civic Platform records.

OnBase Document Management System for AgCSS. 17.0.0

JBOSS EAP Application Server for OpenAM, Customer Portal and GCOM eXtend.

6.4.0

Jasper Reports Adhoc Report engine for AgCSS. 6.4.0

OpenAM and OpenDJ Authorization Management for AgCSS. 13.0.0 and 3.0.0

GCOM eXtend Correspondence Management for AgCSS.

MS SQL Server Database for AgCSS. 2014

HTML HTML web pages for designing web application. 5

Cascading Style Sheet (CSS) Look-and-feel stylesheet framework. CSS3

Bootstrap Theme and cross-browser compatible CSS framework.

Bootstrap 3

Angular Angular is a structural framework for dynamic web applications. It allows us to use HTML as the template language and we can extend HTML's syntax to express our application's components clearly and succinctly.

5

Java Multi-paradigm programming language encompassing strong typing, imperative,

1.8

http://getbootstrap.com/docs/3.3/



declarative, functional, generic, object-oriented (class-based), and component-oriented programming disciplines.

Spring MVC Spring MVC is a tool set for building the UI framework.

4.1.5

Apache Web Server Web Server for AgCSS application. 2.4

PureConnect AgCSS Call Center solution 2018 R2

Brainware OnBase OCR component 5.8.1

Exhibit 3-1: Technology Stack


SECTION 4 SYSTEM ARCHITECTURE

4.1 SYSTEM ARCHITECTURE DIAGRAM

Accela Version 9.2.x

`

Online

`

Mobile

`

Online

AGCSS Back Office Users Customer Portal

Web

Ser

vice

sD

atab

ase

Inte

rfac

esH

TTPS

Pos

t

Ad hoc Reporting

Online Payments

Melissa Data

USPS

LDAP

Onbase

AGCS

S D

atab

ase

(Acc

ela,

O

nbas

e)

EncryptionBatch Support Services Database Access Services

Data and Business Integration

Monitoring

Plan Review

Billing

System administration

Oversight Inspection

GIS

Enforcement

Inspections Monitoring

Research

Perform

Billing

Review History

Oversight Inspection

Result

Inspector App(Accela Inspector app )

Inspections

Complaints Renewals

Application Processing

Amendment Account Management

Research & Inquiry

Payments

Customer PortalWorkflow Inspections

Address Monitoring

Application Processing

Hearing

Contacts

Billing

System Administration

Research & Inquiry

Renewals

GIS

DocumentsEnforcement

Accela Automation(AA)

Web

serv

ices

Pay

men

t Documents

Billing

Common Services

HelpAlerts

Authentication Correspondence Payment Processing

Expression BuilderReporting Event Manager EMSE Scripting

Licensed Professionals

OnbaseDoc versioning

Doc repository

Global search

Metadata Integration

Results

License

Monitoring

Authorization Conditions

Accela Inspector app

Condition

`

Remote

`

Mobile

Open AM

GCM

Genesys

Additional Interface

Exhibit 4-1: Accela High-Level Components

4.2 NARRATIVE FOR SYSTEM ARCHITECTURE COMPONENTS

The application architecture for the AgCSS project consists of the Accela Commercial Off-The-Shelf (COTS) product, which is designed to satisfy the business requirements. In general, Accela is designed to function in standard three-tier architecture, utilizing Java 2 Platform, Enterprise Edition (J2EE) standards with relational databases or standard TCP/IP network protocols.


All the Accela components are scalable without impacting the existing environment. The Accela environment can be scaled up by adding more virtual machines with required components running on them. This will not impact the currently configured services in that environment.

The infrastructure of the AgCSS system has been designed to meet the requirements and guidelines of FDACS. Accela GIS, Customer Portal, and the Mobile Gateway are identified as components that will need to be publicly accessible, and therefore will be hosted in the public DMZ zone. Accela Ad hoc Reports and Civic Platform services will only be accessed by internal AgCSS resources; therefore, their services will be hosted in the internal FDACS Core zone. Additionally, SQL Database, GCOM Correspondence (GCM), OnBase Document Management, SFTP, SMTP, LDAP, ArcGIS and SVN services will be hosted in the internal FDACS Core zone.

The following descriptions of the functionality within each of the major software components is detailed in Exhibit 4-1 above.

4.2.1 CUSTOMER PORTAL

Customer Portal (CP): Public users access CP online to submit requests for applications, renewals, payments, and complaints, etc. The Customer Portal mobile application will not be a part of AgCSS. However, in the future, FDACS may decide to involve a mobile application as a part of AgCSS system. The current site will be developed using responsive design to work on mobile browsers.

Payments: The customer can pay invoiced fees for one or more applications via credit card, debit card, or an electronic check.

Complaints: The customer can have several options of submitting complaints and inquiries, which are dependent on FDACS business rules. Customers can have direct access to FDACS via the public portal. Complaints can also be submitted using options such as email, phone, or fax. Complaints that are submitted using these options must be manually entered into the AgCSS system. Complaint forms, which are sent as Fax, can be scanned and incorporated via OCR into the system.

Renewals: The customer may apply online for renewal of license, certifications, etc. Depending on the business rules and FDACS guidelines. When a license expires, the user can renew the license and pay for the newly-generated fee through the Payment Processing portlet in CP. (NOTE: A portlet is a component in the user interface containing the buttons, menus, lists, and forms that allow you to accomplish the tasks related to, in this case, application forms, billing, and other automated processes).

Application Processing: Every license request will start by processing initial application request. The customer portal allows customer to request license by submitting online application with necessary information, such as: applicant information, contact information, work descriptions, addresses, license-specific information and other details. The customer will have ability to check status of submitted application using portal dashboard. Additionally, once


application is approved and license is issued, portal will allow to initiate a process, such as: schedule an inspection, or submit a renewal or amendment.

Research and Inquiry: Customers will have page searching ability to search their permits, inspections, etc. They will have the option to perform an inquiry relating to their account(s), AgCSS services, payments, etc.

Amendment: A customer can apply for an amendment on the Customer Portal by accessing his or her current license record. The applicant pays the amendment fees and submits the amendment. After the agency approves the amendment via the workflow, all the amended information will be copied into the parent record.

Account Management: Using the CP Account Management page, users can create a login account to submit application or renewal requests, etc. AgCSS can be configured for users to receive notifications of various activities and status updates via emails, phone call from IVR or text messages. Users will have the option to provide notification and alert preferences for email or text messages on their mobile devices. They can reset or retrieve their passwords via the Forgot Password link, update security questions, and can change their address/contact information.

Documents: Users can upload documents for various purposes to an application in CP on the documents page before submitting the application. The system can also be configured to mandate the required documents for each type of application based on business rules and FDACS guidelines.

Monitoring: Applicants can monitor the status of their requests submitted with AgCSS for application or renewal. AgCSS can be configured to send notifications to the users about any change in statuses of their applications, per their preferences.

Billing: Applicants can view their invoices and make online payments for applications, renewal, violations, or inspections via CP.

Results: Based on business, applicants can view and download the license or approval letters of inspections or tests.

Inspections: The Public submits inspection requests to FDACS either in person or online through CP, the public facing portal.

4.2.2 ACCELA AUTOMATION (AA)

AgCSS Back Office Users: AgCSS Back Office Users access their AA accounts online to perform daily activities assigned to them. Inspector or Supervisor performs inspections in the field by using a hand-held device (mobile). AgCSS Back Office Users may login remotely through VPN to access their desktop and work remotely. All Back-Office users account will be integrated with Agency Active directory.


Workflow: A workflow is a series of tasks linked together to accomplish a result, such as processing an application or tracking a service request. Effectively designed workflows can help save time, streamline the process, improve communication, cut out unnecessary work, make better use of human resources, and prevent tasks from falling through the cracks.

Inspections: Inspection requests can be submitted either through the CP by the public or by AgCSS internal users through AA. Accela Automation can be configured to create inspection request automatically based on business rules such as: time interval inspection (e.g., every six months), based on license type business rule (inspection required before issuance of license), etc. Inspectors perform inspections based on the checklist on their hand-held device and results are sent to their Supervisor for approval.

Application: FDACS customers can appear in person or submit via mail and have FDACS staff submit their license requests in AA on their behalf. FDACS staff will collect fees and upload the relevant documents provided by the customer.

Application Processing: The lifecycle of an application is tracked in AA. The steps of the application process include:

Submit application. Pay fees. Approve application via workflow. Send the license or approval letter.

Contacts: The Contacts tab is used to add, maintain, and view information about the people associated with an application. A tab is a button on the page to go to a section in the page. There are two classes of contacts: Reference contacts and Transactional Record contacts.

Address: The Address tab is used to add, maintain, and view information about an address associated with an application. A tab is a button on the page to go to a section within the page. There are two classes of contacts: Reference Address and Transactional Record Address. All addresses will be validated using the Melissa Address validation service.

Renewals: FDACS staff will have access to AA to complete the renewal request on behalf of the customer. Staff will scan all relevant documentation and associate it to the application.

Billing: Fee Schedules can be predefined, or AA can base them on the job value (valuation) of an application. For instance, through the application process, or because of inspections, fees may be assessed and determined by a configured fee schedule. Fee schedules can be unique and include payment periods and multiple fee items. Customers will still have the option to pay fees by mailing a check, via coupon payment. Penalties or late fees can be applied in Civic Platform based on the agency’s business rules. Financial data in Civic Platform, such as refunds, can be tracked via transaction code (preferred method), receipt, or invoice number.


Research and Inquiry: An FDACS employee can conduct research and make an inquiry to complete the investigation of the submitted request. Inquiries can come from many sources, including members of FDACS field staff, the public, or application request data errors.

GIS: Accela GIS provides a geographic view of all land use, zoning, and infrastructure information associated with agency records, including parcels, permits, inspections, plans, assets, work orders, and service requests.

System Administration: Assigned administrator(s) can add users, edit user profiles, run batch jobs, etc.

Administrative Action: AgCSS will be configured to capture all administrative action to include the following: Internal User determination of applicant ineligibility; investigations of licensed or unlicensed individuals or businesses; system determinations of licensed ineligibility based on specific business rules; Internal User review of miscellaneous documents received via complaints, notifications from law enforcement agencies, etc. Accela automation provide out of box Public hearing component to support additional process which can fall under Administrative Action processes.

Documents: In Accela Automation, an agency user can upload documents to a record at any time from either the Documents tab or from the Inspection portlet (screen). During upload user will force to select document type to associate with uploaded document.

4.2.3 ACCELA INSPECTOR APP

Accela Mobile Applications: Accela Mobile Inspector will be installed on the FDACS Inspectors’ hand-held devices. Inspectors will use an application to perform their related tasks in the field.

Accela Mobile Inspector:

Inspections: Inspectors can perform an inspection using the preloaded checklist in the Accela Mobile Inspector. They can access any kind of checklist specific to an inspection through the application. Results of the inspection are updated automatically and sent to the appropriate supervisor for review, if needed.

Billing: An Inspector will have the option to issue a bill after the completion of an inspection.

Review History: An Inspector can view applicant information, past inspections, and administrative actions associated to a record.

Research: An Inspector can research the contacts, addresses, routes, and related documents prior to the inspection.

Perform: An Inspector can perform an inspection using a preloaded checklist for the given type of inspection; this eliminates paper checklists.


Result: Inspection results can be tracked in the mobile application. An Inspector can issue letters of approval or violations onsite.

4.2.4 COMMON SERVICES

The services tier provides common services (such as security) as well as services that are specific to certain product modules (some services are common to all product modules. Other services are specific to the product modules that are installed). The services tier must have access to the metadata repository tier and the engine tier. The Common Services are applicable to records submitted in CP, AA, and the mobile application.

Reporting: Reports can be setup to extract current data from AA. Agencies typically setup their reports by module and user group, enabling them to control the reports that are available both by module and by user group. In AA, the users will be able to create a graphical representation of data; for example, a bar chart or line graph. A user can generate a line graph by using SmartChart in Accela to represent the data in a list view. This is useful if one needs to compare records from a list.

Alerts: Messages can be configured to alert the user if any business process is not met or fails. For example, if the application requires a mandatory training be completed, and if the requirement is not met based on the submitted information, the user will be alerted. The Event Manager Scripting Engine (EMSE) script system will have an option to alert the customer by sending a notification when there is a status change in the workflow, or if the applicant has not met the required criteria to process the application. For example, in AA and CP, before an application can be successfully submitted, a message will appear if there is data missing for any mandatory field. Using EMSE scripts and batch job setup, the system can provide alerts when there is a change in status.

Help: Various Help texts can be configured in CP and AA to help the user better understand each field on the application form.

Event Manager: The Event Manager identifies events, such as scheduling an inspection, finding a record, assessing a fee, etc., and launches a related script. The Script Engine produces an effect based on the parameters that Event Manager passes to it, and by the design of the script used to process the event. Event Manager can be used to make the system more efficient and perform at a high level of customization. Events are already defined within Accela Automation. Once an event is triggered, product internally calls Master script, which provides script extension for doing additional business rules during a particular event. For example, application submitted after an event is triggered by product when record is submitted, which internally is called ‘Applicationsubmitafter’ Master script. This Master script provides extension to add additional script to include business rules. For example, once application is submitted, send email confirmation or initiate workflow task and assign agency staff.


Exhibit 4-2: Event and Script execution

EMSE Scripting: EMSE comprises the AA scripting platform, and AA stores the master script files, written in JavaScript, in the AA database. Each master script file contains a global set of Civic Platform functions that can be configured through a Standard Choice script control that ties the function to a specific before or after event. Civic Platform launches scripts when the events associated with the script occur. These events can trigger scripts to assess fees, update workflows, automate business processes, etc.

Expression Builder: Expression Builder provides an interface in which to script client-side interactions (or expressions) before triggering an event type (for example, submitting a form) handled by the master script framework. Expression Builder can be used to define expressions that trigger when a form loads or when a user selects or enters a value in an individual form field.

Authentication: Authentication provides a way of identifying a user, typically by prompting the user to enter a valid user name and valid password before access is granted. The Customer Portal users are authenticated against the OpenAm database. If the credentials match, the user is granted access to the application. If the credentials do not match, authentication fails and application access is denied. OpenAM authentication will be integrated with Customer portal and Accela Automation. FDACS LDAP will be configured with Accela Automation for FDACS internal user.

Authorization: After authenticated, a user will have access to functionality based on their designated role. Users can be authorized to perform a specific subset of functionality within the


system rather than being provided full access. Authorization is achieved by creating groups and user roles within the groups, and then rights are assigned to the groups.

Correspondence: A record-level list of correspondence will be kept tracking communications initiated from and received by Accela Automation.

Payment Processing: AgCSS application will use Bank of America (BOA) gateway to accept payment. A payment adapter will be developed to redirect users to BOA gateway to accept payments via credit, debit cards or echeck(ACH). The Public still has an option to pay fees in check payment at FDACS, via coupon payment and money orders. The system provides the capability for processing refunds, voids, cancels, hold payments, fund transfers, audit trails, etc.

Conditions: There are two types of Conditions in Accela: Conditions of Approval and General Conditions. They share the same logic but are used for different purposes. Conditions of Approval describe the list of requirements that citizens must meet to receive approval for a license or certification. General Conditions indicate a problem on the record, inspection, address, contact, or other application component. A Condition can be configured to lock or hold a record or to provide a notification. In AgCSS implementation condition will be used for document requirements, printing requirement and alert messages.

4.2.5 DATA AND BUSINESS INTEGRATION

Data and Business Integration: This represents the integration services between the database and business, such as the following:

Batch Support Services: To efficiently perform bulk database updates and automated processing.

Encryption: This feature allows sensitive data to be encrypted within the data files to prevent access to it from the operating system.

Database Access Services: Allows developers to connect to the database using a client program such as SQL developer.

4.2.6 ADDITIONAL INTERFACES

Additional Interface Systems: Section 5.1 outlines the approach that will be used to develop various interfaces. Refer to DEL12 - Interface Development Inventory for a complete list of all interfaces scoped for the AgCSS project.

Lightweight Directory Access Protocol (LDAP): Single sign-on with LDAP. Accela Automation user will login using network user ID and password. Password policy will be maintained by agency active directory (password expiration, etc.). Even Accela Automation is using Active directory user and password, currently Accela does not support auto-sign on once


users are already signed into desktop using network login. Accela product team is working additional solution to provide requested functionality by FDCAS.

Online Payments: To allow customers to make payment online and process and confirm payments.

Ad hoc Reporting: This allows users to easily create reports displaying data from Records. The Form Designer feature within the Ad hoc Report Writer provides additional functionality to create letters, permits, forms, and other documents.

GCOM Correspondence Management (GCM): The GCOM Correspondence Management functionality allows end users to create new correspondence from the correspondence template library. Workflow processes triggered from the Accela Automation can be configured to select a specific template based on business rules. Using GCM the user can create correspondence templates, view the draft correspondence, make edits to the template content, and then finalize the correspondence. The interface will trigger Accela Automation communication and document management services to 1) issue the correspondence to the internal or external customer via email or physical fulfillment process and 2) store/link the final copy of the documents in the OnBase EDMS and the Accela transaction record in PDF or HTML format.

OpenAM: OpenAM (open source access management) entitlements and federation server platform. OpenAM service will be used to authenticate users for the customer portal.

Genesys: AgCSS will be integrated with Genesys Platform tools to enable an enterprise call center technology platform for internal and external AgCSS users. Please refer Section 5.5 for detail about Genesys integration with AgCSS system.

OnBase: AgCSS will be integrated with OnBase Platform to enable an enterprise document management platform for internal and external AgCSS users. Please refer Section 5.6 for detail about OnBase integration with AgCSS system.


SECTION 5 BUSINESS DESIGN COMPONENT

5.1 ACCELA AUTOMATION CONFIGURATION DATA CONCEPTS

Before exploring the details of the data model for the AgCSS solution, it is important to understand concepts regarding how data is stored within AA. Below are the major components used to form a transaction record in Accela.

5.1.1 AGENCY

As per the established deployment model, AgCSS will be part of the FDACS Agency’s AA instance. In AA, the unique agency code is assigned, also referred to as a Service Provider Code. In nearly all tables in the database, the Service Provider Code is stored as part of the key field for that entry. This allows for the isolation between agencies to be easily enforced within the Accela products, and within any reports that are written against the database. In all cases, the database field label is SERV_PROV_CODE. The Service Provider Code for the AgCSS will be FDACS. An Agency’s database contains the profiles for authorized users, as well as various configuration objects (ASI, ASIT, Workflow, etc.), that can be reused for Record Types across all groups within that Agency.

5.1.2 MODULE

Within each AA Agency, there are one or more modules. Modules are used to represent a collection of transactions that are representative of an entire unit of business within the Agency. It is possible that the solution will require the creation of more than one Module within the AgCSS system to segregate business processes appropriately (e.g., DoL, DoA, etc.). Security permissions for end users can be configured by Module. For example, a user may be allowed to see only transactions for one Module within an Agency.

5.1.3 RECORD

The primary object within AA is the Record. A Record represents the entire lifecycle of a business process. An Agency will typically have many Records. A Record can represent many different types of processes, such as a renewal, amendment, permit, complaint, or enforcement case. A Record is a package of many other Accela Automation objects, such as contacts, addresses, inspections, fees, payments, documents, workflows, etc. Multiple Record Types can share these objects to avoid redundancy. A Record is a collection of data that represents a business process in AA.

5.1.3.1 Record Type

A Record Type is a construct for modeling a collection of data for a business process (such as authorization) and the associated configurations. Transaction Records are created from the template defined by the Record Type definition. Record Type is defined by hierarchy within the Agency of Group/Type/Sub-Type/Category. This structure provides an organization of processes such as tasks, inspections, and conditions of approval, as well as data such as


addresses and contact information. The hierarchy is used to define common business areas within the application for better organization. In addition to the visual grouping, this hierarchy helps minimize duplication of coding for reports and event scripts. Every Record Type will have an alias name, which will be decided when every specific Record Type is created during the design process. This alias name is the name which will be visible on the page of the public user.

5.1.3.2 Group, Type, Sub-Type, And Category

Group: The first level of the hierarchy of a Record Type, called a “Group,” is used to represent a collection of processes that is representative of an entire unit of business within the Agency. In many cases only a single Group for each Agency may exist. Additional Groups can also be utilized to identify departments within the Agency or other functional areas, such as DoL.

Type: The next level of the Record Type hierarchy, called a “Type,” is typically used to represent a business grouping within AgCSS. These can be the high-level functional business processes, such as 790, 493, etc. Grouping by organization is not recommended if the tasks can be moved from one organizational group to another.

Sub-Type: The next level is called a “Sub-Type,” which is a more detailed level within a Type. Depending on how the Type is structured, the Type and Sub-Type taken together will represent a unique Record Type, such as “Class CC.”

Category: The final level, called a “Category,” is used to represent the action taken on the same type of record, such as Application, Renewal, Amendment, and Authorization, etc.

Examples of a Record Type illustrating all four levels appear in the table below. When Type and Sub-Type are not applicable, it can be configured as “N/A.”

Record Types Alias name Group Type Sub-Type Category

Concealed Weapon Application DoL 790 CW Application

Concealed Weapon Application DoL 790 CW Renewal

493 Class CC Private Investigator Intern License

DoL 493 CC Application

Exhibit 5-1: Examples of Record Types


5.1.4 RECORD COMPONENTS

Components of a record can be shared across Groups under the same Agency Code. This includes the reference data (Permit, Address, Parcel, and Owner), workflows, and inspections.

Workflow

Record/ Transaction

Guidesheet (Checklist)

Address

Process

Contact

Reference Address

Reference Contact

Fee Schedules Document Code Inspection Group Conditions

ASI/ASIT

Group Description Value

Group Table Column

0..m

0..m 0..m

0..m

0..m

0..m 0..m

1..m

0...m

1..1

0..1

ASI

ASIT

Related Reference

data

Owner

Reference Owner

Value

0..m 0..m 0..m

Parcel

Reference Parcel

Default Document Code

Default Document Type

LicensedProfessional

Reference Professional

0..m

Exhibit 5-2: Components of a Record

Below are details about the Components of a Record shown in the above Exhibit 5-2:

Workflow: A workflow is comprised of a sequence of tasks that agency users follow (or tasks that are automated) to process a record. For example, when a user submits a new application, the system creates a record of the specified Record Type and launches an instance of the associated workflow.

ASI: Application Specific Information (ASI) is a collection of custom fields that can be created and applied to records, contacts, documents, conditions, and checklists, to meet the agency’s specific business objectives. ASI fields are agency-defined fields that enable you to leverage the power of the Civic Platform’s highly-configurable architecture.

To create a new ASI group, the group code, name, and first field to be included in the Group must be specified. Other information about the field, including the field type and a default Value can be setup. The system will provide the ability to edit the ASI group to setup additional fields,


change the order of fields in the group, or change any values. An option will be provided to include the display of the newly-added group or field in existing records.

ASIT: Administrators can setup Application Specific Information Tables (ASIT) that let users add application-specific data to multiple items.

Table: Administrators can create new tables to let users add data to applications. ASIT tables can be edited to change the display order, add instructional text, or add or delete subgroups.

Group: Enter a unique code to identify the ASIT table group that you are creating. If you are creating a subgroup for an existing group code, Accela Automation automatically populates this field with the group code.

Column: Enter the name of the first column for this table group.

Value: Enter a default value for the first field in your application-specific information table group.

Fee Schedules: Civic Platform uses fee schedules to organize individual fee items. Fee schedules provide the connection between fee items, modules, and Record Types. Civic Platform does not allow the creation of new Record Types without an assigned fee schedule. A Record Type can have more than one fee schedule assigned.

Document Code: Used to configure documents associated with the record.

Default Document Code: The name of a default grouping of document types that can be attached to instances of the Record Type.

Default Document Type: The name of the default document type, taken from the list of document types for the Default Document Code, to use for record attachments.

Inspection Group: An Inspection Group is comprised of a group of inspection types which represent the set of inspections that must be completed to issue a permit or license. The inspection types specify the checklist group, result group, and grade group, which provide the guidelines for performing the actual inspection and for capturing the inspection score, status, and grade. Inspection types can be defined to automatically schedule inspections and assign them the appropriate inspectors.

Conditions: Civic Platform enforces and applies conditions on Address, Parcel, Owner (APO), and Contact within the Civic Platform database or in an external database. Conditions behave the same whether you apply them to an application or to an application component.

5.1.5 REFERENCE DATA VS. TRANSACTION DATA

Reference data contains reference information about objects that are used and shared in various transactions across departments. Reference data allows users to search, organize, and


analyze data, such as searches for “all permits for this address” or “all licenses this person holds.”

Reference data typically represents an Address, Parcel, and Owner (APO) and Contact information that users can associate with records:

Addresses are physical locations within parcels.

Parcels are an area of land that has a specific location and legally-defined boundaries. A parcel can have multiple addresses.

Owners are associated with specific parcels; they are often responsible for their parcels and can serve as a point of contact.

Contact: Add contacts to maintain and view information about the people associated with an application.

Licensed Professional: Licensed Professionals have data (License Number, First Name, Business Name, License Type, State License Expiration Date, etc.) that Accela will need when it interfaces with FDACS to validate the information about a licensed contractor.

This reference data provides accuracy when creating and maintaining records as the single source for entity data. Security privileges for access to update the reference data should be tightly controlled and granted only to approved and trained system administrators.

Reference Data Components

Reference Address: The Reference Address detail portlet can list all the owners related to the address. Enable the Addresses portlet for users to create and manage reference address information.

Reference Parcel: A Reference Parcel detail portlet lists all the addresses related to the parcel; it enables the Parcels portlet for users to create and manage reference parcels.

Reference Owner: Enables the Owner portlet for users to create and manage reference owner information. Enables the Search and Clear buttons in the Owner section of the application intake form for users to search reference owners and add them to a record.

Reference Contact: Reference Contact is to manage contact types, such as Individual and Organization. Users add the reference contact or licensed professional to a new or existing record.

Reference Professional: New professionals can be added to the reference database. After a reference professional, that professional is available to associate with records.


Exhibit 5-3: Reference Data Concept

AgCSS Reference Record: As part of AgCSS Release 1 implementation, every contact will be created as a reference contact record. All contact such as applicant, manager, members, etc., will be created as an individual reference contact and contact such as Agency, Branch, School, etc. will be created as an organization reference contact.

Transactional Data

All the data objects that exist within each Record are considered as “transactional” in Civic Platform (Accela Automation). Transactional data supports business and organizational processes, such as submitting a permit application, creating an inspection, processing a license renewal, and other activities. Transactional data consists of instances (or copies) of reference data. A Record can hold a snapshot of reference data (or an association to such reference data), documents, custom fields, workflows, record statuses, inspections, etc. Data within the record, such as tracking of dates, times, and statuses, are transactional data and are independent of the reference data.

Transactional Data Components

Workflow ASI/ASIT Record Fee Document Inspection


Condition Guide Sheet (checklist)

The FDACS enterprise platform solution may use reference contacts that can be associated to a Record to capture information about people. When reference contacts are copied to the Record, a relationship to the reference contact is established to the Record through the reference contact’s Key.

5.1.6 ACCELA GLOBAL CONFIGURATION The Configuration team uses this table to configure the global solution, and is a summary of the detailed tables completed in this document. All entities listed below are under the section “Other Associations.” The “Other Associations” section is populated after all details on the “Summary” section are completed. This section represents the association of all elements that comprise a valid application type. Both these sections are available in the “AA Admin” portal under the “Record Type” section.

Application Type Name Inspection Group Name Workflow Code ASI Group Smart Choice Group Expiration Code (Required for renewable records) Exam

5.1.7 EDUCATION Continuing Ed ACA - Enable Application Only ACA - Enable Issuance Record Type Alias (Max 255 characters) Renewal Setting Application Status Group Security Default Status Record ID Partial Record ID Temporary Record ID ACA Page Flow Code Record Document Code


Please refer to the following Configuration Data Tables for detailed information regarding these components.

Table Definition Application Type The application type displays as the record alias, if present. If a record alias is not

present, the application type displays the four-level organization path of the record. (Group/Type/Sub Type/Category).

ID Mask The ID Mask defines the way the record number will appear in Accela Automation and Accela Citizen Access. The examples presented in the table allow for quick identification of the Record Type.

ID Mask Pattern Mask Output Partial ID Mask Temporary ID Mask

Department Organization A Department Organization in Accela Automation recognizes the ID defined by six (6) levels or branches: Agency, Bureau, Division, Section, Group, and Office. Organizations are an established hierarchy within a department and control which departments and staff members are responsible for different assignments.

Service Provider Agency Bureau Group Division Office Department Alias Department Description

User Groups In addition to organizing users into different Departments, it is necessary to establish various roles, or sets of privileges, known as “User Groups.” User Groups must align with your organization structure. By associating each User ID with a certain User Group, you can control the functions to which any individual user has access. User Groups control which daily and administrator functions are made available to certain individual users. For example, an Intake Specialist may be in a user group that includes only daily activities, such as searching for an inspection scheduled online. At least one User Group will be defined for a given Department.

Module Name Group Name Description

User Profile Users can be created for each staff member. Each user has certain privileges within Accela Automation based on their user group, and each user can belong only to a single department.

User Name Department User Group Daily Inspection Units Districts


Table Definition

Record Type Record Types allow you to organize the complex processes, tasks (such as inspections), and other important information that you require. Each time a user wants to perform a daily task in Accela Automation (for example, schedule an inspection), the user must search for an existing record. The Record Type identifies the workflow processes, smart choice groups, inspections, and application-specific information that is associated.

Group Application Type Subtype Category Record Alias

Workflow Configuration The workflow process is the progression of work for a Record Type. The workflow functions as a checklist that tracks the steps that must be completed before the record is closed. Workflows provide an efficient way to keep track of the requirements for a record, and helps a user complete each task within designated times. Each workflow process consists of specific tasks and task statuses that may move the workflow by activating another task. The table below is a written representation of the workflow.

Process Task ACA Displayable – Task (Y/N) Dept./User Task Status ACA Displayable – Task Status (Y/N) Flow Control (No Change, Next, Branch to, and Loop to) Application Status (Visible in ACA) Expected Task Duration (Days) Security

Application Status The Application Status defines the overall state of a record within its lifecycle and can be viewed by the public in ACA. If a record is processed following an agency’s workflow, its status changes. Security settings may be applied to the Application Status to prevent unauthorized users from modifying a record at a given status.

Application Status Group Status Description Note/Actions Security Status Type

Smart Choice The Smart Choice Group determines which standard sections are included on the record submission form, what information is required, and if the user can validate information against the values that already exist in the client database. The record submission form is leveraged for those records that will be created directly in the system. The sections that appear in grey-colored font will not be used in this record, and the section where Display equals “Y” denotes that this information will be displayed in the record submission form.

Smart Choice Group Code Section


Table Definition Section Description Display Required Validate Default Value Display Button Display Order

Exhibit 5-4: Configuration Data Tables

Global Configuration refers to the configuration that is applicable across the system. Changing this configuration will impact all the components that are using it. The following subsections represent the global configuration items for the AgCSS system:

Department Organization User Group User Profile

5.1.7.1 Accela Portlet Inventory

Portlets are Java-based web components, managed by a portlet container, that process requests and generate dynamic content. Internally Accela Automation use portlets as pluggable user interface components that provide a presentation layer (various screens) to systems. Please refer to the Accela Civic Platform Portlet Data Mapping document. This document will be provided as part of SDD deliverable.

5.1.8 ACCELA CONFIGURATION GUIDELINES

The following sections provide the guidelines for configuration within Accela.

5.1.8.1 Configuration Naming

All labels and values that application users see will be full, complete words in proper case. For example, Approved, Certificate Received, and Expiration Date.

Abbreviations will be configured only in extreme cases where very long descriptions exist.

5.1.8.2 General Configuration

Expression Builder should be used to provide users error messages prior to their clicking the Submit button, as required, on any AA form.

EMSE AfterX Scripts should be used to create or update information after the Submit button is clicked on any AA form.


Shared drop-down lists should use the exact Name as the Label associated to the drop-down values. Shared drop-down lists should be used instead of editing the values in the Application Specific Information or Table, except in extreme situations. For example, if Yes/No/NA is needed, create this as a Shared drop-down list to use across multiple Application Specific Information fields. Shared drop-down lists can have three fields: Name, Status, and Description:

Name: The name of the shared drop-down list.

Status: Indicates if the shared drop-down list is active or inactive.

Description: Provides a brief description for the drop-down list.

5.1.8.3 Workflow Configuration

Default Statuses, Due Dates, and Calendars are default statuses of Accela product functionality that are used to develop workflows. If these requirements cannot be met according to the agency requirements, the workflows can be developed by using EMSE scripting and custom code.

Develop workflows that use product functionality to process tasks.

Configure the workflows using product functionality to allow users the ability to update a task manually.

Workflow Task Names should be consistent to ensure quality searching and reporting. For example: Intake, Supervisor Review, and Issuance.

Workflow Task Statuses should be consistent to ensure quality searching and reporting. For example: Complete, In Progress, Approved. Workflow Task Statuses should be used only to update the overall status of the record and to provide information about the status of the task.

Workflow Processes will be shared as much as possible on multiple Record Types.

The Workflow Process Group should be labeled by Group, followed by an exact explanation of group values. Accela Automation users do not see this Group Name.

Workflow Tasks are specific to an actual process to be completed.

Include a task at the end of the process that represents the completion of the workflow processing the record.

Task-Specific Information (TSI) will not be used unless necessary, as it is not apparent to the user and there is no audit trail. If TSI is used, ensure that the data captured is relevant to the task itself, not the record.

Task Names should be consistent to ensure quality searching and reporting.


Labels and Values should be complete words and abbreviations should be avoided.

If one or more concurrent tasks in a workflow have similar statuses, then they should be represented differently.

Avoid having many Task Statuses that do not move the process forward.

5.1.8.4 Workflow Best Practices

Use these flow controls:

Go to Next - If a task has multiple statuses that force the task and/or record to be closed, use “No Change” and code the solutions to meet requirements.

Branch - If a task has multiple statuses that branch to a different task, configure the status as “No Change” and write code to branch to the correct task.

Loop - If a task has multiple statuses associated to a different task, configure the status as “No Change” and write code to loop to the correct task.

Configure Application statuses.

Configure Parent statuses, if applicable.

Do not write code to meet a requirement that could be met with correct and complete configuration.

5.1.8.5 Contact Type

Civic Platform divides contacts into two categories: Reference Contacts that serve as the reference database, and Daily Contacts that users add to records. A best practice is to manage contact types by defining only generic reference contact types, such as Individual and Organization. Record each individual or organization as one reference contact, and then link reference contacts to records in various roles, such as Applicant, Manager, etc. This enables users to easily track all the transactional and reference information about every Individual and Organization. FDACS will follow same best practice.

Before users add new reference contacts, or associate contacts with records, the system must set many Standard Choices to define the methods of managing contacts in Accela Automation, such as CONTACT TYPE, AUTO_SYNC_PEOPLE, and INDIVIDUAL_CONTACT_MATCH_ CRITERIA. For more information, consult the Accela Administration Guide.

For instructions on configuring the Standard Choices, refer to the Accela Civic Platform Configuration Reference Guide. Users often look up existing reference contacts to associate the desired one with a record. You can specify contact identity fields to guarantee the


uniqueness of each reference contact, and specify contact address identity fields to guarantee the uniqueness of each contact address for each contact.

Use Contact Type to indicate whether the contact is a person or an organization/business.

Individual – Person with a First and Last Name.

Exhibit 5-5: Individual Contact Type

Organization – Entity that is a business or company with a Business Name and/or a FEIN.

Exhibit 5-6: Organization Contact Type


5.1.8.6 ASI And ASIT Configuration Guidelines

Application Specific Information ASI (Custom Fields): This is a collection of custom fields that can be created and applied to records, contacts, documents, conditions, and checklists, to meet the specific business objectives of an agency.

Application Specific Information Tables ASIT (Custom Lists): Administrators can setup tables that allow users to add application-specific data with zero-to-many relationships, which enables the storing of the same data for multiple items. For example, storing the quantity and manufacturer for different units of AC refrigeration like Floor, Horsepower, Volts, Serial Number, etc. The name of the attached becomes the label that appears for the user. An ASI table can have as many specific data fields with individual data types as needed.

5.1.8.7 Configuration Limitations

Following are limitations for Accela configuration

Configuration can be setup only as Accela Record type.

All Accela objects (Contact, Address, ASI, ASIT, etc.) are associated only with Record type.

Workflow object is associated only with Record type.

Some of the configuration has limitation for field size. For example, ASI field name cannot exceed 100 characters, ASI instruction cannot exceed 4000 characters, etc.

Within module user can be associated only with one user role.

Florida Department of Agriculture and Consumer Services – AgCSS Project D7 – Systems Design Document (SDD) DED Page 29

5.1.9 ACCELA AUTOMATION DATA OBJECTS DECISION MATRIX

The AA Data Objects Decision Matrix lists the AA Object Properties for:

In the Matrix below, each Object Property begins a row, which then indicates in which data objects are applicable for that property.

For example: For the Object Property represents data to be captured on an application form, the following data objects are applicable:

Usage

Properties

Viewing

Scripts


A

A O

bjec

t Pr

oper

ties

and

Dec

isio

n Tr

ee

ASI

ASI

T

TSI

EXPI

RA

TIO

N

LIC

ENSE

D

PRO

FESS

ION

AL

CO

NTA

CTS

CO

ND

ITIO

NS

INSP

ECTI

ON

S

WO

RK

FLO

W

TASK

AC

TIVI

TIES

AD

DR

ESS

PAR

CEL

OW

NER

DO

CU

MEN

T

Usa

ge

Represents data to be captured on an application form.

Represents an inspection on a physical location.

Represents a task that is a part of a sequence of connected steps that represent the lifecycle of an application.

Represents data to be captured related to a task performed on the application.

Represents the expiration status and expiration date of a record (Licensing Solution only).

Represents a person or business associated with an application.

Usa

ge Represents a

person or business associated with an application.


A

A O

bjec

t Pr

oper

ties

and

Dec

isio

n Tr

ee

ASI

ASI

T

TSI

EXPI

RA

TIO

N

LIC

ENSE

D

PRO

FESS

ION

AL

CO

NTA

CTS

CO

ND

ITIO

NS

INSP

ECTI

ON

S

WO

RK

FLO

W

TASK

AC

TIVI

TIES

AD

DR

ESS

PAR

CEL

OW

NER

DO

CU

MEN

T

Represents a license or licensed professional created by or associated to an application.

Represents a requirement for approval of an application.

Represents a warning or flag of an application.

Represents a document.

Represents an action taken on an application (Phone call, email, etc.).

Prop

ertie

s

Can be assigned to users or departments. Has audit trail on transactional data. Has audit trail on reference data. Can have a comment. Can have a due date. Can be used in fee calculation. Can be considered as criteria for batch processing multiple applications.


A

A O

bjec

t Pr

oper

ties

and

Dec

isio

n Tr

ee

ASI

ASI

T

TSI

EXPI

RA

TIO

N

LIC

ENSE

D

PRO

FESS

ION

AL

CO

NTA

CTS

CO

ND

ITIO

NS

INSP

ECTI

ON

S

WO

RK

FLO

W

TASK

AC

TIVI

TIES

AD

DR

ESS

PAR

CEL

OW

NER

DO

CU

MEN

T

Can be captured from an external source. Can automatically be populated from GIS data. Can update the status of the entire application. Can have a single associated address. Can have multiple associated addresses. Can have activities. Can have conditions. Can have its own custom attributes (ASI). Can have its own custom attribute tables (ASIT).

View

ing

Searchable in the record portlet.

Available in the record list portlet.

Searchable in the Task/Inspection portlet.


A

A O

bjec

t Pr

oper

ties

and

Dec

isio

n Tr

ee

ASI

ASI

T

TSI

EXPI

RA

TIO

N

LIC

ENSE

D

PRO

FESS

ION

AL

CO

NTA

CTS

CO

ND

ITIO

NS

INSP

ECTI

ON

S

WO

RK

FLO

W

TASK

AC

TIVI

TIES

AD

DR

ESS

PAR

CEL

OW

NER

DO

CU

MEN

T

Available in the Task/Inspection list portlet.

Available for Record list quick queries.

Available in Global search.

Quick queries available on Transaction portlet.

Quick queries available on Reference portlet.

General security available access (access to portlet).

View

ing

General security available field (field/status level).

Scrip

ts

Data changes on transactional data will trigger event scripts.

Data changes on reference data will trigger event scripts.

Expression builder scripts are available on transactional data.

Expression builder scripts are available on reference data.


A

A O

bjec

t Pr

oper

ties

and

Dec

isio

n Tr

ee

ASI

ASI

T

TSI

EXPI

RA

TIO

N

LIC

ENSE

D

PRO

FESS

ION

AL

CO

NTA

CTS

CO

ND

ITIO

NS

INSP

ECTI

ON

S

WO

RK

FLO

W

TASK

AC

TIVI

TIES

AD

DR

ESS

PAR

CEL

OW

NER

DO

CU

MEN

T

Scrip

ts Expression

builder "on Populate" scripts are available (when a reference object is searched and selected).

Exhibit 5-7: Object Property

5.1.10 RECORD TYPE CONFIGURATION

Record Types should be organized in a hierarchy to allow users to properly select a Record.

Record Type names should be consistent across the hierarchy.

Record Type Alias should be used always; this is displayed via Custom Portal as well as AA.

5.1.11 ADDITIONAL DOCUMENT

For each record type GCOM team is developing a separate technical design document. This document will provide configuration details for each record type and how these are configured in Accela.

5.2 ACCELA CONSTRUCT API – CUSTOMER PORTAL

Accela Automation is a set of core solutions and templates for civic management, and contains configuration tools for customizing services and user interfaces. The Accela Platform provides ways for other solutions to leverage Automation services and configurations. Accela Construct allows developers to extend existing solutions and create new ones.

The Construct API enables developers to put data in and get it out of Automation through custom websites, web services, or mobile applications without having to rewrite the data model or business rules. The Construct API standardizes the methods developers interact with the Civic Platform while providing a layer of protection and security. To help developers build their applications, Accela provides Software Development Kits for popular mobile operating systems such as iOS, Android, .NET, Windows, PHP, node.js, and Ruby.


The goal of the AgCSS Customer Portal is to integrate effectively and seamlessly the Accela Automation (AA) Civic web service APIs and the AgCSS back office modules, through the development and implementation of a web-based Customer Self-Service Portal. The Customer Portal will become the point of entry into the AgCSS system for applying, buying, managing licenses, and reporting transactions.

The goals of the AgCSS Customer Portal are:

An Integrated Public Interface System that must effectively equip the application users to apply/buy licenses and permits, renew and obtain duplicates for online services offered by FDACS.

Provide a single page application to enhance the user experience.

Incorporation of real-time user transactions reports functionality.

The AgCSS Customer Portal will use a Service-Oriented Architecture (SOA) that will enable Enterprise Application Integration and reusability of service components across various enterprise applications.

For the AgCSS project, Customer Portal will be built using Accela Construct API, Java code base and Angular. On Customer Portal, the Construct API authenticates user identity using an OAuth2 process, which is used to generate API access tokens. The AgCSS system manages secure API traffic between the Construct API and Accela Automation through the Accela Gateway. The Gateway receives requests from Construct API calls and asynchronously sends the requests to AgCSS Automation instance. The Gateway sends Automation data back to Construct API via HTTPS, and back to the client in an HTTPS response body.

5.2.1 SOLUTION ARCHITECTURE

This section describes the overall solution architecture of AgCSS Customer Portal. AgCSS Customer Portal will be designed by following these design principles:

AgCSS Customer Portal solution will be based on Service-Oriented Architecture (SOA) principles. The solution will have a clear split between presentation, business process, service components, and data management, along with cross-cutting layers such as integration and security.

The AgCSS Customer Portal solution will enable a deployment approach with multiple iterative releases, thus reducing the risk significantly and allowing for deployment of fully-tested modules. The system will provide ability for incremental additions of functionality, replacement of components with improved versions, and the removal of unwanted/unnecessary features or components without rewriting the entire system.

The user interface part of the AgCSS Customer Portal will be user friendly and will expose functionality based on the logged-in user (Citizens/Tax Collector).


Interfaces between the AgCSS Customer Portal and Accela Systems will be based on industry standard Representational State Transfer (RESTful) web services specifications using token-based authentication.

The AgCSS Customer Portal system will be based on n-tier architecture, which will consist of a presentation tier, middle (business) tier, integration tier, and security tier. The overall solution will be implemented using a set of Java, HTML5, Angular, and Java MVC components.

FDACS

FDCAS Data Center

ReportService

PaymentService

AccelaBiz Servers

AccelaDatabase

Azure

AccelaPlatform APIRESTFul

Web Server(Jboss)

Citizens

Exhibit 5-8: Architecture

The communication between user browser and application will be secure (HTTPS) and encrypted using 256-bit encryption.

5.2.1.1 Presentation Tier

The presentation tier will be responsible for displaying web pages to the user. This tier will be implemented using the following technologies:

Technology Stack Version Description HTML 5 HTML web pages for

designing web application. Cascading Style Sheet (CSS) 3 Look-and-Feel stylesheet

framework. Bootstrap 3.3.1 Theme and cross-browser

compatible CSS framework.


Technology Stack Version Description Angular 5.x Angular is a structural

framework for dynamic web applications. It allows us to use HTML as the template language and we can extend HTML's syntax to express our application's components clearly and succinctly.

Exhibit 5-9: Presentation Tier

The presentation user interface will be Americans with Disabilities Act (ADA) compliant. The communication between the AgCSS Customer Portal user interface components and business components will be performed using Java Model View Controller (MVC) architecture. The AgCSS Customer Portal will support mobile device as responsive website and the following HTML5 compatible browsers on desktop

Browser Version Internet Explorer Latest Version Mozilla Firefox Latest Version Google Chrome Latest Version Microsoft Edge Latest version Safari Latest version

Exhibit 5-10: HTML5 Compatible Browsers

5.2.1.2 Middle Tier

The AgCSS Portal Components, collectively known as the middle tier, will consist of business components and be hosted on the JBOSS Application Server, running on Windows server. Each of the business modules will be separate deployable units, such as the *.war file.

Technology Stack

Version Description

Java 8 Multi-paradigm programming language encompassing strong typing, imperative, declarative, functional, generic, object-oriented (class-based),


and component-oriented programming disciplines.

Spring MVC 4.1.5 Spring MVC is a tool set for building the UI framework.

Exhibit 5-11: Middle Tier – Technology Stack

5.2.1.3 Data Tier

The AgCSS Portal application will use two data-management disciplines, which are set forth by Service-Oriented Architecture (SOA); namely, data modeling, and data mapping.

In the AgCSS Customer Portal, at a high level, data can originate from Accela Civic API outputs. For example, customer data comes from the Accela REST API, and it will have its own data model.

Target data is what the user will use and see. Data mapping will be used to convert each of these source data models to the target data. The AgCSS Customer Portal will design Domain Models and Data Transfer Objects to represent target data.

5.2.2 INTEGRATION

The AgCSS Customer Portal application, at a high level, interacts with the Accela Civic API server. The AgCSS Customer Portal Integration Layer provides the capability to mediate between these subsystems which include transformation, routing, protocol conversion to transport service requests from the service requester to the correct service provider, service virtualization, service messaging, message processing, and transformation.

The interface between AgCSS Customer Portal business components and Accela Civic API will be designed using RESTful web services, while the interface between AgCSS Customer Portal business components and HTML pages will be designed using Angular and Java code base.

5.2.3 SECURITY

The AgCSS Customer Portal system will address security along four dimensions:

Authentication – The service provider must be able to ascertain the identity of the service requester. AgCSS Customer Portal will integrate the OpenAM authentication module.

Authorization – The service provider must be able to determine whether the requester has the appropriate rights to invoke the service.


Message Confidentiality – Message contents must be visible only to the intended recipient.

Message Integrity – Messages must be guaranteed to not have been altered or tampered with in transport between the service consumer and the service provider.

5.2.4 APPLICATION STRUCTURE

This section describes the AgCSS Customer Portal application structure and dependency. At the bottom of the layer is the Operating System. The AgCSS Customer Portal application will be hosted on Windows 2012 R2 Server. The AgCSS Customer Portal Framework and Services will be built on Java code base.

Tech

nolo

gy E

nabl

er

Presentation Tier

Web Tier

Business Service Tier

Accela REST Client

Report Service

Customer Service License Service

Authentication Service

AGCSSCP Service

Controllers

CSS3 AngularJs/JavaScript/JQuery

JSON Objects

Common Classes

Fram

ewor

k Se

rvice

s

Security(Authorization &Authentication Configuration)

Cache

Exception Handler

Exception Reporter

Logging

Application Platform

Microsoft Windows 2012

JBOSS

AGCSSCPDomainModel

AGCSSCPData Transfer

Objects

AGCSSCP Rules

Exhibit 5-12: Customer Portal Application Structure

5.2.5 FRAMEWORK SERVICES

The infrastructure services are cross-cutting services which are responsible for implementing services across all tiers. The following infrastructure services will be implemented by AgCSS Customer Portal.


5.2.6 SECURITY

Is Un-protected

Page?

Is User Authentica

ted

Is User Authorized

?

Access a Page

YesSecurity Framework allow the serving of the page

NoSecurity Framework auto redirects to login page

YesUser already authenticated

YesUser is authorized

Security Framework allow the serving of the page

NoUser is not authorized

Security Framework auto redirect to error page

NoProtected page

Security Framework auto check authentication

Requested Page

Access Denied Page

Login Page

Failed AttemptConfigurable re-try limitRememberMe Service

Success

Exhibit 5-13: Customer Portal Application Structure

The AgCSS Customer Portal application will be configured in such a way that all the HTTP requests will flow through user authentication and authorization to the requested resource. The above diagram conceptually depicts the security flow of the AgCSS Custom Portal application.

5.2.7 CACHE

The AgCSS Customer Portal application will use cache subsystem to improve application performance. The typical data that will be cached is static web pages and resources, relatively-static data, such as License type and names, etc.

5.2.8 EXCEPTION HANDLER

The AgCSS Customer Portal exception handling classes will be responsible for handling exceptions that may occur in the application. The AgCSS Customer Portal exception handler framework will implement checked and unchecked exception classes. These handlers will extend Java-controller capabilities to handle exceptions in a graceful manner.

5.2.9 EXCEPTION REPORTER

The Exception Reporter service will be responsible for reporting exception information to the user via email or by writing the information to a log file.


5.2.10 LOGGING

The AgCSS Customer Portal modules will use Simple Logging Facade for Java to log the application information for debugging and tracing purposes. The development and test environment’s log level will be set to "DEBUG" for stage, and the production environment log level will be set to "ERROR."

5.2.11 VALIDATION

The Validation service will be implemented either in Java/Angular front-end or back-end validation using Accela EMSE script. The front-end validation (client side) are done using Java/Angular code and backend (server side) validation are done using Accela EMSE script. The AgCSS Customer Portal will use common utility classes to perform common validations such as null check, email address, etc. If custom validations need to be implemented, then those will be part of the AgCSS Customer Portal validation service.

5.2.12 PRESENTATION

The AgCSS Customer Portal Presentation layer has HTML5 web pages, CSS3, Spring MVC and Angular. These pages will be designed to enhance user experience by having a single page web application design and extensive use of XHR (XML over HTTP Request).

5.2.13 WEB API CONTROLLER

The AgCSS Customer Portal Controller layer will be designed as Java classes implementing business data validation and passing the request to the service layer. The WebAPI service will be implemented in complete RESTful manner with the HTTP request-and-response model. There will be individual controllers for each module; these controllers will be called from the client framework (Angular) through XHR calls.

Web API Controllers are the REST API services written to handle Single-Page Application (SPA) requests for data over HTTP. The data can be anything the SPA client needs from or posted to the system.

5.2.14 AGCSS CUSTOMER PORTAL SERVICE

The AgCSS Customer Portal Service is a coarse-grained Java class, which will orchestrate calls between the Accela REST client layer to accomplish business processes.

5.2.15 ACCELA SERVICE CLIENT

The Accela Service Client will convert AgCSS Customer Portal domain-model classes into Accela Civic API JSON Objects, and interface with the Accela REST API using RESTful web services. The Accela Service Client is responsible for getting, refreshing and passing the Accela REST API security token. These services will be fine-grained (smaller components) used in the business service.


5.3 MOBILE APP FOR INSPECTORS

The Accela Mobile Applications, Accela Mobile Inspector and Accela Code Officer, will be installed in the FDACS Inspectors’ hand-held devices. These applications will be used by Inspectors to perform their daily inspection-related tasks in the field. The mobile applications are designed to allow Inspectors to perform their regular activities end to end.

Accela Mobile Inspector: This mobile application provides inspectors with functionality designed to perform an onsite inspection or investigation, using their smartphone or tablet. Integrated with Accela Automation, Accela Mobile Inspector connects mobile workers to their back-office accounts, enabling them to work from their desk, vehicle, or on-site, using their preferred device. Users can perform a complete onsite process–from initial inspection to submittal–and can also view and update their inspection details including checklists, attachments and comments.

Accela Code Officer: This mobile application allows Inspectors to do their jobs more efficiently while

working in the field with their smartphone or tablet. Integrated with Accela Automation, Accela Code Officer enables Inspectors to view locations of cases on a map containing agency-defined map layers, perform sweeps, and trace the paths on the map, create cases right from the app, view assigned cases, search for cases and inspections and add them to a list, and save searches for easy access. The inspector can create a new record for Line of Sight which cannot be accomplished by Accela Mobile Inspector.

Both Applications are part of the Accela Mobile Applications solution which will be adapted by FDCAS Inspectors on site.

Accela Mobile Inspector Features: Inspectors can check their scheduled inspections, route, and perform inspections using checklists in Accela Mobile Inspector.

Below are some, but not all, of the features and capabilities included in Accela Mobile Inspector.


The features of Accela Mobile Inspector such as GIS, Longitude, Latitude, Contact, Owner, and Initiate Communication are available in the Inspector Apps.

The system is configurable to allow multiple comments. The inspector will have access to add or remove the comments.

The Inspector can access multiple checklists through a hand-held device. Currently, Accela Mobile Inspector is limited to two signatures. The system is configured to send reports automatically to the owner. The tracking of mileage (e.g., by trips) is done by the system.

The Inspector or Supervisor has authority to make changes in the system. The system will track the records of the last changes made by the person.

The system will allow performing re-inspection. The system automatically loads the documents, checklists, and all the information related to inspection.

If the Inspector has no access to internet connection, he / she can perform inspection by downloading the relevant documents before going to the inspection site.

The inspection status can be marked as “No Access” in the absence of the owner with many available statuses configured in the system. The system will not allow the Inspector to cancel the inspection without Supervisor approval. Records will be updated in Accela Automation (back office) only when the Inspector submits or completes inspection by clicking the Submit button. Until then, the information is stored locally on his / her mobile device.

The system will allow scanning of a barcode or QR code to generate the Record ID.

Non-fee accounts can be recorded by providing a checkbox in Accela. Once checked or unchecked, corresponding business rules can be applied.

Searching for a record is easier in Accela (e.g., search can be done by Record ID, date, address, etc.).

Layers can be configured on GIS and exposed to Accela Mobile Inspector. To visually represent which checklists have been done, which ones are partial, or which checklist is attached to which item, a report can be pulled from the system. Accela Mobile Inspector is generic and can be configured to work with different business rules. An Inspector performs re-inspection only for the items which are not approved during the initial inspection. Inspectors can refer the inspection to another Unit if they feel it properly belongs there.

Accela Code Officer Features: Below are some of the features and capabilities included in the Accela Code Officer application.


New records can be added to Accela Mobile Inspector by using Accela Code Officer. This will be applicable for Line of Sight / ad hoc inspections when Inspectors are in the field to conduct their scheduled inspections.

If there is any specific additional field required for validation of a record, it can be customized by using the Accela Code Officer application.

Reference data can be updated in the Accela Code Officer application, but not in Accela Mobile Inspector. Accela Mobile Inspector is only related to performing inspections. Creation or updates to records is done in Accela Code Officer and then the records are automatically updated in Accela Mobile Inspector.

Additional information will be found at https://accela.com/civic-apps

5.4 COMMON DESIGN ARCHITECTURE

The objective of Common Design Architecture is to identify, and describe at a high level, the integration and interface components being designed, developed, tested, and implemented. The interface design specifications will be documented for each integration and interface in more detail in the DEL16 - Interface Specification Design Document. This document will include details such as request and response messages for each interface, security, communication protocols, and error handling.

5.4.1 OVERVIEW

This section outlines the approach that will be used to complete the design, development, testing, and deployment for the identified interfaces. The deliverable, DEL 34 - Interface Design Specifications, will contain the mapping, transformation details, and the interface architecture. It will further define the respective roles of each party and the key dates for completing milestones. During the design process, new information may necessitate a change in the method or another design consideration not originally identified in this document.

The following is a list of guiding principles considered during the interface design, development, testing, and deployment phases.

Adaptability: Interface Methods will use an underlying framework that allows for the easy implementation of additional interfaces of the same type by creating and utilizing a common framework.

Flexibility: Interfaces will be built in such a way that they can be easily modified in response to any change or expansion in future phases.

Standards: Custom code for interfaces can be written in any language, such as .NET or Java. Industry best practices and standards will be followed to write the custom code for interfaces.

https://accela.com/civic-apps


Supportability: Interface Methods will utilize notifications, error handling, and logging to provide a base for the identification of and troubleshooting of issues.

Security: Interfaces will be built following FDACS security standards.

5.4.1.1 Integration vs Interface

The term, “integration” means that systems will interact with the AgCSS system through configuration of the Accela products and not by transferring data as the primary activity, such as Payment Gateway, Address Validation, etc.

The term, “interface” refers to data transfers between multiple systems that send to, or receive data from, the AgCSS system such as data transfer between Accela to Rev system

The interface can be inbound or outbound interface. The terms “inbound” and “outbound” describe the direction of data flows in relation to the AgCSS system. Inbound data flows are data that return to an Accela component (BOA settlement file), while outbound data flows are those being sent from an Accela component (Rev data file). Below section provides detail design pattern will be used for all AgCSS interfaces.

5.4.2 BATCH/DATABASE INTERFACE

All the interfaces where data is exchanged between AgCSS and other systems will be performed through SQL databases, XML files, or flat files. These are represented as Batch/Database interfaces in the figure below. A SQL view or table will be provided for all the inbound data exchanges to FDACS.

The exchange frequency will depend on the business requirements for each system. If the data needs to be exchanged for specific intervals, such as Daily, Weekly, or Bi-weekly, batch jobs will be created in Accela to trigger these jobs on the specified schedule. For all the outbound data from AgCSS, data will be generated in the required format and provided to the systems.

All connection-related information will be stored in the configuration files. By doing this, the behavior or the connection information can be updated without making any changes to the script.


5.4.2.1 Inbound

Common Data hub

Flat files/XML files

Database systems

DB 1

DB 2

System 1

System 2

AGCSS

Folder Structure

Accela Database(EMSE/SQL)

Staging Database Custom

mapping process

1

2

3

4

5 6

Error loggingError

analysis & resolution

7

8

Note: Any additional systems identified during requirement sessions will be added as it progresses.

Potential new interfaces will be added once discussed and confirmed. List of systems shown in 'Database systems' and 'Flat files/XML' is representative only.

The master interfaces list is in DEL12-Interface Development Inventory

FDCAS Server’s (only for external

interfaces)

9

DB n-1

DB n

System n-1

System n

Exhibit 5-14: Database Interface Flow for Inbound Data

The numbered items in the above Exhibit 5-13 represent the following:

1. Interface systems that exchange data with AgCSS through a database. 2. Interface systems that exchange data with AgCSS through flat files/XML files. 3. For existing external agency transfers, flat files or XML files will be loaded via Secure

File Transport Transfer Protocol (SFTP) to existing servers that FDACS configured before being loaded to the Common Data Hub. Database Systems are loaded directly into the Common Data Hub. For new external interfaces, details will be discussed with FDACS during the design phase. Based on the outcome of the sessions, interfaces will be categorized into database systems, flat files, or XML files. For internal interfaces, data/files will be imported to the Common Data Hub.

4. The Common Data Hub where all the data from databases, flat files, or XML files will be loaded.

a. Data from the databases will be loaded into a schema through Extract, Transform, and Load (ETL) into the Common Data Hub. Depending on the need, if an interface requires obtaining the data from the AgCSS system, a database view will be created. If the interface needs to exchange data on a


specific schedule, a batch job will be created to generate data on the specified schedule.

b. All the flat files or XML data will be copied to a folder structure. A folder structure will be created by Interface name, and the inbound and outbound data exchange files will be copied to the respective folders. The complete folder structure for each interface will be explained in the DEL16-Interface Specification Design document.

5. All the data loaded into the Common Data Hub will be mapped to the Accela database using a custom mapping process. The system will use PL/SQL to do the mapping.

6. Accela Database: All interface systems data will be mapped and loaded to the Accela database. The Event Manager Scripting Engine (EMSE) scripting or custom code will be used, if required, to process both inbound and outbound data.

7. AgCSS System: Information is updated and made available to the AgCSS system. 8. Error Logging: If a data load fails at Step 3, or if any data cannot be mapped correctly,

proper error-handling processes will be implemented to log the error message. 9. Error Analysis/Resolution: Error logs from Step 8 will be analyzed and proper resolution

steps will be taken. When the scripts are re-run to process the unprocessed data, proper validation will be done to ensure duplicate data is not generated. Email notifications about the unprocessed data can be sent to the system technical owners, if needed.


5.4.2.2 Outbound

Accela Database(EMSE/SQL)

Custom mapping process

Common Data hub

Folder Structure

StagingDatabase

2

FDCAS Server’s (only for external

interfaces)

Database systems

Flat files/XML files

Error loggingError

analysis & resolution

54

7

1

3

86

Note: Any additional systems identified during requirement sessions will be added as it progresses.

Potential new interfaces will be added once discussed and confirmed. List of systems shown in 'Database systems' and 'Flat files/XML' is representative only.

The master interfaces list is in DEL12-Interface Development Inventory

DB 1

DB 2

DB n-1

DB n

System 1

System 2

System n-1

System n

Exhibit 5-15: Database Interface Flow for Outbound Data


1. Accela Database: All the data needed for the external systems will be extracted from the Accela database. If required, EMSE scripting or custom code will be used to process the outbound data.

2. All the data from the Accela database will be mapped to the external system format using a custom mapping process. The system will use PL/SQL to do the mapping.

3. After the data is mapped to the required format by the interface systems, data files will be loaded to the Common Data Hub.

4. From the Common Data Hub, flat files or XML files will be loaded to the AgCSS servers for external interface systems to pick up. Database systems are loaded directly. For internal interfaces, either a database link or a database view will be provided.

5. Interface systems that exchange data with AgCSS through a database. 6. Interface systems that exchange data with AgCSS through flat files or XML files.


7. Error logging: If the external system cannot process the files or data, it can send an email or place the error log file in the external servers for FDACS/GCOM to review.

8. Error Analysis/Resolution: Error logs from Step 7 will be analyzed and proper resolution steps will be taken.

5.4.2.3 Batch Job

A batch job is a set of programs processed in batch mode. This means that a sequence of commands for the operating system to execute is listed in a file known as a batch file, and is submitted for execution as a single unit. Batch jobs can be automated to run on a specific schedule, depending on the need. The Job Scheduler acts as an application that manages your unattended executions in the background, which is commonly called “batch processing.”

Common Data Hub Batch Jobs: Windows services or SQL batch jobs will be utilized in the Common Data Hub to load the files based on either external or internal interfaces.

Accela Batch Jobs: Accela batch jobs will load data to/from the Common Data hub or Accela database. EMSE scripts will be used, if required, for any configuration or processing. SQL Scheduler can be used to schedule job execution based on time/events to monitor, execute, and manage jobs.

5.4.3 WEB SERVICE INTERFACE

Accela will communicate with third-party web services either through an EMSE script or by utilizing the Accela Web Services. The type of interface will determine whether communication will occur through EMSE or Accela Web Services.

For example, if an interface is simple and does not require any data manipulation or transaction, an EMSE script can be utilized. Accela web services are used for complex interfaces where data needs to be converted intermediately so other systems can quickly consume and understand it, such as the OnBase interface.

5.4.3.1 Accela Web Services

Accela Web Services can be utilized to access or interact with the Accela database model. Web services can be consumed by any third-party system to perform a variety of tasks. For example, to communicate with OnBase Document Management for document management tasks, a custom adapter is written and configured in Accela.

Anytime a request is made for a document, a call will be made to the custom adapter service through Accela Web Services. The custom adapter will read the Accela web service request and translate the call so that the OnBase service understands. After the request is processed by OnBase, the custom adapter service will translate it again so that Accela Web Services will understand.


5.4.3.2 Accela EMSE Script

Accela launches Accela EMSE scripts when the events that are associated with the script occur. A script is used to communicate with the third-party web services. This is mostly used when there is a need for simple validation.

For example, to validate addresses from the Melissa data service, a call to the Melissa data service can be made using an EMSE script just to validate whether the address is valid. Based on the result, the user can be further directed, depending on the business rules.

EMSE

Interface Server (web service / Flat

files)

External Services (USPS/Melissa

Service)

Send Response

Error Messages

Accela AA

Accela Web Services

ValidateYes

No

1

2

3

4

5 6 7

Exhibit 5-16: Web Service Interface Flow


1. From the AgCSS application screen, once the user clicks the Validate / Submit button, the request goes to the interface server. Accela Web Services interact with the Biz Server to obtain the database objects.


2. EMSE: Accela’s Event Manager Script Engine integrates with Accela Automation through a custom API. EMSE scripts can be used to call the web services hosted on the Interface Server for validating data.

3. The Interface Server interprets the request and translates the Accela request to a web service definition that the external web service can understand. Communication between Accela Web Services and Interface Server happens with the configuration of Accela Automation, as well as Interface Server configuration files.

4. This represents external systems such as USPS or Melissa Data Service, which has web services to validate data.

5. Validates the request based on the request parameters. 6. Sends the response back to the Interface Server, which translates the response and

sends the data returned by the external system service to be displayed on the Accela Portal. If it is a valid response, based on the requirements, the data is updated or a workflow will be processed to the next step.

7. Error Handling: For all invalid responses, an error message will be logged and, based on the requirements, the system will send the appropriate message to be displayed on the Accela Portal. If needed, the system can be configured to send a notification to the appropriate parties.

5.4.3.3 Security

For all the web service interfaces, communication will be over the HTTPS protocol. The connection details to different external sources can be configured in the Interface Server using a custom Java code (*.config file). Service accounts need to be created for authentication. Service account credentials are stored in a secure configuration file. For example, in OnBase, one service account will be used for authentication and authorization will occur in Accela.

5.4.3.4 Error Handling

Throughout the interface design, sophisticated error-handling features for dealing with exceptions will be provided. Based on the types of errors, such as semantic errors or process execution level errors, appropriate features will be implemented, as follows:

Logging errors will be logged wherever possible with error descriptions. Custom exception handling scripts will be provided that can be used at runtime to give

a new, distinct meaning to one or more problems that can occur within the code. Automatic email notifications will be sent, if any step in the process fails, with a

description of the root cause of the exceptions. Errors will be routed and displayed in a web form for the end-user to correct and

resubmit the data.

https://adeptia.com/designing-workflows-adeptia-integration-suite


5.4.3.5 Technology Stack

The AgCSS interface components will be hosted on the JBOSS Application Server, running on Windows server. Each of the business modules will be separate deployable units, such as the *.war file.

Technology Stack

Version Description

Java 8 Multi-paradigm programming language encompassing strong typing, imperative, declarative, functional, generic, object-oriented (class-based), and component-oriented programming disciplines.

Spring MVC 4.1.5 Spring MVC is a tool set for building the UI framework.

Exhibit 5-17: Technology Stack

5.5 CALL CENTER INTEGRATION OVERVIEW

PureConnect/Accela Integration Architecture

The current Genesys Voice Platform (GVP) solution includes an AudioCodes SBC, which allows the GVP platform to integrate with the existing Unify PBX through SIP trunks. Calls that need to be routed to agents are then handled by the Unify PBX.

The new design will include removal of the GVP and AudioCodes SBC from the IVR call flow. The PureConnect platform will integrate directly to the Unify PBX through SIP trunks, which allows the existing public-switched telephone network (PSTN) trunks to be utilized for PureConnect, as well as calls to be transferred between the PureConnect and Unify systems. The SIP integration will also allow the PureConnect platform to participate in the current four-digit dial plan. The self-service functionality currently residing in the GVP system pertaining to the Division of Licensing will be migrated into the PureConnect platform. Calls that need to be routed to an agent will route through the PureConnect platform.


PureConnect will integrate to Accela via HTTPS RESTful web services to obtain and pass caller and chat data for the purpose of screen pops, Accela updates and IVR services. PureConnect will expose an HTTPS RESTful web service to allow Accela to initiate calls, texts, etc.

Exhibit 5-18: PureConnect / Unify / Accela Integration

5.6 ONBASE INTEGRATION OVERVIEW

The AgCSS Solution will integrate the Accela Civic Platform with brand new OnBase Enterprise Document Management System (EDMS). This provides the department with the ability to manage documents with Accela AgCSS while leveraging the enterprise document


management system infrastructure created for AgCSS implementation. What this means is that documents will be stored in the OnBase EDMS database, but accessible by FDACS Workers in the Accela Worker Portal and by external customers in the AgCSS Customer Portal.

AgCSS will have two types of integration with OnBase.

From Accela to OnBase: Agency users or External users upload document from Accela automation or Customer portal. This functionality will be implemented using Accela EDMS adapter code base.

From OnBase to Accela: All intake document will be scan in OnBase and interface will be created to map those documents to Accela record type.

5.6.1 FROM ACCELA TO ONBASE

The Accela Platform EDMS SDK package contains the scripts to assist developers to integrate Accela with a third-party EDMS system for document management through the EDMS. The EDMS adapter will support AgCSS requirements for document management actions performed through the Accela UI. Accela Automation does not store any information about Documents internally other than metadata to keep the link between Accela records and OnBase documents such as Document ID, Document type, etc.

It always queries the EDMS Server through the EDMS Adapter to get lists of documents. Documents can be loaded into the EDMS Server through Accela Automation or through Customer Portal. OnBase is the enterprise solution for AgCSS document management. AgCSS is configured to integrate with a single document management instance of OnBase.

The one instance would store documents for all divisions/program (part of Release 1, 2 and 3 implementation) that are uploaded through Accela Automation or Customer Portal. The integration of AgCSS to the single document management instance would be achieved with the Accela EDMS OnBase adapter.

An EDMS adapter will be developed as a Java codebase which will be used in conjunction with out of the box OnBase web services provided by OnBase to manage OnBase document repository.

The documents associated with Accela Automation entities (record, inspection) are stored in OnBase document repository.

Each document in the repository is configured with metadata that include the fields that associate the document to an Accela Automation record.

Please refer to figure below for the flow of communication from end to end.


Exhibit 5-19: EDMS Communication Flow

Exhibit 5-20: EDMS Translation Flow

Note: Please refer to the AgCSS_R1_DEL16 - Interface Specification Design Document – EDMS Adapter document for interface design details. This document will be delivered as part of Sprint 9 deliverables.

5.6.2 FROM ONBASE TO ACCELA

The below section describes mail Intake process from receiving until association with Accela record type.


Exhibit 5-21: Intake Process Flow

1. The system will have two different batch types for the scanning: One for document with a remittance and other for non-remittance documents. Batch preparation will open envelope and scans documents with a remittance and they set non-remittance documents in one of the hold bins for scanning into a different batch type.

2. OPEX machine will be set to batch remittances to any quantity (25 or 50 preferably). 3. Operator scans transactions with checks together into virtual batches. 4. OPEX process will process barcodes and assign basic Form Types and metadata

where available. Metadata such as Tracking Number, Form type etc. 5. OPEX process will assign a batch # and transaction # to each document in a batch. 6. Checks will be physically imprinted with batch # and transaction # for searching and

verification. 7. After the batch is complete users will rubber band the checks for each batch and put a

batch ID on them until they are ready for deposit. 8. Fingerprint transmission to FDLE will be done as per the current process. 9. Workflow will perform Doc Type adjustments based on Accela to OnBase data

structure. 10. Workflow will add Forms needing recognition to a Scan queue for Brainware

processing.


11. Workflow will hold related documents to have keyword updates based on return values from Brainware to OnBase.

12. OnBase will provide XML file to export data into Accela including document handle to keep document link between Accela to OnBase.

13. Using daily Batch process, Accela will create Deposit Record per batch (all payment) and Application records as per business rules. Both record will follow required (based on requirements) workflow process inside Accela.

Note: Daily batch process to create Accela record using OnBase XML file will be elaborated more detail in ‘AgCSS_R1_DEL16 - Interface Specification Design Document – OnBase Integration.’

5.7 GCOM CORRESPONDENCE MANAGEMENT (GCM)

The GCOM Correspondence Management (GCM) functionality allows end users to create new correspondence from the correspondence template library. Workflow processes triggered from the Accela Automation can be configured to select a specific template based on business rules. Using GCM the user can use out-of-box features of the GCM to create correspondence template(s), view the draft correspondence, make edits to the template content, and then finalize the correspondence. The interface will trigger Accela Automation communication and document management services to 1) issue the correspondence to the internal or external customer via email or physical fulfillment process and 2) store/link the final copy of the documents in the OnBase EDMS and the Accela transaction record in PDF or HTML format.

GCM will have two types of interfaces with Accela.

Use Case 1 – User-Generated correspondence

› User will have ability to view and edit correspondence before store/link the final copy of the documents in the OnBase EDMS (ex: EO Letter).

Use Case 2 – Batch Process

› Correspondence using Accela Batch process (ex: Renewal Notice).


5.7.1 USE CASE 1 – USER-GENERATED CORRESPONDENCE

Exhibit 5-22: GCM Process Flow – User Generated Correspondence Step 1 - Accela User requests a letter by sending required parameters (TemplateID,

UniqueID, regenerateFlag and EDMS Flag) as a request parameter to AgCSS GCM Web Module URL.

Step 2 - AgCSS Web Module will invoke AgCSS WebService and WebService in turn will send these parameters to Accela/GCM Interface.

Step 3 - Accela/GCM Interface accesses GCM DB to retrieve template-specific SQL. Each template will have corresponding SQL to get the data-for-data mapping with GCM template. This step is executed only if regenerateFlag = ‘Y’.

Step 4 - GCM Interface will invokes construct API to execute those SQL to get the result back from Accela Database. This step is executed only if regenerateFlag = ‘Y’.


Step 5 - Accela sends back requested information. This step is executed only if regenerateFlag = ‘Y’.

Step 6 - Accela/GCM Interface then consolidates this information as a Map and sends it back to AgCSS GCM Module. This step is executed only if regenerateFlag = ‘Y’.

Step 7 - AgCSS GCM Module then invokes GCM WebService with this Map and requests a letter generation. This step is executed only if regenerateFlag = ‘Y’.

Step 8 – If regenerateFlag = ‘Y’.

› GCM Module retrieves HTML Template, replaces all required formation from the map and sends back generated HTML correspondence which is rendered in AgCSS GCM UI.

› If regenerateFlag = ‘N’. › GCM Module retrieves previously saved correspondence and rendered in AgCSS

GCM UI. Step 9 - User reviews and updates the generated letter as necessary and saves the

final letter to GCM DB.

Step 10 - GCM sends PDF byte array of final correspondence back to AgCSS which is then stored in OnBase.

Step 11 - User may print this correspondence in AgCSS GCM UI or correspondence might be sent to Printing from OnBase as batch process.


5.7.2 USE CASE 2 – BATCH PROCESS

Exhibit 5-23: GCM Process Flow – Batch Printing Step 1 - Accela Batch Service triggers a letter generation by invoking AgCSS

WebService.

Step 2 - AgCSS Web Module will invoke appropriate Controller and that Controller in turn will send these parameters to Accela/GCM Interface.

Step 3 - Accela/GCM Interface accesses GCM DB to retrieve template specific SQL. Each template will have corresponding SQL to get the data for data mapping with GCM template.

Step 4 - GCM Interface will invokes construct API to execute those SQL to get the result back from the Accela Database.

Step 5 - Accela sends back requested information.


Step 6 - Accela/GCM Interface then consolidates this information as a Map and sends it back to AgCSS GCM Module.

Step 7 - AgCSS GCM Module then invokes GCM WebService with this Map and requests a letter generation.

Step 8 - GCM Module retrieves HTML Template, replaces all required formation from the map and sends back generated HTML Template as well PDF Byte back to Batch Service.

Step 9 - Batch Service then stores the generated letter in PDF format in OnBase.

Step 10 - Batch Service may trigger printing of these generated letters.

5.7.2.1 Component Details:

The primary job of this interface is to offer a service which will take Template ID and Record ID as an input, gather template-related information and respond with Data Map. This interface will have access to both Accela Data as well as GCM Components.

Input Parameters Usage:

1. Template ID: This will be used to retrieve SQLs from Database for that template. These SQLs will then be executed on Accela Environment for the given Record ID to retrieve information. For Example, for E&O Letter, SQL will retrieve all corresponding data such as error code selected for E&O Letter, Application name, address, etc.

2. Record ID: This is the unique identifier of the record for which letter needs to be generated. This ID will be used along with the SQLs retrieved in Step 1 to fetch correspondence information from Accela using construct APIs.

3. RegenerateFlag: This is the identifier that will be used to decide if a letter needs to generate again or use previously saved letter. For example, during application approval process, Reviewer will generate letter and Supervisor will approve generated letter. In such case during reviewer process flag will send as ‘Y’ to GCM to generate letter and during supervisor review process flag will send as ‘N’ to retrieve letter which was previously generated by reviewer.

4. EDMSFlag: This is flag values (‘Y’ or ‘N’) will indicate when to save correspondence in OnBase. Only final copy of correspondence (before actual printing) will be saved in OnBase. Before finalizing correspondence user will have ability to regenerate letter or modify.

There ER Diagram below explains three tables that will be used for this configuration.


Exhibit 5-24: GCM ER Diagram

5.8 ADDITIONAL INTERFACE INVENTORY

Please refer to Appendix B: Interface List.


SECTION 6 USER INTERFACE CONTROL

6.1 PORTAL SCREEN FLOW COMPONENT

Exhibit 6-1: Login and Create Account Screen Flow

The numbered items in the above Exhibit represent the following:

1. From login screen, once the user clicks Create account, the create account page will open.

2. The user will then need to fill in the required fields to continue. If the user doesn’t enter the required fields, then system will show error screen.

3. After the user fills in all the required fields and clicks on create account button, then the account will be created and the user will navigate to the login screen.


6.1.1 DASHBOARD WITH DETAIL CARDS

Exhibit 6-2: Dashboard with Detail Cards The numbered items in the above Exhibit represent the following:

1. After login, the user will then navigate to the dashboard, on the dashboard the user can view Alerts, Applications, and Licenses.

2. Under Alerts section the user can see alerts on related previous owned licenses. 3. Under Applications section, user can continue working on applications and fix error on

applications. 4. Under Licenses section, the user can view details on existing licenses by clicking on

view detail card button.


6.1.2 CW LICENSE APPLICATION - QUALIFICATION

Exhibit 6-3: CW License Application - Qualification


1. To create CW License Application - After answering qualification questions on page 1, the user will continue to more Qualification questions related to Law Enforcement, Privacy, Citizenship, Criminal History, and Training. After clicking continue button, the user will be navigated to Application page.

2. On application page, the user will input Applicant information, provide supporting documents, and could also find information on fingerprints.

3. By Clicking Applicant Information, the user can fill user personal information, Residence address, and Billing address.


6.1.3 CW LICENSE APPLICATION - APPLICATION

Exhibit 6-4: CW License Application - Application


1. By Clicking start button on Applicant Information section, the user can fill user Personal information, Residence address, and Mailing address. After the user inputs the information the user could save the information by clicking save button. This information will be saved under Applicant Information section.

2. The user could provide supporting documents by clicking start button under supporting documents section. The user needs to select documents, until the user selects type of document the add file button will be grayed out. After uploading the documents, the user can view them under supporting documents section.

3. Under fingerprint section, the user could find information about scheduling an appointment with local specialist for fingerprint scanning.

4. By clicking Continue, the user will be displayed summary of the information.


6.1.4 CW LICENSE APPLICATION - APPLICATION

Exhibit 6-5: CW License Application - Application Summary


1. On this screen, user could review the information and could edit information by clicking edit button. After clicking the Continue button, the user navigates to the Oath of Applicant page.

2. The user needs to input name and time to continue to payment.


6.1.5 CW LICENSE APPLICATION - PAYMENT

Exhibit 6-6: CW License Application Payment


1. After the user confirms applicant by name and date, then the user is navigated to Payment summary page. On this page, the user could review the quantity and license fee. By clicking Add to Shipping cart, the user will navigate to the Shopping Cart page.

2. The user could remove the items from the cart or Pay by clicking pay button. When the user clicks pay button, the user will then navigate to payment gateway.

3. By clicking Add another license, the user will navigate to the AgCSS home page or licensing page.

4. After user completes payment process on payment gateway, the user will then be navigated to the confirmation screen.


6.1.6 493 CLASS D - QUALIFICATION

Exhibit 6-7: 493 Class D - Qualification The numbered items in the above Exhibit represent the following:

1. To create 493 Class D - After answering qualification questions on page 1, the user will continue to more Qualification questions related to Military history, Criminal history, Alias information, Personal history, and Training and experience, Privacy, and Citizenship. After clicking continue, the user will then be navigated to Application Applicant information page.

2. On application page, the user will input Applicant information, provide supporting documents, and could also find information on fingerprints.

3. By clicking Applicant Information, the user can fill user personal information, Residence address, and Mailing address.


6.1.7 493 CLASS D - APPLICATION

Exhibit 6-8: 493 Class D - Application


1. By clicking start button on Applicant Information section, the user can fill user Personal information, Residence address, and Billing address. After the user inputs the information the user could save the information by clicking save button. This information will be saved under Applicant Information section.

2. The user could provide supporting documents by clicking start button under supporting documents section. The user needs to select documents, until the user selects type of document the add file button will be grayed out. After uploading the documents, the user can view them under supporting documents section.

3. Under fingerprint section, the user could find information about scheduling an appointment with local specialist for fingerprint scanning.

4. By clicking Continue, the user will be displayed summary of the information.


6.1.8 493 CLASS D - COMPLETE APPLICATIONS

Exhibit 6-9: 493 Class D - Application


1. On this screen, user could review the information and could edit information by clicking edit button. After clicking Continue button, the user will navigate to the Oath of applicant page.

2. The user needs to input name and time to continue to payment.


6.1.9 493 CLASS D - PAYMENT

Exhibit 6-10: 493 Class D - Payment


1. After the user confirms applicant by name and date, then the user is navigated to Payment summary page. On this page, the user could review the quantity and license fee. By clicking Add to Shipping cart, the user will then navigate to shopping cart page.

2. The user could remove the items from the cart or Pay by clicking Pay button. When the user clicks pay button, the user will then navigate to payment gateway.

3. By clicking Add another license, the user will navigate to goes AgCSS home page or licensing page.

4. After user completes payment process on payment gateway, then user will then be navigated to confirmation screen


6.2 AA SCREEN FLOW COMPONENT

6.2.1 LOGIN

Exhibit 6-11: FDACS Accela Automation Login Page


6.2.2 LAUNCHPAD

Exhibit 6-12: Launchpad

Exhibit 6-13: Sign Out Link


6.2.3 NEW APPLICATIONS

Exhibit 6-14: Record Portlet New Button

Exhibit 6-15: Record Type Select


Exhibit 6-16: Class D Security Officer Applicant Information

Exhibit 6-17: Class D Security Officer Applicant Address Information

Exhibit 6-18: Contact Address Information


Exhibit 6-19: Class D Security Officer Application Specific Information 1




Exhibit 6-22: Class D Security Officer Document Section

Exhibit 6-23: Class D Security Officer Submission Confirmation


Exhibit 6-24: Class D Security Officer Summary Screen

Exhibit 6-25: Workflow


Exhibit 6-26: Work Flow Task Detail





Please refer to the AgCSS Online Intake Screen Flow document. This document will be provided as part of SDD deliverable.

Please refer to the AgCSS Accela Screen Flow document. This document will be provided as part of SDD deliverable.


6.3 ONBASE SCREEN FLOW COMPONENT

This document will be updated and re-reviewed after OnBase development has been completed. Please refer to the AgCSS OnBase Screen Flow document for out-of-box screen flow, which will be updated once the OnBase development has completed.

Genesys PureConnect Screen Flow Component

This document will be updated and re-reviewed after Genesys development has been completed. Please refer to the AgCSS Genesys Screen Flow document for out-of-box screen flow, which will be updated once the Genesys development has completed.


SECTION 7 DATABASE

7.1 DATA STRUCTURAL TOOLS

There is no need to create database design for Accela. Accela Automation system administrator tool will be used to configure Accela objects, which will internally update Accela database structure.

7.2 DATA DICTIONARY

Please refer to the Accela Data Dictionary of Common Accela Automation Fields.pdf document. This document will be provided as part of the Systems Design Document (SDD) deliverable.

7.3 ENTITY RELATIONSHIP DIAGRAMS (ERD)

Please refer to the Accela ERD - MultiPage.pdf and the Accela ERD - One Page.pdf documents. These documents will be provided as part of the SDD deliverable.


SECTION 8 AGCSS REPORTING TOOLS

8.1 REPORTING COMPONENTS

AgCSS implementation will use following reporting components –

• Microsoft SQL Server Reporting Service - For all reporting requirements. • Microsoft PowerBI - For Dashboard requirements.

All reports will be configure using Accela Report Manager and will be available for user to run within Accela interface. Below section provide detail configuration steps to run report with in Accela interface.

8.1.1 MICROSOFT SQL SERVER REPORTING SERVICE

Accela supports Microsoft SQL Server Reporting Services. These can be configured in the Reports Manager on the V360 Admin.

Exhibit 8-36: Accela Admin Screen for Report Manager Setup


Within Report Manager, Accela provides ability to configure new Report Service.

Exhibit 8-37: Create New Report Service

Provide reporting service a name and select the appropriate version of SSRS reports server.

Exhibit 8-38: Report Service Form

For AgCSS implementation PDF report will be used as output format.


The Reporting Service URL and Report Name List URL will be updated to create SSRS service. Please refer ‘SQLServerReportingService_installation.pdf’ for installing SSRS services and creating both Reporting Service URL and Report Name List URL.

Exhibit 8-39: Report Service URL Setup

Development of SSRS reports can be done on any machine that has a stand-alone SQL Server Report builder installed and connection to Accela database. Once developed, the developed report file (generally .rdl extension) can be move to the ‘Report Name List URL’ location mentioned above. From here developed report can be used within the Accela environment.

For example, the report developed on the stand-alone machine is Permitbytype.rdl, which takes a date and permit type as the input and lists all the permits/records of that type created on the date specified. To make this report available to AgCSS users, in Accela V360 navigate to Admin > Reports > Report Manager and select New Report from the Menu button.



Give your report a meaningful name to be identified by the business.

Process service will be ‘SSRS Reports’ or whatever name was specified when the reporting service was created. Output format is PDF. Select the appropriate category for this report to show under (e.g., Daily reports)



Now for the Report Link, click on the small icon just next to the ‘Report Link’ as depicted below.

Exhibit 8-42: Report Link

It should pop-up the window as below, which will provide list of all .rdl files. Select the radio button next to your .rdl file and click select.

Exhibit 8-43: Report File List

Your New report portlet should now look like below and submission of below screen will create report in Accela.


Exhibit 8-44: Report File List

Once report is setup, it will be available in the Accela navigation menu or it can be triggered from the EMSE script.

8.1.2 POWER BI DASHBOARD

Power BI is a suite of business analytics tools to analyze data and share insights. Power BI dashboards provide a 360-degree view for business users with their most important metrics in one place, updated in real time. AgCSS will use Power BI report server to create various dashboard for AgCSS users. Power BI Report Server hosts Power BI reports (.PBIX) file. Accela Report manager setup will expose those Dashboard reports to AgCSS users.


SECTION 9 INFRASTRUCTURE REQUIREMENTS

Below is a list of the different environments that will be setup as part of the AgCSS project. Detailed information about the purpose and specification of each environment is provided under the ‘AgCSS_R1_D8_Architecture Design Document’.

Development Environment (DEV)

Test Environment (TST)

Stage Environment (STG)

Production Environment (PRD)

Note: In the proposed solution there are two more environments namely, Development Maintenance and Operation (DEV MO) and Test Maintenance and Operation (Test MO). These environments will be built as part of Release 2.

Please refer to the AgCSS_R1_D8_Architecture Design Document. This document will be provided as part of SDD deliverable.


SECTION 10 SECURITY REQUIREMENTS

The AgCSS system has been architected to meet the security requirements and guidelines of FDACS. Different components of AgCSS have been architected and placed in different zones to ensure that the back-end systems are not exposed directly to the public interface. All public interface service will be designed to use HTTPS protocol, leveraging trusted certificates to ensure data security. Firewall rules have been configured between different servers across the tiers. The final validation of security will be performed as per the security accreditation rules set by FDACS. The design leverages network and system anti-virus software installed to secure access to the solution being designed. The AgCSS system enforces approved authorizations for access to information accordance with applicable access control policies. In this case access enforcement is controlled by Accela’s Logical Access Control using Accela user role and permission setup.

Florida Department of Agriculture and Consumer Services ... - Syst… · Florida Department of...

Documents

Transcript of Florida Department of Agriculture and Consumer Services ... - Syst… · Florida Department of...