How does Java Callout policy update the member variables of the Java code?

Not applicable

A customer who uses Apigee Edge Private Cloud version 15.07 asked me about the API proxy with Java Callout policy which has Java code with some class member variables that is NOT static final.
Then the question is when the API proxy is called by multiple requests at a time, is the member variable overwritten and updated to the value in the latest call?

If so and the customer wants to preserve the variable data respectively for every API request, do they need some sort of storing data for each request?
I found that it's the case for JavaScript callout policy explained at; https://community.apigee.com/articles/7590/execution-time-of-the-policies-in-a-proxy.html

Could someone please advise me?

Regards,
Toshi

Solved Solved
1 2 661
1 ACCEPTED SOLUTION

Yes - you need to set state on the message context.

messageContext.setVariable(variableName, variableValue);

The MessageContext is passed into the execute() method of the callout.

My practice is to derive the variable name from the Java class name, or to use a shorthand. For example a Java callout that parses JWT might use jwt_ as the prefix for any variable it sets. jwt_error, jwt_status, and so on.

Some built-in Apigee Edge policies set variables with names that depend on the name of the policy. For example, AccessEntity sets a variable named AccessEntity.## , where ## is replaced with the name of the policy itself. This dis-ambiguates the output of one AccessEntity policy with the output of another.

Unfortunately I have not found a way for a Java callout policy to use the same approach. In other words, with this policy configuration:

<JavaCallout name='Java-RemoveSoapHeader'>
  <Properties>
    <Property name='xmlns:soap'>http://schemas.xmlsoap.org/soap/envelope/</Property>
    <Property name='xmlns:act'>http://yyyy.com</Property>
    <Property name='source'>request.content</Property>
    <Property name='xpath'>/soap:Envelope/soap:Header</Property>
    <Property name='action'>remove</Property>
  </Properties>
  <ClassName>com.dinochiesa.edgecallouts.EditXmlNode</ClassName>
  <ResourceURL>java://edge-custom-edit-xml-node.jar</ResourceURL>
</JavaCallout>

...there is no way for the Java code to retrieve the value "Java-RemoveSoapHeader".

But that ought not be too difficult a problem to surmount. You can use a property name to set the variable prefix, if necessary.

View solution in original post

2 REPLIES 2

Yes - you need to set state on the message context.

messageContext.setVariable(variableName, variableValue);

The MessageContext is passed into the execute() method of the callout.

My practice is to derive the variable name from the Java class name, or to use a shorthand. For example a Java callout that parses JWT might use jwt_ as the prefix for any variable it sets. jwt_error, jwt_status, and so on.

Some built-in Apigee Edge policies set variables with names that depend on the name of the policy. For example, AccessEntity sets a variable named AccessEntity.## , where ## is replaced with the name of the policy itself. This dis-ambiguates the output of one AccessEntity policy with the output of another.

Unfortunately I have not found a way for a Java callout policy to use the same approach. In other words, with this policy configuration:

<JavaCallout name='Java-RemoveSoapHeader'>
  <Properties>
    <Property name='xmlns:soap'>http://schemas.xmlsoap.org/soap/envelope/</Property>
    <Property name='xmlns:act'>http://yyyy.com</Property>
    <Property name='source'>request.content</Property>
    <Property name='xpath'>/soap:Envelope/soap:Header</Property>
    <Property name='action'>remove</Property>
  </Properties>
  <ClassName>com.dinochiesa.edgecallouts.EditXmlNode</ClassName>
  <ResourceURL>java://edge-custom-edit-xml-node.jar</ResourceURL>
</JavaCallout>

...there is no way for the Java code to retrieve the value "Java-RemoveSoapHeader".

But that ought not be too difficult a problem to surmount. You can use a property name to set the variable prefix, if necessary.

Thank you so much Dino. This would help them to resolve the required spec of handling API requests on Java code and API proxy.