Imran, This seems like a complexity and maintenance nightmare. You might want to rethink your approach for simplicity and maintainability. I don't know your exact requirements and all of your use cases, but it might help if you can normalize and generalize a bit to streamline the process. At the very least, I would rely on Camel to perform the routing and processing, and if you need a state machine, use something like StatefulJ and don't clutter your camel orchestration with it.
Owain, are you referring to the Guava EventBus, or Google Cloud Pub/Sub? On Wed, Jan 10, 2018 at 1:35 PM, Owain McGuire <owain@integration.technology > wrote: > Imran, > > Have you thought of a publish/subscribe model where each topic triggers > multiple subscriptions. Perhaps have a look at Google pub/sub component. > > HTH. > > O. > > > > On 10 Jan 2018, at 18:23, Imran Raza Khan <imranrazak...@gmail.com> > wrote: > > > > Hi Steve, > > > > Thanks for detail reply. > > > > - I will evaluate StatefulJ if it fits into my requirements. > > > >>> With Camel, I prefer to route a message, and then hand off the work as > > fast as possible, and then free up the routing to handle more messages. > To > > separate concerns, if the action being performed is not directly related > to > > one of the EIPs, then I would avoid performing it with Camel. > > > > - I have more than 100 states and on every request on the base of > different > > criteria it select 10 to 15 states to be process. As from sample table > you > > can see mostly i required integration with different nodes on backend > like > > billing system, customer profile system, SMSc, catalog manager etc. My > > program infact take request and forward on base of state. Due to > > integration almost 6 to 7 backed systems with different protocols SOAP, > > REST, XMLRPC, SQL Procedures calls i choose camel. > > For some legacy nodes i suppose to retry multiple times so again camel > > support in this regard very well. > > > >>> For better granularity, you can split up the process steps into their > own > > routes, which is what I would personally do. Each phase (order > > creation, order > > placement, and order completion, notifications, etc) would include the > > error handling that you will want in your order placement chain of > > operations. > > > > - In sample table i showed only couple of states otherwise we cant divide > > it into three categories as you mentioned, we have 100 of products and to > > order each we have different states and nodes to handle. in some case i > > only call 2 back-end nodes and for some scenario i have to call all 7 to > 8 > > back-end nodes before final processing of order. Same product has > different > > prices and rules on base of customer profile. > > > > Regards > >
