Passing return code from previous step as argument to the next step

[MarcHoogerwerf]

Hi,

Is it possible to pass the return code from one step as the argument to a next step?

If have a step where the user selects one of three values in a question step. I would like to pass that answer into a JTXExecuteSQL step as part of the SQL to update a field in an extended property table.

so if I have an extended property table EXT_PROP I'd like to do something like:

update EXT_PROP
set Status = [return code from previous step]
where job_id = [JOB:ID]

If that's not possible, is there another way to accomplish this? As a work-around I configured as many JTXExecuteSQL steps as I have return codes and used conditional returncodes on the connectors to execute the correct update statement, but it feels like a clumsy way to implement what I want.

Marc

[Anonymous User]

Hi Marc,

Passing a return code forward to the next step as a token isn't something that is currently supported in Workflow Manager, however we have noted it as a potential future enhancement based on the value described here.

The work around you have configured is one way to resolve your issue. There is another avenue to implement similar functionality which would be to replace the question step with an 'Edit Extended Properties' step. You would need to create a seperate lookup table within your WMX repository with a field for a 'statement/question' and then you would have a field with the potential answers for 'Status'. Then in the Job Type edit the Extended Properties Status value to use a Display Type of Table list. You can follow basic instructions for something similar under 'Define Extended Properties' in the help menu to set it up properly.

The end result is that when the Edit Extended Properties step is run users can select from a pulldown the options that would get populated directly into the Status field.

Hope this helps. If you have any further questions please let us know.

Cheers,
Michael

[MarcHoogerwerf]

Hi Michael,

That's a good solution for the case where the previous step requires some user interaction. I'd also like to see it to work with steps that execute automatically. I know how I can do it with stand alone Python scripts and JTXStep.ExecuteGPTool but it would be great if this principle (of passing on and acting on return codes) could make be incorporated in the WMX Workflow Framework. I filed an enhancement request through Esri NL support (Esri Incident #1144174, your ref: 1045974 (Steven E), maybe you can find the whole conversation with these reference numbers in NIMBUS).

The problem with the stand alone Python script solution is that you can't use take the output from a GPTool variable and create a returncode from the output variable (unless you wrap that GPTool into a stand alone Python script) .

Here's the general idea applied to a GPTool in a JTXCustomStep.ExecuteGPTool step where you can specify the name of the output variable of the GPTool that will hold the returncode.
[ATTACH=CONFIG]24305[/ATTACH]

But it would be great if any step could take the returncode from a previous step as input.

Cheers,

Marc

[Anonymous User]

Hi Marc,

Thanks for the additional details, I'll look for the incident numbers/enhancement request and confirm that it is present in our backlog.

In the meantime please continue with the methodology you have setup, and consider the Edit Extended Properties when the step requires user input as a way of saving some additional time.

Take care,
Michael