Transcript project-open[ Architecture Overview

Architecture
2005-09-03
Frank Bergmann <[email protected]>
Content



The Big Picture
GUI Structure
Component Architecture
– Component Use Overview
– Component Conventions



Localization
Permission Model
Customization Concept
– Application Lifecycle
– Customization Options (1)
– Customization Options (2)
Basics & Roadmap




P/O
Open-ACS
Data
base
Date
]project-open[ is a web-based
“Project-ERP”.
V 1.0 ACS 3.4.9
Oracle 8i
11/2003
(8.1.7)
It combines project collaboration
V 2.0 OpenACS 5.0
8i
3/2004
(content & community ) with
V 3.0 OpenACS 5.1
8i, 9i,
10/2004
financial and management
Postgres
functionality (costs, invoicing,
Platfrom Roadmap: V1.0 and V2.0 depended on Oracle, but V3.0 features
accounting, …)
PostgreSQL as a free database.
]project-open[ is based on the
OpenACS (Open ArsDigita Community System) platform.
Most ]project-open[ modules are free or GPLed, except for
specific customer functionality
Base GUI Structure
Home
Main Pages
with
Business
Objects
Projects
Clients
News
Project
Details
Tickets
Tasks
Project
Calendar
“ListPages”
with filters
New/Edit
Pages
Admin-Pages
Tickets
Details
Tickets
Team
Projects
Team
Costs
Interact
Costs
Links
Project
List
Details
Invoice
Client
Details
Filters
Links
Client
List
Details
Corp.
Details
User
Ticket
Tickets
Details
Assign
to
others
Details
Portrait
Profiles
Billable
Tasks
Customer
Interaction
History
File
Space
Filters
Client
Projects
Ticket
History
Clients
Interactions
Filters
Links
Invoice
List
Details
Filters
Links
User
List
Details
Filters
Links
Ticket
List
Details
P/O Core Data Model
ProjectUrlMap
UserContact
project
url
UrlType
Project
parent_project
customer
Rel (OACS)
Customer
object_one
BizObject
office
object_two
BizObject
Organization
Office
BizObject
Superclass of all biz objects.
Manages permissions using acs_rel
with users.
User
country
Customer physical location
object_type
object_status
BizObject
Business Objects
Object
ComponentPlugin
Infrastructure
Category
ViewColumn
view
Profile
Country
View
Menu
Currency
Group
Object
Component Architecture
Component Use Overview
Home
Project
Client
Invoice
User
Ticket
-Project List
-ViewPage
-ListPage
-New/Edit
-View: Project List (short)
-New: Project List
-List: Filter
-View: Renderer
-Print: Renderer
-Project List
-Project Select
-Project Render
Client
Components
-Client List
-List: Renderer
-List: Filter
-Project List
-Project/Task List
-Project Filter
-Project List
-Project Select
-Render Comp
Invoice
Components
-...
-...
- View: Invoice List
-View Page
-List Page
-New/Edit
-...
-...
User
Components
-...
-...
-...
-...
-View Page
-List Page
-New/Edit
-...
Ticket
Components
-...
-...
-...
-...
-...
-View Page
-List Page
-New/Edit
-View: Perm+Estim
-View: Key Accounts (perm)
-View: Customer employees
(perm)
-...
-...
Project
Components
-...
Permissions
-...
Component Architecture
Component Conventions



(GUI-) Components are used to render lists of objects, to
render individual objects (in various variations) and to
“filter” objects (restrict the elements of a SQL “where”
clause).
These components have to deal with all important functions
such as permissions, localization and design templates.
HTML pages are used to validate input variables, generate
the page layout, and to “wire” the GUI-components
together (glue-code).
Payroll
HR
Skill
Database
Recruiting
Workflow
Application
Modules
Application
Services
Platform
Services
Web
Server
Project
Project &
Mgmt.
Subprojects
Project
Controlling
Timesheet
Mgmt.
Collaboration,
File
Calendar Content & KM
storage
Online
Wiki
Chat
Discussions
Mail Server WebDAV
Incident
Integration
Workflow
Content
Management
CMS
Blog
Full-Text
Search
Workflow
Engine
Reporting
Engine
Portal &
Components
Localization
Framework
OO
OO
Frame
Model
Object
Metadata
DynField
Object
Extensions
SOAP &
XML-RPC
DB-API
AOLServer
Search
Engine
TSearch2
Oracle Intermedia/Text
Database
PostgreSQL
Oracle 8i, 9i, 10g
Operating
System
Windows
+ CygWin
Linux
Solaris
Room
Reservation
ECommerce
BSD
Mac OS
Other
]po[
Overview
Surveys
Web-Mail
Finance
Finance
Base
Controlling
Quotes &
Invoice
Freelance
Invoicing
Payments
Timesheet
Financial
Invoicing
Reporting
Software
Package
Development
Manager
Profiling &
Templates
Performance
Debugging
Automatic
Automatic System
Testing
Software
Form
Updates
Builder
TCL
TransTranslation
lation
Workflow
TM
Integration
Automatic
Invoicing
Glossary
Available
Documentation
CRM
Contact
Mgmt.
Customer
Web Reg.
Marketing
Campaigns
CRM
Tracking
Mail Server
Integration
ISDN Tel
Integration
Security
OpenACS
Permission
Page
Basic
Contracts
Authentication
SQL
LDAP
Templates
Authentication
Automatic
Audits
Pound
Revers Proxy
BigBrother
Sys Mgmt.
Database
Replication
CVS
System
Mondrian
DataWarehouse
Postfix/
Sendmail
Finance
Guide
Translation
Workflow
Guide
Forum
Guide
Filestorage
Guide
Configuration
Guide
OpenACS
Developer
Guide
Operations
& Maint.
Guide
OpenACS
Inst. Guide
Unix Install
Guide
Localization





All numbers, currency amounts, dates, times and physical
locations are rendered as a function of the chosen user
locale
All currency amounts are preceded by a currency identifier.
A system currency determines the default.
All static text used in pages and components is translated
before rendering the HTML page. An English text in the
target location is used as a default value in case of
incomplete translations. The translation interface also
specifies the target location to provide a context for
translators.
Dynamic text (names and descriptions ob business objects)
are not translated.
Future versions of ]project-open[ may contain accounting
modules specific for individual countries.
Permission Model


Permissions are divided into profile-based permissions and
role-based permissions
Profile-based permissions
– Restrict the visibility of pages and modules to a user
– Are modified as part of system administration
– API: im_permission(user_id, token): Validates that a user
has access rights to the permission token.

Role-based permissions
– Restrict the access to business objects (currently “Project”
and “Client”)
– Permissions can be modified by the creators of the respective
objects, to configure project/client team.
– API: im_has_role(user_id, object_id, role): Validates
that a user has been assigned the specifc role.
– Roles are ordered hierarchically (administrator -> member ->
specific_roles).
Profile Based Permissions
„Vertical“ Permissions
Our Company
(Project Matrix)
Provider
Client

Predefined Profiles:

Access permissions to
all critical data can be
assigned to profiles
Additional profiles can
be defined if
necessary
Managers
Freelancers
General
Manager
Project
Operations
Director Sales Manager Finance
Manager
Manager
Clients
Project
A
Project
B
General
Manager
Project
Man.
Free
lance Free
Free
lance
lance
Project
C
Project Managers
Project
Man.
Proj. Client
Man. Staff
Project
Man.
Finance
Employees

–
–
–
–
–
–
Manager
Project Manager
Employee
Finance
Client
Freelance
Project Based Permissions
Our Company
(Project Matrix)
Provider
Project
Manager
Translators
Project
A
Project
B
Project
C
Client
General
Manager
General
Manager
Project
Operations
Director Sales Manager Finance
Manager
Manager
Project
Man.
Free
lance Free
Free
lance
lance
Project
Man.
Proj. Client
Man. Staff
Project
Man.
Translators
Editors
Editor
 Within a specific project,
freelancers and clients
may have the same
rights as in-house staff.
Freelancers may even
have to act as project
managers.
 Predefined roles:
– Sales/Presales
– Project Manager
– Analyst, Developer,
Tester, ... (ITConsulting)
– Editor, Translator, Proof
Reader, ...
(Translation)
– Texter, Designer, ...
(Advertizing)
Application Lifecycle
Capture
Requirements
Customization
Install
Configuration
Data
Import
Operations
Installation
Initial Implementation
Capture
Requirements
Customization
Install
Data
Conversion
Operations
Retirement
Upgrade
Upgrade
ERP applications are not a static systems, but need to
evolve continually with changes in the business processes
of the client (customizations)
 ERP applications need to integrate/communicate with other
corporate applications
 ERP applications have life-cycles of 5-20 years
 The challenge is to maintain customizations when
upgrading to the next release.

Extensible Architecture
IT/Consulting



A central core allows
for extensions with
different application
modules
Different industry
sectors need different
configurations and
modules
Customizations
should be portable to
the next version as
easily as possible.
Engineering
Advertizing
…
…
…
…
Support
Mgmt
…
Project Project
Reporting Mgmt
Call
Center
Projects
Accounting
ReportGenerator
Clients
Expenses
CRM
…
Invoices
Sales force
Mgmt
KM
KProfiles
…
Users
Reporting
KMart
Translation
HR
Inventory
Mgmt
Perf.Recruit
Reviews
ing
…
…

ri
n
er g
t
T izi
ra n
n g
sl
a
In tio
tl
.I n
T
In De
tl
p
. P t.
ro
d
u
c
t
A
d
v
ee
g
E
n
g
in
ul
ti
n
s
n
C
o

Not all modules are
useful for all sectors
Some modules are
different for every
sector (for example
invoicing)
Some of these modules
may exist in several
variants specific for
each sector.
IT

D
ev
.
Extensible Architecture
Presales
*
*
*
*
*
(*)
(*)
Project Collaboration
*
*
*
*
*
*
*
Project File Sharing
*
*
*
*
*
*
*
Customer Management
*
*
*
*
*
*
*
Emplyee Management
*
*
*
*
*
*
*
Timesheet
*
*
*
*
*
*
*
Travel Costs
*
*
*
*
*
*
*
Project Reporting
*
*
*
*
*
*
*
Support Management
*
*
*
*
*
*
*
Recruiting
*
*
*
*
*
*
Invoicing
+
+
+
+
+
CRM light'
*
*
*
*
*
*=applicable, (*)=maybe applicable, +=customized modules
 The Module architecture has to deal with the
interdependencies between each other and over time.
Customizable Items
How can additional module change the “core”?

GUI
–
–
–
–

Home-Page (module-specific status boxes)
The main menu
Submenus of business objects
Views of biz objects (Project, Client, User, …)
Categories (=workflow states and types)
– Object status categories
– Object type categories

Data Model
– Add columns to existing BizObj tables (system modules)
– BizObj extension tables (sectorial configuration modules)


TCL Libraries
Permission Model
– Add new permission tokens
– New system roles
– New Object/Group specific roles
Customization (1)
1. Configurable Customization (100% preservation)
The system has been designed for the particular
customizations. The customization involves changes in the
configuration file and/or database contents.
 Future version of ]project-open[ maintain compatibility
with these configurable options, possibly extending them.
2. Business Object Extensions (90% preservation)
Business Object database tables can be extended to hold
additional fields via the "DynField" SQL Metadata system.
These extensions are not replaced during a system
upgrade. Rendering of the fields is handled automatically
by components in a new library.
 Future version of ]project-open[ must not overwrite the
extension tables. The client will have to integrate the
modified components into the new View/List/Edit pages.
Customization (2)
3. New Custom Modules (80% preservation)
The user may add new modules to the system, including
their own data model and components.
 Future version of ]project-open[ will not take into
account the compatibility with custom modules.
However, it is likely that the integration of the new
modules with the new version will be easy to manage.
4. Custom Extensions (50% preservation)
In some cases the client wants to modify the core business
objects or component libraries.
 Future version of ]project-open[ will not take into
account the compatibility with custom extensions.
That means that the client will have to port the extensions
to the new version.
Participate!


Build _useful_ software
We teach you how to build real software
–
–
–
–
–
Learn about high-performance server applications
See why Java doesn’t work for _real_ software
Learn basics of SQL and Database Management
We have prepared some exercises that guide you through
the process
Learn how to keep a web application running



Choose a module to concentrate
Study some background material and become an expert
Design a user-friendly GUIs and a solid data model

Being a leading developer with your module, clients will
ask for your experience