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; } } }

CSSDK - invoke workflow(grouptask)

kshah

I am writing a Java program to invoke our Teamsite(version 7.2.1.0.0) workflow through CSSDK api. I have used the debug option in workflow screen to copy job spec xml file that I use in my CSSDK workflow call..
...
CSWorkflow workflow = wfEngine.createWorkflow(xml);
...
This works fine and i am able to create workflow job through the api.

Now we need to update one of the user task to a grouptask setting [html] [/html]element to a set of Teamsite users who can "take ownership" of the workflow job and finish the workflow tasks. The workflow job is created but I don't see the "take" link to take ownership of the job. I figured this was as it was waiting on input on other cgitask's which were earlier than the grouptask. I have tried to convert the grouptask as the first task (start="t"); but it looks like thats not allowed - I get a "Task cannot be a start task" exception. Is there any other way to have the grouptask as the first task in a workflow spec file ? or any other ideas ?

Find more posts tagged with

Comments

Rick Poulin

I didn't quite understand why your group task must be the first task in the workflow, but AFAIK there's nothing preventing group tasks from being the first task. DummyTask is the only type that's not allowed to start a workflow. You also can't have more than one task marked as the starting task, so perhaps there was an issue in your jobspec?

I generally try to mess with the jobspec as little as possible, and instead do things through the API (less error prone, or at least you can catch exceptions). Consider setting your allowed owners to just $IW_USER by default, and then use an external task as your start task. In the external task, resolve your CSGroupTask through the CSSDK and set the sharedBy that way.

Migrateduser

You also can't have more than one task marked as the starting task

Why not? I think you can.

kshah

So it turned out to be an issue with ordering of xml elements within the grouptask element ! I figured this out by running the iwjobc command through command prompt and it showed a different error (than CSSDK !). Anyways here is the order of the elements which worked and I have the grouptask as the first task in the workflow.

[html]

[/html]

I need grouptask as the first task as this workflow will be invoked from a java migration script which pushes content through the existing workflow but need to be started by a group of teamsite users.

kshah

I have one other issue with invoking our workflow through CSSDK api. May be this is an issue with my understanding of the workflow tasks and how they are invoked through teamsite UI.

As I said earlier in the thread I am invoking the workflow through CSSDK api by passing in a Job Spec XML file. The grouptask works fine - in that it allows users in sharedby element to "Take" ownership of the workflow and go forward with other tasks. What I am seeing is that in one of our tasks (cgitask - for metadata capture) the form is shown as "Read Only" in the UI. I have tried to set the readonly="f" on the cgitask but that doesnt solve the issue. Here is the workflow job spec xml for that cgitask. If someone has any ideas please let me know ?
[html]

[/html]

ISCBorisB

I have one other issue with invoking our workflow through CSSDK api. May be this is an issue with my understanding of the workflow tasks and how they are invoked through teamsite UI.

As I said earlier in the thread I am invoking the workflow through CSSDK api by passing in a Job Spec XML file. The grouptask works fine - in that it allows users in sharedby element to "Take" ownership of the workflow and go forward with other tasks. What I am seeing is that in one of our tasks (cgitask - for metadata capture) the form is shown as "Read Only" in the UI. I have tried to set the readonly="f" on the cgitask but that doesnt solve the issue. Here is the workflow job spec xml for that cgitask. If someone has any ideas please let me know ?
[html]

[/html]

Chances are, your CGI Task Owner does not have writing credentials for the File with MD you are trying to set.

Adam Stoller

You also can't have more than one task marked as the starting task
Why not? I think you can.

In this case, Smitty is correct, you can have multiple start tasks - but it does tend to make things a bit complex.

The rest of the issue seems to have been resolved ...

Migrateduser

In this case, Smitty is correct

Translation: It pains me to say this, but Smitty is correct

Smiley Happy

kshah

Chances are, your CGI Task Owner does not have writing credentials for the File with MD you are trying to set.

That is exactly the issue. The CGI Task owner - the user in the grouptask - (sharedBy) who took ownership does not have write credentials on the metadata capture form cgitask. I am not sure how I can solve this issue. It looks like I need to know at run time - the user who took ownership of the grouptask and then set that user as the owner on the CGITASK. Is this even possible ?

Thanks for the replies...

Adam Stoller

That is exactly the issue. The CGI Task owner - the user in the grouptask - (sharedBy) who took ownership does not have write credentials on the metadata capture form cgitask. I am not sure how I can solve this issue. It looks like I need to know at run time - the user who took ownership of the grouptask and then set that user as the owner on the CGITASK. Is this even possible ?

Thanks for the replies...

Setting the owner of a CGI task following a Group task, to the user who took ownership of the Group task is possible - using an iwat script, which has been posted about in the past; two such examples:

The last time I attempted to do this on Windows, the Perl script didn't work unless the person who took ownership of the GroupTask had logon locally privileges.

Rick Poulin

In this case, Smitty is correct, you can have multiple start tasks - but it does tend to make things a bit complex.

The rest of the issue seems to have been resolved ...

Sorry, I'm starting to forget the WTF world Smiley Happy

In WFM though, I distinctly recall trying every conceivable way to make this happen (e.g. Start (> AND|OR Gate)? >> [multiple tasks]) and the model would validate but **** itself at instantiation. Granted this was a while ago and I haven't tried again since, instead using a starting external task that does nothing but immediately transition to its parallel successors. Was this just a bug with the early versions of WFM?

(I do plan to answer my own question with a test when I get around to it, unless someone can confirm first)

Adam Stoller

Sorry, I'm starting to forget the WTF world
In WFM though, I distinctly recall trying every conceivable way to make this happen (e.g. Start (> AND|OR Gate)? >> [multiple tasks]) and the model would validate but **** itself at instantiation. Granted this was a while ago and I haven't tried again since, instead using a starting external task that does nothing but immediately transition to its parallel successors. Was this just a bug with the early versions of WFM?

(I do plan to answer my own question with a test when I get around to it, unless someone can confirm first)

It's "WFT" not "WTF" (the latter being the general reaction to most implementation issues ;-)

I've successfully used conditional links for start tasks in WFM (conditional links placed between the "Start" element and the tasks I want to be considered for being the first activated tasks).
I've not had to deal with concurrent start tasks, but I see no reason why it wouldn't work since the underlying workflow engine system (the one that is used by both WFT and WFM after instantiation form processing) supports it.

Rick Poulin

It's "WFT" not "WTF" (the latter being the general reaction to most implementation issues ;-)

Right.. you can tell which of those my fingers are more used to typing Smiley Happy

I've successfully used conditional links for start tasks in WFM (conditional links placed between the "Start" element and the tasks I want to be considered for being the first activated tasks).

I've done that too, but I assumed that worked because once the model is compiled to a jobspec, you still end up with only one start task.

I've not had to deal with concurrent start tasks, but I see no reason why it wouldn't work since the underlying workflow engine system (the one that is used by both WFT and WFM after instantiation form processing) supports it.

Such logic has failed me one too many times with iwov. Can't help but think that this product would never have gotten off the ground on Vulcan. ^^