The main goal of an execution context class is to provide IN values for parameters and functions. This is achieved by a get method of HyperonContext class:
Whenever a parameter or function needs IN value it queries above get method providing a path. In case of parameters the path is taken from VALUE SOURCE property of an IN column definition:
In case of functions the path value is taken from path argument to ctx.getX(String path) call:
A function body can include parameter evaluation. That parameter will query the context by itself.
The developer has a full flexibility how he/she would implement the context. He or she must only remember that context is responsible for translating paths into values.
Very simple and truly not recommended context implementation would store values in map for given paths (keys), e.g.:
That is how HyperonContext basic constructor works:
A better approach would be to construct a mapper to retrieve values from a POJO (or more complex data structure):
and the mapper implementation:
Once the CalcContext object is created it can be reused for subsequent calls to parameters, functions and domain attributes' values. This approach does not invoke all Policy.getX methods at context initialization. That is postponed to the moment they are really needed. This is normal that a given parameter or function uses only subset of a context (e.g. only policy.premiumPerDay). That can be altered by redesigning parameter's definition in Hyperon Studio. Mind that the execution code that calls a parameter or function:
remains fully intact as engine relies on context only.
More robust way of preparing adapters for complex data is described on next page.