Thanks for the clarification, Owain. Imran, are your states the same across all of your nodes/systems? I agree that orders always have a particular state, and they consequently have rules for state transitions. Can you elaborate a little bit more on how you can have a hundred different states for an order, though? That sounds like it is a bit excessive. If each of the backend systems have different states (or how the states are named), it would probably help if you can come up with a common set of states that can be translated to the specific enumerations of states on the backend systems. For each backend system (or node) you could have a means of translating state from their set of states to your ordering system's set of states. That would compartmentalize and separate the complexity of coordinating the states of systems that you interface with from the states that your ordering system keeps track of. When a backend system changes their set of states, it localizes and minimizes the maintenance work that you would need to perform in your ordering system, and if you need to add another backend system, it makes it much easier to do so.
If this sounds like your situation, consider using the double dispatch pattern to easily convert between states. When you have your states defined, you can define an interface that has two methods: toLocalState(final State remoteState) and toRemoteState(final State localState). Then, for each remote system, implement this interface and both methods would inspect the incoming state to determine what outgoing state should be returned. Your logic (in, for example, a Camel Processor instance) would have the appropriate implementation wired in as the interface type so that you can call the appropriate method on the interface type, rather than the concrete state conversion dispatch implementation, and you will have the correct state to pass through the route. This will keep the specific knowledge of states and transitions to and from a particular backend system agnostic to your camel routing, and any changes in the enumeration of states for any given system (or the addition of new systems and new states) to the double dispatch implementations and the state definitions themselves in your StatefulJ (or other) implementation. If this idea doesn't seem like it fits, then if you could elaborate a bit more on your requirements, we could probably help a little better. On Thu, Jan 11, 2018 at 2:42 AM, Owain McGuire <owain@integration.technology > wrote: > 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 > >> > >> > >
