I'm working on a power view map to display to our user. I achieved to create a map that display all the data to the user. It look like this exemple. The data source is an SSAS project.
But now, I would like to filter this data depending on the connected user.
For example, we have ProductManager and TerritoryManager. The product manager can see his product on all the map, but only his product. The territory mananger can see all the product, but only on his territory.
The solution that I've found is to create an SSAS project for each product/territory, and after that allow some rights on this files. But this solution is impossible to maintain.
Is there a way/solution/best practice to realize this?
Any help is welcome
Damien
You probably just need one SSAS database. You can set security in the SSAS project. If you are using SSAS multidimensional, see here. For tabular, see here.
As long as you have Kerberos configured, you can have one Power View map and one SSAS source. Then when the user accesses the report, their credentials are passed along with the query, and only the data they are allowed to see will be returned. This will meet the needs you described.
You'll probably want to add a table to facilitate dynamic security. You'll need some way to tie product managers to the products they own and territory managers to the territories they own. You add this to the data in the SSAS model. And then use it to set security. Other than setting the data source for Power View to use Windows authentication, no changes are required to the report.
Related
I need to combine the energy consumption every month in my company from various sources. I do the calculations in the excel sheets which I receive every month. How do i combine all the sheets and make a dashboard and also update the dashboard every month automatically once the excel is updated?
Which is the best form of tableau to use(Public,desktop or server)?
What exactly is the difference among the three?
Are the excel sheets a good data source in tableau?
You are asking a lot of questions which should probably be raised separately, but I will try to answer some of them anyway since they all relate to the same use case.
1. How do I combine and make a dashboard
Since Tableau 9.3 you are able to use Union. This will combine all your excel files into a single source of data you can use. I think your data sources should however have the same structure. Meaning the sheets containing information should have the same columns.
You can dynamically and automatically do this using wildcard search. This way it will try and add all files that for example are located in the same folder.
More information on this here.
From the moment you have at least one file as a data source you can start creating a dashboard.
2. Which is the best form of Tableau
I don't think you truly understand the difference between the Tableau applications you mention.
You will need Tableau Dashboard to actually create a dashboard.
If you want to be able to share this dashboard through the web you will need either Tableau Server, Tableau Public or Tableau Online. Everything published on Tableau public will be publicly available. So if your data is considered restricted, sensitive or should not be shared outside your company you should not consider this.
Tableau server on the other hand is server software you can install on a local host which allows you to publish your dashboards and sheets so people with a Tableau server license can access it through a web interface.
Then there is Tableau Online which offers almost the same except that Tableau will take care of the hosting. This is the SaaS solution for making your dashboards available online.
Lastly there is Tableau Reader which is a free desktop application that is able to open your Tableau workbooks, but cannot modify them and has limited access to external data sources.
3. Is Excel a good data source
This really depends on your use case and is probably opinion based. Since the possibility of union and the ability to automatically bring in and update data I think Excel files can be a useful resource. What you need to consider is where the Excel files are stored, how you will connect to them and how many users will need to access them. If other users can easily modify the Excel file and create errors this is another downside of using them as a source.
When you publish your dashboard on e.g. Tableau Server and you want the dashboard to automatically change there as well, the Excel file needs to be accessible from there as well and should not be included in the dashboard. If you feel like none of the above is an issue then at the moment Excel is great for you.
I am new to this.
I built a pivot report in excel 2007 on SSAS. It connects to a cube on my local pc. Now I want to send this pivot report to other people to make them be able to view the pivot report and do some analysis by themselves (expanding year-month-day etc).
When my colleague tried he couldn't expand.
How can I achieve this?
Thank you,
Nian
Your colleague needs to be able to access the cube in order to refresh it. This means that your cube should be on a shared machine (like a server). I would recommend putting the cube on a server and setup a database read-only user login and setup the Excel file to use that username/password. You may be able to have your local machine be accessible, but I don't have experience with this and I would advise against it anyhow (your users wouldn't be able to refresh the cube if you don't have your computer on the network).
Also, even if you send them the file with data cached from the cube, only so much data gets cached. When you expand items, it won't need to request the data from the cube (on your machine/server) if it has that particular data cached. The same may happen when you create filters.
Entity has a custom field based on which, some security roles should have access to records of that type and some should not.
Javascript can be used to close form after checking roles. But I'm looking for back end solution that will disabled access to this records in workflows and searches too.
For example, product should viewable by everyone if manufacturer is our company and only by Competitor Products Specialist if other.
You might be able to write a plugin that would automatically share the record with the appropriate Users/Teams. When somebody updates that field, the plugin would run and share/unshare the record according to your business logic.
Disclaimer: I haven't actually tried this before, and there may be performance issues if you have lots of records (and therefore lots of sharing records).
I ended up writing the plugin that works on pre-Retrieve event and modifies retrieve query by adding additinal filter by field.
I am a student developer with Oregon State University's Business Solutions Group and I am currently working on a Salesforce integration project for one of the University's colleges. As you can imagine, the data we are working with is coming from several different places and in a variety of different formats. I was wondering if anyone with more experience in setting up Salesforce object schemas could talk about the pros and cons of relational database style normalization in Salesforce. What do we gain by not normalizing and using Record Types to categorize data? (For example: a Person-Account that encompasses Students and Faculty and uses Salesforce Record Types to differentiate between the two) What do we lose?
This message was inspired by this webpage:
Salesforce Guru: Record Types
Notice that the first thing it advises is to not normalize (overmuch) because it prevents us from taking advantage of some built-in Salesforce functionality. Overall, the page seemed helpful, albeit incomplete.
The answer to this question seems critical to the success of our project and will help us to decide how to reorganize the data we are initially migrating to Salesforce and ultimately build our Salesforce object schema, so any thoughts, additional resources or advice are very much appreciated. Thanks!
The inspirational web page is correct. With the "standard objects" like Account, Contact, Case, Lead, etc. and even with custom objects the system works best to use fewer tables (objects) and segregate the data based on some value (such as record type).
By using record types you leverage the point-and-click UI. For example, for the Account object you have a default page layout. But for each record type you can have a unique page layout. Furthermore the security model uses record types to limit or grant access as appropriate to different user profiles.
As the author says SOQL is NOT SQL.
Pardon the length here...hopefully I didn't go overboard...
I'm in the process of working on my first production MVC application and I'm trying to stick to DDD principles in the process. I've run into some questions related to how to deal with the security requirements of the application and thought I'd see if the SO community could offer some best-practice suggestions.
Domain Information
To use a simplified explanation, this application will have AffiliateCompanies, Users, and Customers.
AffiliateCompanies are hierarchal, so one affiliate can sign up and be tied to the activities of another affiliate. The root is the main company providing the products/services.
Users all belong to an Affiliate entity.
Customers are organizations to which the products/services are sold. Affiliates are assigned to customers such that it is possible for two hierarchically-unrelated affiliates to split a Customer.
Security Information
Rights to perform certain actions in the application will be determined based on an ACL-type of arrangement. Each User object has a property that is a collection of SystemAccessRules that determine what actions they can perform and what the scope of their permissions are (their own objects, their affiliate's objects, or their entire hierarchy's objects). Users can also belong to roles, which themselves have that same collection of SystemAccessRules.
As a result, if a user logs in and wants to see a list of "their" customers, the list could be comprised of customers they are individually assigned to, customers anyone in their affiliate organization is assigned to, or customers anyone in their organization or any of their child affiliate organizations are assigned to.
Database Considerations
DDD aside, at some point the storage strategy has to come into play. In this simple scenario, the tables align with the objects above (including a roles table), with a few support tables to support the relationships between the objects:
AffiliateCustomers - this table allows for a many-to-many relationship between affiliates and customers by storing the PK of each entity as a pair of FKs that are themselves a composite PK for this table.
ACL - this table stores the security information, specifically the subject of the entry (either a user or a role), the action in question (e.g. "CreateCustomer"), the permission (allow or deny), and a scope (their own stuff, their organization's, or their network's).
The Question...Finally
I'm using a combination of repositories and services. I'm trying to keep business logic in the services and out of the repositories or database, but due to the security design here, a simple request for the list of "their" customers could be immensely burdensome, especially as the data set grows. I was trying to use Linq where possible, but this architecture seems not to be very suited. As I see it, here are my choices:
Accept the requesting user as an argument for service methods (or determine it by context), and have the service method populate a list through multiple queries to Linq repository. This would require pulling the list of customers, then iterating through each customer to issue another query to pull the ACL data, then using that data to filter the first list based on permissions. The hierarchy issue would require some fancy Linq footwork (like this), if it's possible at all.
Even if the hierarchy issue could be made to work, it seems like this solution won't perform very well...
Accept the requesting user as an argument, but pass it and the required permission (e.g. "View Customers") to the repository in order to retrieve appropriate data from the database through a stored procedure that would use several EXISTS clauses in a CTE query that could account for the hierarchical nature of the data and the need to check for role and user security.
This pushes a fair amount of logic to the database, which seems very anti-DDD and generally bad.
I'm leaning more toward the second option, but that may be because in my past projects that's how I've done it. I'm not even sure if my design overall is on the right track (in the past the permission declarations were done using bit flags, so it was even easier to do the DB query using bitwise operator).
Has anyone been in similar situations, and if so can you comment on the performance and maintainability of the solution you pursued? I want to stick to high-minded programming principles, but not at the expense of simplicity and common sense.
Have you considered using the specification pattern to pass your business rules down to your data access layer?
The service constructs a specification tree which it passes to the repository. The repository converts the specification into an Expression<Func<Customer, bool>> which it passes to IQueryable<Customer>.Where(...). When the repository materialises the collection, e.g. by calling ToList(), the business rules are translated into SQL and executed on the database server.
Last time I checked, LINQ to SQL didn't support CTEs, so you may need to use a view to flatten the hierarchy.