-
15. Re: How to define a new custom provider?
Essentially that is how the MessageRedeliverer works. So yeah that's a very valid use-case. --Kurt
-
16. Re: How to define a new custom provider?
If it involves new code, then JIRA it and we'll prioritise. But it isn't on the 4.2.1 roadmap at the moment and won't be unless it is JIRA-ed.
-
17. Re: How to define a new custom provider?
"burrsutter" wrote:
Tom/Team,
How about if he created a service manage the schedule but another service to perform the actual processing on a message by message basis? Essentially the message composer attaches the arraylist to the message object. The first action in the scheduled service action chain loops through the arraylist and use the ServiceInvoker to queue those messages up for the actual processing service.
What do you think?
Burr
I would think that that would be a perfectly valid way of doing it Burr. It would be preferable (IMO) to batch processing a load of messages in one go (for the reasons outlined above). -
18. Re: How to define a new custom provider?
"burrsutter" wrote:
Tom/Team,
How about if he created a service manage the schedule but another service to perform the actual processing on a message by message basis? Essentially the message composer attaches the arraylist to the message object. The first action in the scheduled service action chain loops through the arraylist and use the ServiceInvoker to queue those messages up for the actual processing service.
What do you think?
Burr
From what I know from the 4.2M3 code, you have 2 clases that deal with a "gateway". One is the actual gateway, which can retrieve a list of object from the specific source and the second is the composer class, the one that actually transforms ONE foreign object into ONE ESB message.
I already created 2 classes, one to serve as the gateway and one to serve as the composer. The scheduler approach actually merges the gateway and the composer, so you have to read one message and fire it into the ESB.
What I have not figured out so far is how to define (in the esb xml) the custom gateway/composer + specific attributes. I suppose the attributes can be placed as:<property name="x" value="y">
I also know how you can specify a composer class/method to a listener, but from all the available documentation I don't know how to specify a custom gateway. From here started all this thread, after all... I can manage for now with the "frequency" firing gateway that processes one message, I don't think the incoming messages will be so many (at least not yet), but you never know...
Also we'll have to implement some other custom gateways in the next period so any improvment on the model is eagerly awaited. -
19. Re: How to define a new custom provider?
"tfennelly" wrote:
I would think that that would be a perfectly valid way of doing it Burr. It would be preferable (IMO) to batch processing a load of messages in one go (for the reasons outlined above).
Another thing,
We may have define 2 gateways. One for example a FTP gateway and the other one of our custom gateways. The chain of actions will be the same, just you have 2 sources from where you get the data. So we need to have a standard approach about how we define the gateways/listeners.
If I understand correct, Burr is saying: for this cursom gateway put a specific action in the chain? -
20. Re: How to define a new custom provider?
My understanding is that all of this will be getting cleaned up soon enough.
1. The "gateway" concept will disappear into the background (JBESB-788), so you'll just be left to think in terms of Services that have "listeners" (note the generic term) that supply composed messages to an action pipeline.
2. The configuration mapping that takes place, going from the XSD based model to the legacy ConfigTree model will also disappear (JBESB-789). I bet this is at the root of most of your confusion!!
Check one of my earlier posts on this thread re how to specify a custom gateway using the current config model - check out those unit tests etc.<?xml version = "1.0" encoding = "UTF-8"?> <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd"> <providers> <bus-provider name="My-Provider-X"> <property name="Provider-prop-1" value="val-1" /> <property name="Provider-prop-2" value="val-2" /> <bus busid="My-Provider-X-Gateway"> <property name="Bus-prop-1" value="val-1" /> <property name="Bus-prop-1" value="val-1" /> </bus> </bus-provider> <jms-provider name="JBossMQ" connection-factory="ConnectionFactory" jndi-URL="jnp://localhost:1099"> <jms-bus busid="local-jms" /> </jms-provider> </providers> <services> <service category="Bank" name="Reconciliation" description="Bank Reconciliation Service"> <listeners> <listener name="Bank-JMS-Gateway" busidref="My-Provider-X-Gateway" is-gateway="true"> <property name="gatewayClass" value="com.acme.MyGatewayClass" /> </listener> <jms-listener name="Bank-Listener" busidref="local-jms" maxThreads="2"> <jms-message-filter dest-type="TOPIC" dest-name="queue/B" selector="service='Reconciliation'" /> </jms-listener> </listeners> <actions> ...... </actions> </service> </services> </jbossesb>
In fact, I think you could define the "gatewayClass" directly on the provider config (Vs the listener config).
So with something like this, you're still going to have a period of confusion re the mapping from the XSD based model to the ConfigTree model. To help get over that, create some test configs and run them through the test helper class org.jboss.soa.esb.testutils.ESBConfigUtil. This will help you visualise the sort of ConfigTree model your XSD based bus-provider config will generate.