Trigger ServiceCallout in Async in PostFlow

Hi Team, 

I need to trigger a different proxy on the same apigee cluster to take care of some notification stuff in background. And i do not want to wait till that is completed, so wanted to fire and forget the request. 

I thought to use JS policy to just initiate request and proceed, but got to know that we have to use 'LocalTargetConnection' for triggering different proxy in same cluster. 

So, started looking into ServiceCallout and as per some of the threads 'https://www.googlecloudcommunity.com/gc/Apigee/Asynchronous-calls-using-service-callout-policy/td-p/... have removed the Response tag, but i still see that my overall response is waiting for the service callout to resolve, which is not intended. 

Below is my SC Code, 

Show More
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="true" enabled="true" name="Delegate-Callbacks-Callout">
<DisplayName>Delegate Callbacks Callout</DisplayName>
<Properties/>
<Request clearPayload="true">
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<Set>
<Verb>POST</Verb>
<Payload contentType="application/json">{callbackDelegate.request}</Payload>
</Set>
<Copy source="request">
<Headers>
<Header name="authorization"/>
</Headers>
</Copy>
</Request>
<LocalTargetConnection>
<Path>/delegatecallbacks/PlaceOrder</Path>
</LocalTargetConnection>
</ServiceCallout>

Please help me understand if i am missing anything or let me know if i can use JS to trigger call to diff proxy in same cluster. 

Using Apigee X 

 

Solved Solved
0 6 459
1 ACCEPTED SOLUTION

Hey @harishav ,

As far as I know, the ServiceCallout policy blocks the policy flow until getting a response. If you do not care about processing the response, you can place the policy in the PostClientFlow. (see 

https://cloud.google.com/apigee/docs/api-platform/fundamentals/what-are-flows#designingflowexecution...)

When you place a policy in the PostClientFlow, it executes after the main HTTP response has already been sent to the client. While this is not truly async, it does make it appear "Async" as the execution of the policies in the PostClientFlow won't affect the overall latency seen by the caller.
 
Before running the ServiceCallout policy in the PostClientFlow, you would need to setup flow variables ahead of time (in other flows) that will be used as the payload for the ServiceCallout.
 
 

View solution in original post

6 REPLIES 6

Hey @harishav ,

As far as I know, the ServiceCallout policy blocks the policy flow until getting a response. If you do not care about processing the response, you can place the policy in the PostClientFlow. (see 

https://cloud.google.com/apigee/docs/api-platform/fundamentals/what-are-flows#designingflowexecution...)

When you place a policy in the PostClientFlow, it executes after the main HTTP response has already been sent to the client. While this is not truly async, it does make it appear "Async" as the execution of the policies in the PostClientFlow won't affect the overall latency seen by the caller.
 
Before running the ServiceCallout policy in the PostClientFlow, you would need to setup flow variables ahead of time (in other flows) that will be used as the payload for the ServiceCallout.
 
 

As far as I know, the ServiceCallout policy blocks the policy flow until getting a response.

The ServiceCallout policy will block:

  • until it sends the request, if there is no Response element in the policy config
  • until it receives a response, if there is a Response element in the policy config.

Hi @dchiesa1 ,

Yes, that's what even i learnt based on the docs and other community post that you have answered on the same lines. But somehow that didn't worked for me and the new way suggested works so went ahead with that 

But somehow that didn't worked for me and the new way suggested works so went ahead with that

I'm glad you got it sorted out. I was not suggesting a different way or an alternative from what Miguel suggested. I was just attempting to add some clarifying information.

Thank you so much @miguelmendoza , moving the service callout to PostClientFlow solved the issues. You saved my day! 

Thanks again! 

Everyone should consider this, when using ServiceCallout for logging.