limitations of java code in a Java Callout policy in Apigee

[kairuppala_pras]

Hi,

I have successfully tried Java callout policy having simple Java codes .

Now i am trying to incorporate a complex java code like - which calls a different URL and fetches the data,

but I am getting flow execution error.

I am not able to use a service callout policy as the backend url has a different authentication mechanism.

Any limitations on the complexity of the code that can be incorporated in the Java callout policy?

Thanks in advance!

K.Prashanthi.

UPDATE to this above query: To enable the NTLM authentication to Microsoft SharePoint from APIGEE On-Prem, we are trying this Java Callout Policy. In this Java code we are using Apache HTTPClient Libraries as jars(totally 7 jars).

Inside the Java code, we are calling the on-prem API Proxy of the SharePoint Backend Service. In this case, API Proxy which has this Java Callout and the API Proxy we are calling inside the Java Code are same.

Please provide some idea for the betterment. Thanks!

[#2]

Hi @Prashanthi,

There are no limitations on calling the external URLs, as far as I know. The Java callout restricts you from doing the local IO, but calling external endpoints should be ok.

As long as you package your jar file with required dependencies and the right manifest, you should be able to execute your java code. I usually set context variables in between my java code, to debug and see how far along the code got executed (there might be better ways to do that)

Also, any reason why you are not using Node.js or javascript for your use case? I find the debuggability better when I use javascript/node.js

[DChiesa]

You asked two questions:

1. what are the limitations of Java callouts? Is it possible to make network calls out from Java?
2. Please comment on the design approach of a Java callout calling the API proxy in which it is embedded.

First, the Java callout cannot perform system i/o, including local filesystem i/o, except for limited reading capability on limited directories . The Java callout can read resources from the Jar in which it is embedded. Java code in callouts can also initiate network calls, including network calls made via the Apache commons HttpClient library. Apigee Edge includes commons-httpclient-3.1.jar , which means (a) you don't need to include the commons-httpclient jar in your API proxy bundle, and (b) you should compile against the v3.1 of the library.

You said that you have 7 jars total, but didn't specify which jars. Can you please tell me the jars you are using? I may be able to advise you on other jars as well.

Second, you asked about the design approach. It is a bad idea to have a Java callout initiate a network call to the API proxy which contains it. This can lead to infinite loops or thread starvation. It is only slightly less bad to have a Java callout initiate a call to a different API proxy which is hosted in Edge. If the API Proxy is running on the same message processor, you can still get the snake-swallowing-it's-tail effect. Why not have the Java callout communicate to Sharepoint directly?