I have CNAME registered in AWS to transfer traffic between below two Orgs with weighted routing. Could someone suggest me on how to route the traffic from "app1.dev.org.com" to "dev.nip.io/app1" in apigee?
I'm not clear on the problem. It sounds like you have AWS DNS (Maybe Route53?) set up. And you can do the weighted routing. You have 2 Apigee orgs, each with a distinct hostname. So... is this not just a Route53 problem?
The Apigee issue comes in when you have APIKeys or Opaque tokens, issued by Apigee.
Let's look at a couple scenarios. Scenario 1:
- clientA has no token
- clientA connects through AWS (Route53) and gets the hostname for dev.nip.io
- clientA sends its request-for-token, along with its client credentials (client id + secret), to dev.nip.io.
- the proxy at Org1 receives the request, validates credentials, creates a new token, and sends an opaque access token in response.
- clientA then sends its token in with a request for service. It uses the cached host and IP address.
- clientA sends its request to dev.nip.io. The Apigee org there (Org1) validates the token and allows the request.
- Some time passes. The token expires. clientA wants a new token. clientA does a lookup on the hostname, this time Route53 tells it to use dev-new.nip.io
- clientA sends its request-for-token, along with its client credentials (client id + secret), to dev-new.nip.io.
- the proxy at Org2 receives the request, tries to validate credentials, fails because it does not know about those client credentials. No token.
Scenario 2:
- clientA has no token
- clientA connects through AWS (Route53) and gets the hostname for dev.nip.io
- clientA sends its request-for-token, along with its client credentials (client id + secret), to dev.nip.io.
- the proxy at Org1 receives the request, validates credentials, creates a new token, and sends an opaque access token in response.
- Some time passes. clientA then sends its token in with a request for service. Route53 now resolves the DNS name to dev-new.nip.io.
- clientA sends its request to dev-new.nip.io. The Apigee org there (Org2) knows nothing about the token issued by Org1. Invalid Access Token.
These are just two potential pitfalls when migrating from one org to another.
To manage through scenario 1, you can duplicate (copy) the credentials from Org1 to Org2. There are "org export/import" scripts and tools to help with this. This prior community Q&A discusses a good one.
Managing through scenario 2 is harder. To manage this, you need org1 and org2 to be always synchronized. First you need the client credentials to be copied, as above. But also, you need the orgs to be connected at runtime, such that when org1 creates a token, it sends the token to org2, live, right now, so that org2 can ingest it. Now the same token is valid in both organizations. Even then, if you have things like rate limits by token, that will fail, because org1 and org2 will have distinct rate limits. And what happens if the token gets created by org2? Do you want to replicate back to org1? Probably not. So you need to distinguish between tokens at the router, and if it's an org2-native token, route only and always to org2. If it's an org1 token, the request can go to either org1 or org2.
As you can guess from this brief explanation, managing through the second scenario is possible, but expensive in terms of time and attention and testing effort. It might be more feasible to simply schedule a maintenance window, at which point you switchover the traffic from org1 to org2. At that point tokens held by all clients will be invalid, but they all should be coded to get a new token, if you've copied the client credentials. (even refresh tokens will not work - be aware.)
Which approach you take will depend on your business requirements.
You might want to seek help from one of the Apigee services partners who have done large-scale migrations like this and understand the pros/cons and how to execute a plan successfully. Benefit from their experience.
LinkedIn
Twitter
