SetActivityStreamListener Not Behaving As Expected?

We are in the process of modifying the OOTB Approval workflow and are getting some behavior from the user task for reviewing comments that does not appear to be correct.

Basically, there is a user task for reviewing comments after a voting process is rejected by one of the voting roles which uses a task listener to gather comments. The user task is created as expected with a link to the asset and the verbiage from the documentation field. Based on our understanding of this task listener, that task modal UI should contain the comments made during voting (basically any comments made after the workflow task ID provided in the startTask of the Task listener). However, we see no such comments, just the name/link of the asset.

So I guess my specific question would be this:

Am I correct in assuming that the task UI should summarize the comments made in the voting step?
If that that is correct, can someone verify that this is actually working as expected for them (e.g. the user task contains a summary of the comments)?

Is there some other configuration that maybe we are missing. We verified that we haven’t done anything significantly different from what comes with that OOTB workflow with regards to this listener task, but wondering if there is some initiation class that has to be added to the start task or something. We can find nothing in the documentation indicating that, but just want to verify.

Thanks in advance for any insight you can provide for this.

tjbrodeur1

Posted 3 years ago · Edited 1 year ago·Last reply 3 years ago

8 comments

Sean Pyle

·3 years ago · Edited

Hi TJ,

You’re right, the UI should summarize the comments and show a time stamp. See the screenshot below.
I’ve noticed that ActivityStream Listener isn’t working properly with Workflow Designer (not sure if you modified this in Eclipse or WFD?). In WFD, the forms seem to have trouble picking up the listeners since the listeners are tied to the process file and not tied to the form itself.

I recommend putting a ticket with support to get some engineers to take a look at the issue.

**1

tjbrodeur1

OP3 years ago · Edited

Thank you so much for the clarification. I wondered if it might be something specific to the Workflow Designer.

I’ll definitely submit a support ticket, but I’m also wondering how I might be able to modify the BPMN file to get this to work correctly. I’ve looked at the BPMN code in VS Code and can’t see anything obvious with how these task listeners are being invoked or in the task itself (e.g. something in the task that is Workflow Designer specific). Do you happen to have any insight on this?

Sean Pyle

·3 years ago · Edited

Happy to help TJ,

At present, I think the only way to get it to work would be to use form properties to create the form for the user task instead of using a Workflow Designer form. By using form properties the BPMN engine may recognize the presence of the listener along with the other form fields. Let me know how it turns out if you try it!

-Sean

tjbrodeur1

OP3 years ago · Edited

So digging back in I was reminded that I did not actually use any Workflow Designer forms. In fact, this User task doesn’t even use form properties, only Task Listeners which are invoked as extensionElements in the BPMN code.

Comparing the workflow designer BPMN code there are only two differences I can see:

The engine in this legacy workflow uses the “activiti” engine set in the definitions at the beginning of the BPMN file (xmlns:activiti=“http://activiti.org/bpmn”). This is different from the workflow designer which uses a “flowable” engine (xmlns:flowable=“http://flowable.org/bpmn”). I know Collibra migrated to flowable a while back, but a lot of our workflows are still using activi and I’m wondering if this functionality loss has to do with flowable.
There are a couple of additional parameters being added by the Workflow Designer in this user task. These don’t seem like something that would break this, but I thought I’d call it out for the engineers. The parameters are:
flowable:task-candidates-type</flowable:task-candidates-type>
design:stencilid</design:stencilid>

One question for you: on the example you showed, is that workflow using the activi or flowable engine?

Sean Pyle

·3 years ago · Edited

@tj.brodeur,

The user task should either have at least one form property or a Workflow Designer form. I tested this with a workflow a found that the activity stream doesn’t show unless there is at least one form property.

Yes, as you noted, workflow elements using activiti have been depreciated for some time, even before the release of Workflow Designer. We have a CLI tool that checks workflows for depreciated APIs. . However, for listeners, you could also do this manually by updating the reference to the listener. You can find the reference for the new API for ActivityStream Listerner here..

The example I showed is using flowable API v2 com.collibra.dgc.workflow.api.listener.SetActivityStreamListener

tjbrodeur1

OP3 years ago · Edited

Interesting about the form properties. Especially since the out of the box version didn’t have any. I’ll see if I can add one to get this to work.

We did run the CLI tool on our production workflows last year and updated the APIs. For some reason, that didn’t seem to update this (flowable vs activiti), just the API reference and syntax. I’ll have to go back and review that.

tjbrodeur1

OP3 years ago · Edited

OK. So I tested the adding a form property and that seems to do the trick. That is an interesting requirement. I would not have guessed that, nor did I see that in the documentation.

Anyway, thank you so much for the help.

satishkumar_sahoo

·3 years ago · Edited

Hi TJ,

The comment should be accessible on the asset itself; I don’t believe it is logged within the task.

Regards,
Satish