Workflow Manager Step Assignement Deprecated - Workaround?

[SachinChand]

We had WMX running with parallel steps in our job workflows (and appropriate user queries to see their respective assigned steps).  We just upgraded to v10.6 (from v10.2) and see that the step assignment has been depreciated.  This has rendered out step assignment queries useless.  We are trying to figure out a new way to go about this.  We cannot use path assignments (which coincide with job "assignment") because we have workflows with parallel steps and this would cause a problem as only one person in the parallel steps would be notified, therefore we see no way to continue to run parallel job workflow steps (please correct me if I'm wrong).  We have decided to generate spin-off jobs to remove the parallel steps.  To that end, what is the difference between the "JTXDesktopSteps.CreateJobAdvanced" step and the "JTXSteps.CreateJob" step?  Moreover, given our situation, any recommendations on the best way to proceed given our situation described above?

[Anonymous User]

Hi Sachin,

The step assignment you'd previously defined still works under the hood as is, we only changed the ability of setting new step assignments and editing existing ones (can only reset) to promote path assignment which results in many fewer configuration issues in a workflow. But anything you had previously would still work unchanged.

I'd be happy to assist you in your issue but I don't know what this sentence means and need additional clairification "workflows with parallel steps and this would cause a problem as only one person in the parallel steps would be notified" When you say notified, what specifically are you referring to? As that sounds like the crux of your issue.

Thanks,

Michael

[SachinChand]

Hi Michael, thank you for the response.  We have a WMX desktop setup with multiple users performing different tasks(steps) in various workflows.  What I meant by notification is that we have a universal query setup where WMX reads the Windows user login ([SYS:CUR_LOGIN]) when it is opened (their user name is also configured in WMX) and sees their "currently assigned steps".  With steps being deprecated, we thought we could change our query to use the "assignment" or "assigned_to" value instead, as it seems to be tied to the new path assignments.  Since we have parallel steps, however, this did not work as only one user can have the job assignment whereas multiple users could have step assignments in a workflow.  The end result being in a workflow with parallel steps, only a single user would see a job in their assignment query where there should actually be two users.  We are currently looking into using the "JTXDesktopSteps.CreateJobAdvanced" method to create child jobs.  Even though these child jobs can be independent, I didn't see a way where job properties could transfer to the spin-off job using the "JTXSteps.CreateJob"  method.  That was the second part of my question in trying to understand the difference between the two.

[Anonymous User]

Hi Sachin,

Yes you can use Create Job Advanced to copy over parameters and you can do everything as child jobs, that's a common way of doing this workflow. If you go to "Custom Steps" in the help it'll describe the options for copying items over.

The only real complication this adds is wrt reporting on all the pieces, but if you don't do any intense reporting then this is fine.

The other option would be to actually make an extended properties table to manage the assignments as a reference in parallel, and write a sql or python script before the steps to set the values in extended properties.

As a longterm path we do intend on supporting seamless parallel workflows, where steps can be assigned in parallel to different users and those users can complete their work independently without having to transfer the job back and forth. It is part of our next generation initiative and so even though this doesn't solve your immediate issue we're happy you have addressed it to us to provide support towards our future path. It was a lot of work to get working properly!

[SachinChand]

Hi Michael, we've got the CreateJobAdvanced working (its working in our test environment, at least) so we should be good.  Even though we do have extended properties, CreateJobAdvanced seems to be the simpler route rather than scripting route .  Thank you for providing feedback on this matter.