[Apiman-user] How to update backend implementation URL for published Service without changing the version
Eric Wittmann
eric.wittmann at redhat.com
Thu Jan 7 08:08:19 EST 2016
No nothing like that should be needed. Doing that curl command is just
like doing an UPDATE on a SQL db. I even tried it locally (switching
between URLs by updating that record in elastic) and didn't have any
problems.
Did you restart apiman after the change? Unfortunately (for this
use-case) apiman will cache the information so that it doesn't have to
do a lookup in ES for *every* request.
Also what happens how when you do the -XGET call? Do you see the new data?
-Eric
On 1/7/2016 2:58 AM, Sanjay Melinamani wrote:
> Hi Eric,
> Even after the restart, gateway is still using the OLD service
> implementation URL. Do I have to rebuild the index, clear cache or do
> something else??
> When grepped for old URL, I can still see it in indices folder of
> elastic search. I tried to clear cache and used refresh commands but did
> not work!
>
> Appreciate if you can provide some more guidance here.
>
> Thanks
> Sanjay
>
>
> On Wed, Jan 6, 2016 at 12:57 PM, Sanjay Melinamani <mssanjay at gmail.com
> <mailto:mssanjay at gmail.com>> wrote:
>
> Thanks a ton! Worked like a charm :)
>
> Sanjay
>
>
> On Tue, Jan 5, 2016 at 8:01 AM, Eric Wittmann
> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>
> Drop the /_source from the PUT command. :)
>
> -Eric
>
> On 1/5/2016 1:45 AM, Sanjay Melinamani wrote:
>
> Thanks Eric for your reply! makes sense...
>
> I tried to use the two CURL commands.
>
> GET worked and I was able to see the end point being used.
> curl -XGET
> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
> {"endpoint":"http://OLD_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}
>
>
>
> But the PUT failed as below..
>
> curl -XPUT
> http://localhost:19200/apiman_gateway/service/prism:osa:1.0/_source
> -d
> '{"endpoint":"http://NEW_URL","endpointType":"rest","publicService":false,"organizationId":"prism","serviceId":"osa","version":"1.0","endpointProperties":[],"policies":[]}'
>
> No handler found for uri
> [/apiman_gateway/service/prism:osa:1.0/_source]
> and method [PUT]
>
>
> Thanks again for your time
>
> Sanjay
>
>
> On Mon, Jan 4, 2016 at 11:26 AM, Eric Wittmann
> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>
> <mailto:eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>>> wrote:
>
> Hi Sanjay, thanks for the questions.
>
> Currently there is no easy way to update the backend
> implementation
> endpiont URL without creating a new version of the service.
>
> However, if this is a one-off sort of thing then you
> may be able to
> get it done. It depends mostly on what configuration
> you are
> using. But I'll explain based on the most recent 1.1.x
> release
> (1.1.9.Final) with its default configuration.
>
> The Manager and Gateway are decoupled, resulting in the
> duplication
> of *some* of the data (including the endpoint URL). So
> when you
> "publish" a service from the Manager, the Gateway is given
> information about the service. This information is
> stored in the
> Gateway's "registry". By default the registry
> implementation is
> elasticsearch. So if you wanted to change the endpoint
> URL for a
> service, you would need to update that information in
> your Database
> (you did this) *and* in elasticsearch.
>
> It's actually not that difficult to update the
> information in
> elasticsearch. You'll need to find the correct record
> and then
> update it. If you're using the default installation,
> then ES is
> running on port 19200. If you want to change the
> following service:
>
> Organization: Example
> Service ID: MyService
> Version: 1.0
>
> Then you might do something like this:
>
> curl -XGET
> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0/_source
>
> You could then take that JSON result, modify the bits
> you want to
> change, and then update it like so (as an example -
> please replace
> the JSON below with the JSON you get back from the GET
> above):
>
> curl -XPUT
> http://localhost:19200/apiman_gateway/service/Example:MyService:1.0
> -d '
> {
> "endpoint" : "http://UPDATED-ENDPOINT-HERE",
> "endpointType" : "rest",
> "publicService" : true,
> "organizationId" : "Example",
> "serviceId": "MyService",
> "version" : "1.0",
> "endpointProperties": [],
> "policies":[]
> }
> '
>
> Once this is done you'll have to restart apiman so that
> the Gateway
> picks up the changes.
>
> Note: we are making some changes in apiman 1.2.x that
> will make all
> of this easier under some circumstances. In
> particular, as of
> apiman 1.2.0.Final you will be able to re-publish
> "Public" services
> (now called APIs). So if the API is public then you
> can simply make
> changes and then republish those changes to the
> Gateway. If the API
> is *not* public then the current semantics are the
> same: you cannot
> make changes and republish because that may violate
> contracts that
> consumers have made with your API.
>
> -Eric
>
>
>
> On 12/29/2015 12:19 PM, Sanjay Melinamani wrote:
>
> Hi All,
> I am using APIMAN 1.1.9 and for an existing API
> that I have
> published to
> consumers, I like to change its backend
> implementation end point URL
> without changing the API service version.
> I updated the backend implementation URL in
> database table
> "service_versions". I can see the updated URL from
> UI but still the
> gateway is using the old implementation URL specified.
> Does it cache the implementation URL once the
> service is
> published ? Is
> there anyway I can update the implementation URL
> for an
> existing service?
>
> Appreciate your time and help.
>
> Thanks
> Sanjay
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> <mailto:Apiman-user at lists.jboss.org>
> <mailto:Apiman-user at lists.jboss.org
> <mailto:Apiman-user at lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
More information about the Apiman-user
mailing list