Multiple Java Callouts policies sharing a resources that needs to be updated

mrios
Participant IV

We're using OPDK 18.01 and we have a set of proxies that are using a Java Callout policy. We are going to push the jar use in that policy as a resource at the environment level because it's convenient for us to do releases by environments.

The team that develop the java resource want to be able to do something like:

  1. Release a new version from their jar
  2. Push the new version as a resource to an specific environment in Apigee.
  3. All the current policies that are using the previous version of the resource should be automatically update with the new version that's available. No redeploy of other proxies should be needed

They want 3. because having to redeploy all proxies again will be a multi-team and time consuming effort given that each team has ownership of their own proxies.

One option we thought but we are not sure it's possible is to use a variable in the ResourceUrl tag. Is that possible? Is there any side effect? how long will take to the change to be propagated?

if it's not possible to use a variable, what other options do we have to not be the bottleneck for this use case?

Solved Solved
0 1 417
1 ACCEPTED SOLUTION

I understand your desire.

Unfortunately it is not possible.

You need to redeploy the proxies in order to get the latest version of the JAR attached to the environment.

also it is not possible to use a variable in the ResourceUrl tag.

I think one way to accomplish what you want is to do rolling redeploy of API Proxies that use the updated JAR.

Hmmmm, now that I think of it, not sure it is possible to redeploy the SAME REVISION of an API Proxy. Let me look further.


[Update 2018 Jun 22] After further review and consideration, I'm going to say... don't do that.

I talked to a few other people here and ... my conclusion is I'm not comfortable with the idea of an implicit version update of a library. I'd recommend that you apply a version number to the shared Jar in the environment, eg, library-1.2.3.jar . And then each Java callout would use an IncludeUrl that specifies that version of the jar.

When you want to update the shared jar, load library-1.2.4.jar into the environment, and then add a new revision of each API Proxy that uses the Jar, with an updated Java Callout, that refers to the new version of the shared jar.

There may be some optimizations you can make. For example, aside from the shared resource, there are two other sharing mechanisms in Apigee Edge that may be of interest.

  1. Chained proxies. If the Java callout can or should be wrapped in an API Proxy, you may choose to create a separate proxy, and then have each API proxy that needs the special Java function to call to that "shared" API proxy via a LocalTargetConnection. This would mean you'd contain the Java callout to a SINGLE proxy, and you'd need to update and redeploy as I described above, only on a single item. All of the other API proxies would be unaffected.
  2. Shared Flows. With this mechanism, you can specify a sequence of policies, including Java callouts. A Flow Callout policy from any API proxy would then call out to that sequence. Shared flows have revisions and get deployed just like API Proxies. But they don't listen on virtual hosts; they are not callable externally. Here again, you could contain the Java callout to a SINGLE artifact (the shared flow), and you'd need to update and redeploy as I described above, only on a single artifact. All of the proxies using the shared flow would get the updated behavior.

I really like the latter option for sharing, given what I know about your situation.

View solution in original post

1 REPLY 1

I understand your desire.

Unfortunately it is not possible.

You need to redeploy the proxies in order to get the latest version of the JAR attached to the environment.

also it is not possible to use a variable in the ResourceUrl tag.

I think one way to accomplish what you want is to do rolling redeploy of API Proxies that use the updated JAR.

Hmmmm, now that I think of it, not sure it is possible to redeploy the SAME REVISION of an API Proxy. Let me look further.


[Update 2018 Jun 22] After further review and consideration, I'm going to say... don't do that.

I talked to a few other people here and ... my conclusion is I'm not comfortable with the idea of an implicit version update of a library. I'd recommend that you apply a version number to the shared Jar in the environment, eg, library-1.2.3.jar . And then each Java callout would use an IncludeUrl that specifies that version of the jar.

When you want to update the shared jar, load library-1.2.4.jar into the environment, and then add a new revision of each API Proxy that uses the Jar, with an updated Java Callout, that refers to the new version of the shared jar.

There may be some optimizations you can make. For example, aside from the shared resource, there are two other sharing mechanisms in Apigee Edge that may be of interest.

  1. Chained proxies. If the Java callout can or should be wrapped in an API Proxy, you may choose to create a separate proxy, and then have each API proxy that needs the special Java function to call to that "shared" API proxy via a LocalTargetConnection. This would mean you'd contain the Java callout to a SINGLE proxy, and you'd need to update and redeploy as I described above, only on a single item. All of the other API proxies would be unaffected.
  2. Shared Flows. With this mechanism, you can specify a sequence of policies, including Java callouts. A Flow Callout policy from any API proxy would then call out to that sequence. Shared flows have revisions and get deployed just like API Proxies. But they don't listen on virtual hosts; they are not callable externally. Here again, you could contain the Java callout to a SINGLE artifact (the shared flow), and you'd need to update and redeploy as I described above, only on a single artifact. All of the proxies using the shared flow would get the updated behavior.

I really like the latter option for sharing, given what I know about your situation.