Steve, I was meaning the Pub/Sub pattern in general so there are many solutions. I have just been using Google Pub Sub which I found very straightforward on Camel but look at the examples on Github as a starter. Also with the Google Pub Sub API you can programmatically define topics and subscriptions which might address Imran’s complexity (store in a config file/db Imran?). Imran you might want to programmatically define camel routes if you have a lot of similar ones?
HTH. O. > On 11 Jan 2018, at 01:32, Steve973 <steve...@gmail.com> wrote: > > 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 >> >>
