SOW Attachment A4.4 Bureau Reporting Sub System RSR.pdf

Ryan White HIV/AIDS Services Reporting (RSR) Web Application Project

Detailed Design Document

Attachment A.4.4

Health Resources and Services Administration

Office of Information Technology 5600 Fishers Lane

Rockville, MD 20857

RSR Web Application ii

Table of Contents

1 Introduction

1.1 Background

1.2 Purpose and Scope

1.3 System Overview

1.4 Document Organization

1.5 Change Control

1.6 Target Audiences

1.7 Assumptions

1.8 References

2 Design Considerations

2.1 Goals and Guidelines

2.2 Development Methods

3 Architectural Strategies

3.1 SOA Ready Application

3.2 Shared HAB Administrative Feature

4 System Architecture

4.1 Overview

4.2 External Interfaces

4.3 Hardware Architecture

4.4 System Software Architecture

4.5 RSR Application Layers

4.6 Subsystem Architecture

5 Detailed System Design

5.1 Grantee Contract Management System (GCMS)

5.1.1 Responsibilities

5.1.2 Constraints

5.1.3 Uses/Interactions

5.1.4 Resources

5.1.5 Processing

5.2 Client-level Data Upload Engine

5.2.1 Responsibilities

5.2.2 Constraints

5.2.3 Uses/Interaction

5.2.4 Processing

5.3 Validation Engine

5.3.1 Responsibilities

5.3.2 Processing

5.4 Workflow Engine

5.4.1 RSR Workflow Engine Design

5.4.2 RSR Workflow Engine Implementation

5.5 Email Engine

5.5.1 Responsibilities

5.5.2 Processing

6 Database Design 7 External Interfaces iii

7.1 Email Notifications

7.2 EHBs Integration

List of Tables

Table 1: Server Specifications

List of Figures

Figure 1: RSR Application Architecture Figure 2: Architecture Overview Figure 3: External Interfaces Figure 4: Environment Figure 5: Software Components Figure 6: Base Class Inheritance Figure 7: Master Base Page Inheritance Figure 8: RSR Workflow Engine Design Figure 9: Participants involved in a Status Change Request Figure 10: Grantee Report Workflow Figure 11: Provider Report Workflow Figure 12: Validation Workflow Figure 13: Provider Report Review Process Workflow Figure 14: EHBs Integration Figure 15: Platform Lite Integration

1 Introduction The Human Immunodeficiency Virus (HIV) / Acquired Immunodeficiency Syndrome (AIDS) Bureau (HAB) developed the Ryan White HIV/AIDS Services Reporting (RSR) web application to measure performance of the Bureau's Part A, B, C, and D programs. In addition, it was developed to meet the names-based reporting requirements of the Ryan White Treatment Modernization Act of 2006 and to comply with the Government Performance and Results Act (GPRA). The RSR supports the information and analytic needs of key decision-makers at several levels within HAB.

The RSR data is used for several activities related to performance, including (1) monitoring and measuring; (2) analyzing and assessing; (3) reviewing processes and taking action to improve program operations; and (4) identifying successes and problems.

A key difference between the RSR application and its predecessor system, the Ryan White Data Report (RDR), is that the RSR is designed to facilitate client-level data reporting as opposed to the aggregate data collected by the RDR.

1.1 Background

The RSR web application provides an online data collection and reporting system through which grantees and providers, funded under Parts A, B, C, and D of the Ryan White legislation, can report their performance data annually. Rather than submitting data separately under each part, providers funded under multiple program parts can submit their data in a single submission.

The RSR web application:

• Allows users to enter and modify RSR data through a standard web browser.

• Allows users to generate RSR reports in printer-ready portable document format (PDF).

• Performs automatic data validation based on pre-established rules.

• Allows grantees to review and comment on their providers’ entries, and to accept provider submissions or return them for changes.

• Automates the workflow process of collecting, validating, and storing RSR data.

• Allows electronic uploads of RSR reports in Extensible Markup Language

(XML) format, which is compliant with the published RSR XML schemas for a given reporting period.

All entered data is stored in a central database located on a server administered by Health Resources and Services Administration’s (HRSA) Office of Information Technology (OIT).

1.2 Purpose and Scope

The purpose of this document is to provide a detailed description of how the RSR web application is implemented. Specifically, this document describes the following aspects of the RSR web application:

• System Architecture

• Software Design

• Database Design

• External Interfaces

This document describes Leidos' approach to implement the capabilities and functions of the proposed system and to satisfy all of the requirements enumerated in the RSR Requirements Definition Documents.

1.3 System Overview

The RSR web application allows users to enter/upload, modify, submit, and approve RSR data for Part A, B, C, D grants with activity codes of H12, H76, H89, and X07.

Users of the RSR web application include:

• Grantees receiving funds from HAB.

• Providers who provide services funded by HAB grants.

• HAB’s data contractor, WRMA/CSR, Incorporated.

• HAB staff members.

• Leidos’ development team tasked with building and maintaining the system.

• HAB’s Project Officers (PO).

Users access the RSR web application using a standard web browser (i.e., Microsoft Internet Explorer [IE] Version 11.0). The system servers (i.e., Web Server, .Net Application Server, and Database Server) are hosted by HRSA’s OIT.

The RSR web application requirements are defined in detail in the RSR Requirements Definition Documents. The following summarizes the functionality of the RSR web application:

• Enter RSR Grantee and Provider Report data.

• Import RSR client-level data.

• Validate RSR Grantee and Provider Reports using pre-defined validation rules.

• Perform workflow tasks (i.e., Submit/Un-submit, Accept, Reject, Approve, etc.)

for RSR Provider Reports.

• Print RSR Grantee and Provider Reports in PDF format.

• View and print workflow reports.

• View and print client-level data summary reports, such as the Client Data

Completeness Report and the Client Data Upload Confirmation Report.

The RSR web application employs the following technologies, as described in more detail later in this document:

• Microsoft .Net Framework 4.0, ASP.NET 4.0, and C#.Net 4.0

• XML and Extensible Stylesheet Language Transformation (XSLT)

• Microsoft SQL Server 2012

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Internet Information Server 7.x

• JavaScript

• Infragistics NetAdvantage ASP.NET User Controls

• NHibernate

• Bootstrap

1.4 Document Organization

This document is divided into several sections and appendices:

• The System Architecture section provides an overview of the hardware, software, sub-systems, associated systems, and external interfaces that comprise the HAB RSR web application.

• The Detailed System Design section provides a detailed description of the custom software built and maintained by the Leidos Development team.

• The Database Design section addresses the relational database that stores RSR web application data.

• The External Interfaces section describes the various ways the RSR web application communicates with outside systems and databases.

• The appendices consist mostly of detailed technical diagrams and tables.

These are referenced in the body of this document.

1.5 Change Control

During the initial and subsequent development cycles, the technical details of the HAB RSR web application changed as functionality is added, enhanced, removed, or otherwise changed. Even during the application maintenance phases, the design changes from time to time. As a result, this will be a “living” document that the Leidos team will keep up to date.

Once HAB has accepted the initial version of this document, it will be considered under change control. All subsequent updates will be documented in the Document History table. OIT and HAB will be notified of all changes and will be provided an updated electronic copy of each future version.

1.6 Target Audiences

This document will be used by two main groups of software developers:

• Implementers of the RSR web application.

• Maintainers of the RSR web application after it is deployed.

This document will be reviewed by HRSA and Leidos managers responsible for overseeing the project.

1.7 Assumptions

This document was written based on the following assumptions.

The following assumptions relate to the actions necessary to prepare the RSR web application for the reporting period and to cover data initialization and database access:

• An updated list of Part A, B, C, and D Grantees and deliverables will be provided in electronic form by WRMA/CSR to the development team before the deployment phase begins.

• The RSR Grantee Report list of providers and services will be initialized for all grantees.

The following assumptions were also made regarding environments, setup, and maintenance:

• OIT will install the operating system on the Production and other environment web and database servers.

• The RSR web application development team will be given administrator access on all application and database servers used in this development effort.

• OIT will obtain and install Secure Sockets Layer (SSL) certificates on Production and other environment web servers.

• OIT will do firewall configuration, as necessary, to allow secure traffic from providers and grantees on the Internet, through the firewall to the Production and other environment servers on the default secure port (i.e., 443).

• OIT will provide sufficient computer hardware and network bandwidth to accommodate peak expected usage on the RSR database server and web application server.

• The HRSA Electronic Handbooks (EHBs) will not implement significant changes that effect how the RSR web application will integrate with EHBs.

• End-user workstations must have, at a minimum, a Pentium 133 MHz processor with a Microsoft Windows XP operating system.

• End-user workstations will be set to a screen resolution of at least 1024x768.

1.8 References

The following documents were referenced in the development of this document:

• RSR Web Application:

https://performance.hrsa.gov/hab/RsrExternal/App/UI/rsr.aspx

• RSR Registration and Login Application:

https://performance.hrsa.gov/RegLoginApp/Admin/Login.aspx

• The Ryan White HIV/AIDS Services Report Requirements Definition Documents and Change Requests.

• RSR Instruction Manual available in Adobe Acrobat Reader format at https://careacttarget.org/library/ryan-white-hivaids-program-services-report-rsr-instruction-manual

2 Design Considerations

2.1 Goals and Guidelines

• Better user experience o Navigation o Performance o Simplicity o Support the three main browsers: IE, Chrome, and Firefox

• Technical o .NET 4.5 o Object-Oriented Programming (OOP) – Follow Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion (SOLID) design principles o Service-Oriented Architecture (SOA) – Distributed architecture that allows machine to machine client data upload, upload confirmation report, and data completeness report using WCF Streaming capability o Unit test coverage: 50% o HTML5 - WebSocket o Fluid/Responsive design o Core application logic in application o Parallel processing o Asynchronous processing - server side and client

• Maintenance o Maintainability o Better system for troubleshooting, auditing, etc.

• Scalability o Support for server farm/load balancing

• Integration o Better integration with EHBs: more integration points o Retrieve more EHBs data

• Documentation https://performance.hrsa.gov/hab/RsrExternal/App/UI/rsr.aspx https://performance.hrsa.gov/RegLoginApp/Admin/Login.aspx https://careacttarget.org/library/ryan-white-hivaids-program-services-report-rsr-instruction-manual https://careacttarget.org/library/ryan-white-hivaids-program-services-report-rsr-instruction-manual o Simple, but complete documentation

2.2 Development Methods

The RSR web application development team uses an adapted Agile Scrum Development Methodology. With Agile Scrum Methodology, the Product Owner works closely with the development team to identify and prioritize system functionality in the form of a “Product Backlog”. The Product Backlog consists of many work items including features, bug fixes, and non-functional requirements. With priorities driven by the Product Owner, the team estimates and agrees to deliver increments of software during successive sprints. Once a sprint has been completed and the work items delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of work items are selected for the next sprint.

3 Architectural Strategies

3.1 SOA Ready Application

The RSR web application is an SOA ready application. SOA is a software design and software architecture design pattern based on distinct pieces of software providing application functionality as services to other applications.

The RSR web application will have a service layer, which will consist of different service modules such as the Client Upload Service. Each of the services is designed and developed in a way that allows the services to be accessible through Windows Communication Foundation (WCF) services for future enhancement. Some of these services include client data upload, validation, and reporting.

The RSR web application can use the internal service directly or use it through the WCF service passing required credentials. If using it through the WCF service, security will be enforced and provided through WCF’s strong built-in security features. WCF comes with strong out of the box security features including transfer security, access control, and auditing.

Figure 1 depicts the proposed RSR web application architecture.

Figure 1: RSR Application Architecture

The following approach was used to implement the SOA for the RSR web application:

Step 1: Design and code each main module as an internal service. The RSR web application will consume these services directly. These internal services are designed to be used in the future by outside consumers.

Step 2: Develop the WCF service to expose the services that need to be exposed.

The service will require extra security such as username and password.

Step 3: Develop a guide and code samples for vendors who may want to use the WCF service.

Step 4: Vendors modify their applications to consume the WCF service.

The following benefits may be gained by using SOA for the RSR web application:

WCF

TRAX CAREWare Other Vendors

( with Authentication , Authorization , SSL )

( with Authentication , , SSL )

RSR

Presentation Layer

UI Components

Logging Utils

Exce ption Ha ndling Business Layer

Cross - cutting

EHBs Gateway :

Data Services

Services Authenti cation /

Authoriz ation

Validation Workflow Data Process

Entities Domain Objects

Data Layer

SQL

Server

Data Access SSRS

Integration

Windows Services Validat ion Service

Client Upload Service

Email Service

EHBs Request Service

Wraps Client Validation Service Client Validation

Service

Wraps Client Upload Service

Client Upload Service

Wrapper More

Services ...

Authorization

1. Logic in services will be written only once as part of the RSR solution, but it can be available to different applications/vendors.

2. The vendors will have the option to use the Client Upload Service to develop a batch upload feature in their application.

3. Provider/Grantee users using an application programmed with the WCF service can upload their client data directly from the vendor application rather than having to generate XML files and upload through the RSR web application.

Leidos developed the RSR web application as an SOA ready application (refer to Step 1). Becoming an SOA ready application will make RSR more flexible, easier to provide more features to users, and potentially available for Business-to-Business (B2B) features.

3.2 Shared HAB Administrative Feature

The Administrative features like downloading a log file, user management, and system message posting are directly accessible from the RSR web application as well as from other HAB web applications.

System Administrators, Data Support, and HRSA Contact Center (HCC) users have access to the administrative feature area of the RSR web application.

4 System Architecture The RSR web application is deployed as a .NET application.

4.1 Overview

Figure 2 provides an architecture overview, including servers, clients, sub-systems, databases, and the communication between them. The web/application server will reside in the Demilitarized Zone (DMZ), between two firewalls. Users outside of the HRSA network (e.g., WRMA/CSR, grantees, providers, Help Desk, etc.) will access the site through encrypted Hypertext Transfer Protocol (HTTP) SSL, or Hypertext Transfer Protocol Secure (HTTPS) communication. Users inside the HRSA network will access the site through standard HTTP requests.

WAN

Compaq Server 1 Application Server

Compaq Server 2 Database Server

WRMA/CSR

Grantees & Providers

HRSA Contact Center

Internet Information Server (IIS)

Web Server SMTP Server

RSR Web Interace .Net Application

Security / Authentication

.Net Application

DMZ

HRSA Network

SQL Server

HAB

Database

HAB

Leidos Development Team https http smtp

Native SQL Server

Named Pipes

File System Write

.Net State

Server Other .Net Applications

Security / Auth

Database

Other Databases file system / docroot

Figure 2: Architecture Overview

The .NET application may be configured to use Microsoft State Server, running in a separate process, to maintain session information, or it can store session information in-process. The application is designed so either of these methods can be used and HRSA can easily scale-up the application by adding hardware without redesigning the software. As long as the application is deployed on a single application server, it will be configured to store session information in-process. If it is later determined that the system needs to boost performance or accommodate increased load, HRSA can add a load-balancer and a second application/web server. The RSR web application will be able to run unchanged in this distributed environment once the .NET application configuration is changed to use State Server. This is especially important because HRSA is deploying multiple applications on the same server.

The RSR web application will allow some users to upload electronic versions of their RSR data in XML format through the site.

4.2 External Interfaces

Figure 3 summarizes the application’s external interfaces. External interfaces are described in more detail in Section 7 of this document. There are five main external interfaces:

1. Email alerts are sent out for the registration process and throughout the workflow process.

2. For print-friendly RSR Provider and Grantee Reports, the system uses SSRS to create a PDF version of the RSR.

3. Certain applications, including CAREWare, can generate client-level data output files in XML format that is compliant with the HAB RSR XML schema definitions. These files are uploaded to the web application file system and processed by the application that moves data from the XML files into the RSR web application database.

4. Custom reports for HAB, WRMA/CSR, and Leidos are implemented as SSRS ReportViewer reports.

5. Interface with HRSA’s Electronic Handbooks (EHBs) to get and update deliverable and other statuses, as well as to get grantee contact information.

EHBs Environment

HAB Application

EHBs WCF Service

EHBs

GEMS

Database

Platform Lite Integration

Platform Lite

Leidos Components

HAB Core Components

Legend EHBs Gateway

EHBs EIS

Seamless User Interface

Real-Time System Communications

Leidos EHBs Integration Architecture

Date Updated: 10/13/2015

Figure 3: External Interfaces

4.3 Hardware Architecture

The RSR web application is deployed on four Compaq ProLiant Servers, two application servers, and two database servers. Each environment (e.g., Quality Assurance, staging, and Production) consists of one application and one database server. The production server specifications are as follows.

Production Database Server:

• HAB-DB-PROD2, virtual machine

• 4 CPUs

• 64 GB of RAM

• 150 GB hard drive for operating system

• 200 GB hard drive for structured data storage

• 100 GB for temporary storage of structured files such as backup files.

• 100 GB for unstructured data storage (e.g., MS Word, etc.)

Production Application Server:

• Perf-app-p3.hrsa.gov, virtual machine

• 4 CPUs

• 16 GB RAM

• 100 GB hard drive for operating system

• 200 GB hard drive for data storage

The servers are deployed across the environments as shown in Figure 4. HRSA OIT maintains these servers.

MCHB DB

Server

(perf-db-prod2)

HAB DB Server (hab-db-prod2)

GEMSDB1EHBs Prod

Access Perf Reports

BRS Prod Architecture

Firewall

EIS

MCHB App Server (Perf-app-p4)

MCHB Apps

SSRS EHBs Gateway

HAB App Server (perf-app-p3)

HAB Apps

HRSA DomainOITNET (DMZ)

EHBs Users

PL

PL

Windows OS: 2012 Standard Database: SQL Server 2012 .NET: 4.x IIS: 7.x

SSRS: 2012

Platform Lite: 2.35.25

Created: 10/14/2015 Printed: 10/14/2015 Last Updated: 10/14/2015 Created by: Leidos

FORHP DB

Server

(orhp-db-p1)

FORHP App Server (Orhp-app-p1)

PL

PIMS

SSRS

SSRS

GEMS ODS

Server

(Ehb-app-p5)

ODS

SSAS?

Figure 4: Environment

Table 1 further describes these servers and how they will be configured.

Table 1: Server Specifications

SOFTWARE SPECIFICATIONS

(Software needed to configure the database, web, and application servers)

Database Operating System

Sever Application Application

SQL Server 2012 (with System Administrator [SA] login privileges)

MS

Windows Server

MS

Windows Server

MS Internet Information Server (IIS)

7.5 or later

• MS .NET Framework*--minimum requirements for .NET:

• Internet Explorer 9 or later

• Windows 2012

• MDAC 2.8

• IIS 7.x or later

• ODBC Drivers (for MS Access)

• Infragistics NetAdvantage for ASP.NET

Control Library .NET 2008 Vol. 3 CLR 2.0

• AJAX Server Extensions 1.0

• RSR Web-Interface application code

(provided by developers)

• Platform Lite integration code (provided by a

HAB Contractor)

• Need at least one Administrator

Account/Remote Desktop Account

• .NET runtime 2.0 – 4.0

* The Microsoft .NET Framework can be downloaded or execute ‘Dotnefx.exe’ from the Windows component CD. (Note: See below for detailed minimum software and hardware requirements for installing Microsoft .NET.)

HARDWARE SPECIFICATIONS

Sever Type Model CPU Memory Speed Processor

Database Server

VMare 64GB 8vCPUs x2.20GHz

Intel XeonE5-2660

Application Server

VWare

ECC SDRAM 4GB 2 X

2.20GhzGHz

Intel Xeon E5-2660

4.4 System Software Architecture

The RSR web application consists of the following software components, which are illustrated in Figure 5:

• Microsoft Internet Information Server 7.0 o World Wide Web (WWW) server o Simple Mail Transport Protocol (SMTP) server

• Microsoft .Net Framework 4.0

• Microsoft SQL Server 2012

• Microsoft AJAX Server Extensions 1.0

In addition, the Leidos Development team is using the following development tools:

• Microsoft Visual Studio .Net 2010.0 for SQL Server Reports

• Microsoft Visual Studio .Net 2012

• Microsoft SQL Server Management Studio 2012

• XmlSpy 2010 Professional

• ERWin from CA

• Telerik Controls

• NHibernate 3.0 – an open source Object-Relation mapper tool

Custom software developed by the Leidos Development Team includes:

• RSR Web Application

• HRSA Performance System Registration and Login Application

• Configurable Data Conversion Application

• Various Windows services that support the RSR Web Application

• Various SQL Server Reports

The RSR web application supports Microsoft Internet Explorer Version 11.0, Google Chrome, and Mozilla Firefox using the SSL protocol.

IIS

Web Server

.Net Framework

SQL Server Database www smtp HAB/RSR Web Application

HAB/RSR

Web Database

SSRS

Software

Components Third-party Software

Custom Software

IE

Web

Browser

RSR Form

Legend

Figure 5: Software Components

4.5 RSR Application Layers

The RSR web application consists of the following six layers:

1. HRSA Integration Layer: Provides generic integration service to all BRS systems.

2. HAB Integration Layer: Provides common integration needs specific to all HAB systems.

3. RSR Presentation Layer: Contains RSR web application user interfaces.

4. RSR Service Layer: Contains all RSR specific services modules.

5. RSR Domain Layer: Defines all RSR business domain objects.

6. RSR Infrastructure Layer: Contains all crosscuts, utilities, etc.

The HRSA Integration Layer provides generic integration service to all BRS systems.

HAB systems have their own integration layer, called the HAB Integration Layer.

This layer provides integration needs specific for HAB systems and inherits from the HRSA Integration Layer. In addition, the HAB Integration Layer provides additional activities and functionalities such as initializing the HrsaUser object with appropriate information that is relevant to the user. This information consists of user contact information, report information, authorized resources of the systems (both EHBs users and non-EHBs users), access control, HAB grantee organization synchronization with the EHBs of grantee of records, report header information rendering, report initialization, etc.

The HAB Integration Layer provides integration services mainly through a base class called HabBasePage. This class inherits from the HrsaBasePage class, which is part of the HRSA Integration Layer. The HrsaBasePage class inherits from a Platform Lite base page class, which ultimately inherits from the Page class of ASP.NET. The HabBasePage class is the base class of all classes that need to have access to the functionalities that are provided by the base class. The hierarchy of the base class inheritance is shown in Figure 6.

Figure 6: Base Class Inheritance

Another class in the HAB Integration Layer is a base master page called HabMainMaster. This class inherits from the HrsaMainMaster class in the HRSA Integration Layer, which inherits from the base master page that Platform Lite provides. This class provides access to the properties of the controls on the Master page that is provided through Platform Lite. It also implements an interface called

HabMainMaster, which is created to facilitate the abstraction of the HAB layer integration only.

The master base page inheritance hierarchy is shown Figure 7.

Figure 7: Master Base Page Inheritance

4.6 Subsystem Architecture

Subsystem architecture consists of the following services:

• RSR Client-level Data Upload Windows Services

• RSR Validation Windows Service

• RSR Batch Print Windows Service

• HAB Email Process Windows Service

• EHBs Request Windows Service

5 Detailed System Design The RSR web application consists of the following components:

1. Grantee Contract Management System (GCMS)

2. Client-level Data Upload Engine

3. Validation Engine

4. Workflow Engine

5. EHBs Request Engine

6. Email Engine

5.1 Grantee Contract Management System (GCMS)

RSR grantee users access the GCMS module through the RSR web application to add/update contracts between grantees and providers.

5.1.1 Responsibilities

GCMS stores the central source of data for HAB grantee contracts.

5.1.2 Constraints

All grantee contract information is maintained in GCMS, and information will be synchronized to the RSR by a grantee user on the Program Information page.

5.1.3 Uses/Interactions

The GCMS user interface is developed in the UserControls project as user controls, which are shared by multiple applications (e.g., Program Terms Report [PTR], RSR, and Expenditures Report).

5.1.4 Resources

GCMS initial contracts data are populated from RSR for Part C and D, and from PTR for Part A and B. Grantee users will continue to use GCMS as a central source location to enter and maintain the contract data.

5.1.5 Processing

HAB contract data are centrally stored in GCMS. When an RSR grantee report is created, a copy of the contract data that overlaps the RSR reporting period will be copied over to RSR and stored in the RSR Contract tables. RSR grantees will be prompted to review the contract data once any difference is detected between RSR and GCMS after the grantee report creation. Grantee users have a choice to synchronize or not to synchronize the difference.

5.2 Client-level Data Upload Engine

5.2.1 Responsibilities

The Client-level Data Upload Engine allows users to upload client-level data XML files and generate Client-level Data Reports as an outcome.

5.2.2 Constraints

Client-level data must be uploaded and imported using an XML file that conforms to the client-level data XML schema definitions. Users can upload a single client-level data XML file. If the file is a compressed Zip file, then a directory is created based on the user’s organization and the content is extracted into this directory after deleting any existing XML files, but preserving any existing ZIP files.

5.2.3 Uses/Interaction

Users will be redirected to the RSR Client-level Data Upload page to upload their client-level data.

5.2.4 Processing

The RSR Client-level Data Upload page will validate the uploaded XML file against the XML schema definitions. This process is referred to as the “schema check.” If it fails the schema check, the user is notified with an error message that is shown on the screen, which is being used to upload client-level Data.

All client-level data XML requests are queued in HabAdmin. The HAB_CldUploadRequest table records the requests and requests are processed in the order that they are inserted into the table by a standalone Windows service, Leidos RSR ClientUpload 2015 v1.0.

The following three (3) different kinds of client-level data XML upload requests can be submitted by users and processed by the Client-level Data Upload Engine:

1. Upload Client-level Data XML Request – Client-level Data Upload engine will process a client-level data XML upload request.

2. Clear Data by Organization User Request – Client-level Data Upload engine will clear the data that were previously uploaded by the organization and reprocess all upload requests that were previously made except the ones selected by the organization who made the Clear Data by Organization User Request.

3. Clear Data by System Administrator Request – System Administrators can see all previous upload requests and select which data files that s/he wants to remove. The Client-level Data Upload Engine will clear the data that were previously uploaded and reprocess all upload requests that were previously made except the ones selected by the System Administrator who made the Clear Data by System Administrator Request.

The Client-level Data Upload Engine will first use a wrapper class, XmlSerializationWrapper, to de-serialize the XML data into a client-level data XML schema based object, ROOT. ROOT is a collection of client-level data in an object base representation. The process then extracts new data records from ROOT by comparing the ClientUci field in ROOT with the ClientUci fields that are in the database. If the ClientUci in ROOT does not exist in the database, the process uses the ADO.Net SqlBulkCopy class to insert the new data records into the database. If the ClientUci in ROOT matches a ClientUci in the database, the process will apply the client data merge functionality to update the data records in the database with information from the records in ROOT based on the HAB merge rules.

After completing the processing of a XML upload request, the Client-level Data Upload Engine will generate the following reports for each individual upload request as well as for the entire set of reported data:

• Upload Confirmation Report o The Upload Confirmation report reflects aggregate data that resulted from the upload.

o After the XML data for each upload request is processed by the Client-level

Data Upload Engine, the RSR web application will aggregate the data and provide the total count and percentage for each data element.

• Data Completeness Report o The Data Completeness Report provides details on the completeness of the uploaded client-level data.

o After the XML data for each upload request is processed by the Client-level Data Upload Engine, the RSR web application will aggregate the data and provide the statistic for each data element.

• Validation Report o The Validation Report reflects the compliance of uploaded data with the defined validation rules. From the Validation Report, users can easily and quickly identify the errors in their data and how to fix them. Users can correct and re-upload the corrected XML until they determine that they are ready to submit the data to HAB.

o After the XML data for each upload request is processed by the Client-level Data Upload Engine, the RSR web application uses the Validation Engine to validate the data against a list of check codes.

5.3 Validation Engine

5.3.1 Responsibilities

The Validation Engine is designed to validate the Grantee Report, the Provider Report (Including the Client Report), and the Check Your XML Report.

5.3.2 Processing

Each Validation Rule is defined as a Check Code. Grantee Reports, Provider Reports, and client-level data files, all have their own Check Code lists. The Validation Engine will use the “Report Id” to figure out the right report type and load up the corresponding list of Check Codes. Then the Validation Engine runs the list of Check Codes against the reported data. Each unsatisfied Check Code yields a validation error, warning, or alert. Validation results are saved in the [habAdmin].[HAB_ValidationResult] table.

All the Check Codes are saved in the [habAdmin].[HAB_ValidationCheckCode] table, “IsActive” flag is used to include / exclude the check code in the validation process.

5.4 Workflow Engine

RSR has the following workflow processes requirement:

• Grantee Report Workflow (Figure 10)

• Provider Report Workflow (Figure 11)

• Validation Workflow (Figure 12)

• Provider Report Review Process Workflow (Figure 13)

5.4.1 RSR Workflow Engine Design

The design of the workflow engine adapts the chain-of-responsibility design pattern.

The chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. In the RSR Workflow Engine design (Figure 8), we chain a list of workflow status objects in the proper sequence and start looping each workflow status object to match with the request status. If a match is found, the workflow status object will process the tasks: (1) update the request (report) status, (2) queue a request to update EHBs deliverable status, and

(3) log the workflow action. Otherwise, the process will pass on to the next workflow status object in the chain to repeat the matching process.

Figure 8: RSR Workflow Engine Design

5.4.2 RSR Workflow Engine Implementation

When a workflow action is initialized, a WorkFlowRequest object will be created and processed by a WorkflowProcessService object as shown below.

RsrGrNotStarted

RsrGranteeReportStatusClass

RsrGranteeReportStatus

WorkflowReportStatusClass

Properties

MethodsGetDateInitializeRsrGranteeReportStatusUnsubmitGranteeReport

RsrGrSubmitted

RsrGranteeReportStatusClassRsrGrWorking

RsrGranteeReportStatusClass

RsrGrCertified

RsrGranteeReportStatusClass RsrGrAccepted

RsrGranteeReportStatusClass

WorkflowReportStatusClass

Properties

MethodsInitializeProcessRequestSetToAcceptedSetToApprovedSetToCertifiedSetToChangeRequestedSetToCompleteSetToInProgressSetToNotStartedSetToReviewSetToSubmittedSetToWorkingWorkflowReportStatus

In the above code snippet, a grantee report workflow status change request from “Not Started” to “In Progress” is created. Lines 284 to 293 show the RsrWorkflowRequest creation and lines 295 to 296 for processing the request by a WorkflowProcessService object.

The constructor of a WorkflowProcessService object defines the chain of report workflow status as below.

Each workflow status object defines a ProcessRequest method to perform the proper action for the workflow process. The ProcessRequest method will perform the following:

1. Update workflow status.

2. Queue an EHBs request to update the EHBs deliverable status.

3. Log the workflow action.

In the above example, line 18 shows workflow status has been updated to “Working”.

Lines 19 to 26 show queuing a request to update the EHBs deliverable status. Line 27 logs the workflow action.

When the workflow process gets started, it will loop through each workflow status object defined in the workflow chain to find a match with the current workflow status.

If a match is found, the corresponding ProcessRequest method of the workflow status object will be triggered to perform the workflow action. The loop to find the match workflow status object in the chain is shown below.

The sequence diagram (Figure 9) below shows the participants that are involved in the status change described above – the status of a RSR grantee reports changes from “Not Started” to “In Progress”, and the methods that are called from each participant.

Create Report GranteeReportService

GranteeReportWorkflowProcessServic e RsrGrNotStarted

Create report

ProcessRequest(Requeest)

ProcessRequest

Find the right status and invoke the ProcessRequest method on it

ProcessRequest

Update Report Status

Queue Ehb Status update req.

Figure 9: Participants involved in a Status Change Request

Grantee logs in and navigates to the report via the EHBs

Grantee selects “start” to access the RSR System#

EHBs Status: Not Started RSR Status: Not Started

HRSA Review Status:

Not Applicable

Grantees completes the Grantee Report

EHBs Status: In Progress RSR Status: Working HRSA Review Status:

Not Applicable

Grantees validate the Grantee Report

EHBs Status: In Progress RSR Status: Working HRSA Review Status:

Not Applicable

Errors found?Yes

No

Grantee “Certifies” the Grantee Report

EHBs Status: In Progress RSR Grantee Report Status:

Certified HRSA Review Status:

Not Applicable

Provider Report Workflow

Grantee selects “Create” to begin the Grantee Report‡

EHBs Status: In Progress RSR Status: Working HRSA Review Status:

Not Applicable

Start

EHBs Status: Submitted RSR Grantee Report Status: Submitted

Grantee accepted all Provider Reports?

Yes

No

A new Pending Task is created in EHBs

HRSA Review Status:

Review In Progress

Pending Task Status:

Not Started

POs starts the Pending Task

HRSA Review Status:

In Progress

Pending Task Status:

In Progress

PO completes review and “Accepts” Submission

HRSA Review Status: Processed EHBs Status: Submitted

RSR Grantee Report Status:

Accepted

Pending Task Status: Complete

End

# If the grantee does not complete the report in a single session, the next time the grantee enters the EHBs, the link with be “Edit”.

‡ If the grantee does not complete the report in a single session, the next time the grantee enters the RSR system, the icon will be “Open” not “Create”.

At this point pass in “X of Y

Approved”

Update EHBs status description each time the grantee approves a provider report

Figure 10: Grantee Report Workflow

Start

Provider accesses RSR System as appropriate*

RSR Provider Report Status:

Not Started

Selects “Create” to begin the Report

RSR Provider Report Status:

Working

Provider completes the online form

RSR Provider Report Status:

Working

Provides Client Services?Yes

Provider selects the “submit” link in menu

RSR Provider Report Status:

Working

Provider uploads CLD XML File

RSR Provider Report Status: Working

Provider Report Review Process:

Grantee(s) review the report

All Grantees Approve the Report

RSR Status: Submitted

End

All associated Grantee Reports are certified? Yes

No

Report Is successfully submitted

RSR Provider Report Status: Review

Validate Report

No

Warnings without comments? Yes

Errors Found?

No

Yes

Show message:

Not all Grantee

Reports are Certified.

No

Figure 11: Provider Report Workflow

Start

Provider validates report

RSR Status: Working

Errors Found? Yes

No

End

All Warnings Have Comments?

Yes

Warnings Found? Yes Provider enters warning comments

No

No

Provider Completes Report

Figure 12: Validation Workflow

Start

Grantee(s) review Provider Report

Report is approved?

Last required approval?

Provider Report status updated to

“Submitted”

End

Yes

Yes

No

No

Provider Report Workflow

Provider Report Status: Working

Update EHBs status description and, if necessary, EHBs

Deliverable Status

Update EHBs status description and, if necessary, EHBs

Deliverable Status

Figure 13: Provider Report Review Process Workflow

5.5 Email Engine

5.5.1 Responsibilities

The Email Engine sends out email to the recipients based on the email request set up.

5.5.2 Processing

All email requests will be submitted and stored in the HabAdmin.HAB_EmailRequest table. The Email Engine is a standalone window service. The Email Engine parses out all email required fields such as email recipients and email body content from each email request. This engine uses the SmtpClient in the System.Net.Mail namespace to send out the email. After the email is sent, the Email Engine will update the ProcessStartTime, ProcessEndTime, and RequestStatus to reflect the process duration and the request status for the corresponding email request.

6 Database Design The RSR database design diagrams are embedded at the end of this section.

RSR Grantee Report.pdf

RSR Provider Report.pdf

RSR Client Report.pdf

7 External Interfaces This section describes the interfaces between the RSR web application and its external interfaces.

7.1 Email Notifications

Depending on each stage of the RSR Provider Report workflow, each involved provider, grantee, and RSR Administrator will be notified by email. For example, when a user returns an RSR Provider report for changes, an email will be sent to the affected users. HAB’s Internet Information Services (IIS) SMTP server will send all emails.

7.2 EHBs Integration

The RSR web application is integrated with the EHBs through Platform Lite, an integration framework that provides consistent look and feel with the new EHBs as well as backend integration such as deliverable status updates (Figure 14). The version of the Platform Lite used is 2.35.25.

ADR

EHBs

IHttpModule

RSR MAIFORHP AETC

WCF Service

EHBs Gateway:

- Authentication/Authorization

- Status Updates

- OFAM status

- Deliverable Management

- User Management

- Other

IHttpModuleIHttpModuleIHttpModuleIHttpModule

HAB Core Components

Leidos Components

Legend

Platform Lite Reusables

Rationale for this proposal

• Support for non-grantee users. Promote loose coupling

• Easier maintenance

• Cost savings

SAC/

EIS

Wrapper

Figure 14: EHBs Integration

E:\Projects

PlatformLite

V2.35.25

Platform bin

V2.14.9

Platform Lite Deployment Structure for QA/Production/Oak

PLConfig_External

PLConfig_Internal

The PlatformBin is a link directory that points to the Platform folder under /PlatformLite/v2.xx.xx/ bin.

Platform Lite configuration:

configDirectory="..\..\..\ PlatformLite\V2.35.25…..”

Date Created: 08/27/2014 Date Modified: 08/27/2014

NOTE: For the application to find the PL DLLS, one more step is needed: web.config needs to be changed to add below to the configuration element:

<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="PlatformBin" /> </assemblyBinding>

</runtime>

And then add appropriate PL DLLs to the /compilation/ assemblies/ block such as <add assembly="REISys.PlatformLite.Core"/>

Figure 15: Platform Lite Integration

A Platform Lite integration layer is created to help all Bureau Reporting Systems (BRS) to integrate with Platform Lite (Figure 15). This layer deals with general activities and functions that are common to all applications. These activities and functions include a consistent mechanism for top and left menu rendering and user authentication. This layer is called the HRSA Integration Layer. Please refer to the EHBs New User Interface (UI) Integration Design Document embedded at the end of this section, for the detailed design of this layer.

EHBs New User Interface Integration.d