Assign Message Issue in Target PreFlow Response

I am storing the request "Accept and Content-Type" header in variables and changing it to "application/json" while firing the target service. Post target response ( success or fault ) I am looking to reassign the request "Accept and Content-Type" header back to initial value.For this I have created a Assign Message policy as given below and placed it in target response preflow.

<AssignMessage name="AM-ResetRequestHeaders"> 
  <Set> 
    <Headers> 
      <Header name="Accept">{api.Accept}</Header> 
      <Header name="Content-Type">{api.Content-Type}</Header> 
    </Headers> 
  </Set> 
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> 
  <AssignTo createNew="false" transport="http" type="request"/> 
</AssignMessage>

Though I am trying to operate on request object and not the response object, it is always setting values for response instead of request. Is it as designed or expected behavior? Or I am missing something else to make it work with request instead of response in target flows.

8947-trace-screenshot.png

0 1 134
1 REPLY 1

Though I am trying to operate on request object and not the response object, it is always setting values for response instead of request. Is it as designed or expected behavior?

Yes, this is the expected behavior given the configuration you provided. You have:

  <AssignTo createNew="false" transport="http" type="request"/>

The AssignTo element specifies which "message" the AssignMessage policy will modify. In your case you have not specified any message at all; the text value of the AssignTo element is empty. What you have configured is equivalent to

  <AssignTo createNew="false" transport="http" type="request"></AssignTo>

Do you see? It's empty.

With an empty value for the AssignTo, the AssignMessage policy is operating on the current default message which is "message" and in the target flow, that equates to "response." Had you attached that same policy in the request flow, it would have operated on the request message.

If you want to always have the policy operate on the request message, you must specify it:

  <AssignTo>request</AssignTo>

Some further comments: The createNew attribute is used in case the specified message variable does not exist. But the "request" message always exist, so createNew is inoperable. The transport is a throwback and is not meaningful in any way, though the policy UI still suggests it. Finally the type= attribute is used when creating a new message. Since you never want to create a new message, that type attribute is inoperable also.