task order development requirements - state of ohio ... · web viewthis document serves as...

Ohio Workforce Case

Management Systems

(OWCMS, OMJ, WIET)

Application Development Task Order Standards Addendum

Contents

Revision Log..................................................................................................................................3

Introduction and Background.........................................................................................................4

Executive Summary.......................................................................................................................4

Architecture....................................................................................................................................4

Coding Guidelines/Standards........................................................................................................6

JSF........................................................................................................................................................... 6

JPA.......................................................................................................................................................... 6

EJB.......................................................................................................................................................... 6

Maintainability/Standards......................................................................................................................... 6

Java Naming Conventions....................................................................................................................... 7

Code Design/Review.....................................................................................................................8

Screen Design Standards........................................................................................................................ 8

Design Document..................................................................................................................................... 9

CODE REVIEW...................................................................................................................................... 10

Dimensions..................................................................................................................................10

Check-in Process................................................................................................................................... 10

New Project............................................................................................................................................ 10

Design Part For New Items.................................................................................................................... 10

Database Administration.............................................................................................................11

Database Standards.............................................................................................................................. 11

Formatting Standards............................................................................................................................. 11

Reusable Code...................................................................................................................................... 11

Reporting Database/ Informatica............................................................................................................11

Cognos........................................................................................................................................11

Interfaces.....................................................................................................................................12

Application Development Task Order Deliverables Document

Revision Log

Date Revision Description Author

9/6/2017 1.0 Original OIS Development


INTRODUCTION AND BACKGROUND

The Ohio Workforce Case Management System (OWCMS) supports the Office of Workforce Development in helping people to get back into the workforce or improve their place in the workforce. It administers a number of grants and funding programs that provide services to targeted population to help them get to a life sustaining wage.

Originally, OWCMS was introduced as Sharing Career Opportunity and Training Initiatives (SCOTI) application and was developed using Oracle Forms technologies. This application was converted to a Java web application that runs on WebSphere application server and is now known as OWCMS.

EXECUTIVE SUMMARY

This document serves as both an introduction to the Ohio Workforce Case Management Systems (OWCMS, OMJ, WIET) and a reference document. Although negotiable, this document represents constraints on the solution space and development processes to be used to enhance OWCMS.

Architectural/Design Constraints:

1. There will be a JFS development lead assigned to each task order.

2. The listed platform software (and revision levels) are expected to be maintained unless there is an explicit requirement to move to a different software base.

3. Tools listed are the ones currently in use by the JFS development team and the solution cannot cause new tools to be needed without prior approval.

4. New frameworks, components or libraries must have prior approval from the JFS development team.

5. There will be parallel development going on in the source tree, strict adherence to the merging constraints is required.

6. JFS will not provide an independent environment.

ARCHITECTURE

Configuration for all the app servers for the below J2EE applications are mentioned in Dimension under: /Architecture/OWCMS Architecture Documents/WCMS Oracle Conversion Documents/SCOTI-JavaApps-Configurations.xls


Framework OWCMS OWS WIET InterfacesOracle 12c Database X X X X X X X X

Application has Transaction and Reporting database X X X X X X X XIBM Rational Application Developer (RAD) 8.5.1 X X X X X X X XWebSphere Application Server 7.0.0.41 X X X X X X 8.5JEE 5 X X X X X X

X X X X X X 1.7 or 7IBM Rational Application Developer 8.5 X X X X X X X XEJB 3 X X X X

X X X XJSF 1.2 X X X XHibernate 3.3.2 X X X X 3.0? 3.0? X

X X XFacelets 1.1.15 X X XSeam Framework 2.2.2 X X X X

X X X X XBootstrap 3.3.0 X XServlet 2.5 X X X X X X XApache libraries to handle multiple functionalities X X X X X X XCPI Logging using TIBCO client XIBM MQ interacts with IBM Mainframe XInteracts with Cognos using Cognos Java libraries X

X XSend email using SMTP X X X XJackson jars for handling JSON Datastructures X

Interacts with Monster WebServices using restful api client XLog4 logging X

X X X X

X X X X WS SecuritWS Security 2.0X X X X X X X X

OJDBC6 X X X X X X X XStruts XTiles XOccuCoder X X

X X XInformatica Designer/Repository/Workflow 9.6.1 X X X X X X X XSpring Frame Work X XSpring LDAP X X

XXSD XApache Axis XFTP Client XJasckson XJaxp XMySql XPOI XXerces XSax XSOAP X

Chrome X X X X X X X X Safari (Mac) X X X X X X X X Internet Explorer X X X X X X X XTool

X X X X X X X X

WCMS HELP

OBG OMJ Web Service

OMJ OJI Web Service

OWCMS Web Services

Java 1.6 (or Java 6)

JPA 1.0

JBoss Richfaces 3.3

JSP 2.1

Cognos Developer suite 10.1.1 to generate Cognos reports

Interacts with LDAP using native j2ee jazn authentication

Authentication and Authorization using WebSphere Custom Logon Module JDBC

Authorization based on the ldap as well as Database driven roles/groups that was specified in the user defined tables

XML

Browsers (Current JFS Supported Versions)

1) TOAD 12.0.1.2


CODING GUIDELINES/STANDARDS

The final deliverable will utilize the benefits of each technology/framework of the specific java application and be developed and maintained using IBM Rational Application Developer (RAD) Version 8.5.1. Any new applications or requirements needing secure user accounts must implement the custom login module and use j_security check. Any technologies or frameworks not specified in this document should not be used without prior approval.

Any new j2ee application must be built with the same design as the OWCMS application. That code can be found in dimensions, Product: SCOTI , Project: SCOTI_WS: OWCMS_JAVA and uses these technologies/frameworks:

JSF (Apache myface) Richfaces Seam JPA EJB

JSF

No inline styles in JSF. Styles should be in clearly organized Cascading Style Sheets (CSS). Avoid using rich:dataTable whenever you can. The h:dataTable of JSF usually provides good

enough options. Use Ajax validations to immediately fire the validations without going to the action. This along

with seam tags s:decorate can provide good validation. There should be minimum JSF’s per form including header, footer, and navigation for ease of

maintenance and better performance.

JPA

Use IBM JPA implementation. GUI should not interact with JPA. GUI should interact with EJB layer. Use the JPA annotations if they are really going to be common throughout the application as one

JPA can be accessed from different pages for different functionalities.

EJB

GUI should interact with EJB layer. EJB should be thick, web layer should be thin. All database transactions should be controlled in EJB layer, not web layer. EJB should contain the business logic and validation. Handle exceptions and log using log4j.

MAINTAINABILITY/STANDARDS

Use well structured code. Use Seam to allow JSF to talk directly to EJB layer. EJB should handle all database queries and

transactions. Web layer should not connect directly to database layer (JPA). Proper separation of application/controller and database logic using MVC pattern.


Simple validations should be done on web layer, ie format validation, ssn validation etc. Document code and use comments to explain methods using Javadoc. Use multiple application property files for text. No duplicate business logic and no duplicate entity beans. Minimal database changes to not impact performance ie. LOV selects should not be converted to

database views. Exception Handling – throw to user, must be consistent. The j2ee application must use Optimistic locking for all the database records. Implement log4j for every method/exception (all levels). But avoid excessive logging as it slows

down the performance. Do not use sys.outs and also do not log only method calls and error messages.

Limit session size to reduce risk of crashing server. Use @In, @out with session scope or @Datamodel, @DataModelSelection can be used to carry the values of objects throughout the session.

Avoid displaying large tables to user. Use pagination. Three ways of validations – JSF validations, JPA level validations with annotations, and EJB level

validations. Please make sure to use the JPA annotations if they are really going to be common throughout the application as one JPA can be accessed from different pages for different functionalities. In JSF, use ajax validations to immediately fire the validations without going to the action. This along with seam tags s:decorate can provide good validation.

Design for new j2ee application must include site navigation/mapping showing flow of system pages including JSF’s.

All new entities, allocation size must be set to 1.

JAVA NAMING CONVENTIONS

Naming conventions make programs more understandable by making them easier to read. They can also give information about the function of the identifier-for example, whether it's a constant, package, or class-which can be helpful in understanding the code.:

Identifier Type Rules for Naming Examples

Packages

The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, gov, org, etc.

Subsequent components of the package name vary according to an organization's own internal naming conventions.

com.sun.eng gov.ohio.jfs.owcms.resources

Classes

Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations. Avoid abbreviations, business related acronyms are fine.

class MiniSeeker; class Employer;

Interfaces Interface names should be capitalized like class names. interface RasterDelegate; interface Storing;

Methods Methods should be verbs, in mixed case with the first letter lowercase, run();


with the first letter of each internal word capitalized and should indicate the purpose of the method.

runFast(); getBackground();

Variables

Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed.

Variable names should be short yet meaningful. The choice of a variable name should be designed to indicate the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.

int i;char c;float myWidth;string lastName;

Constants

The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.)

Public static final String OMJ_INTERNAL_CONTEXT = “ows”;

Additional guidelines/conventions:

Use java Camel Case naming conventions Meaningful classes and methods make code self documented Limit the variable and method scopes. Do not use System.out.println – Use loggers instead. Use stringbuilder for large/repeated string concatenation. Prefer For each instead of explicit iterators. In the facelets, Id every UI component with short names Configure UI Navigations in pages.xml Code UI logic and UI event handlers in Seam Page Actions (POJO Seam Components with

EVENT scope – can request injection of class variables from other required scopes). Services can be injected into Seam Page Actions.

Code business logic in Stateless/Stateful session beans. Use @In annotation to acquire entity managers in services. JPA entities must have basic validation annotations and multi field validations can be coded as

methods with @AssertTrue annotations. Validation and other messages must be placed in resources file.

CODE DESIGN/REVIEW

SCREEN DESIGN STANDARDS

Fonts – Must be consistent with the application.

Colors – Must be consistent with the application.


Drop-down list - no pull down listings. Lov’s need to be used. Lov screen/functionality already created and can be copied for use in other areas. Dropdowns with lengthy option descriptions may use the selectWide class – this will ensure that the description does not get chopped off.

Tabbing – order must be left to right, top to bottom. User must be able to tab through the screens without lifting hand from the keyboards unless otherwise agreed to by OWD.

Required fields in new application must be bolded and have red * to the left hand side. For existing applications, use standard for that application for required fields.

Dates use calendar function

Default menu bar used on all main screens

No hardcoding of values/lists/links without approval from JFS Development team.

DESIGN DOCUMENT

All new and updated screen changes must have a design document. Access to Dimensions will be given upon awarded contract.

Design document template found in dimensions at: \Design Documents\JAVA\Design Template.doc. Below is v1.1, but the latest version in dimensions should always be used:

Design document should be for a specific component/functionality of the application. First check dimensions to see if a design document already exists for the component being changed, in the appropriate folder within \Design Documents\JAVA\<app folder>. If not, then create a new document using the name scheme like others in the JAVA folder. Ex \wiet\AdvanceSearchDesign.docx and \owcms\OWCMSEmployerresumeReferralDesign.docx. If one does exist, then check out that design document and update:

1. Flow Diagram – Update this diagram with any changes to the flow.

2. Component Description – Update any components being changed or add any new component descriptions.

3. Database – This section should contain a comprehensive list of database tables used by the functionality/component. Update the list if it changes.

4. Shared Components – Update any changes to shared components if any.

5. Technical Design for CSR_xxx – Delete the previous design in this section and put all the details of your design in this section 5. This section will contain all new details, the design for your changes.


6. Unit Testing – Delete the previous testing details in this section and put details on how you tested. This section will contain all new details of how you tested your changes and any regression testing.

7. Version History – Update with new version of document and other details.

CODE REVIEW

A list of files changed/created for each piece of functionality must be documented using below code review template document.

Code review document template found in dimensions at: \Architecture\TaskOrderDeliverables\CodeReviewTemplate.xlsx. Below is v1.0, but the latest version in dimensions should always be used:

DIMENSIONS

CHECK-IN PROCESS

Check-in all only successfully compiled and fully unit tested code and documentation in Dimensions.

Compare with the appropriate repository version before check-in. Update and merge as necessary.

Use state naming standards for all files/scripts checking into Dimensions.

NEW PROJECT

Development must be completed in a new separate project created by the state development team. The following document in Dimensions gives guidance on how to work with a new project and how to merge a new project back into the main project:

\Architecture\Application Architecture\WorkingWithSeperateProjectinDimensionToAvoidBranching\ DimensionWorkingWithProject.docx

Below is v1.5, but the latest version in dimensions should always be used:

DESIGN PART FOR NEW ITEMS


New items must be created in the correct design part for the application. Do NOT use the default design part: SCOTI:SCOTI.A;1.

DATABASE ADMINISTRATION

DATABASE STANDARDS

Triggers should NOT include ‘WHEN (USER NOT IN….’ statement in the ‘FOR EACH ROW’ of the trigger. The condition should be in the body of the trigger.

JFS application DBA will run all scripts in any state environment. All new or updated tables must have a history table in HISTOWNER schema with appropriate

triggers to capture all record updates in history.

FORMATTING STANDARDS

Do not use auto formatter except for new objects. Minimal changes should be made to existing objects so compare tools will only show changes.

Do not use ‘&’ even in comments.

REUSABLE CODE

Frequently used functions must be stored as objects in the database so that they can be re-used by all processes (stored database objects, sql queries, data fixes, interfaces, java, etc).

If it is necessary to create more than one version of a function, comments must be placed prominently in all copies. When changes occur, updates must be made in ALL copies.

REPORTING DATABASE/ INFORMATICA

Informatica is used for any changes to the reporting refresh process for all new DB columns and any changes to the transaction(production) database that needs to be reflected in the reporting database. Changes must be coordinated with other development efforts. The following document must be used for mapping the report refresh change in Informatica:\Informatica\Documentation\Informatica_Source_To_Target_Data_Mapping_Template.xlsx

Below is v1.0, but the latest version in dimensions should always be used:


COGNOS

Internal reports must use Cognos to generate the pdf report based on the requirement.

INTERFACES

Batch jobs must utilize Control-M.

SMR must be used for new new jobs using the latest version of the document. Use JFS standards..

New job SMRs must be checked into Dimensions at: \SCOTI ECS Jobs\SMRF\

The most current SMR documents are located at

http://innerweb.odjfs.state.oh.us/OIS/InfrastructureOperations/IMOS/OpSup/SMRF-Documentation-and-Forms.stm

The creation of Control-M jobs must be coordinated with other Development efforts.


