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).
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.
XFProj will help with some of it, I use it for all my projects.
