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

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Retrieving the currently pending signals

lmollea

Wanted to know if there is a way to retrieve via Activiti API the current pending signals for a certain process Instance or if the only way is via a db query like:

select ID_, EVENT_NAME_ from ACT_RU_EVENT_SUBSCR where PROC_INST_ID_ = ? and EVENT_TYPE_ = 'signal'

Seems that only in 5.15 there is a CustomSQL extension point in ManagementService, isn't it?

Thanks

Find more posts tagged with

Comments

trademak

The right API call would be:

runtimeService.createExecutionQuery().processInstanceId().signalEventSubscriptionName()

You can also write your own query and use the custom sql approach if necessary, yes.

Best regards,

lmollea

Uhm… nope.
I don't want to know if a certain process instance is waiting on *that particular* signal name.

I want to know the names of the signals that a process instance is waiting on: I don't have the value of the parameter to pass to signalEventSubscriptionName(), that's what I am trying to know.

Mind, yes I "know" which are the signals that are "declared" in the process because I designed it. But with your approach I would have to query N times the database to see if for every signal the process has an execution pending. Not advisable when you have about 30-50 signal point in the process.

jbarrez

There is an unexposed EventSubscriptionQueryImpl that you can use for this purpose.

See the org.activiti.engine.test.api.nonpublic.EventSubscriptionQueryTest how it is used.

lmollea

Thanks, it's working.
Prefer using an API even if not "officially" exposed than putting some raw queries into the code.
(Actually the chance that my query or the unexposed API will break might be the same…)