| Author |
Message
|
| apmohan |
 Posted: Wed Jan 23, 2019 5:05 am Post subject: Way to Set a Variable which is accessible outside the Broker |
 |
|
Apprentice
Joined: 28 Dec 2012
Posts: 27
|
Hello,
I have a requirement where the consumer URL will be set in the requester flow(BROKER1) which need to be passed to over HTTP Request and that URL should be used on the other Broker (Broker2 - Different Server)(Common Flow which is deployed on the other Broker to hit the endpoint).
Use of LocalEnvironmentVariable doesnt solve the Purpose as the value set in the Broker 1 is not available in Broker2 but the request message constructed in Broker1 is available on Broker2.
Can some one help on this  |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jan 23, 2019 6:28 am Post subject: Re: Way to Set a Variable which is accessible outside the Br |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| apmohan wrote: |
| I have a requirement where the consumer URL will be set in the requester flow(BROKER1) which need to be passed to over HTTP Request and that URL should be used on the other Broker (Broker2 - Different Server)(Common Flow which is deployed on the other Broker to hit the endpoint). |
What exactly is driving this rather unusual requirement? Are you sure this is the only way to achieve what you need to happen?
| apmohan wrote: |
| Can some one help on this |
If you need to share something between brokers (and of all the possible sharing scenarios yours would never occur to me) the embedded global cache would be the obvious choice. Unless you actually have the full version of eXtreme Scale in which case use that.
But think very carefully about what you're trying to do. I really don't get what you're trying to achieve and I worry you're tying yourself in knots.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mpong |
| Posted: Wed Jan 23, 2019 1:50 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2010
Posts: 164
|
the embedded global cache will not help as you mentioned broker 2 is on the different server. Cant you pass the target endpoint along with request message? In the ideal case, broker 2 should be able to determine which endpoint it needs to post the data.
Is there a requirement to dynamically determine the endpoint here? |
|
| Back to top |
|
|
| apmohan |
| Posted: Thu Jan 24, 2019 1:09 am Post subject: |
|
|
Apprentice
Joined: 28 Dec 2012
Posts: 27
|
| mpong wrote: |
the embedded global cache will not help as you mentioned broker 2 is on the different server. Cant you pass the target endpoint along with request message? In the ideal case, broker 2 should be able to determine which endpoint it needs to post the data.
Is there a requirement to dynamically determine the endpoint here? |
You are right, we need to define the Endpoint Dynamically based on the request we receive (Add/Delete) so we are setting those URL's in the UDP on Broker1 and passing the URL with the data which will be received in Broker2, then I will extract the URL from it and detach the part it before I hit the endpoint as the URL shouldnt be sent along with the Data.
Thanks for your view on this  |
|
| Back to top |
|
|
| timber |
| Posted: Thu Jan 24, 2019 4:27 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
So Broker1 looks at the data and adds routing information.
Broker 2 uses the routing information (URL) to call an endpoint.
Why not just expose two different URLs on Broker2 - one for Add and one for Delete? Then Broker1 can directly call whichever one it wants to route the message to. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 24, 2019 6:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mpong wrote: |
| the embedded global cache will not help as you mentioned broker 2 is on the different server. |
What's the problem with having the cache spanning multiple servers? Aside from having to create a configuration for it rather than accepting the defaults?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 24, 2019 6:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| timber wrote: |
So Broker1 looks at the data and adds routing information.
Broker 2 uses the routing information (URL) to call an endpoint.
Why not just expose two different URLs on Broker2 - one for Add and one for Delete? Then Broker1 can directly call whichever one it wants to route the message to. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| apmohan |
| Posted: Thu Jan 24, 2019 11:27 pm Post subject: |
|
|
Apprentice
Joined: 28 Dec 2012
Posts: 27
|
| Vitor wrote: |
| timber wrote: |
So Broker1 looks at the data and adds routing information.
Broker 2 uses the routing information (URL) to call an endpoint.
Why not just expose two different URLs on Broker2 - one for Add and one for Delete? Then Broker1 can directly call whichever one it wants to route the message to. |
|
We can opt this option also, but we are trying to generalize the interface on Broker2 as the Broker1 can have different URL's (say for different countries - different URL's), so we will be setting those Country Specific URL in UDP on Broker1 which should be sent along with the Payload to Broker2 to hit the corresponding URL's.
Thanks all  |
|
| Back to top |
|
|
|
|
