How can I pass parameters to a Flow Callout Policy?

Not applicable

I want to create a Shared Flow that puts something in the cache and makes a call to slack, but depending on given parameters the text in the call to slack and the key for the cache should be different.

I've looked at http://docs.apigee.com/api-services/reference/flow-callout-policy but I haven't seen how to add a variable.

Can I use <AssignVariable> like in the Assign Message Policy?

Solved Solved
2 5 4,690
1 ACCEPTED SOLUTION

FYI,

Apigee has added an enhancement to the FlowCallout to allow explicit parameterization of the callout. The reference is b/74750586 .

Usage is like this:

<FlowCallout name="FC-MySharedFlow">
    <Parameters>
        <Parameter name="input1" value='FOO'/>
        <Parameter name="input2" ref='request.header.bar'/>
        <Parameter name="destination">FOO</Parameter>
        <Parameter name="tmplvalue">{request.header.foo}</Parameter>
    </Parameters>
    <SharedFlowBundle>MySharedFlow</SharedFlowBundle>
</FlowCallout>

The effect is that the execution of the sharedflow will begin with a new set of context variables, corresponding to the set of Parameter elements. They're just normal context variables, so within policies inside the sharedflow, you can access those context variables as you would normally. Eg., in a JavaScript policy within MySharedFlow you could

var input1 = context.getVariable("input1");
var destination = context.getVariable("destination");
var value = context.getVariable('tmplvalue');
context.setVariable(destination, value.toLowerCase()); 

As you can see from the sample configuration, there are a number of options for specifying the value for each Parameter.

  1. specify the value with a value= attribute. This is a fixed value.
  2. Specify the value with a ref= attribute, which refers to a different variable.
  3. specify the value with a text value of the node. This is actually a Message Template, so you get curly-braced variable dereferencing and the Message Template functions too.

If you repeat a Parameter name, the behavior is not defined.

Special note: If context variables with those names already exist , they are temporarily overwritten with new values. When the SharedFlow completes, the former values of these context variables are restored.

I'll link to the official documentation when it becomes available.

This should be available in the cloud soon.

This isn't a huge new feature, but it is a nice ease-of-use thing. It will make it easier to explicitly see the intended inputs to a FlowCallout invocation.

View solution in original post

5 REPLIES 5

@Friso Denijs ,

Apigee flow variables you can access from shared flows too. You can set a custom variable using Assign Message Policy & access same like any other flow variable in shared flow. It should be similar to using the flow variable in the same proxy.

For example, See attached proxy & shared flow. I have used Assign Message Policy in proxy to set custom variables & accessed same in Javascript policy inside shared flow.

Proxy : no-target-7-rev1-2017-06-14.zip

Shared Flow : printvariablefromproxy-rev1-2017-06-14.zip

Assign Message Policy :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="Assign-Message-1">
    <DisplayName>Assign Message-1</DisplayName>
    <Properties/>
    <AssignVariable>
        <Name>flowVariable.myKey</Name>
        <Value>hello</Value>
    </AssignVariable>
    <AssignVariable>
        <Name>flowVariable.myValue</Name>
        <Value>world</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

You can also do dynamic reference to values using Ref in assign message policy, For more details please see policy documentation here.

5120-apigee4mv4d-apigee.png

Hi Anil,

Thanks for the explanation and example.But when I am trying to print the variable value, defined in Assignmessage Policy , getting "null" in tracing.

Can you maybe post a new question explaining your problem?

FYI,

Apigee has added an enhancement to the FlowCallout to allow explicit parameterization of the callout. The reference is b/74750586 .

Usage is like this:

<FlowCallout name="FC-MySharedFlow">
    <Parameters>
        <Parameter name="input1" value='FOO'/>
        <Parameter name="input2" ref='request.header.bar'/>
        <Parameter name="destination">FOO</Parameter>
        <Parameter name="tmplvalue">{request.header.foo}</Parameter>
    </Parameters>
    <SharedFlowBundle>MySharedFlow</SharedFlowBundle>
</FlowCallout>

The effect is that the execution of the sharedflow will begin with a new set of context variables, corresponding to the set of Parameter elements. They're just normal context variables, so within policies inside the sharedflow, you can access those context variables as you would normally. Eg., in a JavaScript policy within MySharedFlow you could

var input1 = context.getVariable("input1");
var destination = context.getVariable("destination");
var value = context.getVariable('tmplvalue');
context.setVariable(destination, value.toLowerCase()); 

As you can see from the sample configuration, there are a number of options for specifying the value for each Parameter.

  1. specify the value with a value= attribute. This is a fixed value.
  2. Specify the value with a ref= attribute, which refers to a different variable.
  3. specify the value with a text value of the node. This is actually a Message Template, so you get curly-braced variable dereferencing and the Message Template functions too.

If you repeat a Parameter name, the behavior is not defined.

Special note: If context variables with those names already exist , they are temporarily overwritten with new values. When the SharedFlow completes, the former values of these context variables are restored.

I'll link to the official documentation when it becomes available.

This should be available in the cloud soon.

This isn't a huge new feature, but it is a nice ease-of-use thing. It will make it easier to explicitly see the intended inputs to a FlowCallout invocation.

olgunkaya
Participant II

Hi @dchiesa1 

Thanks for the explanation but, how can I access these parameters from the shared flow via references ? I mean;

I call the shared flow via and it fails. Since the parameters does not exist in shared flow runtime and status code can not be null. Other parameters are also null.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<FlowCallout continueOnError="false" enabled="true" name="SpikeErrorResponse">
    <DisplayName>SpikeErrorResponse</DisplayName>
    <FaultRules/>
    <Parameters>
        <Parameter name="my.error.code">MESSAGE_SPIKE_ERROR</Parameter>
        <Parameter name="my.error.message">Too many request in 1 minute-shared</Parameter>
        <Parameter name="my.error.type">SPIKE</Parameter>
        <Parameter name="my.error.statusCode">429</Parameter>
    </Parameters>
    <SharedFlowBundle>error-response</SharedFlowBundle>
</FlowCallout>

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault continueOnError="false" enabled="true" name="error-response">
    <DisplayName>error-response</DisplayName>
    <Properties/>
    <FaultResponse>
        <Set>
            <Headers/>
            <Payload contentType="application/json">
              {
                "errors" : [ 
                    {
                        "code"    : "{my.error.code}",
                        "message" : "{my.error.message}",
                        "type"    : "{my.error.type}"
                    }
                ]
              }
             </Payload>
            <StatusCode>{my.error.statusCode}</StatusCode>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>