Workflow - Natural Resources Conservation Service

whinnycampingΜηχανική

5 Νοε 2013 (πριν από 4 χρόνια και 3 μέρες)

247 εμφανίσεις












W
ORKFLOW

Version 1.
2


Web Presence Project

Online Migration

Phase 2











Natural Resources Conservation Service

June 05, 2012


W
EB
P
RESENCE
P
ROJECT

P
HASE
2


WORKFLOW

V. 1.1



2



R
EVISION
H
ISTORY


Change
History

VERSION

DATE

AUTHOR

COMMENT

1.0

05.28
.2012

Pr
iyank Devenraj

Initial Baseline Document

1.1

06.04
.2012

Sarah Photowat

Editing, Reviewing

1.2

06.05.2012

Timothy Pleus

Editing, Reviewing

1.3

07.23.2012

Priyank Devenraj

Response to comments Provided







Document Sign
-
off

VERSION

DATE

REVIEWER(S)

COMMENT

















W
EB
P
RESENCE
P
ROJECT

P
HASE
2


WORKFLOW

V. 1.1



3

1
Introduction

and
Purpose


The current portal system
is

designed to allow a contributor

creating content in the production
environment

to publish

that

content
immediately and
without review by another party
.

There are no
approval or review mechanisms involved in the publication process.
It is assumed that the content
contributor will also be the content owner, and
will therefore be
accountable for

the

accuracy

of the
content
.
Even
if the contributor wished to have a peer review the content when working in collaboration
the application offers no review capability barring publication.

2
Solution


Workflow

(WF)

is an industry standard term used to describe automation of processes
that involve
intellectual human decision
s

at multiple stages. The workflow system intends to automate the
routing/re
-
routing, alerting, tracking, auditing, and reporting mechanisms of the business process flow,
while leaving the critical intellectual decis
ion making to humans at key points in the process. It is much
like how a file moves from desk to desk in a typical organization, encountering multiple stages of mods
and approvals/rejections, until it finally becomes a document for release to general consu
mption.

In the NRCS Portal System, there may or may not be a need to develop such a “dynamic” workflow
system.

2.
1

Dynamic Workflow Solution

2.
1
.1

Definition

In a dynamic workflow
(WF)
system
, the workflow engine
is

separated out of the application, and
workflow features provided by Oracle UCM
can be leveraged. In this context, ‘
dyn
amic’ means
that the
knowledge of business workflow
is not required to develop the
solution
. C
ontent

can be passed

into
a
WF
black box

wi
thin which the control for moving content is transferred. Defining t
he workflow’s
lifecycle
can occur within the workflow

engine per requirements. We intend to utilize Oracle UCM’s WF
component. Multiple WFs can exist
si
multaneously, and based on criteria
definitions, different pieces of
content enters into their respective WFs.


2.
1
.2 Process Flow Diagrams

The “dynamic” solution is a generic workflow solution, where multiple process flows can be designed, as
needed by specific departments or as categorized

by content areas. Here are samples of a few such
possibilities:










W
EB
P
RESENCE
P
ROJECT

P
HASE
2


WORKFLOW

V. 1.1



4

Diagram 1


Basic



In a basic WF design, the contributor prepares the content within the
“Preview Environment
”.
Once the contributor is done, he/she can then set that content to “enter” into a WF.
The basic
WF will have only one stage, where one
designated reviewer, verifies the content (and the
page), and makes a decision to Approve or Reject. Approved content

moves out
” of WF and is
pushed to production. Rejected content is sent back to the original contributor.


Diagram 2


Multiple Hierarchic
al Approvers


In a Hierarchical WF design, the contributor prepares the content within the “Preview
Environment”. Once the contributor is done, he/she can then set that content to “enter” into a
WF.
In a Hierarchical

W
F arrangement, th
ere can be a series of
reviewers
. The content moves
from one
reviewer

to next,
in a series,
until

it gets rejected by one of the
reviewers.

When that
happens, then depending on design, the content can be sent back to the
preceding

person, or
can also be sent back to the original contribu
tor. If the content (and page) is
approved

however,

then the
content “moves out” of WF and is pushed to production.


Diagram 3


Multiple Collaborative
Approvers

Contribute

Contributor 1

Edit/Accept/
Reject

Reviewer 1

Preview Environment

Production Environment

Contribute

Contributor 1

Edit/Accept/
Reject

Reviewer 1

Preview Environment

Production Environment

Edit/Accept/
Reject

Reviewer

2


W
EB
P
RESENCE
P
ROJECT

P
HASE
2


WORKFLOW

V. 1.1



5


In a Hierarchical WF design, the contributor prepares the content within the “Preview
Environment”. Once the contributor is done, he/she can then set that content to “enter” into a
WF. In a
Collaborative

WF arrangement, there can be
multiple

reviewers
, eac
h having the
capability to edit/update the content under review
.
If any one of the reviewers rejects
the
content
, the item goes back to the original contributor.
If no one has rejected, t
he
system
continues to count the number of approvals received. When t
he
threshold

of approval counts
has reached, the
content
is considered as approved, and is pushed to production
.












Diagram 4


Multiple Collaborative Approvers + Automated Processes

Contribute

Contributor 1

Edit/Accept/
Reject

Reviewer 1

Preview Environment

Production Environment

Edit/Accept/
Reject

Reviewer

2


W
EB
P
RESENCE
P
ROJECT

P
HASE
2


WORKFLOW

V. 1.1



6


This arrangement of WF borrows the “human decision
” part from either the Hierarchical or
Collaborative arrangements described above, but on top of that, adds some additional
automation components, which get invoked based on the events triggered by the reviewers.
For example, when
a particular content

item

has been fully approved and
is
transitioning into
production, th
a
t event may trigger an
automated Akamai refresh for the corresponding page
,
so that there is no need to wait for the 2Hr TTL
. AT the same time, since Akamai refresh will be
needed only upon
change happening to a page, the overall TTL can be increased to say 24Hrs,
thereby improving performance, as well as making
it more real
-
time than
today’s 2Hr cycle.

3

Capability List

3.1

Basic
Workflow

The Workflow Component
,
which covers the same
functionality as most COTS Workflow products
,

will
help meet following needs
:




Live Preview



Since Workflow builds upon the Live Preview functionality, it will continue to
expend all benefits of Live Preview.




Review



The system allows for review by M
anager or Reviewer.




Rectify
-

The system allows the reviewer to rectify,

update and enhance the content.




Approve/Reject

-

The system allows the reviewer to approve or reject the content
.




Commenting


The system shall allow for associating comments with
each action.




Email Notification


The system shall send email notifications to content creator and reviewer
when the status of the content changes.

Contribute

Contributor 1

Edit/Accept/
Reject

Reviewer 1

Preview Environment

Production Environment

Edit/Accept/
Reject

Reviewer

2

Notify
Subscribers

Trigger Some
Report


W
EB
P
RESENCE
P
ROJECT

P
HASE
2


WORKFLOW

V. 1.1



7

4
Limitations


The
WF

feature

will be applicable only to Stellent Content. It will not apply to Database
items
, (such as

Short C
uts & Ads), or supporting assets
,

(
such as

images and documents
)
. This means that if
an IA
change is made,

or Shortcut is created, it will appear in Production
without delay as currently occurs
.
However
,

the content that lives under
that IA or

the

Shortcut
’s target content

will still
flow through the
workflow

system.

For the purpose of this document it is
understood per the Phase 1 Requirements and
Gap Analysis

that it is not necessary to include the
database
in
the
workflow
model. If it becomes
necessary, the Level of Effort will change as it

will add significant effort to the task
.

5

Dependencies/Pre
-
Requisites

The Primary Pre
-
Requisite for
a
WF solution
is to have the Preview Functionality implemented. The
workflow

componen
t will leverage several features of the Preview environment to build upon.


There

are no additional dependencies or prerequisites. For example
, implementation of Workflow is
independent of the following deliverables
:



Workflow
is independent of Style Guide
changes
.



Workflow is i
ndependent of Session sharing changes
.


6

Implementation Requirements


Implementing workflow

will require code change,
as well as

change to the

system’s architectur
e
. The
m
ajority of the changes will be on the contribution application and Oracle UCM
WF

component
development.
Some code changes will be required on Content Delivery
.


6
.1
Live Preview Development

Live Preview development is a prerequisite

and will need

to be completed and functional prior to
undertaking
workflow

development. Live Preview

is being developed with the intention of subsequently
implementing workflow
.

6
.3 Contribution Application Code Changes

The contribution application code will require
significant changes, as all the process flow shall be
managed and reported from the Contribution application.

6
.4
E
-
mail System
Integration

Additional email server integration shall be required to implement notifications functionality.

6
.5
Consumptio
n Changes

The changes to

the

consumption application shall be minimal, as most of the requirements are expected
to be covered in the Live Preview effort itself.


W
EB
P
RESENCE
P
ROJECT

P
HASE
2


WORKFLOW

V. 1.1



8

6
.6
Support Tasks

A
ll the support tasks will
also be needed for this effort. These include
:

1.

NI
TC Coordination

2.

NITC environment setup

3.

Deployment

4.

Functional Testing

5.

UAT

6.

Security Scan

7.

Load Testing


7

Level of Effort


The Level of Effort for Basic Workflow is broken down as follo
w
s:



Contribution Application Code Changes: 9 weeks
*



Consumption changes: 3

weeks
*



Support tasks: 3 weeks



Labor Category

Hours

IT Subject Matter Expert

120

Business Process Consultant

1
6
0

Programmer

5
20

Application Programmer

12
0

Business System Analyst

16
0

Project Manager

120


*
Some
of this work is covered in the development and implementation of the Live Preview component. For the purposes of
this document Workflow and Preview LOE are being treated discreetly, however, there is some crossover.

8 Appendix


An
Appendix
containing Workflow Design Wireframes
is attached as a separate PowerPoint
document.