I have a scenario where there is a jbpm process calling subprocesses. One of the subprocess has a human task that expects a manual approval or rejection. But the human task is never getting completed if approves or rejects. This is happening only for this subprocess scenario. Otherwise the human task is working fine in independent process scenario.
taskService.complete(taskId, userId, data);
Above is the line of code where it is stuck.
taskService is -->
TaskService taskService = runtimeManager
.getRuntimeEngine(ProcessInstanceIdContext.get(
Long.valueOf(processInstanceId)))
.getTaskService();
Related
What happens to a failed Service Task when the application is restarted. Will it attempt to retry the Service task once again.
If not, how does the Process proceed. Is there a way to manually retry the Service task ?
I could see from Flowable API, that taskQuery lists only the UserTasks.
In Flowable when an execution fail (due to some exception), the transaction would be rollbacked to the previous wait state in your workflow. This means that the next time it runs it would continue from there.
You can make a Service Task async which would make it a wait state. In that case an Async Job would be created and that would be retried (by default 3 times, but that is configurable). If the Service Task fails all the time (the configured number of retries) the job would be moved into the dead letter job and then you need to manually trigger it.
I am writing a SCDF spi implementation for supporting stream and task application. As part of this we need to perform some clean up operations once the task finishes.
Could someone provide info on whether SCDF will be getting a callback on task completion. If not then what are the alternative ways to perform cleanup.
A Task is a short-lived and finite operation. Depending on what you're trying to accomplish, you can do one of the following to invoke any custom cleanup routine.
1) A task running a batch-job and in that job, you can define "n" number of steps as part of a workflow, and upon successful upstream steps, the last step could invoke the cleanup routine.
2) You can have a stream in SCDF listening to Task-complete events (a batch-job example here), which can finally kickoff another task/job to invoke the cleanup routine.
3) You can define a composed-task graph (via Dashboard/shell) where each of the steps (aka tasks) can run its intended operation, and upon successful transition or failure event, you get the opportunity to kick off the cleanup routine.
I am working with Activiti 5 REST API interfaceintegrated with Spring Boot Activiti Starterand I am trying to complete a process instance. I was able to instantiate a process definition, walk through the process instance tasks and complete each of them. It correctly works until the end of the process, when there are no pending tasks left. I would expect the process instance to be completed - i.e. completed: true-, as I have an end event (terminateEventDefinition), but it is not.
I could not find the REST Api to complete the process instance. So, what's the correct way of managing process instance completion?
Thanks.
Perhaps I am missing something, but after the last task is completed the process will end normally and no longer visible in the /runtime/process-instances list.
Now, you mention that you complete the instance with a Terminate End Event, Terminate End events will complete the instance but will not set the "complete" flag. Terminate is typically used for cancelling a running process.
Instead of terminate, you should use a regular end event, this should set the complete flag.
Again, maybe I am missing somethign in your description.
Thanks
Greg
We have a "service" that is actually nothing more than a C# console app running periodically as a Windows Scheduled Task.
On purpose, we would let the exceptions, if any, bubble up to the main course execution of the program, so that the Windows Task Scheduler could detect this and provide detailed information for the people in charge of monitoring the servers. The application itself is not complex, and does, in fact, make sense to halt all its execution when an error is encountered.
However, we have just found an error because of its side effects of the service not running, and trying to troubleshoot, the people in charge of these servers told me that the only information that they get on this task is its start and end time, no extra information about how did it run.
Is this correct? Or am I supposed to do anything else than just bubble up the exception so that WTS can get detailed information of the task result?
Experiencing intermittent issues, related to named events when processes are running in different user contexts: WaitForSingleObject (and WaitForMultipleObjects too) for such event handle fails with WAIT_FAILED (GetLastError returns 6 - Invalid handle value).
We have an application to schedule tasks on Windows machines under user accounts, and issue happens after some tasks are completed.
Service part of application (JobManager) starting executable (JobLeader) under user account (CreateProcessAsUser) to run user task, and waiting for named event to be signaled.
Manual reset named event is created by JobLeader in the "Global\" namespace and signaled when user task is completed.
JobManager waiting in the loop, calling WFMO(WaitForMultipleObjects) with delay of 10 seconds, to see if named event or JobLeader process handle are signaled.
Periodically named event handle, opened by JobManager through OpenEvent API call, causes WFMO (WFSO is also called after to identify which handle is broken) to return WAIT_FAILED, with error code 6 - "Invalid handle value".
After reopening the event, this error may gone, or may not - WFMO may again returns WAIT_FAILED because of invalid handle value.
Interesting, that it may pass few dozens tasks without this error, and then - sequentially few tasks have it. Tasks used for testing are identical - just a cmd.exe script, dumping environment.
Anyone have ideas about this?
Regards,
Alex
Do you create the event in your JobManager and then open it in the 'JobLeader'? If not, how do you communicate the event handle (and/or name) between the two processes?
My gut tells me it's a race condition...