Back to Search Back to Search Results

Overview

The purpose of this reference guide is to help an IT administrator install and configure the Titania Sync Services. The way this application works is it exports content from a CMS to the local filesystem, them imports it into the Delivery system. In most cases the target system is Titania Delivery. Titania Sync is a Java application that is designed to pull content from one location, and push it to another. When it comes to exporting content from Windchill, Titania uses HTTP requests to Windchill to get the content. Before Windchill 12.1, InfoEngine is used. From Windchill 12.1 and beyond, the Windchill WRS REST API is used. All content and metadata is exported to a temporary location. XML content has special processing that also exports referenced content and resolves those references. If the XML content uses specialized document types, the DTD’s must be specified for that to work. An ACL script to be executed in Arbortext Editor is provided to generate the catalogs required for this utility to read specialized XML but valid XML Catalog files must be provided to the utility. Once all the content has been exported from the CMS, the content is pushed to the delivery system.

Titania Sync was primarily designed and is support on Windows platforms. It is a Java application though, so it can run on other systems, but Oberon does not officially support those systems.

Titania Sync has a few common use cases.

  • Incremental Sync — This use case is identified by the FolderSync task type, a titaniaRepository parameter included in the task, and a query filter in the associated collection that references currentDate. This use case involves targeting documents that were updated in the number of days for synchronization. This use case is characterized by the use of a QueryFilter that uses the a query like (thePersistInfo.updateStamp>'currentDate') before Windchill 12.1

  • Publication Sync — This use case is identified by the FolderSync task type, with a titaniaRepository param included in that task. It involves targeting a single DITA publication, usually by number, and Windchill Sync will also pull down all descendant files for synchronization.

  • Project Sync — This is identified by the use of the TDSync task type. This allows you to export a batch of files from Windchill, and push those files to a project in Titania Delivery.

The following are the pull from Windchill methodologies.

  • Folder Filter

  • Query Filter

  • State Filter

The following are push to Titania Delivery methodologies.

  • Project Sync — This use case is activated by using the TitaniaSync sync config task type.

  • Find, update, and create — This use case is activated by using the FolderSync sync config task type, with a titaniaRepository also configured. It is leveraged by the Incremental Sync and Publication Sync use cases above.

The find, update, and create use case is designed to migrate content from Windchill to Titania. It will find any of the content that already exists in Windchill and update it using its Windchill Number. The Windchill Number can exist as metadata, or in the filename. If a publication does not exist in Titania, this utility will create a project, and upload the publication to that project along with all referenced content.

At a high level, how this is accomplished is by exporting a batch of content to a folder. It then loops over each file in the folder, pulling the metadata from a HARP-META/metadata.json file. It queries Titania for the object using its Windchill Number which is retrieved from the metadata.json. If the object exists, it updates all instances of it. If it does not, and it is a publication, it creates a project based on the publication title, and uploads it along with any referenced content.

This use case has the following flow.

  • Configure the application

  • Clean up the Windchill export cache

  • Archive the last export job if needed

  • Delete the export directory if needed

  • Run Windchill Export if job is set to pull or full

  • Run Windchill Upload if job is set to push, or full

    • Delete the Manifest

    • Recursively loop over each file in the export directory

      • Query Titania for objects that have the same number, or have the number in the name

      • Loop over each result

        • Recursively update referenced files

      • If the object does not exist in Titania, and a title is returned from one of the titleXPath values, then create a new project and recursively upload referenced files

Frequently Asked Questions

  • How does Titania Sync know what files need to be updated in Titania Delivery?

    • In the case of Project Sync, Titania Sync does an MD5 hash comparison between the file on the server, and the file locally. If they do not match, the the file and metadata are uploaded to the project.

    • In the case of Publication Sync and Incremental Sync use cases, Titania Sync queries for every version of the file on the server. It does an MD5 hash comparison, if they do not match, then it uploads the file. If they do match, then it compares the metadata, and if any of the metadata changes then it updates the metadata.