Configurable Lookup Columns Description

Name

Identifier of the Lookup operation. It will need to be referenced in the code.

userSourceType

Type of the table. LookupConfiguration has been tested with PX/PP/PCOMP tables.

selectedFields

Map in the JSON format. Keys of this map will be referenced in the code. After the lookup is performed, there will be record’s data under these keys in Groovy Map. Values match either ColumnNames or atributeIds.

key1Field

Column name or attributeId. Value of that column needs to match key1 of the current context. In PLI and PGI, key1 is always SKU. If empty, the lookup will be cached rather than batched – because values will not differ for different products.

key2Field

Column name or attributeId. Value of that column needs to match key2 of the current context. In PLI and PGI, key2 is always secondaryKey. Take into consideration that while still batched, constructed filter needs to contain Filter.and of 200 filters instead of one Filter.in with 200 elements. This is an expected trade-off when using secondaryKeys.

key1Transformation/key2Transformation

Path to the function which can transform a PGI/PLI key into a different lookup value. Useful when the data has plain structure (not hierarchical), but it is less granular than line items.
Example usage: In PG logic, secondaryKey is CustomerName. Product costs differ based on CustomerGroup. Here, you will pass the path to the function which translates from CustomerName to CustomerGroup, so you will not need to artificially generate new data entries.

customFilter

Any filter which will be applied to data lookup. It supports tags which are dynamically resolved at runtime:

• <<FIELD_NAME(value)>> – Value will be expected to be the column’s name which will be dynamically translated into attributeId.

• <<TARGET_DATE>> – Will put translated into target date of the current calculation (in the format suitable for filtering on date fields).

sortByField

How data should be sorted on the database level if more than one entry is returned.

checksConfig

Map defining behavior in case something goes wrong. Keys in the map are types of error, while values define how to handle it. Cases when the check is performed:

• No entry found: “NO_ENTRY“

• More than 1 entry found: “MORE_THAN_1“

• First entry does not have value x. x is a selected field, a key in the “selectedFields” config: “NO_FIRST_VALUE-x“

• No entry has value x. x is a selected field, a key in the “selectedFields” config: “NO_ANY_VALUE-x“

• Lookup engine returned an error, usually by incorrect configuration: “LOOKUP“

• Possible behavior when an issue happens:

  • IGNORE – Ignores the issue. Default value for all checks.

  • LOG – Logs the issue to api.logInfo.

  • PSP_WARNING – Does not interrupt the flow, but registers the error to PSP WarningManager.

  • WARNING – Does not interrupt the flow, but registers the error by api.addWarning.

  • PSP_THROW – Throws an exception and registers the error to PSP WarningManager.

  • THROW – Throws an exception.

  • PSP_ABORT – Throws an exception and aborts the rest of the current PSP module.

  • ABORT – Calls api.abourtCalculation and throws an exception.

IsUsingDependencyLevelHierarchy

Allows you to turn on and off (by setting Yes/No) fallback on parent Dependency Levels. Integration to complex PSP mechanism.