AssignMessage policy ignores value of type attribute

Not applicable

I am attempting to set to custom headers using AssignMessage policy in the response flow of PostFlow in my API proxy. Though I have incorrectly specified request as the object in the type attribute of AssignTo element in the configuration, Apigee adds the headers in the response message. Is it expected behavior by design? I thought type="response" would be the necessary configuration for this purpose.

<AssignMessage name="Assign-Message-1">
    <DisplayName>Assign Message-1</DisplayName>
    <Properties/>
    <Add>
        <Headers>
            <Header name="X-DEPRECATED">No</Header>
            <Header name="X-MSG-ID">sampleguid</Header>
        </Headers>
    </Add>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo type="request" createNew="false" transport="http"/>
</AssignMessage>
Solved Solved
1 2 304
1 ACCEPTED SOLUTION

Hmm, yes, Thanks for the report! I've just observed the same behavior.

My first inclination was to say, "yes, that seems like a bug."

Upon further consideration, this behavior is "as designed". It may be a little bit surprising, but it's designed to behave that way, and I believe it's documented to behave that way as well.

Here's why: to specify the message to which the AssignMessage should apply, we use the AssignTo element. If we want to assign to the request message, we do it this way:

<AssignTo>request</AssignTo>

Notice the "request" text value inside that XML element.

If we want to assign to response, then replace "request" with "response", above.

If you omit the AssignTo element, or include the element but do not specify a text value, like this:

<AssignTo/>

... the AssignMessage applies to "the ambient message". In the request flow, that's the request message. In the response flow, that's the response message. This is the case you're seeing.

There are some attributes that apply to the AssignTo element In the special case in which you wish to create a new message. These are type, and createNew. Only when createNew is true, is the type attribute considered.

If you omit the text value of the AssignTo element, and include the attributes, the attributes are ignored; they are meaningless. If createNew is present, and false, then type is ignored.

The transport attribute is in any case ignored.

Your form was:

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

...which is equivalent to

<AssignTo/>

That says, "assign to the ambient message".

So I think what you are observing is expected behavior. If you think the documentation could be improved to make this behavior clearer, let me know, and we'll see if we can improve it.

Here are some configurations for this one element, and the expected behavior from them:

config behavior
<AssignTo>request</AssignTo>
		
assigns to request.
<AssignTo/>
		
assigns to ambient message. (Depends on where the policy is attached)
<AssignTo>response</AssignTo>
		
assigns to response message.
-no AssignTo element- assigns to ambient message.
<AssignTo type="request" createNew="false" transport="http"/>
		
assigns to ambient message. the type attribute is ignored.
<AssignTo>msg1</AssignTo>
		
assigns to msg1, if it exists. If it does not exist, then runtime error (fault).
<AssignTo createNew='true'>request</AssignTo>
		
runtime error (fault). I think!
If createNew is true, then the element
needs a type, which should be either
request or response. It's possible that
the type defaults; not sure. But anyway
it seems sloppy, so don't do this.
<AssignTo createNew='true' type='request'>request</AssignTo>
		
The "request" message gets overwritten with a new request message.
<AssignTo createNew='true' type='response'>request</AssignTo>
		
The "request" message gets overwritten with a new response message. This is possible, but it seems really confusing, so don't do it.
<AssignTo createNew='true' type='response'/>
		
Not sure. Maybe this will work, and maybe not. But it's a bad idea. If you want to create a new message, you should specify the name of the to-be-created message.

View solution in original post

2 REPLIES 2

Hmm, yes, Thanks for the report! I've just observed the same behavior.

My first inclination was to say, "yes, that seems like a bug."

Upon further consideration, this behavior is "as designed". It may be a little bit surprising, but it's designed to behave that way, and I believe it's documented to behave that way as well.

Here's why: to specify the message to which the AssignMessage should apply, we use the AssignTo element. If we want to assign to the request message, we do it this way:

<AssignTo>request</AssignTo>

Notice the "request" text value inside that XML element.

If we want to assign to response, then replace "request" with "response", above.

If you omit the AssignTo element, or include the element but do not specify a text value, like this:

<AssignTo/>

... the AssignMessage applies to "the ambient message". In the request flow, that's the request message. In the response flow, that's the response message. This is the case you're seeing.

There are some attributes that apply to the AssignTo element In the special case in which you wish to create a new message. These are type, and createNew. Only when createNew is true, is the type attribute considered.

If you omit the text value of the AssignTo element, and include the attributes, the attributes are ignored; they are meaningless. If createNew is present, and false, then type is ignored.

The transport attribute is in any case ignored.

Your form was:

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

...which is equivalent to

<AssignTo/>

That says, "assign to the ambient message".

So I think what you are observing is expected behavior. If you think the documentation could be improved to make this behavior clearer, let me know, and we'll see if we can improve it.

Here are some configurations for this one element, and the expected behavior from them:

config behavior
<AssignTo>request</AssignTo>
		
assigns to request.
<AssignTo/>
		
assigns to ambient message. (Depends on where the policy is attached)
<AssignTo>response</AssignTo>
		
assigns to response message.
-no AssignTo element- assigns to ambient message.
<AssignTo type="request" createNew="false" transport="http"/>
		
assigns to ambient message. the type attribute is ignored.
<AssignTo>msg1</AssignTo>
		
assigns to msg1, if it exists. If it does not exist, then runtime error (fault).
<AssignTo createNew='true'>request</AssignTo>
		
runtime error (fault). I think!
If createNew is true, then the element
needs a type, which should be either
request or response. It's possible that
the type defaults; not sure. But anyway
it seems sloppy, so don't do this.
<AssignTo createNew='true' type='request'>request</AssignTo>
		
The "request" message gets overwritten with a new request message.
<AssignTo createNew='true' type='response'>request</AssignTo>
		
The "request" message gets overwritten with a new response message. This is possible, but it seems really confusing, so don't do it.
<AssignTo createNew='true' type='response'/>
		
Not sure. Maybe this will work, and maybe not. But it's a bad idea. If you want to create a new message, you should specify the name of the to-be-created message.

Thank you, Dino. Appreciate your detailed response.