Automic Workload Automation

I plan to implement checks of objects in the transport case unload files, such as: • validating adherence to naming conventions • confirming that dependent objects are present • checking the contents of job Process tabs for problems I have analyzed the structure of the transport case unload file and believe I understand the overall structure and many of the details, but it would still help to have a proper file format specification. Has anyone written up a specification of the transport case unload file format? Second, I would like to build a Java program that reads in a transport case unload file and then builds Java objects corresponding to the tables, rows, and fields contained in the file. Has anyone written such a program?

Update: See Transport case file format 

Chuck Williams said:

No, but I have written Java programs to create transport cases. One program creates an XML manifest file by recursively reading a specific folder in a specific client. A second program reads the transport case, executes a job to turn off version management, copies all the listed objects in the manifest to the transport case, executes a job to export the transport case and then calls a job to turn version management back on.

That sounds a lot like the solution we implemented, although we did everything but the first step via ordinary shell scripting & UC4 scripting.

We do not disable version management when exporting the transport case. Why do you do this?

The load will also take longer with Version Management enabled if there are already objects of the same name in the target system. 

The Load process has to correlate the versions and re-number them accordingly.

Jennifer Jinhong said:

The load will also take longer with Version Management enabled if there are already objects of the same name in the target system. 

The Load process has to correlate the versions and re-number them accordingly.

Oh wow. I never thought of that. I guess it can get complicated!

Chuck Williams said:

Version management is disabled and re-enabled after the transport case is created as I don't want to be promoting prior/old/obsolete versions of an object from Development to QA to Production. I only want the latest (tested) version to be included. I was told by an Automic consultant, that if that was not done, all versions would be included in the transport case.

 

Are you sure? I've never found old versions in my transport cases. As long as I know, the import of a transport case into the target system creates a new version. The old versions of the target system remain and are re-numbered (as Jenifer says). Old versions of the target system are not overwritten of those from the source. 

You may not *see* the old versions as objects, but check the Version history of some of the transported items, and you may find them there.

Daryl, I think we are talking of the same. As long as Chuck does not need any versions of his transports on the target system turning off version management is the right thing. 

Just to clarify  ( - not that this is setting the world on fire)

Chuck Williamssaid:

I was told by an Automic consultant, that if that was not done, all versions would be included in the transport case.

 

It's just that the version history do not get transported from a to b. Versions and their history get created on the traget systemen. The version history looks only the same on both sides if you transport each single version. 

  Source                Target
1. Va
2. Vb    > transport >  1. Vb
3. Vc                   2. Vb.1 (eg. some minor change)
4. Vd    > transport >  3. Vd

Chuck, in a post, you wrote: "... copies all the listed objects in the manifest to the transport case..". How to you exactly put objects in the transport case? I would love to be able to do that within a code, but so far, I have just succeeded to mess up the database...

JF,

Here's a code fragment that puts an object in the transport case programmatically:

IFolder uc4Folder = tree.getFolder(folder.getName());

FolderList folderList = new FolderList(uc4Folder);

uc4Connection.sendRequestAndWait(folderList);

for (Export export : folder.getExport()) {

FolderListItem folderListItem = folderList.findByName(export.getName());

if (folderListItem != null) {

                                                  // InsertVersionTag.insertVersionTag(uc4Connection,

                                                  // folderListItem, versionTag);

TransportObject transport = new TransportObject(folderListItem);

uc4Connection.sendRequestAndWait(transport);

} else {

System.out.println("Object " + folder.getName() + "/" + export.getName()

                                                            + " not found. Skipping...");

}

}

TheTransportFromFolderfeature of the “UC4 Consulting Tools” does something similar, selecting objects for transport based on their folder location.

Jean-Francois Anctil said:

Is it possible to do it with Automic scripting?

No. I have found no Automic scripting commands that are awareat all of object folder locations.