BPM Base Architecture

8/3/2019 BPM Base Architecture

1/16

CINDY.YEEFebruary 2010

LOreal USA

LOreal BPM

Base ArchitectureBASEARCHITECTUREDOCUMENT


2/16

BPM Base Architecture 2

Version History:

Version Date Summary

1 2/1/2010 Document BPM Base Architecture for transition purpose.

Document Comments:


3/16


Table of Contents

1. BPM Architecture Background ....................................................................................... 4

2. Hardware Architecture ...................................................................................................... 82.1 Production Hardware Configuration ................................................................. 8

2.2 Development Hardware Configuration ............................................................ 8

3. Software Architecture ........................................................................................................ 9

3.1 Database Server .......................................................................................................... 9

3.2 Application Server ..................................................................................................... 9

3.3 Report Server .............................................................................................................. 9

3.4 Client Requirements ............................................................................................... 10

4. Development Methodology ............................................................................................ 11

4.1 Custom Database Objects ..................................................................................... 11

4.2 Front-End Development ....................................................................................... 11

4.3 Process Manager ...................................................................................................... 12

4.4 Reports ......................................................................................................................... 12

4.5 Extensibility and Integration Points ................................................................ 13

4.6 Data Conversion (History from ActionWorks)............................................ 13

4.7 Testing .......................................................................................................................... 13

5. Deployment Methodology .............................................................................................. 155.1 Version Control ......................................................................................................... 15

5.2 Deployment Process ............................................................................................... 15

5.3 User Guides ................................................................................................................. 15

5.4 Process Management ............................................................................................. 16


4/16


1.BPM Architecture BackgroundThe Enterprise Integration Architecture program was launched as a part of

the Summit initiative along with other key technology related programs suchas Fusion. It is focused on the initial implementation of Enterprise Application

Integration into the LOreal USA technology architecture.

In July 2006, the Integration Architecture team began its focus on workflow,

branching into workflow architecture as part of the overall Integration

Architecture strategy and assuming the responsibility of the existing

workflow applications with the goal to further incorporate human-centric

processes with seamless system integration enabling human-centric business

process management. With this focus, an assessment of the existing

ActionWorks (Metro) workflow platform was performed in late 2006. A

number of important business processes were enabled through our legacy

Workflow application.


5/16


The ActionWorks (Metro) workflow platform was implemented in LOreal in

2000. Since implementation, it has been adopted throughout the LOreal

organization and the number of workflow forms initiated has grown

exponentially year-on-year.

At the time of the implementation, Action Technologies, the creator of

ActionWorks (Metro) was a leader in workflow applications. Since then many

new and more advanced companies have embraced this segment of

technology and has evolved workflow to its next generation Business

Process Management (BPM). Today, ActionWorks is no longer amongst the

leaders in this segment and Action Technologies has slipped in market

presence and competitiveness. Action Technologies has also conveyed that

they are no longer investing in development and the growth of its

ActionWorks (Metro) product.

In March 2007, the Integration Architecture team completed evaluation of

BPM tools that will fill the defined needs within LOreal. Based on technology,

costs, implementation time and complexity, ease of administration, and ease


6/16


of end-user interface, Adobe LiveCycle Enterprise Suite has been selected as

the LOreal Enterprise BPM platform.

Adobe LiveCycle workflow engine is widely implemented in the Insuranceand Government industries. SAP has also selected Adobe as its backbone

workflow engine in its core SAP products. Adobe LiveCycle ES enables not

only workflow, but with its BPM capabilities, it enables the manageability of

business process, end-to-end integration, visibility to task, goals, SLAs and

priorities, and the ability to continually discover patterns within the defined

processes for continual process improvement. Adobe LiveCycle ES end-user

interface with PDF forms and Flex front-end surpasses the capabilities of all

other competitive products.


7/16


The implementation of the LOreal Enterprise BPM platform will leverage the

capabilities of Adobe LiveCycle ES in unison with the other existing business

systems to drive process consistency and efficiency, increase personal

productivity, and deliver competitive advantage through proactive business

and performance management.


8/16


2.Hardware Architecture2.1 Production Hardware Configuration

2.2 Development Hardware Configuration

Adobe LiveCycle PROD (CO)VM

USCORADB01 (Application Server)

USCORADB02 (Application Server)

USCORSQLCLD01 (SQL Database)

USCORSSRSLB (Report Server)

USCORSQLDEV00 (Report Server)

Adobe LiveCycle DEV (SB)VM

USCORADBDEV01 (Application Server)

USCORSQLDEV01 (SQL Database)


9/16


3.Software ArchitectureAdobe LiveCycle is a 2-tier environment consisting of a database server tier

and an application server tier. The environment is running Adobe LiveCycle

version 8.2.1 SP 2.

3.1 Database ServerThe database server runs on Microsoft SQL 2005 version 9.0. The production

instance of the MS SQL Server resides on USCORSQLCLD01. The development

instance of the MS SQL Server resides on USCORSQLDEV01.

The Adobe LiveCycle platform consists of two Adobe package databases and

one LOreal custom database. EI_AdobeLCDB is the transactional database for

the Adobe LiveCycle workflow engine. EI_AdobeMeta is the metadata

database for Business Activity Monitoring (BAM). Custom database

EI_AdobeODS was created to specifically house LOreal custom database

objects that are used in supporting all of the workflow applications built using

the Adobe LiveCycle platform.

3.2 Application ServerThe Adobe LiveCycle application server runs on JBoss version 4.0.3. JBoss is

installed on USCORADB01 and USCORADB02 in the production environment

and on USCORADBDEV01 for the development environment.

The Adobe Workflow Server is installed on USCORADB01 and BAM (Business

Activity Monitoring) Server is installed on USCORADB02 for the production

environment. Both the Adobe Workflow Server and BAM Server are installed

on USCORADBDEV01 for the development environment.

3.3 Report ServerAdobe LiveCycle does not include a native reporting mechanism; however

reports can also be developed in Flex, PDF, or Java. Rather than customizing

reports within the Adobe environment, at LOreal, we are using Microsoft SQL


10/16


Server Reporting Services (SSRS) as the standard reporting platform for the

workflow applications. The production instance of MS SSRS resides on

USCORSSRSLB. The development instance of MS SSRS resides on

USCORSQLDEV00.

3.4 Client RequirementsAdobe LiveCycle communicates over the web using the standard HTTP

protocol. Adobe Flash Player 9 or above is required on the client computers

for Flex front-ends. Adobe Acrobat Reader 8 or above is required on the client

computers for PDF front-ends or PDF attachments.


11/16


4.Development Methodology4.1 Custom Database ObjectsCustom database objects should reside in EI_AdobeODS. Schema

EI_AdobeCTL, EI_AdobeData, and EI_AdobeODS are created for different

purposes.

Schema EI_AdobeCTL is used for control data objects. These should bedesigned as reusable objects that can be used for all workflow

applications such as approval routing, business rules, service controls,

and task routing.

Schema EI_AdobeODS is used for ODS data table objects and storedprocedures that retrieve archived data from the ODS data tables.

Schema EI_AdobeACH is used for grouping reusable stored proceduresthat archive data into the ODS data tables.

Schema EI_AdobeDATA is used for custom data objects for specificworkflow applications such as the budget data for RGA where there is

no existing system that stores this data. Object names should be

prefixed with the workflow application name.

Schema EI_AdobeSVC is used for servicing data to external applications.

4.2 Front-End DevelopmentThe Adobe LiveCycle platform natively interacts with two types of front end

coding mechanisms.

Flex Object Oriented PDF with Java Scripting

Flex Builder is used in developing Flex front-end and Adobe LiveCycle

Designer is used in developing PDF forms.


12/16


4.3 Process ManagerWorkflows are built using Adobe LiveCycle Workbench ES consisting of pre-

delivered Adobe LiveCycle process management components such as JDBC,

email, and task assignment components.

LOreal Process Standards:

ODS Archiving - The primary purpose of ODS archiving is for ease of

reporting transactional details and status. All workflow processes

should include standard ODS archiving which includes at the minimum

two snapshots of ODS archives, one when the transaction is initiated,the other when the final approval or task is completed. Additional

interim snapshot into the ODS archives should also be considered based

on each of the workflow user requirements.

Routing For predetermined routing steps, task and approver names

should be dynamically retrieved from the Task Routing table. Where

the routing steps cannot be preset, the front-end should provide options

for the requester to choose the assignees.

Routing Notifications The requester should always be notified as the

request moves along the routing steps. For ease of support, all email

notifications should bcc to eaiadmin mailbox at

[email protected]. Notifications with PDF form attachment, the

PDF attachment should be read-only permission and a copy is saved to

disk under the application name in ApplicationData folder.

4.4 ReportsTwo standard reports should always be included for each workflow

application. Additional reports can be developed based on user requirements.

The two standard reports are the Tracking Report and the Detail Report.
mailto:[email protected]:[email protected]


13/16


The Tracking Report provides the requesters, approvers, and process owners

with the visibility to the progress of the requests.

The Detail Report provides the requesters, approvers, and process owners

with the visibility to the content of the requests.

4.5 Extensibility and Integration PointsWeb services are used for extending dynamic data to the front-end and for

process integration to back-end systems such as SAP.

Custom components can be built using Java or can be purchased from third

party. LOreal has purchased annual subscription to the Avoka service

components. A specific custom component was built for accessing MicrosoftExcel document content for the RGA workflow application.

Reader Extension is used to activate functionality within Adobe Reader such

as enabling web services functionality for MD/PAD PDF form.

4.6 Data Conversion (History from ActionWorks)ActionWorks workflow history data were converted into the ODS table for

reporting purposes.

4.7 TestingUnit tests are performed manually by the development team then the

workflow application is released to the functional IT team and the key

business users and owners for user acceptance testing (UAT). All branches(approved, reject, rework, etc) should be thoroughly unit tested to ensure

for minimal technical issues during UAT.

User Acceptance Testing (UAT) is done in the development environment by

the functional IT team and the key business users. Local user accounts are set

up in the development environment to mimic the users performing the tasks


14/16


at different routing steps. All branches (approved, reject, rework, etc)

should be thoroughly tested by the functional IT team and the key business

users and owners to ensure minimal issues during go-live.

Pilot testing is done in the production environment after deployment toensure that user permissions, group permissions, group queues, routing, and

configurations are set up correctly in the production environment before

releasing to the entire end-user population. The key business users are

responsible for coordinating the pilot user group and pilot testing efforts.


15/16


5.Deployment Methodology5.1 Version ControlAdobe LiveCycle native version control.

5.2 Deployment ProcessDeployment from Development to Production is

done using Adobe LiveCycle native deployment

process via LiveCycle Archive (LCA).

The workflow applications are deployed within

the Adobe LiveCycle environment. Users access

the workflow applications via standard AdobeLiveCycle Workspacefrom their web browsers.

Reports are deployed within the Microsoft SQL

Server Reporting Services environment with links

published in the Reports section on the Adobe

Workflow Home Page.

5.3 User GuidesA User guide is written specific to each workflow

application. Preferably the user guide is written

by the key business users so that insights to

business objectives, process and procedures are

incorporated into the user guide. IT can assist the

creation of the user guide by laying out

navigations and screenshots for the business

users to incorporate information on business

objectives, process and procedures prior to

training and go-live. User Guides are published inthe User Guides section on the Adobe Workflow

Home Page.
http://uscoradb01:8080/workspace/http://uscoradb01:8080/workspace/http://uscoradb01:8080/workspace/http://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://planetloreal.na.loreal.intra/AdobeWorkspacehttp://uscoradb01:8080/workspace/http://uscoradb01:8080/workspace/


16/16


5.4 Process ManagementSystem administrator can view and manage configuration and processes via

the Adobe LiveCycle Administration Console

BPM Base Architecture

Documents

Transcript of BPM Base Architecture