Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

AssignMessage SET request values missing in Target request if JavaCallout is in between

I was trying Dino's AWS Signing V4 - Java callout.  In Target Request Pre-flow:

1. I was using AssignMessage to prepare request.

<AssignMessage continueOnError="false" enabled="true" name="AM-ConstructBackendRequest">
  <DisplayName>AM-ConstructBackendRequest</DisplayName>
  <Properties/>
  <Remove/>
  <Set>
    <Headers>
      <Header name="x-id">{private.id}</Header>
      <Header name="x-scopes">Data.Read</Header>
      <Header name="x-no-of-rows">12</Header>
    </Headers>
    <QueryParams>
      <QueryParam name="from-date">{fromDate}</QueryParam>
      <QueryParam name="to-date">{toDate}</QueryParam>
    </QueryParams>
    <Verb>GET</Verb>
    <Path>/</Path>
  </Set>
  <AssignTo createNew="true" transport="http" type="request">lambdaRequest</AssignTo>
</AssignMessage>
 
2. In AWS Signing Java callout, I refer lambdaRequest as source.
 
In the AssignMessage I have tried createNew="false" or using <AssignTo>Request</AssignTo>.. In debug, I could see the AssignMessage setting all headers; but once JavaCallout is executed, it only sets the signing headers set by Java callout.  When the request is sent to Target server, the headers set in the AssignMessage are missing.  
 
I had to create a new request object (createNew="true"), and after Javacallout, copy that object into request using another AssignMessage policy step(after removing all existing request parameters with <Remove/>).   Can you please check it out; looks like this problem is there in other callouts as well (tried Python callout, it also seem to reset the values).  Looks like this is specific to Target request; because the example for AWSSigning uses ServiceCallout - am sure that would have been tested.  The same sequence for Target request is not working.
 
Thanks,
Muthu  
 
 
Solved Solved
1 5 260
1 ACCEPTED SOLUTION

That's strange. When I try it on my Apigee X instance, it works as I would expect:  AssignMessage sets headers, the Java callout sets additional headers and signs things (including the original headers), and ... the target gets all of the headers.

For my test proxy, I used an "echo" target , which just echo's back what it receives. In the response I can see that the target has received all the headers. 

$ curl -i $endpoint/muthu-20230919/t1 
HTTP/2 200 
version: 20230113-1204
content-type: application/json; charset=utf-8
etag: W/"365-ruPUZhM1ePIvc+0zfzEUEMc6O00"
x-cloud-trace-context: b9baabc0a526e23dc78dfa9a19a00d73
date: Tue, 19 Sep 2023 16:38:38 GMT
content-length: 869
apiproxy: muthu-20230919 r1
x-request-id: 24e6fee8-330e-492b-a7d4-d8f698a2cdd4
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{
  "url": "/t1?from-date=10-08-2023&to-date=15-08-2023",
  "method": "GET",
  "headers": {
    "host": "example.demo.altostrat.com",
    "x-id": "123456",
    "x-scopes": "Data.Read",
    "x-no-of-rows": "12",
    "x-amz-date": "20230919T163838Z",
    "authorization": "AWS4-HMAC-SHA256 Credential=xWxTestKeyxWx/20230919/ap-south-1/lambda/aws4_request, SignedHeaders=host;x-amz-date;x-id;x-no-of-rows;x-scopes, Signature=20ee3afde9222f4f4cef8cc1c5f215eaadb571b05907d82c397dfbc7b609b139",
    "x-cloud-trace-context": "b9baabc0a526e23dc78dfa9a19a00d73/14516245761368739297",
    "traceparent": "00-b9baabc0a526e23dc78dfa9a19a00d73-c974109c0ea74de1-00",
    "x-forwarded-for": "0.0.0.0",
    "x-forwarded-proto": "https",
    "forwarded": "for=\"0.0.0.0\";proto=https"
  },
  "query": {
    "from-date": "10-08-2023",
    "to-date": "15-08-2023"
  },
  "body": {}
}%                                                                        

Attached please find my test proxy. You will need to configure your own echo service in the target. 

 

View solution in original post

5 REPLIES 5
Top Solution Authors