Package net.pricefx.formulaengine

Interface DistFormulaContext

All Known Subinterfaces:
DistCalcFormulaContext, ModelCalcFormulaContext, ModelFormulaContext
public interface DistFormulaContext
DistFormulaContext is a groovy api exposed through the 'dist' binding when evaluating the logic for a DistributedCalculation DL through invocation of the datamart.formulaparams and datamart.distcalcexec endpoints. Both are used in the setup and testing of the DL in the UI. For datamart.formulaparams, the logic is evaluated in syntaxCheck mode only. All the logic elements are executed. If parts of the logic are to be skipped, then that can be achieved by testing on api.isDebugMode(), which returns true for both end points. For datamart.distcalcexec, the idea is that all of the logic is executed to mimic the combined init + calculation + summary stages in an actual DL calculation job. See also DistCalcFormulaContext

  • Method Summary

    Modifier and Type
    Method
    Description
    List<DMField>
    getAllocationFields()
    Proxy for DL.calculationConfig.allocationFields, specifying the fields that are going to be updated, including the aggregation expressions that define the allocation math.
    Object
    getCalcItem()
    In a distributed calculation step, this method retrieves the item to be calculated.
    LocalDateTime
    getIncLoadDate()
    Proxy for DL.incLoadDate.
    LoadMode
    getLoadMode()
    Proxy for DL.loadMode, specifying how the result data is going to be uploaded to the target.
    String
    getTarget()
    Proxy for DL.targetName, i.e. the name of the target for which data is being calculated.
    List<String>
    getTargetFields()
    Proxy for DL.calculationConfig.targetFields, specifying the fields that are going to be updated (enriched) by this calculation.
    boolean
    isIncremental()
    Proxy for DL.incremental.

  • Method Details

    • getTarget

      String getTarget()
      Proxy for DL.targetName, i.e. the name of the target for which data is being calculated. For ex. 'DMDS.Transactions'
      Returns:
      The name of the target in 'typeCode.uniqueName' format

    • getLoadMode

      LoadMode getLoadMode()
      Proxy for DL.loadMode, specifying how the result data is going to be uploaded to the target. The possible values are:

      • 'FULL': The job generates all the rows, values for all fields. The target is truncated before result is loaded. Duplicate rows (:= with identical values for the key fields) are removed
      • 'INCREMENTAL': The job generates additional rows, with values for all fields. Existing rows can be replaced by creating duplicate rows, i.e. rows with the same key as already existing ones. Existing rows can be deleted by setting isDeleted = true.
      • 'ENRICHMENT': The job generates values for fields not sourced from anywhere else, only for existing rows. The list of fields being updated can be retreived with getTargetFields(). No rows can be added or deleted.
      • 'ALLOCATION': Like enrichment but the calculated fields, which must be numeric, are accumulated. A typical example is allocation of rebate amounts, where each rebate record contributes an amount to the transactions used to determine the accrual. The list of fields being allocated to can be retreived with getAllocationFields().

      Returns:
      The LoadMode enum value for this calculation

    • getTargetFields

      List<String> getTargetFields()
      Proxy for DL.calculationConfig.targetFields, specifying the fields that are going to be updated (enriched) by this calculation.
      Returns:
      List of DMField.name of the target fields

    • getAllocationFields

      List<DMField> getAllocationFields()
      Proxy for DL.calculationConfig.allocationFields, specifying the fields that are going to be updated, including the aggregation expressions that define the allocation math.

      Json representation of an example DL, which specifies allocation fields:
       {
   "label" : "Distributed Rebate Allocation",
   "loadMode" : "ALLOCATION",
   "targetName" : "DM.Transactions",
   "type" : "DISTRIBUTED_CALCULATION",
   "distributed" : true,
   "calculationConfig" : {
       "formulaName" : "DistributedRebateAllocation",
       "allocationFields" : [
          {
              "calculated" : true,
              "expression" : "MAX(ForecastBaseline)",
              "name" : "ForecastBaseline",
              "type" : "MONEY"
          }, {
              "calculated" : true,
              "expression" : "SUM(ActualAccrual)",
              "name" : "ActualAccrual",
              "type" : "MONEY"
          }
      ]
   }
 }
      Returns:
      List of DMFields, specifying name and expression for each allocation field.

    • isIncremental

      boolean isIncremental()
      Proxy for DL.incremental. The 'incremental' setting is unrelated to how the result data is uploaded to the target. That is determined only by the LoadMode. Instead, an incremental run denotes the fact that a previous job is being recalculated, for ex. because a number of calculation items failed in that previous run.
      Returns:
      Whether this is an incremental job or not.

    • getIncLoadDate

      LocalDateTime getIncLoadDate()
      Proxy for DL.incLoadDate. This is the start date (timestamp) of the previous, successful, run of the DL. It allows the logic to implement incremental calculation behaviour, though generally this is discouraged as such configuration tends to increase complexity and hence affect the maintainability of the application.
      Returns:
      The incLoadDate value of the DL.

    • getCalcItem

      Object getCalcItem()
      In a distributed calculation step, this method retrieves the item to be calculated. This item will have been created by a previous initialization (logic elements with the 'calculation-init' calculation context). From version 12.0, a calculation item is a new object type, with type code 'DLCI'. It is no longer a entry in a Lookup (PP) table. The object key is (jstId, key1, key2). As evident from this definition, Calculation items are now created for each new job (JST). Note: Logics that reference Key1, Key2, Value and Result (uppercase first letter), will still work, though it is recommended to use the lowercase field names instead.

      Json representation of an example DLCI object:
       {
   "typedId" : "992.DLCI",
   "jstId" : 1597,
   "key1" : "batch",
   "key2" : "21",
   "value" : ["EMEA", "Retail"]
   "status" : "COMPLETED",
   "results" : [
      {
          "resultName" : "NumberOfRowsInBatch",
          "resultLabel" : "#rows",
          "resultType" : "SIMPLE",
          "result" : 200000
      }
   ],
   "messages" : [
      "stuff you see in for ex. JST info, but now on batch level",
      "incl. the profiler trace"
   ]
 }
      Returns:
      The calculation item as a map.