Hi Andreas,
What is the reason you chose a calculated attribute?
Easiest way to solve this is by turning the attribute into a normal attribute, and add the flow which returns the string behind your REST call.
Advantage of this is that you actually have control over the amount of times the attribute is calculated. Since you don't have that control for a calculated attribute I would never suggest to use a calculated attribute.
Hope this helps!
Hi Ward,
I choose the calculated attribute because I want to translate the value of my variable “programmCurrent” from int to string and depending from the value, the string variable should be different. For example, if the int = 128 then the new variable should be “on” and if the int = 256 then the new variable should be off.
I think I need the calculated attribute for this, or am I wrong with this?
best regards
And do you still know, why the calculated attribute is not shown?
Because you are using non persistent objects and those are only client side available. So unless you are in the same session as the user that is using the webservice you will never be able to see those. Make it a non persistent object and do the test again.
Regards,
Ronald
Hello Ronald,
I changed the obekt to persitable but id doesn’t matter. I can’t choose the calculated attribute at all..
In my list view widget or time series widget I can just see the normal attributes..
I am not able to choose the calculated attribute to display data.
You can calculate the variable after rest call:
If you choose to commit the objects returned by the REST call, you can also go for event handlers on the entity itself that will modify your chosen fields on a certain event, e.g. before commit.
Regards,
Paulina
Hi Pauline,
Thank for your help!
I did like ín your exmaple but i get in an endless loop..
Maybe thats because my Rest Call response is a list from my object?
best regards
Mhm I am not sure but it still doesn’t works.
But the calculated variable is working after all…
So maybe I am just using them.. . :)