Transport case unload/load vs. XML export/import

[Michael A. Lowry]

Different approaches to moving objects between AE systems

Transport case

1. Select objects, e.g. via the Transport Case in the User Interface or the TransportObject API class.
2. Unload objects using AE DB Unload program, ucybdbun.
3. Change objects using AE DB Change program, ucybchng.
4. Load objects using AE DB Load program, ucybdbld.

XML

1. Select objects, e.g., in the User Interface or using the FolderList API class.
2. Export objects to XML file, e.g., via the Export function in the User Interface or the ExportObject API class.
3. Change objects in XML file, e.g., using XSLT.
4. Import objects from XML file, e.g., via the Import function in the User Interface or the ImportObject API class.

JSON

TBD — See JSON import/export documentation.

Pros & Cons of each approach

	Advantages	Disadvantages
DB Unload/Load	Faster, because it goes straight to the database. Does not put an additional load on the Automation Engine Recommended by Automic for making mass changes. No maximum file size. Passwords (encrypted) are included.	No simultaneous unloads. Transport case file format not backward-compatible. No official documentation of transport case file format. (Unofficial documentation is available.) Not all object attributes can be changed. Loading objects into a different target folder is not straightforward. ucybchng is not always reliable. Object searches may be unreliable in the moments after a DB load. Bypassing the AE might be less safe. Version history of objects is not preserved
XML Export/Import	Simultaneous exports. XML file format largely backward-compatible. Easy to specify new target folder. Fully documented, human-readable XML schema: Change any object attribute. Validate objects’ compliance with standards & conventions. Present a side-by-side comparison of original & changed XML prior to deployment. Easier to integrate with enterprise applications using Java APIs (e.g.,ExportObject & ImportObject). Going through the AE might be safer. Object searches not impacted. No reliance on ucybchng. Version history of objects is preserved.	Slower, because it goes through the AE server. Puts a higher load on the AE (DWPs). No vendor-supported way of changing exported XML files. Automic no longer publishes documentation of the XML schema. Maximum file size for imports: 30 MB. Not recommended by Automic for making mass changes. Passwords are not included.
JSON Export/Import	TBD

 

Original post

Our current system for promoting batches between staging environments is based on the transport case mechanism. For a while now, we have been looking into the possibility of moving away from this approach, and switching to an approach based on XML. Before we put too much effort into this transition, I thought it wise to ask the broader community for input.

Questions

1. Has anyone switched from using the transport case to XML for batch deployments? How did it go? What did you learn?
2. Has anyone performed benchmarks to compare the relative performance of the two approaches, and to measure the load each places on the AE/DB?
3. How might it be possible to mitigate the disadvantages of the XML approach?

[Legacy User]

Hi Michael

Actually there is a supported XML based transportation & change software (WF2 by System Partners). We're using it for quiet a while and have no big issues so far. The tool exports on a per-object-level, so maximum file sizes are no problem. I regularily export & import around 300 objects - I don't know if you consider this amount as "mass change".

Mutation is either done using the WF2 tool-features itself or self-written sed / xslt scripts - like removing "modified"-dates for Subversion checkins.

Regards
Joel

[Michael A. Lowry]

Joel Wiesmann wrote:

 

Actually there is a supported XML based transportation & change software (WF2 by System Partners). We're using it for quiet a while and have no big issues so far. The tool exports on a per-object-level, so maximum file sizes are no problem. I regularily export & import around 300 objects - I don't know if you consider this amount as "mass change".

Mutation is either done using the WF2 tool-features itself or self-written sed / xslt scripts - like removing "modified"-dates for Subversion checkins.

Thanks for the reply, Joel. We have worked with System Partners before, for a migration project. We have been meaning to run a PoC based on the idea of using WF2 for this, but have not gotten around to it yet. Exporting one XML file per object is certainly a way around the file size limitation; but I wonder if it does not impose other costs.