Hi Michael.
We use transport case for backups, for bulk propagation of objects between environments and whenever we need to make bulk changes to properties that TC is able to change (e.g. when retiring an agent used in multiple jobs via ucybchng).
A predecessor of mine had automated the TC jobs to run every night, so users could propagate objects between environments. Since that once led to a wiped environment due to a (presumed bug), I disabled that automation in my time. Using TC to propagate objects between test and prod environments now requires users to explicitly request this, I then run the transfer on demand. Since that day, I also monitor the transport case's tables in the database to ensure they don't contain nonsensical amounts of entries.
We allow all users to use XML import/export for all purposes using the AWI context menu. We also use XML export in place of TC when we have different versions in prod and test, and TC sometimes (but not always) refuses to work then. XML also sometimes refuses to work in that case, but we've always been able to make it work by manually editing the XML header's version flag with no ill effects.
I myself never had a great impression of TC, mostly due to these design decisions and quirks:
1. I never logically understood why a "transport" mechanism should be invoked for backups and archiving
2. Initially and/or with new colleagues in the mix, the terminology of "unload" and "load" is often times confusing, doubly so when discussed across language barriers, since you can mentally apply these terms to the TC or to the database, which totally changes their respective meaning.
n.b. I suspect that whole TC concept probably dates back to the Windows 95 transport case used for file synchronisation. Much like Clippy, Microsoft quickly abandoned that ill-fated representation.
3. ucybchng is limited in what fields it can change. With an open and at the same time sensible format, this would not neccessarily have been the (no pun intended) case.
4. TC always wipes the version history of any objects. So whether you "bulk transport" or "bulk transform", you always lose the old version info. This is a major drawback.
Regardless, we'll probably stick with TC for the time being, using XML as a fallback. We didn't yet have any major destructive events with ucybchng, the limited things it does, it so far did reliably.
Best,
Carsten
Original Message:
Sent: 10-08-2019 11:41 AM
From: Michael Lowry
Subject: Transport case unload/load vs. XML export/import
I have a quick update on this topic. We have almost completed the migration from our old 'UC4 Toolkit' solution based on the transport case file format to a new app that used the XML file format. The two solutions have been running side-by-side for several months, and we have been migrating users from the old tool to the new one. Next week we plan to shut down UC4 Toolkit, leaving the new XML-based app as the only way for users to promote AE batches between environments.
It has been a long journey, and we have run into several obstacles along the way. However, I am confident we made the right decision.
The transport case format has never been officially documented. And sadly, despite several promises from Automic/CA/Broadcom, no documentation was ever provided. I did manage to reverse engineer the format, but it was never easy to work with. The XML file format, although no longer documented, is at least transparent enough to make sense of. It's also much easier to work with. There are myriad off-the-shelf tools for working with XML, and this has made development much more straightforward.
The new solution is written entirely in Java, and has no dependencies on command-line 'utilitiy' tools from Broadcom. In particular, we will be glad to say goodbye to the AE DB Change program, ucybchng. It has been a thorn in our side for years. It was always at least a version behind in terms of capabilities, and each bug fix risked breaking things that worked or changing behaviors in unexpected ways. We are now in control of the transformation engine - a tool we wrote in-house. The trickiest part was reproducing the behavior of the OBJECT_USE rule - a change rule type that updates object references. There are many, many places in the AE XML schema that can contain references to AE objects, and covering most of them took quite a bit of trial and error.
Now we look forward to leaving the old tool behind and committing 100% to the new approach.
How about the rest of you? Do you still use the transport case, or have you also migrated to an XML-based solution?