Hmm, that's interesting.
I think the policy is refusing to write those variables because the variables already exist. This may be "working as intended" though I understand it is not convenient for what you want to do. Also I cannot see the downside to allowing it to overwrite the existing variables, so even if WAI, it is arguably a bug in the design, and should be changed. In the meantime, I can suggest:
- use a different name on the AccessEntity policy, so you can get a different set of variables on output. In other words, two different policy names.
- try to reset the variable AccessEntity.AE-GetProductInformation with an AssignMessage/AssignVariable setting it to remove the variable. I am not sure how this would work because there is no AssignMessage/RemoveVariable element.
- If you are using X or hybrid, use <OutputFormat>JSON</OutputFormat> to get the output in a JSON format. And RESET that single variable between the distinct calls to AccessEntity. In that case you may avoid the "failure to set variable" problem. Not sure, haven't tested this. This configuration element is not supported in Edge, afaik.
- Write a Java callout to manually remove all the variables of the form AccessEntity.POLICYNAME.xxxxx , and insert this Java callout between the two calls to AccessEntity. Today, as far as I am aware, there is no way to remove a context variable, or to set it to null, using builtin policies. The Java callout can remove variables though. The challenge here is, I think, it will not be possible to do the general thing, "remove all variables starting with the prefix AccessEntity.AE-GetProductInfo". You have to know exactly which variables you want to remove. And there is also no way to inquire "tell me all the variables that start with AccessEntity.AE-GetProductInfo", so you cannot build iterating logic in your Java callout to do what you want. The issue here is that there will be different variables set, depending on the entity. If you have custom attributes on the product, then AccessEntity will set variables that have names that end in the name of the custom attribute. And that will vary for each API product. There's no way to "clear out" all that stuff automatically. This problem of all the myriad variables being set... goes away if you use JSON format as the output. In that case there is only one variable - the toplevel variable - that is set.
A true solution here is to add capability to the AccessEntity, or modify its default behavior, so that it overwrites the variables - it just does what you want. I don't know why it would have been designed in the way it was designed, to make them "read only".
But let me step back - what is the reason you need to call AccessEntity twice, on two distinct API products? What are you really trying to do?
LinkedIn
Twitter
