oop final project documentation jose pagan v2.1

MVP Development Corporation

Event Driven Process Manager Software Architecture Document

Pre-Design Project Proposal and Work Plan Project Requirements / Documentation

Design Documentation Installation Instructions

Version 2.1

MVP Development Corporation Version: 2.1

Software Architecture Document Date: 28/January/2017

EDPMAD

Confidential MVP Development Corporation

2017

of 24

Revision History Date Version Description Author

September 28, 2009 1.0 Initial Design Version José Pagán

November 2, 2009 2.0 First Implementation

Additional classes were added, see revised

Class Diagram in Section 5.1.

Additional Documents were included in the

following Appendices:

I. Pre-Design Project Proposal and

Work Plan

II. Project Requirements / Documentation

III. Design Documentation

IV. Installation Instructions

Jose Pagán

January 28, 2017 2.1 Proofreading José Pagán



EDPMAD


2017

of 24

Table of Contents

1. Introduction 4

1.1 Purpose 4 1.2 Software Description 4 1.3 Tools for Analysis 4 1.4 Scope 4 1.5 Definitions, Acronyms, and Abbreviations 5 1.6 References 5 1.7 Overview 5

2. Architectural Representation 5

3. Architectural Goals and Constraints 7

4. Use-Case View 7

4.1 Use-Case Realizations 7

5. Logical View 9

5.1 Overview 9

6. Process View 12

7. Deployment View 13

8. Implementation View 13

8.1 Overview 13 8.2 Layers 13

9. Size and Performance 14

10. Quality 14

Appendix I – Pre-Design Project Proposal and Work Plan 15

Software Description 15 Tools for Analysis 15 Work Plan 16

Appendix II – Project Design and Documentation 17

Business Rules 17 List of Events 18

Appendix III – Design Documentation 20

Appendix IV – Installation Instructions 23



EDPMAD


2017

of 24

Software Architecture Document

1. Introduction

1.1 Purpose

The purpose of this Software Architecture Document is to describe, through the use of diagrams and

descriptions, the architecture of the Event Driven Process Manager application. The document provides a

comprehensive architectural overview of the system, and conveys the significant architectural decisions

which have been made in the development of Event Driven Process Manager. A Pre-design Project

Proposal and Work Plan, Project Requirements / Documentation, Design Documentation, and Installation

Instructions have been included in the Appendices.

This document depicts different aspects of Event Driven Process Manager using a number of different

architectural views based on Philippe Kruchten’s “4+1” View Model of Software Architecture. Each one

of these views is intended for a different audience. For example, the logical view is used by software

architects for functional analysis, while the use case view provides users with a quick understanding of the

functionality of the software.

This document is intended to give architects, developers, software engineers, project managers,

programmers and power users a thorough understanding of the Event Driven Process Manager architecture

to assist in the analysis, reverse engineering and maintenance of the application.

1.2 Software Description

Event Driven Process Manager is a Console based (Win32) single user software application that allows the

user to manage various tasks performed by employees and other participants in an event driven process.

The application processes different types of events, creates an event log, validates that each event complies

with the rules and parameters provided in an Event Category List, and assigns an agent from an Agent List

to each event, if one is available. If the event does not comply with the rules or parameters specified in the

Event Category List, or there is no agent available to handle the event within the required constraints, the

application generates an exception report. The application also generates a Job Status Report once all the

events have been processed.

Event Driven Process Manager is a free open source application written in C Sharp. The program will

process events from an input file or through manual entry. Reports may be sent to the console or to a

printer. The initial release is limited to reading from a file and output to the console.

1.3 Tools for Analysis

MVP Development Corporation used Microsoft Visual Studio 2008, Microsoft SQL 2008 and Microsoft

Visio to create the application and generate diverse diagrams, including some UML diagrams.

1.4 Scope

This Software Architecture Document applies to the Event Driven Process Manager system, including all

its components and connections. The architecture, forms, functions, files, tools, packages and

configuration of the system are all affected by this document.



EDPMAD


2017

of 24

1.5 Definitions, Acronyms, and Abbreviations

Architecture - The way the components of a computer or computer system are organized and integrated.

Architectural Style – idiomatic patterns of system organization, organizational principles and structures for

certain classes of software.

Components - a reusable black/grey-box entity (a piece of code) with well-defined interface and specified

behavior which is intended to be combined with other components to form a software system (an

application).

Connectors – abstractions that allow for a clear separation of the application’s business logic from the

communication middleware.

UML – The Unified Modeling Language (UML) is an open standard method used to specify, visualize,

construct and document the artifacts of an object-oriented software-intensive system.

1.6 References

Christine Hofmeister, Robert Nord and Dilip Soni, Applied Software Architecture, Addison-Wesley

Professional (November 14, 1999).

M. Shaw, D. Garlan (1996). Software Architecture: Perspectives on an Emerging Discipline. Upper Saddle

River, NJ: Prentice Hall.

Kruchten, P., Architectural Blueprints—The “4+1” View Model of Software Architecture, IEEE Software

12(6), November 1995

First ECG Software Services, Applying 4+1 View Architecture with UML 2, 2007

Dusan Balek, Connectors in Software Architectures, Charles University 2002

1.7 Overview

The rest of this Software Architecture Document contains a description of the architectural representations

used (Section 2), the architectural goals and constraints of the system (Section 3), the architectural views of

the system (Sections 4 to 9), size and performance issues (Section 10), and quality issues (Section 11). The

appendices contain a Pre-design Project Proposal and Work Plan, Project Requirements / Documentation,

Design Documentation, and Installation Instructions for the application.

2. Architectural Representation

The system's architecture will be described using Kruchten's 4+1 View Model shown in Figure 1 below.



EDPMAD


2017

of 24

Figure 1 - 4+1 View Model

The model consists of 5 views used to represent different layers of the system's architecture. These views are:

i. Logical View (Object Oriented Decomposition) - This view focuses on realizing an application’s

functionality in terms of structural elements, key abstractions and mechanisms, separation of concerns

and distribution of responsibilities. Architects use this view for functional analysis.

ii. Process View (Process Decomposition) - This view considers non-functional aspects such as

performance, scalability and throughput, and addresses the issues of concurrency, distribution and fault

tolerance. It shows the main abstractions from the Logical View executing over a thread as an

operation

iii. Implementation or Development View (Subsystem Decomposition) - This is a view of a system’s

architecture that encompasses the components used to assemble and release a physical system. This

view focuses on configuration management and actual software module organization in the

development environment.

iv. Deployment or Physical View (Mapping Software to Hardware) - This view encompasses the nodes

that form the system’s hardware topology on which the system executes; it focuses on distribution,

communication and provisioning. This view accommodates the non-functional requirements such as

availability, reliability, performance, throughput and scalability, and provides all possible hardware

configurations, and maps the components from the Implementation View to these configurations.

v. Use Case View or Scenarios (putting all together) - In addition to the four views discussed above, this

is the central view for capturing scenarios. The Use Case View encompasses the use cases that

describe the behavior of the system as seen by its end users and other stakeholders. Although

traditionally discussed as the last view, this is the first view created in the system development

lifecycle.



EDPMAD


2017

of 24

3. Architectural Goals and Constraints

The objectives of Event Driven Process Manager that have a significant impact on the architecture include:

Safety, Security and Privacy – the application provides for login and password verification.

Future enhancements may include encryption.

Off-the-shelf product – Event Driven Process Manager is a standalone, self-contained application.

Future enhancements will include an installer and an internet connection to search for and install

updates.

Portability, Distribution and Reuse – Event Driven Process Manager is an open source application.

The source code may be easily ported to other platforms or reused in a new application.

Special Constraints – the software must be user friendly and easy to use. It must have a self-

contained help facility that serves as a user manual.

Design and Implementation Strategy – The system is written in C# using Visual Studio 2010 for

Windows and uses a Microsoft SQL 2008 database.

4. Use-Case View

This section illustrates the Use-Case view applied to Event Driven Process Manager.

4.1 Use-Case Realizations

The following Use-Case Realizations illustrate the basic functionality of Event Driven Process Manager

from the user’s point of view.



EDPMAD


2017

of 24

Use Case View

Actor1

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

Process Event File

Print Job Status

Report

Load Event

Categories File

Load Agent List

File

Process Event

(Manual Input)

Add Event

Category

(Manual Input)

Delete Agent

(Manual Input)

Add Agent

(Manual Input)

«uses»

Figure 2 - Use-Case Descriptions

Process Event File: The user may add and processes events from a file and generate an Event

Processing Report and an Exceptions Report.

Print Job Status Report: The user may print a status report for each job being worked on, including

a list of events associated with each job, the agent assigned and its corresponding status.

Load Event Categories File: The user may add event categories to the Event Categories list from a

file.

Load Agent List File: The user may add agents to the Agent List from a file.



EDPMAD


2017

of 24

Features for future development include:

Add Event Category: The user may add event categories to the Event Category List manually

(through the keyboard).

Add Agent: The user may add agents to the Agent List manually (through the keyboard).

Delete Agent: The user may delete agents from the Agent List.

5. Logical View

This section describes the architecturally significant parts of the design model, such as its decomposition

into subsystems and packages. Each significant package is decomposed into classes and class utilities. The

architecturally significant elements and responsibilities are described, as well as important relationships,

operations, and attributes.

5.1 Overview

Software Architecture may be defined based on the implementation of the Perry and Wolfe Equation as:

Software architecture = {Elements, Forms, Rationale/Constraints}

The application was built using the JP.Framework. The main classes of the JP.Framework used in the

application are shown below:



EDPMAD


2017

of 24

The JP.Data Class Library also references the Koko.Data.dll in the Koko.Framework. The JP.Data

DataSource.getDataReader method uses the dataSourceCollection and dataProvider classes in the

Koko.Data.dll to connect to the database. The dataProvider executes SQL stored procedures to access

tables in the database.



EDPMAD


2017

of 24

Figure 3 below shows a class diagram with the most significant elements of Event Driven Process

Manager.

Figure 3 - Logical View of Event Driven Process Manager in Terms of Classes

The system architecture is organized around the EventCategory Class, a class that contains the variables,

criteria and constraints for events. Additional application classes were created to initialize and load data

into the application, validate events, assign agents, and report exceptions. The application uses lists of the

EventCategory, Job, Agent, Service and Customer classes.

The IEntity class in JP.Data.DataObjects is an interface to force print and loadFields methods on all derived

classes. Separate classes have been created for Login, Error Handling, and Output.

A #define Verbosity directive was used to adjust the trace and error console messaging during operation.

Customer Job Event

CustomerId JobId EventId

CustomerName JobEventList EventDateTime

CustomerAddress JobCustomerId EventCategoryId

CustomerTelephone JobServiceId EventAgentId

CustomerServiceTypeId JobAmountPaid EventJobId

EventCategoryConstraintText

EventCategoryConstraintStatus

EventCategoryConstraintAmount

Service Event Category

ServiceId EventCategoryId Agent

ServiceName EventCategoryProcess AgentId

ServiceDescription EventCategoryName AgentName

ServiceCost EventCategoryDescription AgentAvailableDate

EventCategoryPreviousEvent

EventCategoryNextEvent

EventCategoryDuration

EventCategoryAgentList Constraint

EventCategoryConstraintList ConstraintId

ConstraintCategoryId

ConstraintCategory ConstraintParameter1

ConstraintCategoryId ConstraintParameter2

ConstraintDescription



EDPMAD


2017

of 24

6. Process View

The following diagram illustrates the system's decomposition into processes.

Event Input

File

Event

Log List

Event.Get

Event

Categ.

List

Event.Validate

Pass

Fail

Agent

List

Event.

Reportexeption

Event.

AssignAgent

Fail

Job

List

Event.Register

Pass

Output

Interface

Console

Event.

Reportevent

Manual Input

Report

Event

Category List

File

Agent List File

Print Jobs Status

Report

Input

Interface



EDPMAD


2017

of 24

7. Deployment View

This program is run on a single PC running under Windows. It requires connection to a Microsoft SQL

2008 database.

8. Implementation View

This section describes the decomposition of the software into layers and subsystems in the implementation

model, and any architecturally significant components.

8.1 Overview

The most significant layers used are Application Management, Security Management, Error Handling, Data

Management and User Interface.

8.2 Layers

The most important classes used in each layer are described below.

Application

Management

A Session class was created to manage the application including various static

methods such as sessionRun, sessionIinitializeLoadData and

sessionProcessEvents. The sessionRun method calls the Login.loginValidate

and Help.helpPrint methods.

Security Management A Login class was created to provide security using the loginValidate method.

The User must login with a valid user name and password before processing.

Error Handling A separate ErrorHandling class was created with the errorHandlingPrintMethod

to handle all try catch exceptions.

Data Management An interface called IEntity was developed to force uniformity among derived

classes such as Agent, Customer, Event, EventCategory and Service. These

concrete entities override the print() and loadFields() methods but must follow

the structure of the virtual class. The loadFields method uses a GetDataReader

class to access the Database.

All DataObjects contain a loadFields method to populate the class by reading

the database. A class called getDataReader is used to pass a DataReader to the

DataObjects. getDataReader uses the dataSourceCollection and dataProvider

classes form the Koko.Framework. The dataProvider executes SQL stored

procedures to access the tables in the database.

All DataObjects contain a print method to print its contents. All print contents

are directed to the Output User Interface to be sent to the console using the

Output.outputPrintLine method.

List classes and List of List classes are used extensively.

All data from the EventDB Database is loaded to the DataObjects at the

beginning of the program using the sessionInitializeLoadData method. These

DataObjects remain open throughout the session to maximize performance.

UI (Presentation Layer) All output is handled by the Output class with the outputPrintLine method.



EDPMAD


2017

of 24

9. Size and Performance

The application maintains the entire database in list classes in memory to maximize performance. Large

amounts of memory may be needed for large applications.

10. Quality

The application was developed using a framework and object oriented programming techniques to facilitate

maintenance. Data objects were standardized using the IEntity interface and method overloading was used

to adjust the print and loadFields methods for each class. Encapsulation, inheritance and overloading

techniques were used to maximize code reuse and minimize code generation.

Input and output transition classes were provided to facilitate connecting to different input and output

devices without modifying the application code. The #define directive was implemented to control

Verbosity. Separate class libraries were used for Security, Data, User Interface and Diagnostics, to

facilitate maintenance and future reuse.

The JP.Framework references the Koko.Framework directly, allowing future upgrades to the

Koko.Framework to be incorporated into the JP.Framework.

.



EDPMAD


2017

of 24

Appendix I – Pre-Design Project Proposal and Work Plan

This Pre-Design Project Proposal and Work Plan provide a description of the application and tools used in

this project, and an updated Work Plan. For more details about the assumptions made, please refer to the

Software Architecture Document above.

Software Description

Event Driven Process Manager is a Console based (Win32) single user software application that allows the

user to manage various tasks performed by employees and other participants in an event driven process.

The application processes different types of events, creates an event log, validates that each event complies

with the rules and parameters provided in an Event Category List, and assigns an agent from an Agent List

to each event, if one is available. If the event does not comply with the rules or parameters specified in the

Event Category List, or there is no agent available to handle the event within the required constraints, the

application generates an exception report. The application also generates a Job Status Report once all the

events have been processed.

Event Driven Process Manager is a free open source application written in C Sharp. The program will

process events from an input file or through manual entry. Reports may be sent to the console or to a

printer. The initial release is limited to reading from a file and output to the console.

Tools for Analysis

MVP Development Corporation used Microsoft Visual Studio 2008, Microsoft SQL 2008 and Microsoft

Visio to create the application and generate diverse diagrams, including some UML diagrams.



EDPMAD


2017

of 24

Work Plan

Feature Week Priority Status

1

Pre-Design Project Proposal 1 1 Done

2

Work Plan 2 1 Done

3

Project Requirements and Documentation 3 2 Done

4

Design Documentation/Framework Guidelines 4 3 Done

5

Framework Infrastructure 5 4 Done

6

Sample Database 6 5 Done

7

Application Design - Basic Functionality for Flow Control

Application Management 8 6 Done

Security Management 9 8 Done

Error Handling 9 8 Done

Data Management 7 6 Done

UI (Presentation Layer) 9 8 Done

8

Additional Event Validation Features

Validation of Agent Availability 11 9 Pending

Validation of Time, Status and Amount Constraints 12 9 Pending

Manual Data Entry and Output to Printer 12 9 Pending

9

Testing 10 9 Done

10

Finalize Design Documentation 10 9 Done



EDPMAD


2017

of 24

Appendix II – Project Design and Documentation

Business Rules

Issue Description

Process Flow Processes and related events must be keep in order, since quite

a few of them require that previous events be completed before

they start or are possible.

Process/Event Constraints Each process and/or event may have none, one or many

constraints typically of the following form:

Date – Time Constraint – the total number of days and/or hours that the event has before it is considered expired and not valid anymore. Or it can be used as a date-time to set an alarm or time to trigger another event that requires some action.

Amount Constraint – this is a floating-point value that may be used to set the full amount of something that must be part of the event.

Text Constraint – a string text value that could be used and/or compared to set the valid and expected value.

Status Constraint – given a list of possible status values, each with a specific meaning, including: accepted, requires revision, archived, dismissed, rejected. The constraint will require routing the process / event to another process or event.

Next Event When looking at any event, the following or next event must be

known at all times.

Individuals Identities The identity of each individual should be unique and be related

his event capabilities.

Individual Capabilities Each individual is associated with a level of capability that

clarifies the individual to participate in a given event.

Individual Roles A single individual could have various roles within the process /

event flow.

Services Offered Service Description Price

Service A Deluxe Service $10,000

Service B Cheap Service $20,000

Service C Intermediate Service $50,000



EDPMAD


2017

of 24

List of Events

Event Note

Process: Request

Request Registration The customer request is registered as soon as the customer fills

in a set of documents.

Request Pre-Review An agent reviews the submitted documentation and accepts,

requires revision to customer, or rejects the registration. If the

submission is rejected, the customer has 2 weeks to resubmit

from registration date.

Customer Payment Customer pays specific amounts based on the request type.

Only if the full amount is paid, the request will be sent to the

following processes and/or events. After customer receives the

pre-approval, the customer will pay a specific amount. He/she

has two months from the initial registration date to pay, else the

registration is canceled and the documentation must be submitted

in full again.

Final Pre-Review Again, agent reviews the submission and accepts or approves it

for further consideration. Upon consideration, the request is

queued for investigation. Note that after the request is queued,

the company has 15 days to start the “Investigation” process.

Process: Investigation

Investigation Notification Upon the de-queuing of a request for consideration by an Agent,

a notification notice must be sent to the requester to alert him/her

about the start of the “Investigation” process.

Inspection Request An agent schedules a Visit with the requester for inspection. The

customer has 30 days to setup the first inspection and get

inspected.

Inspection The agent inspects whatever needs inspection and collects all

needed information and/or photos for further evaluation.

Request Review Agent reviews the documentation submitted, the data collected

during the inspection, and the applicable rules for approval or

rejection, and prepares a document with the decision. The review

should be completed within 3 days after inspection.

Results Notification The customer is notified to personally review the results.

Results Review The Agent and the Customer review the results and agree

whether to proceed with the service. If an agreement is reached,

the service request is queued. The company has 15 days to call

the customer to schedule of the requested service.



EDPMAD


2017

of 24

Process: Service

Service Notification Upon the de-queuing of a request for service by an Agent, a

notification notice is required to be sent to the requester to alert

him/her about the start of the “Service” process.

Service Request An agent schedules a Visit with the requester for service. The

customer has 30 days to setup the first service.

Service The agent provides the service and collects all needed

information and/or photos for further approval.

End of Service Notification The collected service documentation is delivered to the customer

for his/her approval. This notification should be submitted to the

customer not later than 1 week after the service has been

completed.



EDPMAD


2017

of 24

Appendix III – Design Documentation

The project was designed and built using the JP.Framework, a framework derived from the

Koko.Framework developed by Dr. Eduardo Sobrino. This framework references the Data.dll from the

Koko.Framework and utilizes the dataSourceCollection and dataProvider classes of the Koko.Framework

to create its own dataReader class. The dataProvider executes SQL stored procedures to access the tables

in the database.

The JP.Framework application guidelines are customized for this project based on end user needs.

Application Guidelines

The following lists of guidelines are provided to framework users to ensure maintainability and consistency in their projects:

Interfaces Use Interfaces to enforce a contract on their users that will specify what properties and methods should be implemented along with their signature (name, arguments and parameters). Always use an “I” (i) in front of the name of the Interface to distinguish it from a class, for example “IDisposable”.

Enumerators When writing an enumerator always reserve the “0” (zero) value for the “Unknown”. Expect users to use the “Unknown” value on those occasions that the value is not provided or known at the time they are entering the data.

Destructors Implement a destructor when your class contains unmanaged resources or any resource that consumes lots of space or holds another resource that is costly to maintain. For example, on Database Connections.

When a using a class that implements the IDisposable pattern, always call the Dispose method.

For classes that manage expensive resources, always instantiate them as late as possible and dispose of them as early as possible.

Private Fields All private fields’ identifiers will begin with “m_” and will continue with the Camel Notation, for example “m_MyInternalField”.

Methods Arguments All method arguments identifiers will begin with a lowercase word and will continue with the Camel Notation.

Property Names All public property identifiers will be written using the Camel Notation.

A property should be created for each class field; no class field may be accessed directly.

Public Fields All public field identifiers will be written using the Camel Notation. Global variables will begin with “A” or “An” prefixes.

Assemblies All framework dll files are built in the JP.Framework/Assemblies/Debug folder.



EDPMAD


2017

of 24

A description of the most important helper classes used is also provided below.

Application Management

A Session class was created to manage the application including various static methods such as sessionRun, sessionIinitializeLoadData and sessionProcessEvents. The sessionRun method calls the Login.loginValidate and Help.helpPrint methods.

Security Management A Login class was created to provide security using the loginValidate method. The User must login with a valid user name and password before processing.

Error Handling A separate ErrorHandling class was created with the errorHandlingPrintMethod to handle all try catch exceptions.

Data Management An interface called IEntity was developed to force uniformity among derived classes such as Agent, Customer, Event, EventCategory and Service. These concrete entities override the print() and loadFields() methods but must follow the structure of the virtual class. The loadFields method uses a GetDataReader class to access the Database. All DataObjects contain a loadFields method to populate the class by reading the database. A class called getDataReader is used to pass a DataReader to the DataObjects. getDataReader uses the dataSourceCollection and dataProvider classes form the Koko.Framework. The dataProvider executes SQL stored procedures to access the tables in the database. All DataObjects contain a print method to print their contents. All print content is directed to the Output User Interface and sent to the console using the Output.outputPrintLine method. List classes and List of List classes are used extensively. All data from the EventDB Database is loaded to the DataObjects at the beginning of the program using the sessionInitializeLoadData method. These DataObjects remain open throughout the session to maximize performance.

UI (Presentation Layer) All output is handled by the Output class through the outputPrintLine method.

Security Management

User Authentication and Authorization

Provides select authentication authority.

o Operating System - Windows based authentication o Database Management System o Directory Services (LDAP)

Windows based authorization is being used to access the EventDB database.



EDPMAD


2017

of 24

Data Encryption

Encrypt / Decrypt

Hashing

Encryption will be done in future development.

Error Handling (Diagnostics)

Error Logging (to a File or System Log) – Validation errors are concatenated into a string and sent to the output device after each event is processed.

Exception Handling strategy - provide specific classes to trap issues. All exception handling through try/catch should always include the “General” exception to trap “System.Exception” instances.

Create the User Feedback strategy when an exception happens and is trapped by the Framework.

Data Management

While working with Databases, the following technologies are commonly used to work the needed connectivity, request submission, error / exception management and results gathering:

ODBC Object Database Connectivity

OLEDB Object Linked and Embedded Database (Connectivity)

ADO Access Database Object

DAO Direct Data Object

JDBC Java Database Connectivity

CLI Class Library Interface

.Net Providers Manage providers available in .Net

Provide a Collection of DataSources that will store connection strings that will be targeted to a provider and accessed in the application by a Key. This class should provide the necessary connection string encryption without the developer having to be concerned with the security issue.

The Framework should provide a Data Layer that has a Class that resolves the connection to the database once the Connection String is provided, ideally using a single method.

The JP.Framework uses the dataSourceCollection and dataProvider classes in the Koko.Framework.



EDPMAD


2017

of 24

Appendix IV – Installation Instructions

The application has been created in C# using a framework named JP.Framework. JP.Framework must be installed

in the same directory as the Koko.Framework as it references the Koko.Data.dll in its JP.Data Class Library.

The sample datatabase tables are included in an Excel Spreadsheet named Data Structures 7. To load the Database,

create a database in Microsoft SQL 2008 and load the tables using the Import and Export Data (32 bit) utility. The

connection string in the JP.Data.DataSource.getDataReader must be updated with the proper server and database

names. A stored procedure must be created for each table in the database using the following stored procedure

names:

Sample stored procedure script is provided below:

USE [EventDb]

GO

/****** Object: StoredProcedure [dbo].[Agent$_Select] Script Date: 11/01/2009

23:08:44 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

-- =============================================

-- Author: <Author,,Name>

-- Create date: <Create Date,,>

-- Description: <Description,,>

-- =============================================

CREATE PROCEDURE [dbo].[Agent$_Select]

-- Add the parameters for the stored procedure here

AS

BEGIN

-- SET NOCOUNT ON added to prevent extra result sets from

-- interfering with SELECT statements.

select * from Agent$

END



EDPMAD


2017

of 24

The level of verbosity in the application may be reduced by deleting the #define Verbosity directive at the beginning

of the Application Program.

Once the application is executed, it requests a user id and a password. Enter Sob for id and OpenK for password.

Next, the program will display a help screen. Press enter to execute. The program loads the database into lists of

Jobs, Event Categories, Customers and Agents. It then processes the events from the EventInputFile$ located in the

database. At the end of processing, enter Return to see the updated Job Report.

oop final project documentation jose pagan v2.1

Data & Analytics