Tidal Transporter

[jerzyborn]

Any one else using transporter to move between non-prod and prod environments?  Any "best practices" you can offer?

[Marc Clasby]

Yes we use the Transporter to move jobs between masters  DEV-->QAS-->UAT-->PRD at my company.

There is a Transporter best practices that covers most of this like order of componenets (you have to do things in a certain sequence other wise there are conflicts) If I can find I i can send it to you if you want.

1. A couple of keys... have mapping files in a network location that is backed up
   
2. write or copy your transporter logs (client controls locaiton) to the network
   
3. Make sure your TES standards (naming, depth) allow for easy transport
   
   1. job dependecies outside of groups break for example
      
   2. Although mapping files can compensate, Variable names should be the same but have different value for different environments
      
4. Have a standard configuration on the transporter client so all team members are using it the same way
   
5. have a rule so that only one persone is leveraging transporter at any one time
   
6. Execute all other "new" components before jobs/job groups  this is our set order
   
   1. (calendars, resources, classes,Variables, actions, events)
      
   2. Actions have to go before events...for example..
      

Marc

[Ceceil Rufo]

Hi

Just got access to the forum and found this information on Transporter, it is helpful.

Could i ask you how do you use transporter? meaning do you use it manually or do you have automated processes setup to do the moves. What type of controls do you have in place to use transporter, such as do you have a chane control procedure for when someone wants something mifrated to production?

Thanks for any insight you can give.

[Marc Clasby]

We use it manually, however I believe it might be possible to automate. If you go into help there is the abiltiy to run transporter in batch mode... but I wouldn't recommend it.at this stage there is xprtcmd in your transporter directory

We have had success with POWERHSELL+SACMD (shut down queues, set variables, file, etc) but haven't dedicated any time to transporter API.Xprtcmd.exe. The Vendor Transporter Manual.pdf document will have a section on Running in batch mode with

c:\Program Files\TIDAL\Transporter\XportCmd.exe

We will likely take a look at the transporter and  XML import/export functionality in 6X when we are looking to upgrade next year Q2-3 (possibly). It would be nice to store jobs in a code repository and then extract and load to tidal. as a "release".

Marc

[jerzyborn]

In answer to your questions

Ceceil

Yes, we use Transporter manually, but we are working on using the XportCmd.exe to "automate" it further.  We transport from dev to qa to uat to production and have several other sub-environments, like training & config.  We have a  Change Control process in place for production code.

Hopefully, they will put some enhancements into the next version (?) making it a bit more user friendly and more "Windows" like including copy and paste, and working archive functionality.  (Too many to list!)

[Dinesh Sankaranarayanan]

Can someone share the Transporter best practices document that is mentioned above ?

- Dinesh

[westdgubbels]

How can I too get a copy of the Transporter best practices document as mentioned above??

Donna

[Marc Clasby]

There should be a new version for 6X but I can't find anything on Cisco Site

Some of the Best Practices Above are 5.3.1 specific

Many issues are fixed in 6X like multiple concurrent connections

Transporter Best Practices 5/25/2011

• Remember that Transporter uses a client connection license, so don’t leave it connected.
  
• Create a mapping file for each environment that may be shared.
  • If you have two masters (one production and one test), you will have two mapping files, one from test to production and the other from production to test.
    
  • The mapping files reside on the network drive, along with the log files and saved transport selections.
    
• Always prompt for a map update. This is set in the configuration.
  
• Copy jobs to production as disabled if they are new jobs.
  • Manually enable the new jobs after transport to the production environment via the Client.
    
  • Existing jobs should always be copied in the same state that they are in production. If you copy an existing enabled job as disabled, the job will be removed from the existing schedules until you enable the job via the Client.
    
• Save selections for jobs/groups that are constantly being transported.
  • These files should be kept in the same location as the mapping files.
    
• Archive activity logs.
  • Make sure that the activity logs on the shared network drive are backed up. You will need to decide what your retention policy is and take action to implement it. Transporter does not maintain the logs after they are created.
    
• Disable auto select dependencies for jobs with complex or many dependencies to enhance performance.
  • All the auto select options should be configured in the off position. Turn them on only when needed. Remember to turn them off again after use.
    
• To replace an existing job in the production environment, use the “includes duplicates” option in Transporter. This can be done in the configuration or by right clicking in the transport console when you have Jobs/Groups selected.
  
• Avoid changing the effective date when transporting jobs unless you want all the jobs being transported to have a future start date.
  • If a job is required to be scheduled in the future, use the TIDAL Client to schedule the job after the transport
    
• Commit / rollback option in the configuration should only be used when no other users are creating jobs with the Client.
  • This option may lock other users that are using the Transporter or the Client.
    
• Transport your scheduling types based on the following sequence:
  • Calendar, Variables, Resources, and Job classes should be transported before all other items.
    
  • Actions must be transported before Events, with the exception of Job Actions. They can only be transported after the Job that they are putting into the schedule has been transported.
    
  • Jobs/Job Groups must be transported after all the other types have been transported.
    
• Set restriction security on non-super users in the Client via the General Category in the Security Policy – “Move Jobs to Production” or “Move Own Jobs to Production”.
  
• Transport Archive should be enabled in the configuration.
  • This will enable you to back out a change if needed. This is done by using the Client to remove the newly transported job, and renaming the Archived job name and changing the parent group to the correct location in the Job Definitions.
    

[Dinesh Sankaranarayanan]

Mark, thank you so much !

[kishoreit410]

Hi All,

Can any one say me how long will it take to transfer a single SAP job from one environment to other environment, For me its taking more than 1 hour. Is it the correct time or am I missing anything else., I checked in log file as well everything seems to be ok without any issue but even though it make more time.

Please advice your thought and timings on it.

Regards

Kishore J