nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to Locate Successors in WFModeller

System

Hi all,

Please help me out to find the successor in WF modeller. As I have to use callback method in an external task.

How can I get to know 0,1,2.. etc to implement callback......

Thanks in advance.
Raj

Find more posts tagged with

Comments

moonkhanna

Raj, its in the order you place the links (left to right)(0,1,2..) as far as I found. But to revalidate you can do the callbacks and see which transition leads you to which task..

yuvpurush

You are correct.

I have tested this few times and it works exactly the way you have mentioned.

Does not look very professional. Smiley Happy

Migrateduser

hi

try to debug the WFmodel by changing the path attribute to 'debug' instead of 'prod' in the model element.the instantiate the WFmodel..u will two option button for debug true or false.By deafult it is always false ,select true then proceed further,you will get a expanded job specification file and an original one having green background ,from there find the task and the suceessor link which come first for that will be 0, and so on.

i got the same prob and sort out in this way as this way u can locate successor exactly.

best of luck

Bill Klish

This is very easy to do in the Java CS SDK. I am not sure about coverage for the callbacks in perl when using the modeler. Seems risky to rely on left to right ordering in the model. Changing the layout of the model could impact the functioning of the workflow.

moonkhanna

This is very easy to do in the Java CS SDK. I am not sure about coverage for the callbacks in perl when using the modeler. Seems risky to rely on left to right ordering in the model. Changing the layout of the model could impact the functioning of the workflow.

Changing the layout does not impact the functionality. Yes, of course if you change the order intentionally then it will impact.

"These are the rules of the WFM, it seems"

Adam Stoller

Changing the layout does not impact the functionality. Yes, of course if you change the order intentionally then it will impact.

"These are the rules of the WFM, it seems"

With WFM you appear to be best off using URI Tasks instead of External Tasks - where the URI Task script can use the description of the succesorset to perform the callback rather than the index of the successorset - because what might appear as a simple change to the model can represent a significant change to the ordering (and hence, index) of the successorsets.

Another possible method (kind of a hybrid) is to use the externaltask - but make use of the TeamSite::WFtask->GetPossibleTransitions() method - which will give you an ordered array of the descriptions (labels) of the successorsets such that if you find the correct index for the description, you can use that index for the callback. (note: this method was added in 6.7)

moonkhanna

Hi Adam,

Thanks for sharing this. Not sure, if you tried this but I tried getting some job variables into a WFM External Task using the getVariable() function however it does not seem to get any values for the same. Do you know if the same is at all supported by the wfm?

Best Regards,

Munish Khanna

Bill Klish

Not sure I understand what you are asking. In the modeler client you added some variables, or during runtime you added some variables?

Adam Stoller

Hi Adam,

Thanks for sharing this. Not sure, if you tried this but I tried getting some job variables into a WFM External Task using the getVariable() function however it does not seem to get any values for the same. Do you know if the same is at all supported by the wfm?

Best Regards,

Munish Khanna

Are you sure you created / set the job variable? You can run iwgetwfobj on the jobid to see what job variables there are - and then, if they are there, double-check your code and make sure that you spelled everything correctly (job and task variable names are case-sensitive so "myvar" and "MyVar" are not the same thing)

moonkhanna

Hi Adam,

Thanks for your response. Yes, I validated that Job Variables actually exist and getVariable() is called as described in the WF Manual. I have been able to use these with wfts. It seems, its just the WFM.. Just thought, if it was just me or is it a known with WFM..

Best Regards,

Munish Khanna

Adam Stoller

Hi Adam,

Thanks for your response. Yes, I validated that Job Variables actually exist and getVariable() is called as described in the WF Manual. I have been able to use these with wfts. It seems, its just the WFM.. Just thought, if it was just me or is it a known with WFM..

Best Regards,

Munish Khanna

Well, without seeing all the data for the case-in-point it's a bit difficult to diagnose - but I cannot think of any reason why an externaltask script launched from a workflow created with WFM should behave any differently than an externaltask script launched from a workflow created from a WFT.

The underlying workflow engine is the same in either case - so all such interactions should continue to work as far as I know.

moonkhanna

Hi Adam,

Thanks for your response. I worked arround things already so I do not have the data in hand. But I am going to try some workarrounds to the issue later this month. I will post then.

Best Regards,

Munish Khanna