Post

10 followers
0
Avatar

importing jobs between dev,test,prod environments

To move a job set from dev to test domains, I run these powershell commands:

import-module jams

$job = get-childitem jams::localhost\<folder>\* -objecttype job

export-jamsxml  D:\work\jams\jobs.xml $job

## copy jobs.xml to the host with JAMS test server

set-location JAMS::localhost\<folder>

import-jamsxml d:\xinstall\jobs.xml

 

My problems is when a job has a dependency on a job that has not been defined, for example:

<Job name="job_send_cheques_for_payment">

 <Dependencies>
      <Dependency xsi:type="DependencyJob" job="job_create_cheques">

job_send_cheques_for_payment  will not import, till job_create_cheques has been defined.

Has anyone got some hand code to work around this? (dicking around with the jobs.xml is too time consuming)

 

Alex Taylor

Official comment

Avatar

Hello Alex, 

In order to import the job, the dependency job must exist before the job with the dependency is imported. This requirement is to ensure that no broken references are created. With that said, your script will have to go out and find the dependency job, export it to XML, then export the job that depends on it. The import process must then start in the reverse order. Import the dependency jobs, then import the jobs with that dependency. This would also be the same for any other references that would exist, such as batch queues, JAMS users, and setup jobs, for example.

Gennaro Piccolo

Please sign in to leave a comment.

4 comments

1
Avatar

Using the JAMShr libraries in a C# project I have had success creating a job stub.  I create all folder, then variables, then jobs creating a job without any of the elements parameters or source if it does not exist.  I then do a second pass to add the elements parameters and source to my jobs without worrying about dependencies.  There is no reason a similar tactic could not be taken using PowerShell.  

Jared Stroebele 1 vote
0
Avatar

We did what Jared said below and removed all dependencies from the xml then imported that one first then the original xml's.

Logan Probst 0 votes
2
Avatar

I realize this is an old topic, but for the benefit of others... We did something similar using a custom powershell module we wrote. We parse the XMl of any object that can have dependencies (or pre-check jobs or notification jobs), then do a topological sort of the jobs to deploy them in the correct order. We deploy from the deepest folder to the shallowest, such that we can have cross-folder dependencies, but only if they are in a subfolder. 

We also have environment-specific configurations in our jobs, so we source control our schedule using tokens as placeholders for those configurable items. So our deployment automation looks something like this:
1. Pull schedule from Github
2. Run token-replacement script for the environment being deployed to
3. Call our custom publish-JAMSFolder function to perform that actual deployment

Let me know if anyone is interested in more detail / sample code

Ken Stuber 2 votes