EP-III Design (Previous Phase)

E-Permitting Design

EP-III Design (Previous Phase):

The architecture of EP-III was broadly categorized in to following layers:

Presentation Behavior Application Business Data Access

(Custom Transaction Layer)

a)Presentation

b)Behavior

c)Application

d)Business

e)Data Access Layer

Implementations at various layers include

a)Presentation: JSP, HTML

b)Behavior: Struts (1.0)

c)Application: Value Objects

d)Business: EJB

e)Data Access Layer: Custom Transaction Layer.

EP-IV Design (Current Phase):

Presentation Behavior Application Business Data Access

(Data Access Layer)

The on-line applications that get included in EP-IV are ERP and CUP. The complexity in these new applications arises from the fact that the actual forms and information are complex and huge in amount.

There were some design changes that were required at some layers to accommodate the complexity.

Data Access Layer

For the database layer, the decision was made to move from the custom transaction layer to the DAO layer (an implementation of DAO pattern).

Motivation:

E-Permitting has requirements where it needs to access persistent storage and legacy data. There is a need to separate the data access from the business functionality and hence to need to abstract the business logic from the data access related functionality.

Solution: E-Permitting achieves the result by applying Data Access Object (DAO) pattern.

Structure:

The benefits of using DAO

1)DAO approach provides flexibility to change an application’s persistence mechanism over time without the need to re-engineer application logic that interacts with the DAO tier

2)The DAO design pattern also provides a simple, consistent API for data access that does not require knowledge of JDBC etc.

3)It centralizes all data access in one single layer.

4)Less complexity in business layer.

Approach:

Epermitting’s long-term goal is to switch to JTA supported transactions. But currently the server environment doesn’t permit the use of JTA supported transaction. So, the solution was created to have the flexibility to use the JTA transactions whenever the server upgrade was done. The flexibility is provided with the use of configuration variable, which says whether it is an SJRManaged transaction or otherwise (JTAManaged).

The config settings:

<TransactionManagement name="SJRManaged" />

The sample usage:

TxEnvContext ctx = TxEnvContext.getInstance ();

UserTransaction uTr = null;

try

{

uTr = ctx.getTransaction();

uTr.begin();

DAOFactory daofactory = DAOFactory.getInstance();

CountyDAO countyDAO = daofactory.getCountyDAO();

countyDAO.updateLogTable(2, uTr);

uTr.commit();

}

catch(DAOException daoexception)

{

daoexception.printStackTrace();

uTr.rollback();

}

catch(Exception exception1)

{

exception1.printStackTrace();

}

When the migration of the server is done to the version that supports JTA transactions, then TxEnvContext’s getTransaction () method will have to be modified to return JTA’ s UserTransaction object returned after JNDI lookup.

Behavior Layer: -

Some changes in the behavior layer include the following:

The idea is to view an Action Form as a scratch pad (i.e. white board). Every action form should have the capability to return the value object that represents its state and vice-versa should be able to set it-self, when it is given a value object. Every action form inherits from a base action form. There is a one-one mapping between an action form and a value object. The value object that the action form is associated with can aggregate other value objects.

BaseActionForm

The important methods included in BaseActionForm include:

SetData(Object) : The objective of this method being, give a value object, the

ActionForm is the best entity to populate itself. All derived action forms should override the default implementation and provide its own implementation.

GetData() : When this method is invoked, the action form should prepare a value object

Representative of the value the enters on the screen and which he indicates

is final(to be saved or to submit). All derived action forms should override the default implementation and provide its own implementation.

SetName(String): The method is responsible to give the action form(i.e. scratch pad) its name.

GetName (): Gets the name of the action form (scratch pad).

SetDataChanged(Boolean): This method is invoked when there is a state change in the action form.

GetDataChanged(): Gets the state change status of the action form.

ERPActionController

ERPActionController is the initial point of contact for the ERP application. It handles the following application events:

a)Init: This event is invoked upon login and click of ERP application menu item. If the user has list of pending forms, then those are displayed along with an option to launch a new ERP application. If not, then the first step is launched automatically.

b)Load: This event occurs on the selection of form id from the list of pending form ids.For the load of selected form id information, the ERPActionController works in conjuction with ERPAction(described next).

c)New: This event clears of the previous ERP keys from the session and starts a new ERP.

d)headeraction: When a new ERP application is launched, the first page (ERP Decision), allows the option to the user to select the type of ERP application. Once the selection is made, on click of Next, this event is fired on ERPActionController. On firing of this event, the handler assists in the display of appropriate tabs.

ERPAction

This is the action class that takes care of the actions the user takes on the scratch pad and also general commands like Next, Exit and Previous.

In handling the actions taken by the user on individual scratch pad, action is assisted by individual helpers. As the user navigates through the process, the system registers all the scratch pads.

a) Save: -

On Exit, the user opts to either to Save or Cancel. On Save, the ERPAction collects all the scratchpads that have been registered. The ERPAction then iterates over the collection and in the process, invokes getData () on each on them to collect value objects. The individual value objects form part of the grand ERP object.

Once the aggregate ERP value object is ready, it is then dispatched to ERPProcessService (which is a remote EJB). The EJB then takes the individual value objects from ERP value object and has the DAO process the information.

b) Load: -

The instruction to load is passed to the ActionController, which forwards the control to ERPAction. The ERPProcessorServic then handles the load instruction. The service on processing the load, eventually readies an ERP object. The ERPAction then disperses the ERP object into individual value objects. When the individual value objects are ready, they are then set into corresponding action forms using the setData () method. Thus when the user navigates the ERP application after the load, the presentation layer can then load the values that are already loaded in the action form.

ActionHelper

The ActionHelper (ERPActionHelper) performs two most important duties for ERPAction

a)aggregateObjects: This method aggregates all the registered action forms(in the session) and collects the value objects that are representative of the values the user entered. These value objects are set in the grand ERP value object. As we iterate through the various action forms, we check for the data changed status of the action form. If the state of the action form is unchanged, then the choice is made to not save it. This method returns a grand ERP value object.

b)disperseObjects: This method does the reverse of aggregateObjects. This method takes a grand ERP value object and disperses into various granular value objects. These value objects are then set into corresponding action forms via setData method.

ERPProcessorService

This is a remote EJB. It acts as a session façade to the ERP business process. Its interface provides various capabilities

a)saveERP: This method takes in a ERP value object as argument. The value objects in the grand ERP objects are submitted to individual DAO objects and processed.

b)RetrieveERP: Given a form id, this method talks to individual DAO objects and build a grand ERP objects.

c)RetrieveFormIDs: Retrieves list of pending form ids for a login id.

d)DeleteFormIDs: Deletes a selected form id from the system.

e)DeleteAttachment: Deletes an attachment based on the ‘Attachment Criteria’ (explained later).

f)RetrieveAttachment: Retrieves an attachment based on the ‘Attachment Criteria’.

Attachments

There are 4 steps to the attachment process:

1)Upload: Struts carries an interface known as FormFile that assists in the attachment of files. Epermitting leverages this class to attach files from clients local machine.

2)Display: Epermitting uses a tag to display the files attached by the user. It requires that when the JSP invokes the tag, it first puts in the collection in the request(HTTPServletRequest), with the key: EpermitDocColl. The tag takes in 2 attributes

a)type: Type of the file attached (i.e. Lnd, Site etc.

b)actionName: The struts action to be invoked for deleting and viewing a file.

An example of invocation:

request.setAttribute("EPermitDocColl", fileCollForTag);

<epermit:FileAttachmentDisplay type = "Site" actionName="ERPGeneralSectionE"/>

3)ViewAttachment: This functionality revolves around an object known as AttachmentCritria.

The member variables include

a)seqNo: A key generated to reference the file, when stored in db.

b)Filename: the filename

c)Type: The application type of file.

d)formId: The form Id of the application.

There can be files that have been attached in the memory are not stored in the database. For such files, the seqNo value = -1. For such cases the DataHandler object is prepared from the collection in the memory.

For the files in the db, AttachmentCriteria object is prepared and the RetrieveAttachment method is invoked with the criteria object as parameter.

4)DeleteAttachment: For the files that exist in memory and not stored in the db, collection that exists in the memory is used to locate the file and removed.

For the files in the db, AttachmentCriteria object is prepared and the deleteAttachment method is invoked with the criteria object as parameter.