...
In the next element, the code directly references that list (bad) and then modifies data in the list ! (awful).
In the third element, the code directly references the list again in api.global and presents the values into a matrix.
...
Instead, the above logic could be something like sothis:
DataUtil.groovy
| Code Block | ||
|---|---|---|
| ||
List<Map> getTransactionData() {
def ctx = api.getDatamartContext()
def dm = ctx.getDatamart("Transactions")
def q1 = ctx.newQuery(dm, true)
q1.select("Sku")
q1.select("SUM(NetSales)", "SumNetSales")
q1.select("SUM(Cost)", "SumCost")
q1.where(Filter.equal("Sku", api.product("sku")))
return ctx.executeQuery(q1).getData()
} |
...
In this example, variables are passed explicitly using out.XX or using explicity explicitly method calls.
This code is much easier to debug and refactor than the first version.
...
api.
...
global for Caching
Consider the same example as above , where we need to cache the result of the query data:
...
| Code Block | ||
|---|---|---|
| ||
api.global.queryData.each { it ->
// do something
} |
This could be written much more effectively following the suggestions in the caching guide:
DataUtil.groovy
| Code Block | ||
|---|---|---|
| ||
List<Map> getTransactionData() {
return libs.SharedLib.CacheUtils.getOrSet("MyDataCacheKey"){
def ctx = api.getDatamartContext()
def dm = ctx.getDatamart("Transactions")
def q1 = ctx.newQuery(dm, true)
q1.select("Sku")
q1.select("SUM(NetSales)", "SumNetSales")
q1.select("SUM(Cost)", "SumCost")
q1.where(Filter.equal("Sku", api.product("sku")))
return ctx.executeQuery(q1).getData()
}
} |
...
Consider the following, where DataLibrary.groovy is a groovy Groovy library that can be called from any logic:
DataLibrary.groovy (library logic)
| Code Block | ||
|---|---|---|
| ||
List<Map> getTransactionData() {
def ctx = api.getDatamartContext()
def dm = ctx.getDatamart("Transactions")
def q1 = ctx.newQuery(dm, true)
q1.select("Sku")
q1.select("SUM(NetSales)", "SumNetSales")
q1.select("SUM(Cost)", "SumCost")
q1.where(Filter.equal("Sku", api.product("sku")))
q1.where(Filter.equal("Category", api.getElement("Category")))
q1.where(Filter.greaterThan("NetSales", out.NetSalesMinimum))
q1.where(Filter.notIn("Sku", api.global.exclusionSkus))
return ctx.executeQuery(q1).getData()
} |
In this example, lines 10 - 1310–13, you can see there are 4 different variables being magically injected into the filters. While this might work when called from a pricelist price list logic where all of those scoped variables are present, it will never work for other logics where those scoped variables aren’t are not present.
Instead, this lib method should use method parameters, so it can be easily reused by any other piece of code like so:
DataLibrary.groovy (library logic)
| Code Block | ||
|---|---|---|
| ||
List<Map> getTransactionData(String sku, String category, Number netSalesMinimum, List<String> exclusionSkus) {
def ctx = api.getDatamartContext()
def dm = ctx.getDatamart("Transactions")
def q1 = ctx.newQuery(dm, true)
q1.select("Sku")
q1.select("SUM(NetSales)", "SumNetSales")
q1.select("SUM(Cost)", "SumCost")
q1.where(Filter.equal("Sku", sku))
q1.where(Filter.equal("Category", category))
q1.where(Filter.greaterThan("NetSales", netSalesMinimum))
q1.where(Filter.notIn("Sku", exclusionSkus))
return ctx.executeQuery(q1).getData()
} |
...