Add support for caching in Flows

[jongpie]

[jefersonchaves]

Are you considering adding Flow Apex Action(s) to put and get items from the cache to expose a portion of the cache into Flows?

[jongpie]

@jefersonchaves yeah, the idea is to add Apex invocable actions that can by used in Flow to put and get cache values. I meant to add details to the description of this issue, but I guess I never did 😅

Since you can have only 1 invocable method per class, and invocable methods don't support generic Object data type, I think it would have to be 2 invocable actions per data type (1 invocable for put, 1 for get). Ideally, it should support retrieving/adding singular and collection values (like String and List<String>)

I haven't spent much time exploring this, but my original thought was to have something like this for each primitive data type:

public class FlowStringCacheAdder {
    public class FlowInput {
        @InvocableVariable(required=true)
        public String cacheKey;
        @InvocableVariable(required=true)
        public String cacheType;
        @InvocableVariable(required=true)
        public String cacheValue;
    }

    public static void execute(List<FlowInput> cacheKeys) {
        for (FlowInput input : inputs) {
            CacheManager.getOrganizationCache().put(input.cacheKey, input.cacheValue);
        }
    }
}

And for retrieving the values...

public class FlowStringCacheGetter {
    public class FlowInput {
        @InvocableVariable(required=true)
        public String cacheKey;
        @InvocableVariable(required=true)
        public String cacheType;
    }

    public static List<String> execute(List<FlowInput> inputs) {
        List<String> cachedValues = new List<String>();
        for (FlowInput input : inputs) {
            CacheManager.getOrganizationCache().get(input.cacheKey);
        }
        return cachedValues;
    }
}

Let me know if you think this pattern/approach makes sense.

[jefersonchaves]

That is interesting because it may be four classes per Data Type (due to the Flow Apex Action structure):

• Get String.
• Put String.
• Get List<String>.
• Put List<String>.

This makes me wonder if this is the right path or if we should do it differently: primarily due to Custom Data Types - which can be handy but maybe not so much in Flows. I'm not fond of using JSON serialization to bypass it due to excessive CPU consumption.

Perhaps a top-level class for Get and another for Put with optional variables may work better also because I'm thinking about finding the correct Action on the toolbar.

This way it may end up with two with multiple optional inputs and returns:

• Put with optional input:
  • String
  • List<String>
  • Decimal
  • List<Decimal
  • SObject
  • List<SObject>
• Get with optional return:
  • [Same as 'Put' above]
  • Data type to retrieve (e.g. String, or List<String>).

Another option would be to wrap some of it for Flows, but that is what I'm trying to stay away.

[jongpie]

@jefersonchaves I agree that having 4 classes per data type is a lot of classes, but it feels like the more intuitive & scalable approach overall. My concerns with the approach of a top-level class for Get and another for Put with optional variables are:

1. Having optional parameters could lead to more human error when configuring the action - admins might accidentally select the wrong input/output. With separate classes (1 class per data type + cache action), only relevant properties would need to be included (and inputs could be marked as required)
2. It isn't a scalable design - I want admins/developers to be able to add support for additional data types in their orgs (such as instances of their own Apex classes, etc). With 1 Get and 1 Put class....
   1. Admins/developers could update the Get and Put classes to add the new data types, but that would then prevent them from upgrading to new versions of Nebula Cache Manager's unlocked packages
   2. Admins/developers could create their own Get and Put classes for their own custom data types, but then the UX for people using the Flow actions is inconsistent in their org - they would have to know to use the included Get action for , but use a different action(s) for any custom data types in their orgs. With the approach of 1 class per data type + cache action, orgs that add their own custom classes would provided the same experience in Flow Builder when selecting a caching action

I think there are definitely pros & cons with both options - I'm hoping to build some proof-of-concepts in the coming weeks to see how they compare.