Hi Charles. I'm not 100% certain I understand all aspects of your question - perhaps a diagram would help me, in case my answer doesn't make sense (and if you have the time). :) You are right that there is no 1..N mapping of an apiman service/api to a back-end endpoint URL. That is a feature we are contemplating for the future but it's certainly not available yet. Here are some thoughts that might be useful/relevant to this use case. First is that you could of course implement a custom policy that changed the back-end endpoint URL based on whatever criteria you see fit. The custom policy would simply have to change the value of the ApiRequest->Api:endpoint field. Doing that should be considered unsafe and a temporary workaround, as the Api object is globally scoped, and really should be either cloned (if we want to suppor this use-case) or immutable (if we don't). Another thing to note is that as of 1.2.0.Final we support system property and environment variable replacements in the API endpoint, endpoint properties, and all policy configurations. This means that you could install *identical* gateways on all the per fuse server, configured using the same shared registry. Then, when you configure the Service/API endpoint, you could set the value to something like: ${external_url} Then you could set a system property, which could be different for each gateway node, like so: (on gateway server 1) -Dexternal_url=http://fuse_server_1:port/ (on gateway server 2) -Dexternal_url=http://fuse_server_2:port/ That way your configuration is shared but certain aspects/properties of the configuration are *externalized*. This feature was originally meant to support more easily migrating data between dev/test/prod environments, but it would work fine for this as well. Did any of that help? -Eric On 1/19/2016 5:30 AM, Charles Moulliard wrote: > Hi, > > If I use a loadbalancer (= F5) exposing a physical IP address (= routed > on internet) and calling one of our endpoints (REST, ...) running into > different integration servers (Fuse + Camel), can we design such > topology ? > > We setup an Apiman Manager (Front + ElasticSearch Database) to define > the plans, services, roles, policies of all the endpoints which are > running into different Fuse Servers. As the mapping between the incoming > request and the endpoint is managed by the Apiman Gateway, I'm thinking > to install one Apiman Gateway / Fuse Server. > Is it doable ? > > Client --> 192.168.1.1 (IP Address of the Server replying to a REST > Service) "Loadbalancer F5" --> NAT --> address of the gateway (= > 10.0.2.1) managing the mapping between the request and the physical > endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could > run internally on this addess (10.0.2.100). > > To support high availability or workload distribution, it will be > required that at least each Camel REST / Web Service runs into multiple > instances of Fuse Servers. That means that their IP address will be > different (A REST service will be deployed on 10.0.1.1, 10.0.1.2, > 10.0.1.3, ...). > > Question : As the GUI interface of the Apiman Manager to encode the > address of the endpoint to map proposes one field (and no more if we > would like to distribute the requests to different servers), is there a > possibility to define a 1 to many relation into ApiMan Server (maybe if > we develop such a feature) or do I have also to install an Apiman > Manager / Gateway per Fuse Server and to encode the same info (plans, > services, ...) excepted the IP address of the server which is > different ? > > Regards, > > Charles > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user >

On 20 janv. 2016, at 11:25, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: That looks correct. -Eric > On 1/20/2016 3:26 AM, Charles Moulliard wrote: > Hi Eric, > > Here is a diagram that I have created based on your response. I think > that it should confirm what we have discussed - correct ? > > Regards, > > Charles >> On 19/01/16 15:47, Eric Wittmann wrote: >> Hi Charles. I'm not 100% certain I understand all aspects of your >> question - perhaps a diagram would help me, in case my answer doesn't >> make sense (and if you have the time). :) >> >> You are right that there is no 1..N mapping of an apiman service/api >> to a back-end endpoint URL. That is a feature we are contemplating >> for the future but it's certainly not available yet. >> >> Here are some thoughts that might be useful/relevant to this use case. >> First is that you could of course implement a custom policy that >> changed the back-end endpoint URL based on whatever criteria you see >> fit. The custom policy would simply have to change the value of the >> ApiRequest->Api:endpoint field. Doing that should be considered >> unsafe and a temporary workaround, as the Api object is globally >> scoped, and really should be either cloned (if we want to suppor this >> use-case) or immutable (if we don't). >> >> Another thing to note is that as of 1.2.0.Final we support system >> property and environment variable replacements in the API endpoint, >> endpoint properties, and all policy configurations. This means that >> you could install *identical* gateways on all the per fuse server, >> configured using the same shared registry. Then, when you configure >> the Service/API endpoint, you could set the value to something like: >> >> ${external_url} >> >> Then you could set a system property, which could be different for >> each gateway node, like so: >> >> (on gateway server 1) >> -Dexternal_url=http://fuse_server_1:port/ >> >> (on gateway server 2) >> -Dexternal_url=http://fuse_server_2:port/ >> >> That way your configuration is shared but certain aspects/properties >> of the configuration are *externalized*. >> >> This feature was originally meant to support more easily migrating >> data between dev/test/prod environments, but it would work fine for >> this as well. >> >> Did any of that help? >> >> -Eric >> >> >>> On 1/19/2016 5:30 AM, Charles Moulliard wrote: >>> Hi, >>> >>> If I use a loadbalancer (= F5) exposing a physical IP address (= routed >>> on internet) and calling one of our endpoints (REST, ...) running into >>> different integration servers (Fuse + Camel), can we design such >>> topology ? >>> >>> We setup an Apiman Manager (Front + ElasticSearch Database) to define >>> the plans, services, roles, policies of all the endpoints which are >>> running into different Fuse Servers. As the mapping between the incoming >>> request and the endpoint is managed by the Apiman Gateway, I'm thinking >>> to install one Apiman Gateway / Fuse Server. >>> Is it doable ? >>> >>> Client --> 192.168.1.1 (IP Address of the Server replying to a REST >>> Service) "Loadbalancer F5" --> NAT --> address of the gateway (= >>> 10.0.2.1) managing the mapping between the request and the physical >>> endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could >>> run internally on this addess (10.0.2.100). >>> >>> To support high availability or workload distribution, it will be >>> required that at least each Camel REST / Web Service runs into multiple >>> instances of Fuse Servers. That means that their IP address will be >>> different (A REST service will be deployed on 10.0.1.1, 10.0.1.2, >>> 10.0.1.3, ...). >>> >>> Question : As the GUI interface of the Apiman Manager to encode the >>> address of the endpoint to map proposes one field (and no more if we >>> would like to distribute the requests to different servers), is there a >>> possibility to define a 1 to many relation into ApiMan Server (maybe if >>> we develop such a feature) or do I have also to install an Apiman >>> Manager / Gateway per Fuse Server and to encode the same info (plans, >>> services, ...) excepted the IP address of the server which is >>> different ? >>> >>> Regards, >>> >>> Charles >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >