I am nesting a WMX job within another job using the CreateJobAdvanced custom step so that I can create the job version using the original job version as the parent. I would also like to pass on some properties of the parent job to the child such as job name or job description. Currently I am not too concerned with copying extend properties but rather just the basic job properties. I have found some old questions regarding this but nothing recent.
Thanks in advance for your help.
You could use Clone Job to create the child job with parent's job properties copied. The job properties that you can copy include job description, data workspace as well as selected parent version. It's not recommended to copy job name since it is unique. Also clone job doesn't support copying extended property values from the parent job.
If you would like to share more details about your workflow, I would like to provide more opinions and hopefully can address your concerns.
Thanks Meggie for the reply.
I will check that out to see if that will work.
To elaborate on my process. I am trying to set up a workflow that will handle the addition of new roads into our system and other similar tasks. So the process I envision is to create an LRS job to add the route into the network using versioning. Then before that version is posted an event editor will add the events to the route. But I want to keep the events in a version off of the LRS edit version in case something goes wrong and the event version needs recreated. Once everything is QC'ed then it all can be posted to the default and all required data will show up in default at the same time. We already have a workflow to accommodate event edits and I was trying to nest it within the other one to accomplish this but I wanted to pass a description from the LRS job to the event job.
For instance, we may have received paperwork to add route 1 so a new job is created. An LRS editor will add route 1 in a new version. Once that is done I want to create the event edit job next that will describe what route events apply in a child version off the LRS version. Currently we describe a job using the description field only and use the name just to show if a job is an LRS edit or an Event edit. I want to try to show what is going on and where in the job list which can be confusing.
I hope this makes sense.
Does your event edits job share the same workflow as the LRS job? If it's a different workflow, clone will not work. Clone can only create child job with same job type as parent. Will it be do-able if you can put the information in the extended property of parent job and that can be copied over to the child job via running Create Job Advanced step?
More details on how to configure "Create Job advanced" step can be found:
They are two different workflows so clone is out.
I could put the information in an extended table, we just had not used that functionality so far. I would then, of course, need to add that to the workflow. So far the description has been enough and has served us well. I have already set up a test workflow that uses the Create job advanced step and saw that extended properties could be copied but first thought I would pose the question to avoid the addition of the table and setup of extended properties. I will explore this more and may use the extended properties and take that opportunity to add other properties as well.
Thanks for your help.
This is a bit off topic but what is the difference between the "JTXDesktopSteps.CreateJobAdvanced" step and the "JTXSteps.CreateJob" step?
We had WMX running with parallel steps in our job workflows (and appropriate user queries to see their assigned steps). We just upgraded to v10.6 (from v10.2) and see that the step assignment has been depreciated. Now our user step queries are useless (in job workflows with parallel steps) and we see no way to continue to run parallel job workflow steps (please correct me if I'm wrong). Therefore, we have decided to generate spin-off jobs to remove the parallel steps. My original question is to that end, however, I'm also curious how users migrated from the step assignments to path assignments when there are parallel steps.