SOW Attachment A4.5 Bureau Reporting Sub System PTR.pdf

Program Terms Report (PTR) Web-Based Data Entry and Reporting System

Detailed Design Document

Attachment A4.5

Health Resources and Services Administration 5600 Fishers Lane

Rockville, MD 20857

Detailed Design Document ii

Document History

Version Date Author Description

1.0 1/6/2016 Leidos Initial Release.

iii

RESTRICTED

Table of Contents

1 Introduction

1.1 Purpose and Scope

1.2 System Overview

1.3 Document Organization

1.4 Change Control

1.5 Target Audiences

1.6 Assumptions

1.7 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 PTR 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 Contract Synchronization

5.3 Email Engine

5.3.1 Responsibilities

5.3.2 Processing

5.4 Validation Engine

5.4.1 Responsibilities

5.4.2 Processing

5.4.3 Check Codes

5.4.4 Validation Windows Service

5.5 Workflow Engine

5.6 PTR File Upload

6 Database Design 7 External Interfaces

7.1 Email Notifications

7.2 EHBs Integration

iv

RESTRICTED

List of Tables

Table 1: Server Specifications

List of Figures

Figure 1: Architecture Overview Figure 2: External Interfaces Figure 3: Environment Figure 4: Software Components Figure 5: PTR Application Layers Figure 6: Base Class Inheritance Figure 7: Master Base Page Inheritance Figure 8: PTR Workflow Figure 9: EHBs Integration Figure 10: Platform Lite Integration

PTR Web Application

RESTRICTED

1 Introduction

The PTR web-based application provides a customizable data collection and reporting system through which recipients funded under Part A and Part B of the Ryan White legislation can submit their Program Terms Report data and Allocations Report annually.

The PTR allows users to:

Enter and modify PTR data through a standard web browser.

Generate reports that may be exported in multiple formats.

Perform automatic data validation based on pre-established rules.

Review the consolidated list of contractors if they are grantees.

View the allocation report and specify additional information on it.

Automate the workflow process of collecting, validating, and storing PTR data.

Perform electronic uploads of PTR documents in formats specified by HAB.

All data entered data in PTR 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.1 Purpose and Scope

The purpose of this document is to provide a detailed description of how the PTR web application is implemented for the 1.0 release. Specifically, this document describes the following aspects of the PTR 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 PTR Requirements Definition Document.

1.2 System Overview

The PTR web application allows users to enter/upload, modify, and submit PTR data for Part A, Part B, Part C, and Part D grants with activity codes of H12, H76, H89, X07 and X08. Users of the PTR web application include:

Grantees receiving funds from HAB.

HAB Project Officers (PO).

HAB staff members.

Leidos’ staff tasked with building and maintaining the system.

RESTRICTED

Users access the PTR Web Application using a standard web browser (e.g., Microsoft Internet Explorer [IE] Version 9.0 or higher). The system servers (i.e., web server, .Net application server, and database server) are hosted by HRSA’s OIT.

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

Allow entry of PTR Grantee data and uploading of required documents.

Validate the data using pre-defined validation rules.

Perform workflow tasks (i.e., Submit, Reject, and Approve) Generate user reports, such as the Consolidated List of Contractors Report.

View and print workflow reports.

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

Microsoft .Net Framework 4.0 Microsoft ASP.NET 4.0 Microsoft C#.Net 4.0 Microsoft SQL Server 2008 R2 Microsoft SQL Server Reporting Services (SSRS) Microsoft Internet Information Server 7.x Javascript Telerik Rad ASP.Net User Controls NHibernate Bootstrap

1.3 Document Organization

This document is divided into several sections and appendices:

The Introduction section provides an overview of this the PTR web application and this document.

The Design Considerations section describes the goals and any guidelines for the PTR as well as a description of the development methods considered.

The Architectural Strategies section provides information regarding strategies used in the architectural design of the PTR web application.

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

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

RESTRICTED

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

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

The appendices contain detailed technical diagrams and tables that are referenced in the body of this document.

1.4 Change Control

During the initial and subsequent development cycles, the technical details of the PTR web application may change 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 Development and Maintenance teams will maintain.

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. HAB will be notified of all changes and will be provided an updated electronic copy of each future version.

1.5 Target Audiences

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

Implementers of the PTR web application.

Maintainers of the PTR web application after it is deployed.

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

1.6 Assumptions

The following assumptions relate to the actions necessary to prepare the PTR web application for the reporting period and to cover data migration, 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 Leidos team before the deployment phase begins.

The Program Terms Report (PTR) 2015 Budget Year Consolidated List of Contracts shall be used to initialize the Part A and Part B grantee’s 2015 RSR Grantee Report.

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

RESTRICTED

HRSA/OIT will install the operating system on the Production and Development/Test (Dev/Test) web and database servers.

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

HRSA/OIT will obtain and install Secure Sockets Layer (SSL) certificates on Production and Dev/Test web servers.

HRSA/OIT will do firewall configuration, as necessary, to allow secure traffic from providers and grantees on the Internet, through the firewall to the Dev/Test and Production servers on the default secure port (443).

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

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

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

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

1.7 References

The following were referenced in the development of this document:

The Program Terms Report Requirements Definition Document.

The RSR 8.0 Detailed Design Document.

2 Design Considerations

2.1 Goals and Guidelines

The following goals and guidelines were considered during the development of the PTR web application:

Better user experience o Easy navigation o Good performance o Simplicity of use o Support the three main browsers: IE, Chrome, and Firefox o A more consistent user interface

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 Unit test coverage: 50%

RESTRICTED

o HTML5 o Fluid/Responsive design o Parallel processing o Asynchronous processing - server side and client

Maintenance o Maintainability o Troubleshooting, auditing, etc.

Detailed Logging Scalability o Support for server farm/load balancing

Integration o With EHBs o Retrieve more EHBs data

Documentation o Simple, but complete

2.2 Development Methods

The PTR web application development team adapts the Agile Scrum Development Methodology. With the 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 PTR web application is a Service-Oriented Architecture (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 PTR web application will have a service layer, which will consist of different service modules such client data upload, validation, and reporting.

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 PTR 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 PTR web application.

4 System Architecture

The PTR web application is deployed as a .NET application.

4.1 Overview

Figure 1 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.

RESTRICTED

Figure 1: Architecture Overview

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

PTR 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

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 PTR web application will be

RESTRICTED

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.

4.2 External Interfaces

Figure 2 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 throughout the workflow process.

2. The system uses Structured Query Language (SQL) Server Reporting Services

(SSRS) to create reports that are either printable in Portable Document Format (PDF), or exportable to Excel.

3. Interface with HRSA’s EHBs to get and update deliverable and other statuses, as well as to get grantee contact information.

Figure 2: External Interfaces

EHBs Environment

HAB Application

EHBs WCF Service

EHBs

GEMS

Database

Platform Lite Integration

Platform Lite

Leidos Components

REI

Components

Legend EHBs Gateway

EHBs EIS

Seamless User Interface

Real-Time System Communications

Leidos EHBs Integration Architecture

Date Updated: 10/13/2015

4.3 Hardware Architecture

The PTR web application is deployed on four Compaq ProLiant Servers, two application servers, and two database servers. Each environment (i.e., Dev/Test and Production) consists of one application and one database server. The server specifications are as follows.

Production Database Server:

HAB-DB-PROD1, virtual machine 8 core CPUs at 2.20GHz 64 GB of RAM (but only 32 GB is usable on Windows 2008 R2) 150 GB hard drive for operating system 170 GB hard drive for SQL data storage 100 GB for temporary storage of structured files such as backup files.

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

Production Application Server:

Perf-app-p1.hrsa.gov, virtual machine 2 core CPUs at 2.20G GHz4 GB RAM 50 GB hard drive for operating system 100 GB hard drive for data storage

The servers are deployed across the Dev/Test and Production environments as shown in Figure 3. HRSA/OIT maintains these servers.

RESTRICTED

Figure 3: Environment

MCHB DB

Server

(perf-db-prod2)

HAB DB Server (hab-db-prod2)

GEMSDB1EHBs Prod

Access Perf Reports

BRS Production 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 (PL): 2.35.25

Updated: 1/6/2016 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?

RESTRICTED

Table 1 further describes these servers and how they are configured.

Table 1: Server Specifications

SOFTWARE SPECIFICATIONS

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

Database Operating

System

Server

Application Application

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

MS

Windows 2008 R2 Server

MS

Windows 2008 R2 Server

MS Internet Information Server (IIS)

7.5 or later

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

• Internet Explorer 9 or later

• Windows 2008 R2

• 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

REI)

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 PTR web application consists of the following software components, which are illustrated in Figure 4:

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

Microsoft .Net Framework 4.5

RESTRICTED

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 ReSharper plugin for Visual Studio 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:

PTR Web Application HRSA Performance System Login and Registration Application Configurable Data Conversion Application Various Windows services that support the RSR Web Application Various SQL Server Reports

The PTR web application supports Microsoft Internet Explorer Version 9.0 and up, Google Chrome 36, and Mozilla Firefox 30 using the SSL protocol.

Figure 4: Software Components

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

4.5 PTR Application Layers

The PTR web application (depicted in Figure 5) consists of the following six layers:

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

RESTRICTED

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

3. PTR Presentation Layer: Contains the PTR web application user interface.

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

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

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

Figure 5: PTR Application Layers

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 like user contact information, report information, authorized resources of the systems (both EHBs users and non-EHBs users), access control, HAB

RESTRICTED

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 class that needs 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 IHabMainMaster, 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:

PTR Validation Service HAB Email Process Windows Service

5 Detailed System Design

The PTR web application consists of the following components:

Grantee Contract Management System (GCMS) Contract Synchronization Email Engine Validation Engine Workflow Engine PTR File Upload

5.1 Grantee Contract Management System (GCMS)

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

5.1.1 Responsibilities

GCMS is 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 grantee user on the Program Information page.

RESTRICTED

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

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 Contract Synchronization

At the time of report creation, the GCMS contracts that fall within the appropriate reporting period automatically get copied over to the report. Any subsequent changes to the original contract will show a warning icon next to the contract in question and allow the user to view the modifications and optionally re-sync the contract.

During the initial report creation, a stored procedure is used to find all the contracts that fall within the reporting period in the CMS_Contract table. Those contracts are copied over to the HAB_Contract table, with a foreign key pointing back to the original contract as well as any services that are associated with the contract.

Subsequently, when a user navigates to the CLC Report, or the Allocation report pages, a comparison is performed to check if any contracts need to be synchronized. In order to do that, the PTR Report Service is used to retrieve all the contracts for this report from the HAB_Contract table. Similarly, the CMS Contract service is used to get all the contracts that fall within the current period. The two lists are then compared, and there are 4 possible types of changes that can exist for a contract:

1. A HAB Contract exists, but there’s no matching CMS contract. This means that a contract has been deleted form CMS and might need to be removed from the PTR Report.

2. A CMS Contract exists, but there’s no matching HAB contract. This means that a contract has been added in CMS and might need to be added to HAB.

3. A match is found between the CMS and HAB contracts, but the CMS contracts dates have changed, and are no longer within the reporting period. This would

RESTRICTED

make the HAB contract eligible for deletion, since the original no longer belongs to the report.

4. A match is found between the CMS and HAB Contract and the dates haven’t been moved outside the period, so the services associated with the contract need to be compared. This is done by building a list of CMS Contract Services and HAB Contract services and comparing them. If any services have been added, removed, or had their dollar amount changed, this raises a warning and allows the user to perform the synchronization.

Once the list of differences have been determined, a warning icon is displayed next to a contract that has changed, as well as a warning at the top of the page, with the list of contracts that have changed. Selecting the icon or the link takes the user to another page where they can review the changes, and optionally perform the synchronization.

Based on the list above, there are only three possible synchronization actions that can be taken, and all are performed by the HAB Contract Service:

1. A contract is copied over from CMS to HAB if it’s new.

2. A contract is deleted from HAB if it’s been deleted in CMS (or moved outside the reporting period)

3. The contract is updated with the new information. This is done by updating all the fields in the HAB Contract from CMS contract, removing all the services from the HAB Contract, and then repopulating them with the services from CMS.

5.3 Email Engine

The Email Engine handles all email processing for the HAB applications.

5.3.1 Responsibilities

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

5.3.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 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

RESTRICTED

5.4 Validation Engine

5.4.1 Responsibilities

The Validation Engine is designed to validate all kinds of reports including the Program Terms Report, the Grantee Report, the Provider Report (Including the Client Report), and the Check Your XML Report.

5.4.2 Processing

A report is considered valid if it passes all the Validation Rules. Each Validation Rule is defined as a Check Code. Program Terms Reports, 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 will be saved in the [habAdmin].[HAB_ValidationResult] table.

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

5.4.3 Check Codes

The following code snippet shows an example of a check code.

This is check code number 10, which is used to valid that a report’s EIN is not empty.

5.4.4 Validation Windows Service

In order to run a report validation, a user will have to submit a validation request. All the validation requests are saved in the [habAdmin].[HAB_ValidationRequest] table. Each report has only one request at any time.

The Validation Windows Service monitors the validation request table. Any pending request will be processed in the order it was requested. The following shows an example of checking and processing validation requests.

In the above code snippet, Line 76 shows the windows service getting the entire validation requests. Line 85 to 105 shows each request being processed and its status being updated.

5.5 Workflow Engine

The design of 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 and the rest are passed to the next processing object in the chain. In the PTR Workflow Engine design (Figure 8), a list of workflow status objects are chained 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: PTR Workflow

When a workflow action is initialized, a WorkFlowRequest object will be created and processed by a WorkflowProcessService object. Below is an example of the code to perform this action.

In the above code snippet, a PTR report workflow status change request from “Not Started” to “In Progress” is created. Lines 144 to 152 shows the PtrWorkflowRequest creation and Lines 154 to 155 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. In the ProcessRequest method, it will perform “Update workflow status”, “Queue an EHBs request to update EHBs deliverable status”, and “Log the workflow action”. Below is an example of the code to perform this action.

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

Lines 24 to 31 queues a request to update the EHBs deliverable status. Line 32 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. Below shows an example of the loop to find the match workflow status object in the chain.

The sequence diagram below shows the participants that are involved in the status change described above – the status of a PTR report changes from “Not Started” to “In Progress”, and the methods that are called from each participant.

Create Report

PtrReportService PtrWorkflowProcessService PtrNotStarted

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.

RESTRICTED

5.6 PTR File Upload

Application users have the ability to upload documents that are required for the PTR. A list of required or optional documents is specified though the HAB Admin Tool (HAT) based on the grant Part number. When a user navigates to the File Upload page, the PTR Document Service returns two lists of documents: Instructions and Submission Components. For the Submission components, a user will have the ability to download a document template (which may, or may not be provided) and in turn upload a document to correspond to that component. In the HAB Admin Tool, a particular submission component might restrict the file types that are allowed to be uploaded, and the page will enforce that rule, preventing faulty submissions.

The user also has the ability to upload any number of supplemental documents to a report.

The templates, as well as the documents are retrieved and stored using a service, which is depicted in the code below.

public interface IPtrTemplateService IEnumerable<PtrTemplate> GetAll();

IEnumerable<PtrTemplate> GetTemplatesByReportPeriodAndFundSource( int reportPeriodId, int fundSourceId);

PtrTemplate GetTemplateById(Guid id);

IEnumerable<PtrTemplate> GetTemplatesByListOfFundSources( IList<FundSrcLkup> fundSources);

void InsertTemplate(PtrTemplate template);

void DeleteTemplate(PtrTemplate template);

void UpdateTemplate(PtrTemplate ptrTemplate);

The documents are physically stored inside Microsoft SQL Server, using Filestream.

6 Database Design

The following embedded file contains the database design for the PTR web application.

7 External Interfaces

This section describes the interfaces between the PTR web application and its external interfaces.

RESTRICTED

7.1 Email Notifications

Depending on each stage of the PTR report workflow, each involved user will be notified by email. For example, when a user returns a PTR 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

PTR is integrated with the EHBs through Platform Lite, an integration framework that provides consistent look and feel with the EHBs as well as backend integration such as deliverable status updates (Figure 9). The current version of Platform Lite being used is 2.35.25.

Figure 9: EHBs Integration

ADR

EHBs

IHttpModule

RSR MAIFORHP AETC

WCF Service

EHBs Gateway:

- Authentication/ Authorization

- Status Updates

- OFAM status

- Deliverable Management

- User Management

- Other

IHttpModuleIHttpModuleIHttpModuleIHttpModule

REI 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

PTR

IHttpModule

A Platform Lite integration layer is used to help all Bureau Reporting Systems (BRS) integrate with Platform Lite (Figure 10). 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

RESTRICTED

Interface (UI) Integration Design Document embedded below for the detailed design of this layer.

EHBs New User

Interface Integration.docx

Figure 10: Platform Lite 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"/>