I’m trying to figure out what would be the best approach to check a state on a remote app on constant interval before proceeding flow further,
Option 1 (loop through recreation of timers)
- Process starts
- API call creates the async job on the remote system, storing a variable with the created job id. (JOB_ID)
- The intermediate timer only delays the flow, nothing else.
- the ‘job completed?’ node get the job via the JOB_ID var and put the status on a var (STATUS) var, it also increment some counter stored as a process var too (COUNTER)
- the exclusive GW has 3 edges, where each edge has a condition based on the STATUS / COUNTER to decide where to move next
in case of ‘no’ the flow is transitioned back to the timer, which creates another job with 1 minute delay and so on…
(Is it safe enough as this is going to create more and more timers)
Option 2 (using multi marker)
- One time API invocation to create the job on the remote app
- A sub process which is executed multiple X times sequentially, in case of job completion, a node can change the completion condition of the multi marker (is it possible? does it make sense?) so the other tasks will not run as there’s no need.
- When the sequence ends (whether all tasks were executed = execution exceeded or not), another GW could decide what to do next according to the completion state set by the sub process.
Does this make sense? are there any better ways to tackle this scenario ?
Thanks in advanced,
yea I’ve went through this thread, the concept is based on an event based sub process which performs the checking through a non interrupted timer event on some interval, from my understanding the sub process timer event will be visited first time when the root process instance is instantiated,
If that so, in my scenario, the sub process must start only when some point in the parent process is reached (there are many waitings before that can take weeks and it makes no sense to make the sub process execute every minute before this point is reached)
@Asaf_Shakarzy you can modify the event sub-process or the parent process to accommodate your scenario.
If you system requires polling then you set your event process process to execute at whichever interval is appropriate for your needs. How do you see your sequential process any different than the timer?
I think I got it wrong, I tried to embed the event process within the root flow, the ‘Pattern Feedback’ cannot be apart of the parent flow, it must live on its own separated flow and communicate through messages, so once it is started, the polling of the event sub process starts too and it makes sense,
But in general, is there a differences between modeling a sequential process as I did than instantiating another process ? what are the pros / cons ?
And btw, is a cycle non intermediate timer (within the event sub process) instantiate a process every time it fires?