| Summary: | Timer cycle does not work | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Jiri Locker <jlocker> |
| Component: | jBPM 5 | Assignee: | Kris Verlaenen <kverlaen> |
| Status: | CLOSED DUPLICATE | QA Contact: | Jiri Locker <jlocker> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | BRMS 5.3.0.GA | CC: | atangrin, brms-jira |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-04-12 13:33:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
*** This bug has been marked as a duplicate of bug 801093 *** Note that the format that is used internally in the BPMN2 file looks like this: <timeCycle>500ms###1s</timeCycle> So if you want a timer to trigger repeatedly, you should not just specify a delay but also a period after which it should repeat. Looks like a nice little hack, but I not sure if it is a good idea to keep this "feature" after turning jBPM into a product. There are several issues:
1, it is not mentioned in the documenation
2, it is not intuitive
When I write <timeCycle>1s</timeCycle> I expect the timer to trigger repeatedly each 1s. If I wanted to specify an initial delay duration that is different from the timeCycle, I would probably prepend one more timer with <timeDuration>500ms</timeDuration>, because BPMN 2.0 requires that only one of [timeCycle, timeDuration, timeDate] is used inside timer node (they are mutually exclusive).
The idea to make it possible to specifiy both delay and cycle inside timeCycle element sounds interresting but let's make it optional:
* 1s means "fire each 1s" (now means "wait for 1s and than do nothing", but this is what timeDuration is intended for)
* 500ms###1s means "wait for 500ms and then fire each 1s" (works now)
3, the format is not allowed by process form validation for String inputs
I have <timeCycle>#{cycle}</timeCycle> timer definition where cycle is a process input variable of type String. I cannot set cycle to "500ms###1s" because the process form considers the value invalid.
|
Description of problem: Timer defined like this: > <bpmn2:timerEventDefinition> > <bpmn2:timeCycle xsi:type="bpmn2:tFormalExpression">#{time}</bpmn2:timeCycle> > </bpmn2:timerEventDefinition> does not trigger repeatedly in #{time} intervals. It only delays the process execution for #{time} an then never triggers again. Version-Release number of selected component (if applicable): ER5 How reproducible: always Actual results: Timer only waits for the value of timeCycle element and does not trigger repeatedly. Expected results: Timer should trigger repeatedly in time intervals specified by the timeCycle element. Additional info: