We need to talk about … importing XER files.
The Oracle Primavera P6 database allows any number of projects to be “exported” to a single XER file, and that XER file can be “imported” into a P6 database in a variety of ways:
- One-to-One create, i.e. make one project for each of the projects represented in the XER file.
- One-to-One update, merge the data from the XER file to existing projects
- Many-to-One create or merge or update the data from all the projects in the XER file into fewer, possibly only one, project in the destination database.
Firstly, I should explain the parenthesis around “exported” and “imported”. If only Oracle Primavera had called these processes Backup and Restore I think a lot of customers would have been better prepared for the challenges ahead. The built in Primavera P6 Import/export to an XER file is a first class method of backing up your projects – indeed this can be made so quick and easy that everyone should do it more often – but that’s another story for another time. The P6 import/export is NOT a good way to move data between differently configured P6 databases, e.g. between an Owner and a Contractor. There are also some long standing, let’s call them restrictions, which we need to work around.
What Restrictions Do We Have?
- Importing an activity where a resource is used more than once
- Restoring a group of projects to a single destination project
Many clients use the P6 capability to add a resource more than once on an activity because it requires, say, more than one cost account or there is a change/variation order associated with some of the work. Up to and including Primavera P6 v8.3.2, P6 will only restore the resource assignment record that was added last amongst the group of duplicate resources on a single activity. It simply does not import the same data that was exported.
I first encountered the second of the two problems when an asset owner wanted to merge a large number of contractor projects in a single XER file into a single project in their Integrated Asset Plan. Duplicate activities are added with no discernable pattern, or available workaround to prepare the data prior to import.
Fortunately, Collabro’s Legare handles both of these issues correctly. Indeed the “Duplicate resource” issue has been understood so long the design parameters to deal with it were on the earliest “paper napkin” sketch of how Legare works.
The above two issues affect only a few clients, but everyone operating on the cusp of the owner/contractor boundary – and that’s quite a few of us – are aware of the challenges when importing a contractor XER into the owner’s Primavera P6 database and the lack of configuration control over what we import.
What Control Do We Need When Importing?
Moving data from one P6 database to another is a very regular task in projects that involve both an owner and contractor(s).
The built in XER import offers practically no configuration control when importing. Yes, you can for example ignore all Activity Codes on import, but what if you REALLY wanted:
- Some Activity Codes imported
- One Activity code converted to the owner’s WBS
- Some activity codes converted to UDFs
- Some values of the Activity codes changed
- Some ignored
- Only Activities with certain Activity Code values imported
The above list is typical.
Collabro’s Legare reads the XER file and can transform the data in any way prior to import. It is not modifying the XER file, and most importantly it uses the Primavera P6 API (Application Programming Interface) to update the P6 database NOT the built in Import facility which operates at the database table level. It is therefore completely secure and requires no modification as you upgrade to later Primavera P6 versions.
Legare can perform practically any modification on any of the data prior to import. It can be initiated by a planning engineer using Primavera P6, or utilized as a server side process running timed scripts on a configurable thread count with email notifications.
The import/export challenges have been with us so long that there are a variety of ways of dealing with it. There is a class of products we refer to as XER editors, where the XER file is edited before import. This solves some of the issues – but then still relies on the built in Import functionality in Primavera P6, so they cannot deal with the issues that are native to the import function itself.
Just One Of The Legare Connectors
Legare consists of a core engine that does all the work, and a variety of connectors that customize the creation of import/export scripts depending on the data source. The discussion above requires the core Legare product, and the XER connector.