Goal
Use only 1 logic of a given uniqueName.
Why
Logics
Valid After field was initially introduced in logics to support different pricing strategies for different time periods and keep track of them for auditing purposes. However this is not used for many years and having Valid After is causing confusing errors or issues and unexpected behavior, e.g. in combination with libraries.
The requirement for auditing the logic versions is covered by version controlling system (git). Thefore the long term vision is to remove fields validAfter and simulationSet for Calculation and Worklow logics completely from Pricefx core. But no date planned yet.
Company parameters
Valid After was introduced initially to support different pricing strategies for different time periods and keep track of them for auditing purposes. But this requires a administration user rights to maintain the parameter tables and that is security issue that can lead to serious data losses if users delete e.g. a different table by mistake - database restoration is then needed. The different parameter table of the same name and different Valid After can lead to different structures or security setup.
The long term vision is to allow end users to create multiple validAfter instances but with a reference to the same metadata set. Since metadata should not be defined differently for different validAfter dates of the same uniqueName. But no concrete plans yet.
Next steps
-
Studio and Unity will not show the Valid After field in “Create Logic” and “Create Company Parameter” dialogs and will set Valid After = 2020-01-01 by default.
-
Studio will report and alert any logics of the same uniqueName, but multiple Valid After.
-
Package tool will stop adding a Valid After suffix (e.g. “+2020-01-01) when fetching logics.
-
In Studio, it will be possible to automatically remove the Valid After suffix from folder names located in CalculationLogic, WorkflowFormula or PricingParameter folders.
-
One day, we will remove old logics and remove the validAfter field from the system so it is not part of the primary key. Alternatively keep it and have it always set to 2020-01-01 by the backend.