Creating and publishing measures

This section introduces the various ways of creating measures with the API, or referring to existing ones to use them in calculations.

Basics

Here we'll cover the most elementary Copper measures, created in just one step.

Native measures

The native measure contributors.COUNT is available by calling Copper.count().

Aggregated measures

Aggregated measures refer to selection fields aggregated using a function plugin key. In the ActivePivot sandbox, such measures include pnl.SUM.

In Copper, you can create such a measure by calling Copper.agg(fieldName, pluginKey). We have provided shorthand methods for the most common aggregations -- sum, avg, min, max -- to free the user from having to specify the plugin key every time.

The creation of pnl.SUM becomes:

Copper.sum("pnl").publish(context);

The default name generated for such measures, unless overridden by the user, is of the form field.PLUGIN_KEY.

Level member value

Copper allows you to create a measure whose value is the member of a selected level in the evaluated location, when the level is expressed. This measure may be used for further calculations, or as is.

Copper.member(Copper.level("Desk")).withName("DeskMemberValue").publish(context)

Here, Desk is the name of a level.

Example:

Desk	DeskMemberValue
(ALL)
DeskA	DeskA
DeskB	DeskB

As you can see, the measure named DeskMemberValue returns null on the grand total because the level Desk is not expressed.

Context value

Context values can be used in Copper, and creating a measure whose value is that of the context value of a given class at every cube coordinate is done with Copper.contextValue(contextValueClass).

Constant

Measures that have the same constant value at every cube coordinate can be used to express arithmetic calculations (see next section). They are created using Copper.constant(value).

Named measure

Copper allows you to refer to any measure by its name. You can use this feature to manipulate measures which were initially present in the cube, as well as any previously published Copper measure. This is done with Copper.measure(name).

The name of a measure is the user-given name if any (with CopperMeasure#as(String), see Measure metadata about measure metadata for more information), or the default name generated by Copper.

Copper.sum("pnl").publish(context);
CopperMeasure m1 = function(Copper.measure("pnl.SUM")); // reuse pnl.SUM in a custom function
m1.publish(context);

Note that in this particular example, the whole body can be boiled down to a single equivalent instruction: function(Copper.sum("pnl")).publish(context). See the section about measure publication for more details.

Simple operations

In this section we will review some of the elementary operations that can be performed on Copper measures to create new measures.

Arithmetic operations

Arithmetic operations such as +, -, *, / are naturally supported in Copper, with the methods plus, minus, multiply, divide available for any CopperMeasure.

CopperMeasure pnlSUM = Copper.sum("pnl").publish(context);
pnlSUM.multiply(Copper.constant(2)).publish(context);
pnlSUM.plus(pnlSUM).publish(context);

Lambda functions

For more complex calculations, lambdas can be used: measure.map(value -> ...).

Copper.sum("pnl").map((Double pnl) -> pnl.longValue()).publish(context);
// mapToDouble can be used to manipulate primitive double types
Copper.sum("pnl").mapToDouble((Double pnl) -> Math.sqrt(pnl)).publish(context);

It is however advised to use the arithmetic operations as much as possible, since Copper is able to understand and optimize calculations when they are used, which it cannot do with lambdas.

Copper.sum("pnl").map((Double pnl) -> Math.pow(pnl, 2.)).publish(context);   // DON'T
Copper.sum("pnl").multiply(Copper.sum("pnl")).publish(context);              // DO

Measure combination

Multiple measures can be combined using Copper.combine(CopperMeasure...) and then used in a calculation to produce a single measure with map(lambda). When a query is executed, the mapping function is given an IArrayReader as an argument. This is an array-like object which contains the values of the combined measures at the evaluated location, in the same order. The array reader provides a method to get their values like read, as well as a null-check with isNull and primitive reads to prevent from boxing: readInt, readLong, readDouble, readFloat, and readBoolean.

Copper.combine(
        Copper.member(Copper.level("Desk"))),
        Copper.sum("pnl")
    .map(a -> {
        final String desk = (String) a.read(0);
        final double pnl = a.readDouble(1);
        if ("Desk A".equals(desk)) {
            return a * 2.;
        } else {
            return a;
        }
    })
    .publish(context);

Advanced operations

Here we describe some of the more advanced measure operations in Copper.

Measure filtering

Computing the value of a measure considering only a subset of the records is called filtering. It is performed with a condition on a level, much like one would think "the value of the measure when only considering the contributions for the city of Paris". The CopperLevel interface provides many condition methods, such as eq, lt, geq, etc., for =, <, ≥, and so on.

Copper.sum("pnl")
    .filter(Copper.level("City").eq("Paris"))
    .publish(context);

Complex conditions can be constructed using the and and or methods in CopperLevelConditions. Chaining filter calls with different conditions will have the same result as and'ing them.

Dynamic aggregation/Leaf operation

Dynamic aggregation refers to the aggregation of a measure using a certain function up to a level, and another aggregation function (or no aggregation) above that level.

You may want to compute the sum of the sales for each category of products, but display the average sale amount when aggregating product categories. This is done like so:

Copper.sum("sales")
    .per(Copper.level("Product Category"))
    .avg()
    .publish(context);

Some calculations only make sense when a certain level is expressed: as previously seen in the example above with the combine operator, the value of Copper.member(Copper.level("Desk"))) is null for the Grand Total. It is the user's responsibility to handle this case. If there is no reason to compute anything above the level Desk, it is possible to do:

Copper.combine(Copper.member(Copper.level("Desk"))), Copper.sum("pnl")).map(a -> function(a))
    .per(Copper.level("Desk"))
    .doNotAggregateAbove();

It forces the combine operation to happen at Desk level thanks to .per(Copper.level("Desk")). Because it is mandatory to indicate what to do above the "per levels", we use .doNotAggregateAbove() here to say that the combine operation does not need to be executed above the Desk level.
An equivalent, but more cumbersome and less efficient way of writing this would be:

Copper.combine(Copper.member(Copper.level("Desk"))), Copper.sum("pnl")).map(a -> {
        if (a.isNull(0)) {
            return null;
        } else {
            return function(a);
        }
    })
    .per(Copper.level("Desk"))
    .doNotAggregateAbove();

Analytic functions

An analytic function is a function that computes aggregated values over a group of other aggregated values. The group is defined by a window built along a particular hierarchy used as an axis.

Window specification

For each row of the cell set (i.e. for each location), it indicates the set of other rows (i.e. the other locations) that can be read to compute the result of the operation defined by the analytic (window) function.

The window specification can be created in three parts:

An ordering specification (mandatory) to define how aggregated values are ordered along the indicated hierarchy: Window.orderBy("time"). The ordering follows the rules implied by each level comparator. It can be reversed with Window#reverse().
A partitioning specification (optional) to break up the window into separate smaller windows (partitions; one per level value) over which the analytic function is independently evaluated. Notice it only makes sense to indicate a level belonging to the ordered hierarchy because the window is automatically partitioned by the level values of other hierarchies.
A frame specification (optional) that states which aggregated values will be included in the frame to evaluate the result at a particular location. For example, Window.orderBy("time").rangeBetween(-5, 0) describes a frame including the five values preceding the current value to the current value (included). Not specifying a frame is equivalent to defining an unbounded preceding frame, which means it includes all the values preceding the current value and including the current value.

Siblings

Window.siblings(CopperHierarchy hierarchy) creates a special window that contains for a given row (evaluated location) of the cellset the set of other rows (locations) whose paths along the given hierarchy have the same set of ancestor coordinates.

For example, if the requested cellset contains the following locations, the window for each location is indicated by the set of corresponding row ids:

row id	location	window
0	AllMember\2018\January	[0, 1, 2]
1	AllMember\2018\February	[0, 1, 2]
2	AllMember\2018\March	[0, 1, 2]
3	AllMember\2019\January	[3, 4, 5]
4	AllMember\2019\February	[3, 4, 5]
5	AllMember\2019\March	[3, 4, 5]

The rows 0, 1 and 2 have the same window because they have the same ancestor (parent): [AllMember, 2018] and the rows 3, 4, and 5 have the same window because they have the same ancestor: [AllMember, 2019] However, for the following cellset, the window is identical for all locations because they all have a common ancestor which is AllMember:

row id	location	window
0	AllMember\2018	[0, 1, 2]
1	AllMember\2019	[0, 1, 2]
2	AllMember\2020	[0, 1, 2]

By default, the window contains the row being evaluated. You can exclude it with:

Window.siblings(Copper.hierarchy("time")).excludeCurrent();

The previous result becomes:

row id	location	window
0	AllMember\2018	[1, 2]
1	AllMember\2019	[0, 2]
2	AllMember\2020	[0, 1]

Aggregate analytic function

An aggregation analytic function is a function used to do aggregation over the values belonging to the window. It is typically useful to define a 'running sum' or a 'prefix sum'.

Copper.sum(Copper.measure("pnl.SUM")).over(Window.orderBy("time"));

Every aggregation function can be used, such as max, min, longSum, or shortSum. You can also use custom ones with Copper.agg(CopperMeasure measure, String pluginKey).

Examples of ordering, partitioning, and using different aggregation functions illustrated with a pivot table, given:

a cube with a "time" hierarchy with three levels: "year", "month", "day".
a pre-aggregated measure "pnl.SUM": {@code CopperMeasure pnl = Copper.sum("pnl)}.
A measure to compute a running total of "pnl.SUM" along the time hierarchy, each level being naturally ordered: Copper.sum(pnl).over(Window.orderBy("time").withName("run. tot.").
A measure to compute a running total of "pnl.SUM" in reverse order along the time hierarchy, each level being naturally ordered: Copper.sum(pnl).over(Window.orderBy("time").reverse().withName("run. tot. reverse").
A measure to compute a max total of "pnl.SUM" along the time hierarchy, each level being naturally ordered: Copper.max(pnl).over(Window.orderBy("time").withName("run. max").
A measure to compute a running total of "pnl.SUM" along the time hierarchy, each level being naturally ordered: Copper.sum(pnl).over(Window.orderBy("time").partitionBy("year").withName("run. tot. partitionBy(year)"). The cumulative sum starting over for each different year.

Year/Month/Day	pnl.SUM	run. tot.	run. tot. reverse	run. max	run. tot. partitionBy(year)
(ALL)	17	17	17	17	17
2018	10	10	17	10	10
Jan	7	7	17	7	7
01	5	5	17	5	5
02	1	6	12	5	6
04	1	7	11	5	7
Feb	3	10	10	7	10
01	1	8	10	5	8
02	2	10	9	5	10
2019	7	17	7	10	7
Jan	2	12	7	7	2
02	2	12	7	5	2
03	0	12	5	5	2
Feb	5	17	5	7	7
01	3	15	5	5	5
02	2	17	2	5	7

Navigation analytic function

A navigation function computes the value at a given location by copying the value over a different location from the current location in the window. Notice that the window frame specification is ignored by every navigation analytic function.

The supported navigation function are:

lag: returns the value of the given measure for a location at a given offset before the current location.
lead: returns the value of the given measure for a location at a given offset after the current location.
first: returns the value of the given measure with respect to the first location in the window
last: returns the value of the given measure with respect to the last location in the window

Examples of ordering, partitioning, and using different navigation functions illustrated with a pivot table, given:

a cube with a "time" hierarchy with three "year", "month", "day" levels.
a pre-aggregated measure "pnl.SUM": CopperMeasure pnl = Copper.sum("pnl).
A measure that returns the next values of "pnl.SUM" along the time hierarchy, each level being naturally ordered: Copper.lead(pnl, 1).over(Window.orderBy("time")).withName("lead").
A measure that returns the previous values of "pnl.SUM" along the time hierarchy, each level being naturally ordered: Copper.lag(pnl, 1).over(Window.orderBy("time")).withName("lag").
A measure that returns the first value of "pnl.SUM" along the time hierarchy, each level being naturally ordered: Copper.first(pnl).over(Window.orderBy("time")).withName("first").
A measure that returns the last value of "pnl.SUM" along the time hierarchy, each level being naturally ordered: Copper.last(pnl).over(Window.orderBy("time")).withName("last").
A measure that returns the first value of "pnl.SUM" along the time hierarchy for each year, each level being naturally ordered: Copper.first(pnl).over(Window.orderBy("time").partitionBy("year")).withName("first per year").

Year/Month/Day	pnl.SUM	lag	lead	first	last	first per year
(ALL)	17	null	null	17	17	17
2018	10	null	7	10	7	10
Jan	7	null	3	7	5	7
01	5	null	1	5	2	5
02	1	5	1	5	2	5
04	1	1	1	5	2	5
Feb	3	7	2	7	5	7
01	1	1	2	5	2	5
02	2	1	2	5	2	5
2019	7	10	null	10	7	7
Jan	2	3	5	7	5	2
02	2	2	0	5	2	2
03	0	2	3	5	2	2
Feb	5	2	null	7	5	2
01	3	0	2	5	2	2
02	2	3	null	5	2	2

Shift Measures

Shifting refers to copying the value of a measure at a location other than the evaluated location.

Location shift

Shifting a measure requires the definition of:

the level(s) on which to shift
the operation describing the shift

When the query expresses enough levels, the aggregated value is read from the location specified by the shift function.

There are two ways of defining a shift function:

through a constant value. Example: shifting at day = 1. Every time the shifted measure is evaluated at a certain day, the value for day 1 is taken instead - provided that day 1 exists; otherwise, it returns an empty result.
For constant shifts, the query must express the parent level of a shifted level. Considering a multi-level hierarchy "year" then "month" then "day", the value of the shifted measure at "year 2020 month 6" is the value at "year 2020 month 6 & day 1". If month is absent, we are asking for "day 1 of year 2020" but without knowing the month. As this does not make sense, the result is empty.
through a lambda. This allows you to create dynamic shifts, such as "previous day", "next month", and so on.
Example: shifting at day -> day - 1 shows the value of "day 5" when evaluated at "day 6", and returns an empty result when evaluated at "day 1" - provided that "day 0" does not exist.
Unlike constant shifts, the shift is performed only when all the query location expresses the levels involved in the lambda. Otherwise, the result is empty.
Using the same example as above, the value of the shifted measure at "month 6" or at "year 2019" are empty.

Here is an example of various shift measures illustrated with a pivot table, given:

a "date" hierarchy with the levels "year", "month", "day"
a classic measure pnl.SUM

a constant-shifted measure d1

d1 = pnlSum.shift(
Copper.level("date", "date", "day").atValue(1))

a constant-shifted measure d1m6

d1m6 = pnlSum.shift(
Copper.level("date", "date", "day").atValue(1),
Copper.level("date", "date", "month").atValue(6))

a constant-shifted measure d1m6y2019

d1m6y2019 = pnlSum.shift(
Copper.level("date", "date", "day").atValue(1),
Copper.level("date", "date", "month").atValue(6),
Copper.level("date", "date", "year").atValue(2019))

a lambda-shifted measure prevDay

prevDay = pnlSum.shift(
Copper.level("date", "date", "day")
        .at((Integer d) -> d - 1))

a lambda-shifted measure prevDayPrevMonth

prevDayPrevMonth = pnlSum.shift(
CopperLevel.at(Arrays.asList(
        Copper.level("date", "date", "day"),
        Copper.level("date", "date", "month")),
        a -> {
            a.writeInt(0, a.readInt(0) - 1);
            a.writeInt(1, a.readInt(1) - 1);
        }))

a lambda-shifted measure prevDayPrevMonthPrevYear

prevDayPrevMonthPrevYear = pnlSum.shift(
CopperLevel.at(Arrays.asList(
        Copper.level("date", "date", "day"),
        Copper.level("date", "date", "month")),
        a -> {
            a.writeInt(0, a.readInt(0) - 1);
            a.writeInt(1, a.readInt(1) - 1);
            a.writeInt(2, a.readInt(2) - 1);
        }))

ALL/year/month/day	pnl.SUM	d1	d1m6	d1m6y2019	prevDay	prevDayPrevMonth	prevDayPrevMonthPrevYear
(ALL)	1000			7
2018	200		1	7			200
2018/05	40	4	1	7		40	40
2018/05/01	4	4	1	7
2018/05/02	3	4	1	7	4
...
2018/06	30	1	1	7		30	30
2018/06/01	1	1	1	7
2018/06/02	2	1	1	7	1	4
...
...
2019	300		7	7			300
2019/05	50	5	7	7		50	50
2019/05/01	5	5	7	7
2019/05/02	6	5	7	7	5
...
2019/06	10	7	7	7		10	10
2019/06/01	7	7	7	7
2019/06/02	1	7	7	7	7	5	4
...

It is possible to mix all types of shift function together in a single call to shift.

Parent value

To compute the value of a measure at its parent member in a multi-level hierarchy (or for at AllMember if the hierarchy is single-level), use measure.parentValueOn(Copper.hierarchy(hierarchyName)). This operation is also known as a drillup. You can additionally choose how many levels the operation should "go up" with a third int parameter:

/*
 * compute the "grandparent" along the date hierarchy.
 * Since it is slicing, all locations will show the aggregated value for the current year.
 */
Copper.sum("pnl").parentValueOn(Copper.hierarchy("Time"), 2).publish(context);

If the number of levels to drill up is greater than the level depth of the hierarchy in the evaluated location, the first level of the hierarchy is used instead (AllMember for non-slicing hierarchies, and the member of the first level otherwise). This means that unless the targeted value is actually null, the parent value is never null.

Total

Copper.total is used when instead of drilling up a constant number of levels one needs to always refer to the aggregated value of the first level of the hierarchy.

Copper.total(Copper.sum("pnl"), Copper.hierarchy("time")).publish(context);

Aggregated measures with User-defined aggregate functions (UDAF)

Advanced aggregated measures reuse the concept of aggregated measures, but extend it to obtain much more flexible and potentially complex measures by:

Allowing multiple fields of the selection as input for the aggregation
Allowing the storage of multiple intermediate aggregate buffers to be used for computations.

UDAF are currently supported only in the JIT aggregates provider.

This allows for the definition of complex measures displaying metrics, such as the variance of a field, the correlation coefficient between two fields, or the aggregated sum of a vector field scaled by the values of another field. The latter example is showcased here:

Considering the following data, we want to obtain a ScaledSum measure returning the aggregated sum of the Vector field values (containing integer vectors), scaled by the value of the Factor field (containing double scalars):

Year	Quarter	Factor	Vector
2018	Q1	0.6	[10;15]
2018	Q2	0.7	[20;14]
2018	Q3	0.8	[8;10]
2018	Q4	0.9	[15;12]
2019	Q1	1.0	[14;10]
2019	Q2	1.0	[16;17]
2019	Q3	1.0	[6;15]
2019	Q4	1.0	[13;15]
2020	Q1	2.0	[4;5]

This can be done with the following Copper code:

Copper.userDefinedAgg("Factor", "Vector")
        .aggregationBuffer(Types.TYPE_DOUBLE_ARRAY)
        .contribute(
                (fact, buffer) -> {
                    final double factor = fact.readDouble(0);
                    if (buffer.read(0) == null) {
                        // First call: create a new vector to holds the values.
                        IVector v = ((IVector) fact.read(1)).cloneOnHeap();
                        v.scale(factor);
                        buffer.write(0, v);
                    } else {
                        ((IVector) buffer.read(0)).applyAsDouble(
                                (IVector) fact.read(1), (aggs, facts) -> aggs + factor * facts);
                    }
                })
        .merge((in, out) -> ((IVector) out.read(0)).plus((IVector) in.read(0)))
        .outputFromBuffer(0)
        .withName("ScaledSum");

This measure returns the following values:

row id	location	ScaledSum
0	AllMember	[96.9, 104.6]
1	AllMember\2018	[39.9, 37.6]
2	AllMember\2019	[49.0; 57.0]
3	AllMember\2020	[8.0;10.0]

The previous block can be divided into three parts, corresponding to the steps required to fully define an advanced aggregate measure as well as its UDAF:

First, Copper.userDefinedAgg([...]) accepts a vararg of String values that correspond to the fields that will be aggregated. This method returns a CopperUserDefinedAggregateFunctionBuilder builder to start defining the aggregate function. In our example, we need to aggregate the Factor and Vector fields:
```
Copper.userDefinedAgg("Factor", "Vector")
```
Calling aggregationBuffer(int... types) then specifies the types of the aggregation buffer that will be used by the function to store intermediary results.

This argument defines the type of each buffer used for the intermediary computations of the aggregation. In our example, we have the following value for the bufferTypes argument:
```
   .aggregationBuffer(Types.TYPE_DOUBLE_ARRAY)
```
This is due to the fact that even though the Vector field contains vectors with integer values, the aggregates contain data scaled with double values, and therefore can be vector with double data.

Since there is no need for more data in order to compute the final aggregates, that single buffer will be enough to perform the aggregation. This however is not the case for all the aggregate functions, and we might need to use multiple buffers and buffer types in order to compute the aggregates. Those will be declared in the bufferTypes argument.

The bufferTypes argument defines the size and types of the buffers used when performing the aggregation. Judiciously choosing the buffers of your UDAF is of the utmost importance, both for performance and memory comsumption reasons.
The contribute(SerializableBiConsumer<IArrayReader, IWritableArray> contributor) method then declares the explicit operation performed by the aggregation function when aggregating a row of facts into the aggregates buffer. the SerializableBiConsumer<IArrayReader, IWritableArray> contributor argument is a lambda defining the operation performed when a row of the records is aggregated into the buffer of the aggregation. Let's consider the previous example, in which the contributor was:
```
.contribute(
        (fact, acc) -> {
                final double factor = fact.readDouble(0);
                if (acc.read(0) == null) {
                    IVector v = ((IVector) fact.read(1)).cloneOnHeap();
                    v.scale(factor);
                    acc.write(0, v);
                } else {
                    ((IVector) acc.read(0)).applyAsDouble(
                            (IVector) fact.read(1), (aggs, facts) -> aggs + factor * facts);
                }
            })
```
Here, fact is an ArrayReader containing the data of the fields previously declared as input of the aggregation, in the same order as the declaration. agg corresponds to the WritableArray of aggregated buffers the row of records is aggregated into. The content of that row is defined by the bufferTypes argument.

When defining the contribution lambda, it is crucial to avoid any unnecessary copies, as well as trying to minimize the amount of read/write operations as this lambda will be applied for every fact to aggregate on the stores.

Here, we read once and for all the value of the scaling factor, and only one vector is cloned per aggregate. It is also important to note that when manipulating non-primitive types, the aggregation function must handle null values properly.
Then, the merge(SerializableBiConsumer<IArrayReader, IWritableArray> merger) declares the operation performed when merging two aggregates buffers together. The merger argument is a lambda defining the operation performed when merging the contributions of two aggregated buffers into a single one. In our example, the merger lambda was simple, as we only need to sum the values of the vector already scaled when contributing the rows to the aggregates:
```
    .merge((in, out) -> ((IVector) out.read(0)).plus((IVector) in.read(0))
```
After applying the consumer, the second argument of the lambda is expected to contain the merged contribution of both input aggregates. Here, in is an ArrayReader containing the values of the pre-aggregated values that will be added into the aggregates of the out buffer.
Finally, the output(SerializableFunction<IArrayReader, Object> terminateFunction, int outputType) method completes the definition of both the aggregate function and the advanced measure by providing a third lambda terminateFunction corresponding to the final evaluation function applied to the aggregated buffers in order to return the value of the aggregates. In our example, the final aggregate is already available in our first buffer, so obtaining the aggregates can be a simple read operation:
```
.output(o -> o.read(0))
```
Since terminate functions are expected to often be simple read operations on the buffers, a shortcut method is available as shown in the full snippet:
```
.outputFromBuffer(0)
```
The aggType argument declares the output type of the aggregate function. Note that this is only a declaration and not a cast.

Post-processor

Legacy post-processors are supported in Copper.

Calling Copper.newPostProcessor gives you access to a builder which allows you to specify the post-processor's plugin key, its underlying measures, its properties and so on:

Copper.newPostProcessor(PLUGIN_KEY)
    .withProperty("propKey", "propValue")
    .withName(ppName)
    .publish(context);

Measure metadata

A measure has several elements of metadata that can be configured in Copper, such as:

its name with .withName(). It uniquely identifies a measure so that two measures cannot have the same name. The measure name is the one used in MDX queries, in the UI wizard, and in Copper to reuse the measure in other calculations with Copper.measure(name). Measures named with .withName() will always be published and available for queries by their name. Unnamed measures not explicitly published may not end up in the cube due to optimization that Copper may apply.
its designated output type with .withType(). It is sometimes necessary to designate the correct type to reuse it later. For example, after using CopperMeasure#map.

Note that .withType() does not change the type of the output values of a measure, but it changes the designated typing, as well as the behavior of measures having this measure as an underlying.

As an example, the following measure : Copper.count().withType(Types.TYPE_DOUBLE) returns long values.
However, Copper.count().withType(Types.TYPE_DOUBLE).divide(Copper.constant(2L)) returns double values as the result of the division between double and long values.
This behavior is to oppose the following measure declaration: Copper.count().divide(Copper.constant(2L)) that always has long values as the result of the division operation between two long values.
its formatter with .withFormatter(). The formatter changes the visual representation of the measure values in the MDX cell set.
its measure group with .withMeasureGroup().
its folder with .withinFolder(). It impacts the path to be used when displaying the measure in the user interface.
its visibility. A measure can be visible or not in the UI, but will still be available in queries as long as it is part of the cube description. Measures explicitly published are always visible, unless .hidden() is called. Other measures can be made visible with .visible(). Please refer to the section about publication to know more about why some measures are not visible by default.

ActivePivot

5.9.1

ActivePivot /pivot

ContentServer /register