When building data for a cube, either a full build or a synchronization, think about it this way. The code generated to support this essentially does a SELECT AllOfYourDimensionsMeasuresRelationships FROM SourceTable.
when you have non primary field references these expressions are evauluated as ObjectScript expressions.
These are documented but not on a single page
%sourceID although this is typically thought of being used in a detail listing specifically if you chose the option for whereas the other's are when defining the cube dimension, measures etc
There were several questions asked during the pressentation. One of them was
How can we restrict usage of the cubes so that we only allow users to specific data?
If this were SQL one way of approaching this is to define a View and then grant access to the View but not the table to users. Fortunately Analytics has the same concept. Just as SQL tables are the resource that has the data and a view is defined representation of the data, Analytics has Cubes which has the data and Subject Areas.
A subject is a virtual view of the cube but does not require the additional storage/build/sync time. Within the Subject Area you can
1. Define a filter, consider we want to define a subject on Senior Citizens, we would define a filter on Age > X. Then when we make the Senior Citizen Subject area to a user they will only ever see patients > X,
2. Define what dimensions are available
3. Define listings
Given that the routes in your enabled %CSP.REST class point to class methods you should be able to debug/step thru line by line by calling the class method. In the case where you might have a POST/PUT for your route that calls the class method you can always define the formal specificaiton of the class method to accept parameters and then have the code in your class method look at either your parameter values or %request.Data to determine if the class method is being called by a Http call or your simple debugging.