i have a main flow service which will be called from a front-end system.

within this flow service, i plan to spawn 7 threads.
each thread will finish processing and store their own results into a DB.

finally , the main flow service needs to gather the results from all 7 threads and respond back to the front-end , in the same http session.

is this possible to be done with Broker ?
how should i design this ?

Hi,
You can take one static variable, which will be increased by one by every thread when thread finish their work. You can check for this static variable count. Once count reaches to 7, you can fetch the result from DB and can display to the front end.

Additional options to consider:

• Don’t use threading. I’m assuming you’re thinking about doing that for performance but I’d be willing to bet that serial processing would run fast enough.

• Use Service.doThreadInvoke to kick off each thread. Call getIData on each resulting ServiceThread object to do a join.

i need to finish calling all 7 back-end systems, combine their reply messages, and respond to my front-end client within 3 secs.

so i dont think that looping to check a variable would be feasible.

Hi,
You do not need to loop anything. You just need to check the value of this variable using if condition. Once condition will be matched ‘if’ block will get executed and at the end of the if block you can reset the static variable.
Not sure where and why you r using loop to check the value of static variable.

If your problem is about sending queries to 7 different system and waiting for a reply

• parallelisation is good, as the other systems may need processing time themselfs und shouldn’t be called in serial

• If you use process engine, design a process, implement 7 calls (IS services or webservice) to the backend systems, place them in the process, connect them in parallel to a starting step and joind their outputs to one common step using AND. This is the most elegant solution imho. It matches on of the typical BPM patterns.

• If you do not use processes you can use request reply in a flow service. I personally wouldn’t use threading as this tend to get complicated. You can tell a request reply step to continue processing after sending the request and gather the result in a later step. This way you can send your 7 request and wait for a reply (a timeout is recommended). Details to be found in the publish subscribe developers guide. A typical implementation for publish reply implementation.

Regards

Martin

IMO, there is a high level of risk in being able to support the 3 second response time. The first thing that is of concern is retrieving data from 7 different locations. That alone will probably go beyond 3 seconds.

Parallel processing may provide some performance gains but it is my experience that it usually doesn’t. Using the process engine will introduce overhead that will increase the time consumed, possibly significantly. Request/reply broker events will introduce additional latency.

All of these techniques can functionally work–they just probably won’t be fast enough to meet the 3 seconds. I assume this response time is intended to support a UI of some sort. This may not be the right path.