Access a property set in a shared flow

Hi,

We've extracted some common logic which is reused across different proxies to a shared flow. This shared flow access certain configuration in a property set. This configuration does not change between proxies, so the properties file lives in the shared flow bundle, or at least that was our intention. The reality is that this doesn't work, and a policy in the shared flow can only read a property set in the actual proxy, thus forcing us to replicate the property set, which doesn't change, across all proxies that use the shared flow.

Is this by design? Is it a bug? Wouldn't be more appropriate if this worked in a hierarchical way in which the property set could live in the shared flow but, if also present in the proxy, the property values get overridden by the ones in the property set that lives in the proxy?

Thanks.

Solved Solved
1 4 780
1 ACCEPTED SOLUTION

From the description you provided, it sounds like it's both "by design" and "a bug", a design bug.

Wouldn't be more appropriate if this worked in a hierarchical way in which the property set could live in the shared flow but, if also present in the proxy, the property values get overridden by the ones in the property set that lives in the proxy?

That's an interesting idea. We'll need to discuss this.

In the meantime, you have a workaround: store the propertyset at the Environment-scope. In that case, a sharedflow can reference the propertyset.

To distinguish the configuration for the shared flow from the configuration for other things, You can either

  • use a specific name for the propertyset, for this sharedflow.
  • Use a specific set of keynames in the propertyset for this sharedflow

View solution in original post

4 REPLIES 4

From the description you provided, it sounds like it's both "by design" and "a bug", a design bug.

Wouldn't be more appropriate if this worked in a hierarchical way in which the property set could live in the shared flow but, if also present in the proxy, the property values get overridden by the ones in the property set that lives in the proxy?

That's an interesting idea. We'll need to discuss this.

In the meantime, you have a workaround: store the propertyset at the Environment-scope. In that case, a sharedflow can reference the propertyset.

To distinguish the configuration for the shared flow from the configuration for other things, You can either

  • use a specific name for the propertyset, for this sharedflow.
  • Use a specific set of keynames in the propertyset for this sharedflow

Hi @dchiesa1 , hope you're doing well.

Is there any news on the possibility to have a propertyset into the shared flow -not at the Environment scope- ? We're in the same use case than @danielfrancisco.

At least, the propertysets in the shared flow would be accessed only in the shared flow to set env variables

Many thanks for the update

Merry christmas

In the context of API management and platforms like Apigee, a shared flow is a reusable set of policies and resources that can be applied across multiple API proxies. Shared flows are used to encapsulate common functionalities, such as security checks or logging, and are applied to requests or responses as they flow through an API proxy.

To access a property set in a shared flow, you typically use the context object, which provides a way to store and retrieve data during the execution of the API flow. Here's a general outline of how you might access a property set in a shared flow:

  1. Set Property in Shared Flow: In your shared flow, you would use a policy like "AssignMessage" or "Set Variable" to set a property. For example, you might set a property named "customProperty" with a value.

    xmlCopy code
    <!-- Example AssignMessage policy in Shared Flow --> <AssignMessage name="SetCustomProperty"> <Set> <Headers> <Header name="customProperty">{your_value_here}</Header> </Headers> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </AssignMessage>
  2. Access Property in API Proxy Flow: In your API proxy, you can then access this property from the shared flow using the context variable. The context variable provides access to various elements, including headers, query parameters, and properties set in shared flows.

    xmlCopy code
    <!-- Example Accessing Property in API Proxy --> <AssignMessage name="AccessSharedFlowProperty"> <Set> <Headers> <Header name="customProperty">{context.sharedflow.name_of_shared_flow_variable}</Header> </Headers> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </AssignMessage>

Replace {your_value_here} and {context.sharedflow.name_of_shared_flow_variable} with your actual values and variable names.

Remember that the specifics may vary depending on the version of Apigee or the exact policies you are using. Always refer to the documentation for your specific version for accurate and detailed information...............................

 
 

Hi @markWyatt 

Are you talking about propertySets ? => https://cloud.google.com/apigee/docs/api-platform/cache/property-sets

I have propertySets + AssignMessages in a sharedflow 

like :
  <AssignVariable>
   
<Name>flow_variable</Name>
   
<PropertySetRef>{request.header.propset_name}.{request.header.propset_key}</PropertySetRef>
 
</AssignVariable>
But at runtime with debug tool, I can see all variables like flow_variable remain empty.