We have used Primavera 6.0 + API’s and webservices extensively to integrate Primavera with multiple systems. Some of the key learnings in developing integrations are captured in the blog.
As with any integration, the key is design, design , design. The Primavera programming team has done a tremendous job of documenting the API’s and the Webservices (WSDL’s). Personally if there is some more documentation on the XSD, it will be great but overall there is a wealth of information that can be read through and coded against.
Designing a Webservices integration forces you to think of the network and the amount of data sent over the wire in every call. The goal of any good webservice client is to minimize chatter and a good design will force the integration to do that effectively.
The big leap in designing integration applications on the P6 webservice stack for exchange of project data is to use the ImportService and ExportService provided by Primavera.
The first part of this series will detail on using the ImportService. The figure below shows a typical flow on how to use the import service.
On the face of it the import service simply expects an XML file, set a few options and import the project. The key assumption is for the import service to work properly, the XML file that you construct has to have referential integrity within itself in terms of specifying relationships between objects that are part of the XML. There are multiple ways to create an XML file and to discuss all the approaches is way beyond the scope of this article.
The easiest way to generate an XML that the import service will understand is to create it using the classes that have been generated using the Primavera schema and supplied as part of the P6 webservices deployment. As long as you are familiar with the relationships between these classes, it is quite trivial to create a tree of objects from these classes and use a ‘marshaller’ to output an XML.
The Project ImportService has two interesting options on how to import classes of objects. Primavera has two classes of objects – Global Business Objects and Project Business Objects. Global Business Objects are objects that are shared across projects (e.g. Resources, Roles, Admin Categories etc.). Project Business Objects are specific to the project that you are importing.
The import service has two methods – one for creating a project and one for updating a project.
In Primavera, every project needs an Enterprise Project Structure Node. You can either store the default (where all your imported projects should go to) in your application or ask the user to specify an EPS node of their choice. The internal Id of this EPS object is needed to create a project in Primavera.
If you are planning to update an existing project, you need the existing ‘object id’ of the project that you are going to update.
Happy Importing!
Tags: import, primavera, webservices