]project-open[ Data-Model 100511b

The ]project-open[ Data Model
Frank Bergmann, 2010-05-22

This guide contains overview information that is useful if you
want to write reports or if you need to extract information from
the API.
It is not ment as a developer guide. Please check the OpenACS
manual for more detailed information.

Payroll
HR ProjectMgmt.
Project Subprojects
Trans-lation
TranslationWorkflow
Room
Reservation
Other
]po[
Skill Database ProjectControlling TMIntegration
E-
Commerce Overview
Recruiting Surveys
TimesheetMgmt. AutomaticInvoicing
Workflow Web-Mail
Glossary Available
Application Documentation
Modules
Collaboration,Content KM Finance CRM
Filestorage Calendar FinanceBase ContactMgmt. FinanceGuide
Controlling
OnlineDiscussions Wiki Chat Quotes Invoice CustomerWeb Reg.
FreelanceInvoicing Translation
WebDAV
Mail ServerIntegration
Payments MarketingCampaigns Workflow
IncidentWorkflow
TimesheetInvoicing Guide
ContentManagement
CMS FinancialReporting CRMTracking
Blog Forum
Guide

Application Full-Text Localization Filestorage
Services WorkflowEngine
ReportingEngine Components
Portal Mail ServerIntegration
ISDN TelIntegration Guide
Search Framework

SoftwareDevelopment OOFrame Security
PackageManager OO Model OpenACSPermission
PageContracts Configuration
Profiling Performance Templates ObjectMetadata BasicAuthentication Guide
Platform
Services Automatic SQLTemplates
DebuggingSystem LDAPAuthentication OpenACS
Testing DynField Object Extensions
AutomaticSoftwareUpdates AutomaticAudits Developer
FormBuilder Guide
SOAP
XML-RPC
Operations
Web System
Server TCL DB-API Pound Maint.
AOLServer CVS
Revers Proxy Guide
Mondrian
Search BigBrother
Engine TSearch2 Oracle Intermedia/Text Data-
Sys Mgmt. Warehouse OpenACSInst. Guid
Database PostgreSQL Oracle 8i, 9i, 10g Database
Replication Postfix/
Operating Windows Sendmail
System Linux Solaris BSD Mac OS Unix InstallGuide
+ CygWin
© ]project-open[ 2010, Data-Model / Frank Bergmann / 2

Other Documentation

This is a limited overview document.
For more detailed information please see:

 ]po[ Wiki: http://www.project-open.org/
 OpenACS Developer Guide:
http://www.openacs.org/doc/
 ]po[ List of packages: http://www.project-
open.org/documentation/list_packages


General System Architecture

 ]po[ consists of three main parts:
– A powerful object-relational data model
– TCL pages that render the contents of the database
and
– TCL libraries that provide auxilary functions to the
TCL pages TCL Pages
 The Data Model is particularly important in ]
po[ because: TCL Library
– It is object-oriented
– The TCL layer does not contain objects. It merely
renders the content of the Data Model Data Model
 The Data Model is the location where you need to
go if you want to extract information from the
system


General Conventions

 Tables names are always in plural form and written in lower case
 Tables are held in general in 2nd normal form
 De-normalized table columns are named with a _cache postfix. Normal arrow
means referential
 All main tables have an integer primary key table_name_id. integrity relation-
This primary key references the table acs_objects which contains ship between
the type of the object. tables.
 Most object-object mappings are handleled by the acs_rels
table and its sub-types (see below). Other mapping tables are
called something_something_map
 Boolean fields have a _p postfix and contain 't' or 'f' char values
 All main objects include object_type_id and object_status_id
fields. Type is used to create minor sub-types of the objects, Big arrow tip means
such as the distinction of im_companies such as customer and inheritance relation-
provider. Status is used to deal with the object's lifecycle, ship. An inheriting
object references
such as potential, active, closed and deleted. its parent type with
its object_id.


“Business Objects”


Data Model Overview – Business Objects

 Most data in the ]po[ data model are
acs_objects structured as “Business Objects”
object_id
object_type
(BizObj).
 A “BizObj” is just a database table
im_projects
following a number of conventions
project_id
project_name – A integer primary key called object_id
project_nr
company_id representing a unique object ID
project_status_id
project_type_id – The primary key references the
project_lead_id
supervisor_id “acs_objects” table. acs_objects includes
…
object meta-information such as object
type, creation date, creation user etc.
– Every ]po[ BizObj includes a field
“object_status_id” re



 The ]po[ data model is
based on the notion of
acs_objects
“Business Objects”
 A “BizObj” is just a
object_id
object_type
database table following
a number of
conventions
im_projects – A primary key
im_categories representing a unique
project_id object identifier
project_name category_id – The primary key
project_nr category_type references the
company_id name
project_status_id
“acs_objects” table.
description acs_objects includes
project_type_id
object meta-information
project_lead_id such as object type,
supervisor_id persons creation date, creation
… user etc.
person_id
first_names – Every ]po[ BizObj includes
last_name a field “object_status_id”
and “object_type_id” to
deal with the objects’
livecycle (status_id) and
sub-types (type_id).

persons
acs_rels
person_id
rel_id
first_names
object_id_one
last_name
object_id_two



 The ]po[ data model is based on the notion of “Business
Objects”
 A “BizObj” is just a database table following a number of
conventions
– A primary key representing a unique object identifier
– The primary key references the “acs_objects” table. acs_objects
includes object meta-information such as object type, creation
date, creation user etc.
– Every ]po[ BizObj includes a field “object_status_id” re


Categories


Categories

object object_type
Conventional/ traditional database design normally object_type_id object_type_id
includes “foreign key tables” defining the type and object_status_id name
status of an object. name description
description
... object_status
]po[ takes a different approach in order to
minimize the number of database tables and to simplify object_status_id
name
maintenance. We use a single im_categories table for description
all types of status and type information:
The Classical DB-Design: Every table has
Pros: it's own tables for type, status and similar
information.
+ The total number of DB tables is reduced to a third.
+ A single maintenance screen can deal with all
categories. object im_categories
+ Built-in features: object_type_id category_id
+ Translation/Localization object_status_id category_type
+ Hierarchical categories name name
description description
+ Common GUI widgets ...
+ Referential Integrity is enforced
im_category_hierarchy
Cons:
- In theory it is possible to assign the wrong Category parent_category_id
child_category_id
to a field. However this has never happened in
practice yet. ]po[ DB-Design: All type and status information
is stored in a single im_categories table.


Categories

Categories form a DAG:
 A Directed Acyclic Graph is like a Tree with All
multiple inheritance Companies
 A DAG allows you to tag categories with

don't change!
meta-information

Constants,
CustOrIntl

Categories are partly constants, partly Customers Internal Providers
configurable:
Consulting Freelance
Agencies Providers
The top level (customers, internal, providers,

Freely Configurable
 Law Firm Office Equ.
custorintl) are used as constants by the system. Customers Providers

You'll break the system if you change them. Localization
Customer
...

However, you can localize them.
 The lower level values are freely configurable ...

to the specific company structure

Details for each category are found in the
PO-Configuration-Guide.


Categories
Sample SQL
Categories Definition Select Everything About Categories
-- We use categories as a universal storage for business select
-- object states and types, instead of a zillion of tables c.*,
-- like 'im_project_status' and 'im_project_type'. im_category_from_id(aux_int1) as aux_int1_cat,
im_category_from_id(aux_int2) as aux_int2_cat,
create sequence im_categories_seq start 100000; h.parent_id,
create table im_categories ( im_category_from_id(h.parent_id) as parent
category_id integer from
constraint im_categories_pk im_categories c
primary key, left outer join im_category_hierarchy h
category varchar(50) not null, on (c.category_id = h.child_id)
category_description varchar(4000), where
category_type varchar(50), c.category_type = 'Intranet Cost Types'
category_gif varchar(100) default 'category', order by
enabled_p char(1) default 't' category_type,
constraint im_enabled_p_ck category_id;
check(enabled_p in ('t','f')),
-- used to indicate abstract
-- super-categorys that are not
-- valid values for objects. Extract Categories Without Join
-- For example: Translation -- A helper functions to make our queries easier to
-- Project is not a project_type, read
-- but a class of project_types. create or replace function im_category_from_id
parent_only_p char(1) default 'f' (integer)
constraint im_parent_only_p_ck returns varchar as '
check(parent_only_p in ('t','f')) DECLARE
); p_category_id alias for $1;
v_category varchar(50);
BEGIN
select category
Category Hierarchy into v_category
-- Optional system to put categories in a hierarchy. from im_categories
-- This table stores the transitive closure of the where category_id = p_category_id;
-- is-a relationship between categories in a kind of matrix.
-- Let's asume: B isa A and C isa B. So we'll store return v_category;
-- the tupels (C,A), (C,B) and (B,A). end;' language 'plpgsql';
-- This structure is a very fast structure for asking:
-- -- Example:
-- is category A a subcategory of B? -- select im_category_from_id(48);
-- Create a New Category Entry
-- but requires n^2 storage space in the worst case and insert into im_categories (
-- it's a mess retracting settings from the hierarchy. category_id, category, category_type,
-- We won't have very deep hierarchies, so storage complexity category_description, enabled_p,
-- is not going to be a problem. aux_int1, aux_int2,
aux_string1, aux_string2
create table im_category_hierarchy ( ) values (
parent_id integer :category_id, :category, :category_type,
constraint im_parent_category_fk :category_description, :enabled_p,
references im_categories, :aux_int1, :aux_int2,
child_id integer :aux_string1, :aux_string2
constraint im_child_category_fk );
references im_categories,
constraint category_hierarchy_un
unique (parent_id, child_id)
);


]po[ Objects and Types

acs_attributes
All major ]po[ tables are Objects attribute_id
 Objects are identified by an object_id. pretty_name
object_type
 Information about object type is stored in the acs_objects table_name
table, together with metadata and creation information. column_name

acs_object_types
Advantages of being an object:
object_type
 Permission system: supertype
Associates objects with privileges, including all necessary table_name
maintenance screens id_column
name_method
 SQL metadata system:
Allows the administrators to dynamically extend object types
with new attributes
acs_objects
 Full-Text search:
Indexes all objects and produces generic URL for the search object_id
results object_type
 Configurable workflow:
Allows to manage the status of any object. The WF includes
object
a graphical WF editor.
 Generic Object Relations: object_type_id
object_status_id
acs_rels allows you to define generic relationships between name
objects. description
...


]po[ Objects and Types

 acs_attributes:
– Each row in acs_attributes table defines an attribute of the specified
object type.
– The contents of the table is managed by the intranet-dynfield
package that contains a SQL metadata editor.
 acs_privileges:
– Contains permissions tokens (= privileges). These privileges allow a
user to perform a certain operation in the system.
 acs_permissions:
– Defines a mapping between acs_objects and acs_privileges.
– The mapping is per user group (grantee_id). Groups can be
hierarchical.


Main Object Types


Main Object Types acs_objects
object_id
object_type

acs_rels groups parties
users_contact
rel_id group_id party_id
object_id_one group_name email Home Address
object_id_two url Work Address

im_profiles im_biz_objects persons im_employees
profile_id
object_id person_id Payroll Info
profile_gif
first_names Recruiting Info
last_name

im_freelancers
im_companies im_offices im_projects users
Freelance Info
company_id office_id project_id user_id
company_name company_id project_name username
company_status_id office_status_id project_nr password
company_type_id office_type_id project_path salt
main_office_id Address customer_id auth_token
primary_contact_id
project_status_id
accounting_contact_id
project_type_id
vat_number
project_lead_id
note
supervisor_id
project_budget
budget_currency
budget_hours
start_date
end_date
description
note


Main Types

 im_biz_objects:
– This abstract type defines a number of functions to manage horizontal
permissions (= Please see other ]po[ documentation) for project,
companies and offices
– Horizontal permissions currently include roles such as Project
Manager of Full Member.
 parties, persons, users:
– These three tables form an inheritance hierarchy. There is a view
cc_users that unifies the information from these tables.
 im_freelancers, im_employees, users_contact:
– These are extension tables for persons and define additional
information for users with particular profiles.
 im_profiles:
– This table defines the groups that are relevant for ]po[, as opposed to
potentially hundreds of groups of the underlying OpenACS system.


Users, Groups and Their Relationships
Users and their groups in ]po[ are modeled Groups Relations User Types
using a number of types and tables:
groups acs_rels parties
 User information is stored in 5 different users_contact
tables, depending on the type of user group_id rel_id party_id
(see below). group_name object_id_one email Home Address
 General (OpenACS) groups consist of a object_id_two url Work Address
basic “groups” table. The groups
(“profiles”) used in ]po[ “profiles” are
identified by an entry in “profiles”. im_profiles persons im_employees
 A user-group membership is established membership
when creating a “membership_rel” profile_id
between the two. The membership_rel profile_gif _rels person_id Payroll Info
first_names Recruiting Info
consists of an acs_rels entry mapping rel_id
the user to the group, plus a last_name
member_state
membership_rels entry containing the
information about the member state im_freelancers
(“active”). To disable a membership, you users
can update the member_state to Freelance Info
“deleted”. user_id
username
This way of modeling users allows to password
dynamically extend users, groups and
salt
their relations. This is heavily used in ]po[
(for example there is an “employee_rel”). auth_token
However, it adds a certain overhead (9
tables instead of 3).

User Types:
 Party: Super-type of both “person” “group” and “im_company”, allowing to compose new groups of both users and groups.
 Person: Represents a natural person with first- and last name
 User: Contains the login information necessary for a person to participate in ]project-open[
 users_contact: Extension table with address information
 im_employees: Extension table with employee information
 im_freelancers: Extension table with freelancer information


Financial Types
acs_objects
object_id
 All financial objects in ]po[ are based on the object
object_type
type “Cost Item” in table “im_cost”. This table
contains the common information shared across all
Inheritance! types of cost items.
im_costs im_payments  The field im_cost.cost_type_id determines the
cost_id payment_id specific type of the cost item.
im_invoices cost_name cost_id  The following cost sub-types are derived from the
cost_nr company_id “Cost Item” base type:
invoice_id
cost_status_id provider_id – Timesheet Cost – The monthly cost of an
company_contact_id employee
cost_type_id received_date
invoice_nr
payment_type_id – Expense Bundle – A collected and “bundled” group
invoice_office_id project_id of Expense Items (see below)
payment_status_id
customer_id
amount  “Expense” is a sub-type of Cost Item. Expenses
im_invoice_items provider_id
currency represent money paid by employees to external
cost_center_id
note companies. Expenses are bundled together as
item_id investment_id
“Expense Bundles”. These Expense Bundles are
item_name template_id
typically approved by the finance department and the
project_id effective_date_id im_cost_centers reimbursed to the employee. Sub-types of Expense
invoice_id payment_days refer to the different types of expenses:
item_units amount cost_center_id – Airfare
item_uom_id currency cost_center_name – Taxi
price_per_unit paid_amount cost_center_code – Book
currency paid_currency cost_center_type_id
– …
sort_order cost_center_status_id
tax department_p  “Financial Document” is a sub-type of Cost Item
item_type_id vat implementing any financial items with lines in it. Sub-
item_status_id description types include:
description note
im_expenses – Customer Invoice
– Delivery Note
expense_id – Quote
ext._company_name – Provider Bill
ext._comp._vat_num. – Purchase Order
billable_p  “Repeating Costs” are not yet 100% implemented in ]
reimbursable po[ as of 3.4.0.8.9. This type will represent recurring
bundle_id cost items in the future, including monthly service
fees, employee salaries etc.2010, Data-Model / Frank Bergmann / 20
© ]project-open[

Financial Types

 im_costs:
– This is the main table for all cost items.
– All financial elements in the system are stored in this table. The table
also receives updates from timesheet (cost related to users working on
a project) etc.
 im_cost_centers:
– Is currently not used. The table has been included in the current
datamodel for smooth upgrade in future versions.
 im_invoices:
– This table contains financial documents such as Invoices, Quotes,
Bills and Purchase Orders (the name im_invoices is a bit
misleading).
 im_invoice_items:
– These are the individual lines of an invoice.


Financial Types (2)
Relationship between Costs and Projects

acs_rels
rel_id
object_id_one select distinct
c.cost_name,
object_id_two im_category_from_id(c.cost_type_id) as cost_type,
c.amount * im_exchange_rate(c.effective_date::date,
c.currency, 'EUR') as amount_converted
im_projects from
im_costs im_projects main_p,
im_projects sub_p,
project_id
acs_rels r,
… cost_id im_costs c
where
cost_name main_p.project_id = :main_project_id and
cost_nr sub_p.tree_sortkey between main_p.tree_sortkey and
tree_right(main_p.tree_sortkey) and
… r.object_id_one = sub_p.project_id and
project_id r.object_id_two = c.cost_id

A sample query to extract all financial items
related to a certain main-project.
The Problem:
Cost and Projects can have a N:M relationship:
 One project may have more then one invoice/cost item.
 One cost item may “relate” to more then one project (in particular: project + sub-project, but also the item may be split between two main
projects).
 An invoice may actually not belong to any project at all.

Solution:
 In general, the relationship between projects and costs is defined as an N:M relationship by acs_rel.
 im_costs.project_id points to im_projects ONLY in the case that one cost item relates to exactly one project

Watch out:
 Relation between Projects and Costs:
– im_cost.project_id: Refers to the project only if there is exactly one project per cost item
– acs-rels: Establishes a N:M relationship between projects and cost items. This is used to include several (small) projects in a single invoice.
 Cost Items can be related to a main-project or to a sub-project or any level. So in order to calculate the main project’s total Profit Loss,
you need to sum up the financial items through the full project tree (hierarchical query)


Financial Types (3)
Example

Main project

im_projects
project_id
…

Sub-project
with cost item

im_projects acs_rels im_costs
project_id rel_id cost_id
parent_id object_id_one cost_name
… object_id_two cost_nr
…
project_id

im_projects Sub-project
project_id with cost item
parent_id
…


Relationship Types

acs_objects
object_id
object_type

acs_rel_type
rel_type
object_type_one
acs_rels object_type_two
role_one
rel_id
role_two
rel_type
object_id_one min_n_rels_one
object_id_two max_n_rels_one
min_n_rels_two
max_n_rels_two

membership_rels composition_rels admin_rels group_rels
rel_id rel_id rel_id rel_id
member_state rel_type
group_id

im_biz_object_members
Defines the relationships between an
rel_id im_biz_object and some users. The membership
object_role_id type corresponds to horizontal permissions and
usually includes full member, project manager,
key account and user-defined roles.

Relationship Types

 acs-rels:
– The acs_rels table is essentially a generic mapping table for acs_objects. Once
we come up with a way to associate attributes with relationship types, we could
replace many of the ACS 3.x mapping tables like user_content_map,
user_group_map, and user_group_type_modules_map with this one table. Much
application logic consists of asking questions like Does object X have a
relationship of type Y to object Z? where all that differs is X, Y, and Z. Thus, the
value of consolidating many mapping tables into one is that we can provide a
generic API for defining and querying relationships. In addition, we may need to
design a way to enable type_specific storage for relationships (i.e., foreign key
columns for one-to-many relationships and custom mapping tables for many-to-
many relationships), instead of only supporting generic storage in the acs_rels
table. This would parallel what we do with acs_attributes.
 im_biz_object_members:
– Defines the member of a im_biz_object and their roles (project manager of full
member).
– Such a membership has an impact on the access rights of members to the
business object.
 membership_rels: Defines group-supergroup relations


Translation Types acs_objects
object_id
object_type

im_trans_tasks
im_costs
task_id
task_name im_trans_prices
task_filename
task_status_id price_id
im_invoices project_id company_id
task_type_id task_type_id
source_language_id source_lang_id
target_language_id target_lang_id
subject_area_id subject_area_id
im_trans_invoices task_uom_id uom_id
invoice_id currency
quote_id price
end_date note
task_units
billable_units im_trans_quality_reports
trans_id
report_id
edit_id
im_trans_trados_matrix proof_id
task_id
report_date
other_id
object_id reviewer_id
match_x match_x sample_size
match_rep match_rep allowed_errors
match_100 match_100 total_errors
match_95 match_95 comments
match_85 match_85
match_75 match_75 im_trans_quality_entries
match_50 match_50
match_0 match_0 report_id
quality_category_id
note
minor_errors
major_errors
critical_errors

Translation Types

 im_trans_tasks:
– This tables contains the description of the main activity related to translation projects.
– Includes information about Translation Memory repetitions
– Inludes information about the translator, editor, proof-reader and other assigned to
perform this task (static workflow)
 im_trans_invoices:
– This is currently just a flag (binary information) to identify invoices that have been created
based on im_trans_tasks. Translation invoices are referenced by im_trans_tasks.invoice_id
in order to make sure that every trans_task is included in exactly one invoice. These
references need to be removed if a translation invoice is deleted.
 im_trados_matrix:
– Contains the discounts per customer and translation task type for different Translation
Memory matches.
– The trados_matrix associated with the internal company contains the site-wide defaults
for customer translation prices.


Timesheet Types

acs_objects
object_id
object_type im_timesheet_prices
price_id
company_id
im_costs im_projects task_type_id
material_id
project_id uom_id
project_name currency
customer_id price
im_invoices project_type_id note

start_date
end_date
im_ts_task_deps.
im_ts_invoices ...
task_id_one
task_id_two
dependency_type_id
difference
hardness_type_id

im_tickets im_timesheet_tasks
ticket_id task_id
im_materials
ticket_status_id material_id material_id
ticket_type_id uom_id material_name
ticket_prio_id planned_units material_nr
ticket_customer_contact_id billable_units material_type_id
ticket_assignee_id cost_center_id material_status_id
ticket_sla_id invoice_id material_uom_id
ticket_queue_id priority description


Consulting Types

 im_timesheet_tasks:
– This tables contains the description of the main activity related to
projects.
 im_timesheet_invoices:
– This is currently just a flag (binary information) to identify invoices that
have been created based on im_timesheet_tasks. Timesheet invoices
are referenced by im_timesheet_tasks.invoice_id in order to make sure
that every task is included in exactly one invoice. These references
need to be removed if a timesheet invoice is deleted.
 im_timesheet_prices:
– Contains a price per material and customer.
– The timesheet_prices associated with the internal company contains
the site-wide default price list.


Workflow


Workflow

 ]po[ uses a Petri-Net based workflow Workflow
 A workflow consists of “Places” (states)
Start-
and “Transitions”, linked by “Arcs” that Place
might carry “Guard” expressions.
 WF “Transitions” can be linked to pages
Transition
acting on object’s fields

Place Place

Transition

[Guard] [Guard]

End-
Place


WF @ Runtime

 During runtime, a similar structure is Case
created representing a specific “Case” (a
specific instance of a WF): Start-
– The “case” corresponds to a WF in action. Place
– Transitions become “tasks”, with specific
assignments to users. Task
– Places may include “tokens” that move
through transitions to other places. A single
token in a WF place can be thought as “the Place Place
WF is in status XXX”.
 Petri-Nets allow for more then one token
and more then one token per place, but Task
this option is rarely used in ]po[.
[Guard] [Guard]

End-
Place


WF Tables

Static Workflow Case
Assignments
wf_workflows wf_cases
workflow_key case_id
workflow_key
object_id
state

wf_roles wf_transitions wf_tasks
transition_key task_id
role_key workflow_key case_id
workflow_key role_key transition_key
direction state

wf_places wf_tokens
place_key token_id
workflow_key case_id
place_key
state
wf_arcs
transition_key
place_key
direction


WF “Callbacks”
Transition
“Callbacks” are Pl/SQL database States
procedures that determine the behavior “Enable”

of a transition: “Unassigned” Enable
 A number of “Outgoing Events” allow to
customize the behavior of WF transitions: Enabled

– Enable: Is called when the transition is “Fire”
enabled (a token is placed in one of its input Start
places)
– Unassigned: Is called if the transition hasn’t Time Started
been statically (see below) assigned to a user Deadline
or a group.
– Fire: Is called once the transition gets fired
Hold Timeout Finish Cancel
Notification
 A number of transition’s parameters can be
Can
determined by external routines: Finished
celed
– Time:
“Fire”
– Deadline: autom
– Hold Timeout
– Notification


WF Assignments
Transition
 “Static Assignments”: States
– Specified during the definition of the WF
– Specified using WF “roles”. Each role can be Enable
assigned to one or multiple parties (groups or
users) Enabled
– Specified as “roles” using
wf_transition.role_key and then mapped to Start
parties using wf_context_assignments.
– The specific assignments at runtime are held
Started
in wf_task_assignments.
– This construction might seem a bit complex,
but it is necessary, as you will find out when Finish Cancel
defining your first real WFs.
 “Dynamic Assignments” Finished
Can
celed
– Use the “Unassigned” callback to define the
assigned parties.
– This option allows you to specify the assignee
autom
as a function of object characteristics etc.
– The results of dynamic assignments are
stored in wf_task_assignments.


Timesheet
Controlling


Timesheet Controlling
Requirements and Architecture

 Controlling uses caches per project in order to maintain
aggregated Profit Loss (PL) information.
 The project caches are updated via triggers
 Reporting on portfolios customers is handled by the
reporting engine.

Customer Main Sub “Timesheet”
Customer
Group Project Project Task

“Backward” Reporting “Forward” Propagation
Values are summarized via Reports Costs are cached. Caches are updated via triggers


Timesheet Controlling
Controlling cache architecture

im_projects
 Projects contain a set of “xxx_cache” fields that
contain the aggregated cost elements per type. project_id
…

 CUD (create, update, delete) operations on cost_quotes_cache
cost_invoices_cache
costs (timesheet hours, expenses, …) does NOT cost_timesheet_planned_cache
cost_purchase_orders_cache
update the caches, for performance reasons. cost_bills_cache
cost_timesheet_logged_cache
Instead, cost_expense_planned_cache

triggers reset the cost_expense_logged_cache
cost_delivery_notes_cache
“cost_cache_dirty” to NULL. “Sweeper” reported_hours_cache
Process cost_cache_dirty
 There is a “sweeper” process that periodically
checks “cost_cache_dirty” and updates the
cache. This might be a nightly activity, or every
few minutes.


Timesheet Controlling The hours are
aggregated from
tasks up to main
projects Controlling cache architecture

Project reported cost_ts cach
hours logged e_dirt
y
Main Project (9)
Sub Project1 (4)
im_hours Task1.1 4
user_id Task1.2
project_id SubProject2 (5)
day
Task2.1 3
hours Task2.2 2
billing_rate
billing_currrency conf_project_id
note refers to the main
project. All sub
im_costs projects and tasks
cost_id are included.
conf_object_id cost_id
…

im_ts_conf_objects
conf_id

conf_project_id
conf_user_id
between start_date
end_date

conf_status_id
conf_type_id

Hierarchical Queries

Main Project

Sub-Project 1

Sub-Project 1.1

Sub-Project 1.2

Sub-Project 2

Sub-Project 2.1

Sub-Project 2.2


Auxiliary Tables


Auxilary Tables

GUI
 Define what plugins (these grey boxes) should appear on what
im_component_plugins
page

Menu  Defines the hierarchical menu structure of the system

ViewColumn  Define the columns for ListPages in the core. The ListPages
view need to be extensible at runtime because they might have to
accomodate new columns from add-on modules
View

 The list of all countries in the world
Country

 The list of all currencies
Currency


]project-open[
As a set of services


]po[ As a set of Services

 The difficulty of learning OpenACS and ]
po[ are mostly due to learning and
understanding the “infrastructure” of
OpenACS and to learn how to plug new
functionality into the existing
infrastructure.


Services Provided by OpenACS / ]po[
Part I: SQL
 Packages Package Manager
 Object Oriented Data Model
– PL/SQL Constructors Destructors
 Permissions
 Business Objects
– Status Lifecycle Management
– Type – Subtype Management
– DynFields
 ]po[ Categories
 PostgreSQL
– Referential Integrity
– Indices
– Unique Constraints
– Triggers Transactions
– Constraints
– Hierarchical Objects Queries
 “Portlet” Plug-in Components
 Menu Tabs


Services Provided by OpenACS / ]po[
Part II: TCL
 TCL Pages vs. Library
 Constants
 Packages Package Permissions
 Page Contracts
 Colon Variables
 Authentication System User Management
 TCL Permission API
 Context Bar
 Cascading TCL/ADP Template System
 “return_url” Pattern
 List Builder
 Form Builder
 db_foreach Database Interface
 ]po[ Navbar System
 Localization System
 Oracle/PostgreSQL Database Support
 API-Browser


Frank Bergmann
frank.bergmann@project-open.com
www.project-open.com


]project-open[ Data-Model 100511b

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ]project-open[ Data-Model 100511b

Similar to ]project-open[ Data-Model 100511b (20)

More from Klaus Hofeditz

More from Klaus Hofeditz (20)

Recently uploaded

Recently uploaded (20)

]project-open[ Data-Model 100511b