getting a little frustrated here 🙂
Sorry to hear that.
@razor wrote:
I need to grab some headers that only exist in the Client request, before it is modified by any API Proxy,
But I am also interested in headers and body that will be sent to the client after the target backend server replies etc... In other words, I believe I have to use both Pre-Proxy and Post-Proxy Flowhooks.
I want to gather some data from the request, store it somewhere until the response arrives, gather some data from response, apply some logic, and communicate with external server. This has to happen for each transaction on any API Proxy affected by the flow hook.
- Is storing data on messageContext.setVariable("somekey", "somedata") the right way? Is messageContext unique per session?
MessageContext is unique per inbound message (or request). There is no "session" concept in Apigee. It is ok to store values into the message context with .setVariable(). If you attach a Java callout that executes in the PRe-Proxy flow hook, and stores headers into context, then ... you will be able to retrieve those values later in a different policy that runs in the post-proxy flow hook.
- Should "executionContext.isRequestFlow()" be working for me? It always returns true.
Maybe because your Java callout is always attached to the request flow? I dunno, it's hard to say.
- Running a debug session, I see variable and properties such as:
proxy.flow.name / current.flow.name etc...
Trying to access these from messageContext.getVariable("proxy.flow.name") or messageContext.getVariable("{proxy.flow.name}") (also current.flow.name) and other combinations never return a value.
What am I doing wrong?
I don't know. That should work. Variable names do not begin and end with curly braces. Getting "{proxy.flow.name}" is wrong. Retrieving the values of the bare names looks right to me. "current.flow.name" might return empty/null, if running in a flow hook! The flow name is the name of the conditional flow. In a flowhook you're not in a conditional flow.
@razor wrote:
I have seen the solution by @dino where a wrapper function first check the properties provided by the policy on instantiation, and it returns a curly braced string, fetch it using getVariable. It doesn't work for me.
I'm sorry to hear that doesn't work for you. I know what you're referring to, and it's pretty basic stuff. Something else is wrong with what you are trying.
You didn't provide many specifics about what you are doing. The Java code and the policy configuration. So it's hard to diagnose. I suggest that you start from the basics. Just start with a very basic Java callout. If you want the "resolve properties to context variables" thing, then go ahead and add that. Take it one step at a time. You can start with this example: https://github.com/DinoChiesa/ApigeeEdge-JavaCallout101
Stepping back, aside from the specific challenges you are facing with the Java callout, I think maybe you are asking too much of the Java callout mechanism. The thing you are imagining , read request and response headers and then communicate with some other REST service, is best done in... an API Proxy.... or in an External service like one you might attach via ExternalCallout. The JavaCallout is not a good mechanism in which to wrap external communication. Don't do that. Use the JavaCallout to wrap compute tasks - like decoding, encoding, signing, decrypting, hashing, digests, and that sort of thing. Manipulating or analyzing the message context, including headers, payloads, etc. If you want to communicate to an external system, I suggest that you encapsulate all of that into a separate microservice, and connect to it from the API proxy via grpc. This is possible via the ExternalCallout policy. It will be fast.
What exactly are you doing with the "connect to an external rest service" anyway? What is the point of that thing?
LinkedIn
Twitter
