Cubeview member filter builder to allow multi-line expressions

dbeavon
Contributor

Is there a way to use multi-line expressions in the definition of my cubeview rows?

I would like to break down some of my expressions that are growing too long.  But my fear is that when I use multi-line expressions (assuming that is possible), then other onestream developers won't know about that - since the cubeview doesn't give any visual cue to show that multiple lines are being used.  Here is an example of a really long expression that I'd like to break apart.

 

E#AllBranches.Base:Name("{BranchCode = XFMemberProperty(DimType=Entity,Member=|MFEntity|,Property=Name)},{BranchCurrency = XFMemberProperty(DimType=Entity, Member=|MFEntity|, Property=Currency)},{BranchText2 = XFMemberProperty(DimType=Entity, Member=|MFEntity|, Property=Text2)},{BranchText6 = XFMemberProperty(DimType=Entity, Member=|MFEntity|, Property=Text6)}, XFMemberProperty(DimType=Entity,Member=|MFEntity|,Property=Description)")

7 REPLIES 7

db_pdx
Contributor III

Not sure on the multi-line part, but a potential alternative if you are generating the same text string in multiple reports would be to put the complex logic into an XFBR String formula.  You'll get the benefit of shortened text description in the cube views at the expense of maintaining the logic in the BR.

Cheers -DB

This is helpful.  I will leave the question open for a little longer ... in case anyone is aware of if/how it is possible to have multi-line expressions.  The length of some of our expressions seem problematic, and unsustainable. 

 

I realize that I'm using the cubeviews in a fairly unusual way.  But I think this issue is one that is eventually encountered by anyone who is working with complex requirements.  Perhaps it should be possible to have a small amount of BR logic that is in closer proximity to the cubeview itself... possibly embedded in the cubeview. 

ChristianW
Valued Contributor

I totally agree with db_pdx. In addition to the benefits you are looking for, accessing the properties within a business rule is much easier and cleaner.

My hesitance is related to organization, and deployment.  It seems problematic to put logic in another onestream collection, when it is specific to the requirements of a single cubeview. 

 

Also I'm not aware of any CI/CD strategies for pushing an assortment of dependencies thru onestream environments.  Adding a new dependency on a business rule is just one additional thing that can get overlooked in the (manual and labor-intensive) steps needed to move a report from dev to test to prod.  Let me know if we are overlooking CI/CD features of onestream (automated ones).

ChristianW
Valued Contributor

It doesn't resolve dependencies automatically, but you should have a look at xfproj files. It allows you to specify a list of objects and exports it in one go to a zip file.

I can take a look.  Is the xfprof something which is saved/reused every time we need to do a deployment? (ie. it "remembers" the metadata about the specified objects)?  

As we build more complex solutions, (involving cubeviews, custom code, etc), then we will have lots of moving parts.  What I am asking for ways to automate repetitive deployments.  Where onestream is concerned, the automation might be facilitated as an API.  The API might would accept all cubeviews, BR's and so on.  The automation could be handled via a deployment pipeline, using a git branch as a source.  It would run unattended, and could be triggered by a PR or it could be scheduled to happen nightly. 

 

Without automation, it can take as long to perform the deployments, as it does to implement our application changes in the onestream cubeviews.

ChristianW
Valued Contributor

XFProj will help with some of it, I use it for all my projects.

Please sign in! dbeavon