Architecture

]project-open[ is based on a standard Web application architecture, consisting of an open-source Web server with an underlying open-source PostgreSQL database.

 

(Schematic ]po[ architecture.)

Supporting both Windows and Linux, ]po[ consists of four main components:

• The PostgreSQL  open-source database. Support for Oracle is available on request.

• The AOLserver  open-source Web server for handling Web requests.

• The OpenACS  community system provides the basic application infrastructure.

• The ]project-open[ packages implement the particular project management and finance functionality. 

Modular & Configurable

(A sample GUI page with configurable elements.) 

 

All ]po[ functionality is contained in packages that can be installed and uninstalled at runtime. Packages define a number of GUI elements such as menu tabs, portlets, dynamic fields and categories that can all be enabled, disabled or restricted per user group:

• Packages can be installed or uninstalled using the Package Manager.

• Menu tabs can be enabled, disabled or restricted to certain user groups.

• Portlets can be enabled and restricted like menus. The user can define their placement, with a default location definable by the System Administrator.

• Dynamic fields allow for standard objects to be extended with custom fields. Field read/write permissions can be set per user group.

• Categories allow for all types and states in the system to be extended.

 

Numerous other GUI elements are also customizable:

• Most "lists" in ]po[ pages can be extended by the System Administrator to add new columns and to restrict the visibility of columns to certain user groups.

 

 

 Horizontal Services and Business Objects

A number of powerful "horizontal services" in ]project-open[ have been developed generically for all important business objects. Using these services multiple time allows reducing code redundancies, reducing errors and reducing the learning time for users.

(A number of powerful "horizontal services" apply to most business objects.)

The most important horizontal services are:

• Permission System:
  ]project-open[ incorporates a powerful permission system that combines "vertical" role-base permissions (per user group) with "horizontal" permissions per business object.
  
• Object Status / Life Cycle:
  You can configure the states and therefore the life cycle of business using categories. States may be controlled by a workflow.
  
• Object Sub-Types:
  Sub-types are specific configurations of a business object using categories. For example, both a "provider company" and a "customer company" are companies. However, these sub-types of company may contain different fields and certain business logic may behave differently. Sub-types are a powerful means to reduce redundancy in the database and in the ]po[ code. Sub-types are user configurable to a large degree.
  
• Dynamic Fields & SQL Metadata System:
  Dynamic Fields are custom definable add-on fields for all business objects. The type of fields range from simple text fields to finite ranges of values defined by categories or data in database tabled.
  
• Workflow:
  The ]po[ workflow allows to control the states of a business object across it's lifecycle. Workflows are explained further below on this page.
  
• REST Web-Services Interface:
  The REST Interface allows for permission controlled generic access to all ]po[ business objects. The interface is heavily used for HTML5 application development as generic data sources, but can also be used to integrate ]po[ with other applications.
  
• Full-Text Search Engine:
  The search engine allows users a shortcut access to most business objects, allowing them to skip most search screens.
  
• Relationships:
  relationships are an advanced tool in ]po[, allowing to define generic "directed arrows" between arbitrary business objects that may include with additional attributes. Examples are "Employee Relationship" (users belonging to a company) or "Project Deliverable Relationship" (configuration items belonging to a project).
  
• Audit:
  The audit package tracks user changes to business objects and allows ]po[ to comply with anti-fraud regulations including Basel II or the Sarbanes-Oxley Act.
  
• CSV Import:
  Several business objects can be imported generically from CSV (Microsoft Excel) data sources. The number of supported objects may soon increase.
  
• Finance:
  Most ]po[ business objects are integrated into the financial module, allowing to track the financial impact of the business object with the goal to provide complete accounting for profit & loss per customer, project or cost center.
  
• Calendar:
  The calendar display provides a time based perspective on a number of events related to business objects.
  

 

Workflows

 

(A simple project approval workflow. The task "Approve" automatically appears in the user's Workflow inbox.)

In ]po[, all important business objects are workflow-enabled. Workflows are a convenient way to implement approval processes and route objects across departments or through any business process.

A [graphical workflow editor] allows modifying workflows at runtime. Workflows are started once a new object is created. Assigned users are notified via email, and the assigned task will appear in the user's Workflow inbox.

Workflows are implemented using the Petri-Net formalism , allowing for advanced modeling techniques  such as parallel paths and N out of M conditions. Callback functions allow users to modify the associated business object and the ]po[ data model in general.

 

Permission System

 

(The ]po[ User Permission Matrix defines the (V)iew, (R)ead, (W)rite and (A)dmin rights between
user groups. Bold capital letters indicate set permissions, normal letter indicate no permissions.)

Access to ]po[ objects and all important actions in ]po[ are controlled by a role-based permission system, allowing for fine-grain access control. This detailed level of control has been implemented in order to allow external users such as customers or providers to access the system, an important requirement for being able to share information (→ see Knowledge Management).

• Package permissions allow administrators to control general access to ]po[ on a per-package level.
  

• Privileges control the actions that different user groups are able to perform, such as creating or modifying certain objects. There are a total of 184 different privileges.

• The user permission matrix determines how user groups can relate to each other. For example, customers in ]po[ shouldn't see the presence of providers in the same project room, while it is OK to see all in-house project members. This matrix also makes it possible to define sub-administration rights—for example, the right of the “sales” group to create new members of the group “customers”.

• Menu permissions allow to reduce the system's capabilities for certain user groups—customers or providers, for example.

• Portlet permissions allow to limit the visibility of object information.

• DynField permissions allow to define access permission for each field of an object type.

Taken together, these rich permission options make it possible to adapt ]po[ to the trust relationships within most companies without having to customize the system.

 

Reporting System

 

(An "indicator" tracks a critical performance measure over time.)

 

]po[ provides a large number of options to extract information from the system:

• Reporting Engine:
  The reporting engine formats hierarchical reports with groups and subtotals. It is fully integrated into the Web application and its permission system.

• Data Warehouse:
  ]po[ includes its own data warehouse engine based on ROLAP technology.

• Performance Indicators:
  Indicators track critical performance measures over time and allow for defining Balanced Scorecards.

• External Reporting Tools:
  Thanks to the open and documented data model and the ODBC interface, it is easy to create reports using third-party tools including Crystal Reports, MS Access, Pentaho and others. 

 

Security

]po[ and its underlying OpenACS platform have been designed from the beginning to operate in the hostile Internet environment. A number of security features allow ]po[ to be run safely with direct access from the Internet:

• Parameter Check via “Page Contracts”:
  Every Web page in ]po[ contains a “page contract” that checks any values coming from the hostile Internet environment and determines whether they match the defined data type. Page contracts are obligatory, so the developers can't “forget” this check.
  In other words, ]po[ includes an integrated Web application firewall.

• SQL Injection Blocker:
  SQL injection is one of the most common vulnerabilities in Web applications. To avoid such attacks, ]po[ includes a special database driver that transfers parameter values separately from their SQL statement to the database.

• Cross-Site Scripting (XSS) Blocker:
  The “page contract” mechanism above also acts as a filter against cross-site scripting attacks. By default, no HTML tags are allowed in “string values,” so a developer must explicitly allow for HTML tags. But even “HTML strings” are prevented from containing potentially malicious HTML tags.

• Buffer Overflow Protection:
  ]po[ is written in the TCL programming language, with arbitrary length strings, avoiding buffer overflows. (Buffer overflows are possible in the AOLserver component; however, no such vulnerability has been reported since 2001.)

• “Obscure” but Well-Maintained:
  The combination of AOLserver and the TCL programming language is not commonly found in the Internet, so a potential hacker will need to expend a considerable amount of criminal energy in order to reverse-engineer the application stack. In addition, this code is very well-maintained: AOLserver is the core of the AOL infrastructure, and OpenACS/]po[ is developed as open-source by senior developers.

• Semi-Automatic Security Reviews:
  ]po[ includes a semi-automatic security checker that identifies weak code and potential security threats.

Together, these features have convinced many ]po[ customers that the benefits from seamless Internet collaboration exceed the potential cost of a security breach. A prominent figure amongst this group includes VAW arvato (Bertelsmann group).

 

Performance & Scalability

Benchmark results show that ]po[ can serve organizations with up to 250 active users using a single quad-core processor Intel/AMD server in a typical setting. Up to 1,000 active users can be served using a 4-processor Intel/AMD server.

Higher performance can be achieved by using load balancing and clustered application servers. For this purpose, ]po[ and its underlying OpenACS platform allow the separation of database and application servers. Only the database server limits such a configuration.

Even higher scalability can be achieved using different hardware platforms. For example the Business University Vienna is serving 23,000 users using OpenACS on an IBM Power5 mainframe, with up to 1,200 users concurrently active (please see: Who is using OpenACS?).

Backup & Business Continuity

In order to provide business continuity, a combination of two physical servers has proven to be simple and effective:

• A “production server” executes the productive ]po[ instance.

• A “backup server” serves for backup, development and testing. The backup server should be located in a different building then the production server.

A backup procedure takes a full snapshot of the ]po[ database three times a day (5am, 1pm, 9pm) and copies the snapshot to the backup server. This way, the customer will loose max. 4 hours of work in a worst-case situation.

 

Data Model

 

(Core tables of the ]po[ data model, please click on the image to enlarge.)

 

]po[ is based on a object-oriented data model with more then 120 business objects.

The data can be accessed directly via SQL and modified from external applications using an API written in the PL/SQL database language. This way, advanced users can write reports or import data directly, without having to learn about the higher layers of the application.

The object-oriented structure of the data model allows for advanced features:

• Permissions:
  Powerful and standardized access permissions per object and user group (see above).

• Full-Text Search Engine:
  The search engine indexes all important business objects, considering application permissions.

• Dynamic Fields Extensions:
  Users can extend business objects with new fields without modifying the application code. New fields automatically appear in search forums and data-warehouse cubes.

• Discussions and File Storage:
  All important business objects allow to attach files and to start discussions about them, allowing for e-Room collaboration amongst all team members.

Browser Compatibility

]po[ is compatible with all modern browsers. For minor issues with IE8 showing select lists, a patch is available from our partner ABAKUS. 

Application Integration

(Existing integration links and their maturity status. Please click on the image to enlarge.)

 

]po[ includes a large number of functioning integration links with external applications.

The large number of already existing integrations is at least in part due to the existing infrastructure that simplifies system integration:

• ODBC Protocol:
  ODBC allows external applications to access the ]po[ PL/SQL API, allowing for full control of the application.

• Web Service XML-RPC Protocol:
  A built-in XML-RPC server makes it possible to expose the ]po[ TCL API to external applications.

• Web Service SOAP Protocol:
  A SOAP server module exposes the ]po[ PL/SQL API to external applications.

• XML Libraries:
  tDom libraries allow for parsing and constructing XML documents.

• CSV Libraries:
  A number of libraries support the creation and parsing of CSV documents.

 

Hierarchical Data Structures

A surprising number of ]po[ objects exhibit a hierarchical structure, reflecting the nature of the real business world and allowing ]po[ to report on data at various levels of detail:

• Projects can have sub-projects of any level.

• Customers may be part of a group structure and holdings.

• A company's departments and cost centers structure is hierarchical.

• Groups may have multiple subgroup levels. Members of subgroups automatically become members of the supergroups.

• The types of projects, customers, help desk tickets or other objects may contain subtypes of any level. For example, a “Provider” company might contain the subtypes “IT Provider,” “Office Equipment Provider” and so on. Establishing these subtypes make it possible to generate reports and analyze spending among the unique provider subtypes.

• The states of projects, customers, help desk tickets or other objects may contain substates of any level. For example, a “closed” project could be classified as “Deleted,” “Canceled by the Customer,” “Unpaid,” etc. Bear in mind, however, that timesheet hours should only be logged on “open” projects.

• Configuration items in the ]po[ configuration database (=inventory) may have sub-elements. A “Server” may be the home of several applications, which in turn consist of different modules, and so on.

• Discussions threads may contain replies at any level.

• Files may be located in folders and subfolders.

• Menus in ]po[ allow for any level of submenus.

• The object types in ]po[ themselves form a class hierarchy.

• Permissions in ]po[ are hierarchical. For example the “admin” permission of one object allows the admin to execute “read,” “write,” “create” and “delete,” which in turn may include additional subpermissions.

Hierarchical structures provide customers with a wealth of options to model the real world, as opposed to simplifying or tweaking the reality to match a rigid system. This is one of the most unique characteristics of ]project-open[ and the source of its configuration flexibility.

]po[ includes a number of advanced techniques to speed up hierarchical SQL queries, so there are no performance penalties to using hierarchies.