1. Michael A. Lowry Enterprise Batch Management Swiss Re
UC4 Toolkit A system employing the transport case mechanism to promote batches between separate, independent staging environments
Michael A. Lowry Enterprise Batch Management Swiss Re

2. Integrating the Automation Engine with SCM and ITSM
Abstract:
Large enterprises typically segregate IT systems into multiple staging environments, so that changes can be thoroughly tested prior to going into production. Swiss Re developed a custom solution to facilitate promotion of batches of scheduling objects from one Automation Engine to another — e.g., from the Development environment to Production. Based on a combination of scripting, SQL, and Java, this homegrown solution integrates the Automation Engine with the company’s Source Code Management and IT Service Management systems.
Some Automation Engine customers opt to segregate a single Automation Engine into multiple staging environments by client number. Swiss Re opted to set up completely separate infrastructure for its different Automation Engine staging environments instead — a separate DB, machine, OS, and Automation Engine installation for each staging environment. This necessitated the development of a solution for promoting batches of scheduling objects between these separate systems.
With help from Automic consultants, Swiss Re developed a collection of tools  — the “UC4 Toolkit” — for managing the controlled promotion of batches of Automation Engine scheduling objects from one staging environment to another. These tools, based on the transport case mechanism, allow users to unload batches of objects from the Development Automation Engine environment, and store them in an external source code management system. From there, users can deploy batches to the other Automation Engine environment, Test and Production. The UC4 Toolkit is also integrated into Swiss Re’s IT Service Management platform, and all deployments to Production require an approved change request.
The UC4 Toolkit includes several solutions designed to address software limitations and to provide additional functions requested by users:
Exports are queued, to prevent more than one user from using the transport case at the same time.
All objects under a specified folder are automatically added to the transport case.
Environment-specific changes to objects are made automatically, based on user-specified change rules and environment profiles.
Validation of object naming convention and object type-specific standards.
Pre-deployment check for running tasks, and post-deployment cleanup of old objects, with correction/cleanup of OFS table entries and deletion of empty folders.
For all z/OS jobs, deployment-time validation of job type, job class, message class, JCL library and JCL member.
Automatic start/restart of modified JSCH objects following deployment.
Dynamic creation and import of customized DOCU object with deployment details (date/time, user, ID, log URL, etc.)
These solutions were implemented using a combination of UC4/shell/Perl scripting, SQL, and Java

3. Segregated staging environments
UC4 Automation Engine
Segregated staging environments
It is standard practice in large enterprises to set up multiple separate systems for developing, testing, and running business applications and services.
Swiss Re follows this practice. Our workload automation systems are therefore segregated into three staging environments:
DEV : Development
TEST : Testing
PROD : Production
PROD
TEST
DEV

4. Constraint: user rights
UC4 Automation Engine
PROD Read only By the time the batch arrives in the PROD environment, it should be bug-free, and configured to start automatically.
PROD
TEST Read/execute The TEST environment should resemble as closely as possible the PROD environment. No changes to objects are allowed, but users may execute objects. If a change is required, the user must make the change in DEV and deploy again to TEST.
TEST
DEV
DEV Read/write/execute Users develop and debug their batches in the DEV environment.

5. Challenges PROD TEST DEV UC4 Automation Engine
Find a mechanism for moving (deploying) batches from DEV to TEST and PROD.
Allow the the user to specifiy the changes that should be made to the batch when moving it between staging environments.
Allow the user to configure some objects to start automatically following deployment.
Validate/enforce adherence to standards and conventions.
Integrate with IT Service Management, so that all PROD deployments require an approved RfD.
PROD
TEST
DEV

6. Segregated staging environments
UC4 Automation Engines
Some attributes of scheduling objects need to be changed when moving objects from DEV to the other environments. For example:
Agent name
File names or directory paths
Login name
Object variable values
We use the Transport Case mechanism to move objects between staging environments, and use the UC4 DB Change utility ucybchng to make the necessary changes.
PROD
ucybchng & ucybdbld
ITE
ucybchng & ucybdbld
DEV
Transport Case
ucybdbun
Transport case unload file containing workflows, jobs, events, etc.

7. Deploy Transfer UC4 Toolkit overview Enterprise Scheduler (TWS/UC4)
UC4 Toolkit is the set of tools that Swiss Re developed to facilitate promotion of workload batches from DEV to TEST and PROD. UC4 Toolkit is integrated with other Swiss Re systems, including IT Service Management and SCM.
Deploy
Enterprise Scheduler (TWS/UC4)
Enterprise Scheduler (TWS/UC4)
Source Code Management Platform
UC4 Toolkit
Automation Engines
DEV, TEST, PROD
Transfer

8. Source Code Repository (SVN)
UC4 Toolkit overview, continued
UC4 Automation Engine
RfD
Deploy
SCM Platform
PROD DU
TEST
Source Code Repository (SVN)
DEV
UC4-specific page DU
Legend
DU deployment unit
Transfer

9. Source Code Repository (SVN)
SCM Transfer
Select folder in UC4 DEV & add objects to transp. case.
Read generic deployment rules & profiles.
Unload transport case.
ZIP files together.
Check-in to SVN & tag.
Import to SCM Platform
SCM Platform
6. Import to SCM Platform
Source Code Repository (SVN)
1. Select folder in UC4 DEV
UC4 DEV
Java APIs
2. Read rules & profiles
generic rules & profiles
rules
5. Check-in to SVN & tag
3. Unload DU TC
ucybdbun
ZIP
Zipped Deployment Unit
Transport Case
4. ZIP files together

10. SCM Deployment overview
Automation Engine
SCM Platform DU
PROD
Zipped deployment unit
1. Send to deployment server
TEST
Deployment server
7. Start JSCH objects DU
Zipped deployment unit
ucybdbld
2. Unzip files
6. Load transport case
DEV
generic change rules
Generic deployment rules
Target profile
DEV profile
Target profile
TEST profile
profiles
rules
Other profiles TC
Transport Case
Send zipped deployment unit to deployment server.
Unzip files.
Build change rules for target system, based on generic change rules and profile for target system.
Apply changes to transport case.
Validate UC4 objects in transport case.
Load transport case
Start/reload/restart JSCH objects
The procedure is similar for deployments to DEV.
3. Build change rules for target system
DEV → TEST change rules
Target change rules
TEST Transport Case
Target transp. case
For deployments to PROD, the deployment will be executed only once an associated RfD in SNOW has been approved, and when the DT (deployment task) has started in SNOW.
ucybchng
4. Change transport case
5. Validate transport case

11. SCM Transfer
Detailed description of steps of the SCM transfer process for UC4

12. SCM Transfer in detail User inputs: Data inputs: Actions: Prefix
Deployment unit
Source staging environment
Requesting user (&$USER#)
Data inputs:
Deployment rules
Deployment profiles
UC4 objects
Actions:
Read & validate inputs/rules/profiles
Validate objects:
naming convention
notification objects (JSCH & JOBP)
RunAtDeployment setting for schedules
operator instructions (executable objects)
z/OS job attributes
Select objects & unload transport case
ZIP up all files
Add to SVN, tag, and import to SCM Platform
Currently, this feature is implemented via the UC4.SCM.START_TRANSFER workflow in UC4 DEV and the UC4.SCM.TRANSFER workflow in UC4 PROD.
Transport Case

13. UC4 Transfer steps
1. Read defined environments, profiles, and change rules
GetEnvConfigDetails.java
2. Validate that selected folder exists in source system
TransferPreValidations.java
3. Look up application ID for the user-supplied prefix (DB2)
Bash script, db2 client
4. Build ucybchng change rules file. Validate deployment rules
Bash script, ucybchng
5. List objects & folders. Validate adherence to naming convention.
PrepareUnload.java
6. Mark objects for transport in UC4 DB.
TransportFromFolder.java
7. Unload objects marked for transport to text file.
ucybdbun
PrepareUnload.java and TransportFromFolder.java come originally from the ConsultingTools package used by consultants working with Automic Professional Services.
8. ZIP up all files
Bash script, zip
9. Prepare SCM import (create manifest & metadata XML files)
Bash script
10. Run SCM import client (via ebm_uc4_schedule.pl script)
Perl script

14. UC4 Transfer step 1: Read environment profiles & change rules
Read deployment profiles, VARA objects whose names match the pattern PFX.DEPLOYMENT.PROFILE.X where PFX is the project prefix and X is the name of the environment profile.
Read PFX.DEPLOYMENT.RULES and build the token change file that will replace DEV-specific values with placholders or tokens in the unloaded transport case.
Run ucybchng using a dummy transport case and the token change rule file, just to validate the rules (for syntax errors).

15. UC4 Transfer step 2: Validate objects
We greatly expanded the PrepareUnload.java program originally developed by Automic consultants, adding more validation steps:
Validate adherence to Swiss Re naming convention. (Each object must begin with the three- character prefix associated with the department/group/team/project responsible for the batch.)
Validate that a notification object has been specified for all schedules and workflows.
Validate that the RunAtDeployment XML DOCU attribute has a valid value for all schedules.
Validate z/OS jobs: validate job type, job class, message class, etc.
For executable objects (except schedules), check that operator instructions have been specified, either in the Runbook XML tab of the object, or in an external DB2 database.
Originally these checks were done using Java API calls to the UC4 DEV system.
We later replaced this program with a program that performs the validation checks on an exported XML file containing all the objects. This way requires fewer individual API calls.*
* We also went with an XML-based approach for object validation to begin to familiarize ourselves with the XML schema, in preparation for a planned migration away from using the transport case.

16. UC4 Transfer step 3: Select objects & unload transport case
We use the TransportFromFolder.java program originally provided by Automic consultants, to add to the transport case all of the objects under the specified folder:
Clear the transport case.
Generate a list of all objects under the specified folder, excluding links, folders, and system objects.
Add the objects to the transport case.
The DB Unload program ucybdbun is then used to unload the transport case to a text file.
ucybdbun
transport case text file

17. UC4 Transfer step 4: Build changes rules and verify them
The AE DB Change program ucybchng is used to validate that the user- specified rules are syntactically valid.
If ucybchng returns a non-zero exit code, the user is alerted that he/she has specified invalid rules.
User-specified change rules
User change rules
Output transport case (discarded)
ucybchng
Dummy transport case

18. UC4 Transfer step 5: Import to SCM Platform
Prepare manifest and metadata XML files.
ZIP transport case, rules & profiles.
Check in, commit, and tag in SVN.
Import into SCM Platform.
SCM Platform
Zipped transport case, rules & profiles
SVN

19. Deployment rules & profiles

20. Deployment rules & profiles
Deployment rules indicate what objects attributes should be altered when preparing a UC4 batch for deployment to a given environment, (DEV, ITE, or PROD).
Deployment profiles list the specific strings for each environment.
When the transport case is is prepared for the target environment, to the target environment.
UC4 batch developers create and maintain their own deployment rules and profiles.
Deployment rules & profiles are stored in static VARA objects in UC4_DEV

21. Deployment rules
Deployment rules are used to replace staging environment-specific strings with the correct values when deploying UC4 batches to different staging environments. Deployment rules take one of two forms:
REPLACE      Object Type, Name, Attribute, Key
REPLACE_PART Object Type, Name, Attribute, Key
Object Type is the short name of the UC4 object type, e.g., JSCH, SCRI, JOBP, JOBS, JOBF, EVNT, DOCU
Name is the name of the UC4 object to be changed, e.g., ABC.DEV.MYJOB1
Attribute is the UC4 object attribute that should be changed, e.g., OBJECT_NAME, HOST, LOGIN
Key refers to the keys of the key-value pairs in the deployment profiles, e.g., hostname, script_dir, etc.

22. Deployment rule example
ABC.DEPLOYMENT.PROFILE.RULES
Key
Value 1
hostname
REPLACE JOBS, ABC.*, HOST, hostname
script_dir
REPLACE JOBS, ABC.*, SCRIPT, script_dir
login
REPLACE JOBS, ABC.*, LOGIN, login
env_name
ABC.DEV.
win_dir
C:\scripts
Note that deployment rules are generic. That is, they do not contain specific old values and new values, but rather keys like ‘hostname’ and ‘login’. These keys are used to look up the old values and new values from the profiles associated with the source and target system.

23. Deployment profiles
Deployment profiles are key-value pairs that define details of UC4 objects that are specific to each staging environment, e.g., host name, path name, user name, file name.
Deployment profiles are stored in static VARA objects in each project’s ADMIN folder in UC4_DEV. They are named according to the convention PFX.DEPLOYMENT.PROFILE.ENV where PFX is the project prefix and ENV is the target staging environment, typically DEV, ITE or PROD.
For example, if the project prefix is ABC, a typical set of deployment profiles will be the following three static VARA objects in /APPS/ABC/ADMIN: ABC.DEPLOYMENT.PROFILE.DEV ABC.DEPLOYMENT.PROFILE.ITE ABC.DEPLOYMENT.PROFILE.PROD

24. SCM Deployment
Detailed description of steps of the SCM deployment process for UC4

25. EBM Toolkit UC4 features: Deploy
Inputs:
Prefix
Deployment unit from SCM
Target staging environment
Post-deployment cleanup path (optional)
Actions:
Validate transport case & inputs
Generate object cleanup list
Check for running tasks & quit schedules
z/OS jobs only
Perform job name mapping
Validate JCL existence
Check/correct JCL library
Load transport case into target UC4 DB
Run post-deployment cleanup in target folder
Import JOBPs into XA2
Start JSCHs in target UC4 system
Currently, this feature is implemented via the deploy.sh script on the XMM (UC4/TWS deployment) Linux servers.

26. UC4 Deployment steps
1. Move ZIP file to temp. dir., extract it, and read XML manifest file.
deploy.sh
2. Build profile change rules & change transport case for target system.
deploy.sh
3. Parse transport case, generating lists of objects, folders, etc.
deploy.sh
4. Generate object cleanup list. Check for running tasks & quit schedules.
CheckForRunningTasks.java
5. Validate JCL & perform job name mapping. (z/OS jobs only)
deploy.sh
6. Validate object names & locations. Validate scripting content
deploy.sh
7. Load transport case into DB of target UC4 system.
ucybdbld
8. Remove objects from target folder that were not in the transport case.
PostDeploymentCleanup.java
9. Import workflows (JOBP objects) into XA2.
xa2jstsynchronizer.java
10. Start/restart job schedules (JSCH objects) in target UC4 system.
StartSchedules.java

27. UC4 Deploy step 2: Build profile change rules file
The profile change rules are built based on the user-specified generic deployment rules, the source profile, and the target profile.
generic change rules
Generic deployment rules
DEV→TEST change rules
Profile change rules
Source profile
DEV profile
Target profile
TEST profile

28. UC4 Deploy step 2: Build & validate profile change file
Construct the profile change file based on the user-specified generic change rules, and the source & target deployment profiles.
ABC.DEPLOYMENT.PROFILE.RULES
ABC.DEPLOYMENT.PROFILE.DEV
ABC.DEPLOYMENT.PROFILE.TEST
Key
Value 1
hostname
REPLACE JOBS, ABC.*, HOST, hostname
script_dir
REPLACE _PART JOBS, ABC.*, SCRIPT, script_dir
login
REPLACE JOBS, ABC.*, LOGIN, login
env_name
REPLACE_PART *, ABC.*, OBJECT_NAME, env_name
win_dir
REPLACE_PART JOBS, ABC.*, SCRIPT, win_dir
MYHOST1
/opt/scripts_dev
ABC.DEV.LOGIN
ABC.DEV.
C:\scripts_dev
MYHOST2
/opt/scripts_test
ABC.TEST.LOGIN
ABC.TEST.
C:\scripts_test
Profile change file
REPLACE JOBS, ABC.*, HOST, "MYHOST1", "MYHOST2" REPLACE_PART JOBS, ABC.*, SCRIPT, "/opt/scripts_dev", "/opt/scripts_test" REPLACE JOBS, ABC.*, LOGIN, "ABC.DEVLOGIN", "ABC.TEST.LOGIN" REPLACE_PART *, ABC.*, OBJECT_NAME, "ABC.DEV.", "ABC.TEST" REPLACE_PART JOBS, ABC.*, SCRIPT, "C:\scripts_dev", "C:\scripts_test"

29. UC4 Deploy step 2: Change transport case
The AE DB Change program ucybchng is used to change attributes in the transport from values specific to the source system to values specific to the target system.
Target profile transport case
ucybchng
Source profile transport case
DEV→TEST change rules
Profile change rules

30. UC4 Deploy step 2: Generate object cleanup list
List all of the objects in the target folder in the UC4 system.
Remove from this list any objects that are also in the transport case.
The list that remains is the object cleanup list. These objects will be removed at the end of the deployment.

31. UC4 Deploy step 4: Check for running tasks & quit schedules
For all of the objects in the object cleanup list, check to see if there are any running tasks associated with these objects in the target UC4 system.
If the only running tasks found are JSCH tasks, then quit them, provided they do not have running child tasks.
If any other active tasks are found associated with objects that would need to be cleaned up (removed) later, then abort the deployment before any objects have been loaded, and alert the user by .

32. UC4 Deploy step 5: Special handling for z/OS jobs
For jobs with JCL stored on the mainframe:
Validate the format of the z/OS file name field: JCLLIB(MEMBER)
Perform job name mapping, replacing z/OS JCL member names related to the source system with the corresponding names for the target system.
Validate that the correct JCL library has been specified for the target UC4 system, and change it to the correct JCL library if necessary (using ucybchng).
Verify that the JCL members belong to the same project as the UC4 jobs that are executing them.
Verify that the JCL members have been promoted to the target z/OS system (DB2 query).
For jobs with JCL stored in the Automation Engine:
Perform job name mapping, changing JCL statements to update object names for the target system.
Validate JCL statements.
user with a list of any problems found.
Stage
UC4 System
Library
Sysplex
EXP
UC4_EXP
SYS1.EXP.JCLLIB
Maint
DEV
UC4_DEV
SYS1.DEV.JCLLIB
Dev
ITE
UC4_ITE
SYS1.ITE.JCLLIB
PROD
UC4_PROD
SYS1.PROD.JCLLIB
Prod

33. UC4 Deploy step 7: Load transport case
Run ucybdbld to load the transport case into the target system, with the following options:
–EREPLACE: Replace existing objects with the same names.
–FOT: Preserve folder locations in the transport case, regardless of the locations of any replaced objects in the target system.
ucybdbld
transport case text file

34. UC4 Deploy step 8: Run post-deployment cleanup in target folder
Double-check to ensure that no tasks are running associated with the objects in the object cleanup list.
If any running JSCH tasks are found, and have no running child tasks, these tasks are quit.
If any other running tasks are found, an is sent to the user to notify him/her.
If any active but not running tasks are found, these tasks are deactivated.
Remove from the target UC4 system all of the objects in the object cleanup list.
Remove from the target UC4 system all empty subfolders beneath the target folder of the deployment.
1. ucybdbld V12.1 apparently fixes this problem.

35. UC4 Deploy step 9: Import workflows into XA2
Swiss Re developed a system for scheduler-independent dynamic submission of workload. This system is called XA2. It is capable of submitting workflows to UC4. (It is also capable of submitting job streams to TWS for z/OS.)
XA2 must have an up-to-date template* of each UC4 workflow it submits, so that it knows, for example, the number and order of the tasks within the workflow.
For any UC4 deployment that includes 1 or more workflows, the deployment script contacts the XA2 server and triggers an import/update of the templates for these workflows.
* These are XA2 templates, and should not be confused with Automation Engine object templates.

36. UC4 Deploy step 10: Start/restart schedules
We allow users to specifiy, via a custom XML attribute in all schedules (JSCH objects), how these objects and their tasks should be handled at deployment time.
For any UC4 deployment that includes 1 or more schedules, the deployment script reads the value of the XML attribute RunAtDeployment (via API call).
It then performs additional start/restart actions on the JSCH, based on the user- specified setting.

37. Limitations of UC4 Toolkit
Transport case not backward-compatible.
Only one transport case unload can be running at a time.
ucybchng cannot change all object attributes.
Transport case file format is not documented.

38. 1. Transport case not backward-compatible.
It is not possible to load transport case files unloaded from a newer version Automation Engine into an older version Automation Engine.

39. Staged installation of service packs
Automation Engines
We use the UC4 staging environments to test Automation Engine service packs in a staged manner:
Install the new SP in EXP. Validate basic product functions.
Install the SP in DEV, and allow batch developers to validate the service pack from the point of view of using the UC4 GUI, designing workflows, etc.
Install the SP in ITE, and validate that the transport of batches from DEV to ITE works correctly.
Finally, install the SP in PROD.
PROD
V11
4. Install in PROD
ITE
V11
3. Install in ITE
DEV
V11
2. Install in DEV
EXP
V11
1. Install in EXP
Typically, we allow 2-4 weeks between steps.

40. Transport case not backward compatible
Automation Engines
Our traditional approach for installing service packs will not work for version upgrades (e.g., from V11 to V12), because the transport case file format is not backward-compatible between versions. In other words, during the period when DEV has been upgraded to V12, but TEST and PROD are still running V11, it will not be possible to promote any batches from DEV to TEST or PROD. It will also be impossible to validate the transport infrastructure components. It is not feasible to simply upgrade all staging environments at the same time, because we must have an opportunity to test all stages of the process thoroughly, including testing the UC4 Toolkit itself — that is, batch development, promotion, testing, and execution.
PROD
V11
ITE
V11
DEV
V12
V12 Transport Case

41. Future: Set up separate infrastructure test systems
Automation Engines 1
Test in infrastructure testing systems 2
Install in customer systems
Once a new version has been validated in the infrastructure validation systems, then we can confidently upgrade all of the customer production systems at the same time. This approach will require a considerable amount of additional effort, but it will allow us to prudently and thoroughly test new infrastructure components without interrupting our customers’ work.
PROD
Infrastructure testing Automation Engines
Customer Automation Engines
ITE
DEV
We can use the same approach for testing service packs, and for future version upgrades.
INF-DEV
INF-ITE
INF-PROD
EXP

42. Separate infrastructure test systems
Having a separate set of infrastructure testing systems would allow us to test not just one system, but the complete set of inter-dependent systems and the tools that connect them.
Infrastructure Testing Automation Engines
UC4 Toolkit
Have a separate set of systems for infrastructure testing would allow us to avoid interoperability problems between systems of different versions. Importantly, it would also allow us to test the whole batch promotion process (UC4 Toolkit). It would however require a significant amount of additional infrastructure and labor.
INF-PROD
V12 
change & load
INF-ITE
V12 
change & load
We can use the same approach for testing service packs, and for future version upgrades.
INF-DEV
V12
unload
V12 Transport Case

43. Separate infrastructure test systems
To simplify things, we can use a single Automation Engine for all infrastructure testing, and create separate clients to represent DEV, ITE, and PROD.
Infrastructure Testing Automation Engine (EXP)
Customer Automation Engines
UC4 Toolkit
“PROD” (EXP 0003)
V12
PROD 
change & load
“ITE” (EXP 0002)
V12
ITE 
change & load
We can use the same approach for testing service packs, and for future version upgrades.
“DEV” (EXP 0001)
V12
DEV
unload
V12 Transport Case

44. 2. Only one transport case unload can be running at a time.
The inability to perform simultaneous unloads represents a bottleneck in the batch promotion process, and introduces delays for users.

45. Bottleneck: only one transport/unload allowed at a time
Users expect to be able to trigger SCM transfers immediately, without waiting for other users’ transfers to complete.
We use a SYNC object to queue transfers, but this is frustrating for users, who must sometimes wait minutes.
User 4
Transport Case 4
User 3
Transport Case 3
User 2
Transport Case 2
DEV
ucybdbun
User 1
Transport Case 1

46. 3. DB change program cannot change all object attributes
Some attributes of Automation Engine scheduling objects cannot be changed using the DB Change program ucybchng.

47. DB Change program ucybchng can change only some object attributes
The DB change program ucybchng is the only safe & supported way to change objects in a transport case unload file. Unfortunately, the program is able to change only some attributes of objects. Automic has recognized this, and has recently added support for changing some additional attributes:
Uses (OBJECT_USE) of SYNC and PRPT objects.
Task alias within workflow (TASK_NAME)
ForEach workflow data source (FE_SRC_NAME)
RA job attributes in workflow tasks (JPCVALUE:RA_attribute_name)
Notification/alarm object specification (XML attribute in italics):
JOBP: ExtExecute
All executable objects: WhenExecute
SCRI: MrtExecuteObj
JSCH: RExecute

48. Some object attributes cannot be changed by ucybchng
However, there are still many object attributes that cannot be changed using ucybchng. Examples include:
Properties of individual tasks within schedules
Static variable table (VARA) keys and values
Task pre- and post-conditions
Prompt set variables (default values)
Automic is quick to add new features to the Automation Engine, but the company is less quick at providing full support for changing the associated object attributes via the AE DB Change program.
Because of this, if the batch promotion system relies on ucybchng, AE system administrators must consider carefully whether to permit the use of new AE features. Otherwise, objects will be created in the AE whose characteristics cannot be changed using the batch promotion system.

49. 4. Transport case file format is opaque & undocumented
There is no publicly available documentation describing the structure of the transport case file. The files are not human-readable.

50. Transport case file format
The transport case file format is not publicly documented, but I was able to partly reverse-engineer the file format.
I also developed several transport case parsing scripts that we now rely on to read details of objects, and to perform validations on objects.

51. Other limitations
We would like to have mechanism for highlighting changes between different versions of the same objects, so that during deployment the user has an opportunity to see both versions side-by-side, with differences highlighted. Because the transport case unload file is not human-readable, there is probably no straightforward way to deliver this capability.
We would like to provide users with the ability to define their own custom object validation rules. E.g.
“All of my objects should have Generate at runtime enabled”
“All of my z/OS jobs should use message class 6”
Reverse engineering may be a viable approach in some situations, but it may not be reliable in the long term because the DB structure upon which the transport case file format is based is likely to change with each release.

52. In development: XML-based batch transfer system
To work around the limitations of the Automation Engine transport case mechanism, Swiss Re is developing a replacement batch transfer system, based on the Automation Engine XML file format for object exports.

53. XML-based batch transfer, change & deployment system
To work around the limitations of the transport case mechanism, Swiss Re has decided to develop a new tool that uses the XML file format instead.
Multiple XML exports and imports can be run simultaneously.
The XML file format for Automation Engine objects is fully documented. (Starting with v12, Automic no longer publishes documentation of the XML file format.)
For the first phase of this project, we developed a tool to perform object validations using an exported XML file, instead of using Java API calls to the Automation Engine.
We are currently developing a program to apply changes to these XML files.
There is no XML-based equivalent to the DB Change program ucybchng.
However, since the file format is reasonably human-readable, it should be relatively straightforward to design a system for changing these XML files. Off-the- shelf tools and libraries make this sort of thing easy.

54. Advantages of an XML-based approach
Multiple XML exports and imports can be run simultaneously.
The XML file format is fully documented. (An older version is documented.)
XML files are more easily readable and comprehensible to humans.
All object attributes can be validated/compared/changed.
There are many off-the-shelf tools available for working with XML files.

55. Disadvantages of an XML-based approach
Automic still recommends using the transport case for mass exports/imports, in part because the DB Unload and DB Load programs communicate directly with the database, and do not put a load on the Automation Engine processes.
Performing many XML exports & imports may put a significant load on the Automation Engine.
Automic does not provide a change program for XML files, and does not support importing files that have been modified.
There is a file size limit (30 MB) for XML exports/imports.