GAEA INTERNAL USE ONLY

Rev Requirement Name Owner Date

1.5 Athena 2.0 Gaea

Technical Design of Athena

(Agile-Primavera Connector)

Prepared by: Sury Balasubramanian, Shanmugavel S., Magihzmannan M.

System/Project Name
Athena
Total No. Pages: 14
 GAEA INTERNAL USE ONLY

Record of Revisions
Rev Description Owner Approval Date
1 Initial Draft Sury

- ii -
 GAEA INTERNAL USE ONLY

Table of Contents

1.0 INTRODUCTION...............................................................................................................................................4

2.0 ASSUMPTIONS..................................................................................................................................................4

3.0 TECHNOLOGY OVERVIEW..........................................................................................................................5

3.1 Connector Technology Stack.......................................................................................................................5

4.0 ARCHITECTURAL APPROACH & SUMMARY..........................................................................................6

4.1 Database Layer.............................................................................................................................................7

4.2 Presentation Layer.......................................................................................................................................8
4.3 Business Layer.............................................................................................................................................9
4.3.1 Key Java Classes in the connector..................................................................................................9
4.3.2 Key Technical Design Decisions...................................................................................................12
4.4 Data Access Layer......................................................................................................................................13

5.0 ARCHITECTURAL GOALS & CONSTRAINTS........................................................................................13

6.0 CONNECTOR ADMIN ARCHITECTURE...................................................................................................13

7.0 NOTES................................................................................................................................................................14

8.0 Appendix.............................................................................................................................................................14

- iii -
GAEA INTERNAL USE ONLY

1.0 INTRODUCTION
This document intends to give a summary of the design of Athena (internal code name for Oracle Agile-
Primavera connector). The connector is used to provide the best-of-breed functionality of Oracle Agile and
Oracle Primavera to its respective customers. This should be used in conjunction with the functional design
document 9_3_1_FDD_RPS_Primavera_Integration_v1.2. The primary audiences for this document are
technical architects, programmers and techno-functional personnel intending to understand the connector.
Not all classes are documented here; the writers strongly believe that the code by itself is the living breathing
documentation for any system. This document gives an overview into design decisions, architectural
considerations, code structure and highlights possible future improvements.

2.0 ASSUMPTIONS

Reader knows basic architecture of Oracle Agile and Oracle Primavera and the webservices each of these
products exposes. Please refer to respective product documentation to get familiarized with if there are
any questions regarding them.
Reader understands basic webservices, java patterns and related technologies.

- iv -
GAEA INTERNAL USE ONLY

3.0 TECHNOLOGY OVERVIEW

Figure 1

Figure 1 depicts the architecture of the connector along with Agile and Primavera. A high-level view of the
components involved is also shown.

3.1 Connector Technology Stack

-v-
GAEA INTERNAL USE ONLY

Figure 2

Figure 2 indicates the various technologies used in the connector. The technology stack of connector is Java-
centric with a liberal use of standard frameworks for presentation and the data access layer (Struts, Hibernate).
Two standard patterns Business Delegate, Factory and Service Locators are used.

4.0 ARCHITECTURAL APPROACH & SUMMARY

The connector was logically split into two halves. Classes that use and call Agile webservices will not be
aware of classes that use Primavera webservices. A generic mapping bean which holds the transformed data
will be the bridge between these classes. The connector uses Java reflection to set and get values from
Agile/Primavera webservice clients instead of hard-coding any specific fields in the connector . Thus, the
connector can technically be in the future be split into two separate components that can talk to a common
layer which understands messages (specific or abstract as the case may be) that are sent to each to other. All
transformations are done using Java objects instead of parsing native XML. Axis 2.0 and JAXB 1 are used
to marshall and unmarshall Java objects into and out of XML.

- vi -
GAEA INTERNAL USE ONLY

All the fields that needed to be exchanged between Agile and Primavera were stored in a table
(ATHENA_OBJECT_MAPPING). On connector initialization, the table was loaded into the VM using a
context listener. Hot deployment of changes to the mapping table will be available in the next point release.

The presentation layer for the connector was necessary to satisfy some of the requirements that arose of the
functional design.

4.1 Database Layer

The mapping table that stores the field level mappings of fields between Agile and Primavera are currently
stored in a table. The table can exist in any Oracle DB that can be reached by the connector at the time of
installation and startup. Figure 3 and Figure 4 show the table and its related columns. Current count of the
table is 75 rows.

- vii -
GAEA INTERNAL USE ONLY

Figure 3

Figure 4

4.2 Presentation Layer

A decision was made in the early stages of the project to go with Java/JSP technology stack for the initial
POC. EXT-JS was used as the primary framework in the POC but after further discussions regarding
licenses and the scope of the UI it was decided to go with basic JSP/JSTL and YUI framework for AJAX.
Struts was chosen over Spring as the framework of choice for the presentation layer as the scope of
presentation in the connector was too small to warrant a full-blown Spring stack implementation.

- viii -
GAEA INTERNAL USE ONLY

4.3 Business Layer

Currently the connector exposes calls to the business layer only through the web layer. All web calls go
through appropriate Struts Action classes which intercepts and delegates it to a business delegate.
The business delegate depending on where the call is being initiated from finds a service locator to find the
service and executes its execute method. To illustrate the above, a simple sequence diagram depicts the
flow explained above in Figure 5. The sequence diagram illustrates the flow within the connector when an
admin synchronizes users in agile to resources in Primavera. Please note that web service calls to
Primavera and Agile are not shown here but are made by the respective service classes in the connector. It is
also to be noted that a List<HashMap<MappingBean,Object>> is passed between Agile and Primavera (or
vice-versa) which is then used by the downstream delegate class to transform it into either an Primavera or
an Agile entity before calling the native services exposed by the applications.

Figure 5

4.3.1 Key Java Classes in the connector

Some of the key classes in the connector are shown in this section.

- ix -
GAEA INTERNAL USE ONLY

Figure 6

Figure 6 shows the classes that make up core services that delegates call for authentication, exporting
projects , importing projects, syncing resources, reading activities and so on.

-x-
GAEA INTERNAL USE ONLY

Figure 7

Figure 7 shows the MappingBean class used in transformation.

- xi -
GAEA INTERNAL USE ONLY

Figure 8

Figure 8 shows the Agile service classes used in the connector to Authenticate, Search, import and export
projects. (Note: This will be refactored into separate export and import classes).

Figure 9

Figure 9 shows the IProgramObj interface whose implementation class is the primary driver of exchange of
project information between the two systems.

4.3.2 Key Technical Design Decisions

With the view of keeping the network chatter to a minimum, the connector was designed to make as few
calls to either Agile or Primavera as possible. On an export from Agile, with the help of Oracle Agile
development, a single call to load the entire project tree was accomplished and loaded into java client
objects. This was then used for transformation into instances of MappingBean objects which were then used
to make a single import call to import the project into Primavera. The single import call into Primavera

- xii -
GAEA INTERNAL USE ONLY

would import the project, its tasks, dependencies, resources, roles, budgets and expenses for the project. The
alternative would have been to make separate web service calls to create each of the entities mentioned.

The export out of Primavera would be a single webservice call that would export the project out of
Primavera and marshaled into Java objects , transformed into a list of mapping bean instances which would
then be used to update Agile. The current update into Agile is a three step process:
1. Update Users in Agile from Project Resources in Primavera
2. Update UserGroups in Agile from Project Roles in Primavera
3. Update project in Agile from Primavera project

Other webservice calls e.g. Authentication, Resource sync also minimize chatter between the connector and
the upstream/downstream systems. Specifically authorization in Agile and Primavera are made sticky
using sessions.

Another important design decision that was taken was the load of Primavera Code, User-Defined Types that
are being used in the connector on connector initialization. The objectIds and datatypes of these codes and
user-defined types will have to referred in the XML/Java objects that have to be passed to Primavera and
hence it made sense to load them first and use them throughout the life of the connector.

As much as possible, interfaces and abstract classes were used to stub out the actual implementation details.

Simple POJOs to assist in transformation of the data by means of other the helper classes and utilities
round up the business layer. The properties of the connector (e.g. Primavera webservice location,
loginname, password, Agile webservice location, loginname, password) were stored using the Java
PreferencesAPI.

There was no real need for exposing any of the business services as internal webservices at the time of
design or initial implementation as it was decided to keep the connector within a single JVM

4.4 Data Access Layer

JDBC was the obvious architectural choice for the data-access layer as we are dealing with one table to load
on startup. The DAO pattern has been used with to load the mapping table into the mapping bean.

5.0 ARCHITECTURAL GOALS & CONSTRAINTS

The goal of not using any native SDK/API calls was the primary aim of the connector. All calls whether to
populate the user-interface or perform a business function was done using webservices in Primavera and
Agile. Primavera 6.2 does not support SSO/LDAP so this was a constraint in terms of a true seamless
connector. It is envisioned that Primavera 7 and above supports this at which point a generic authorization
service can be stubbed out in the future. It is hoped that the next version of Agile project import will import
resources and roles in addition to projects.

The goal of scriptlet-less JSP was enforced early on for easy readability of code. While it was desired to use JS
handlers instead of embedding script code, there are instances of JS code seen in JSP.

AJAX calls are made to never call Action classes but downstream BusinessDelegate methods and never a
DAO class as well. The dependency of AJAX calls was always with BusinessDelegates to keep with the
original goal of being data-agnostic whether it is an synchronous or asynchronous call.

6.0 CONNECTOR INSTALLATION & ADMINISTRATION

The connector administration screen is simple and web-based (Struts/JSP) where the administrative user can
change some defaults such as Default EPS in Primavera, synchronize resources and roles from Agile to
Primavera, set logging level etc. These administrative preferences are stored using helper classes using the
PreferencesAPI

- xiii -
GAEA INTERNAL USE ONLY

The actual installation of the connector is swing based with a simple wizard that asks for location of
Primavera and Agile webservice locations (server, port, url) and authentication to verify these. The wizard
also asks for the location of the database where it can store the mapping table. For more details please see the
Connector Installation Guide.

7.0 NOTES

8.0 APPENDIX

- xiv -