This document (including, without limitation, any product roadmap or statement of direction data) illustrates the planned testing, release and availability dates for Spotfire products and services. It is for informational purposes only and its contents are subject to change without notice. Planning to implement - generally 6-12 months out. Likely to Implement - generally means 12-18 months out.
Copyright © 2014-2023 Cloud Software Group, Inc. All Rights Reserved.
Cloud Software Group, Inc. ("Company") follows the EU Standard Contractual Clauses as per the Company's Data Processing Agreement.
Terms of Use |
Privacy Policy |
Trademarks |
Patents |
Contact Us
Hi, I get your points and I think they are valid ones but I don't think a JDBC driver would be a good solution either. LDAP directories (or AD in this case) are good storage structures for hierarchical company directory objects. However there are pretty poor at reporting. Fetching thousands of objects is usually a very time consuming task and has a performance impact on the directory servers. Search queries using wildcards can easily timeout, depending on what attributes you search on. So I would argue that point 2. is actually a bigger risk when reading data directly from LDAP.
Most companies I have seen try to replicate the directory data somewhere else, which is exactly what Spotfire is doing on its own metadata admin schema. The other thing LDAP doesn't give you are historical reporting such as what access did a person had yesterday. That's something you can easily build once you have the LDAP data in a relational database. Obviously replicating the LDAP data has it's own issues as once you do that you risk running into data inaccuracies, not reporting on live data, etc. But for our reporting purposes using the Spotfire metadata DB it's perfectly fine.
As a side note it's worth having a look at Microsoft Powershell as it has built-in support for connecting to AD and outputting data. Again you would probably want to dump the data into a relational database but you may be able to meet some particular reporting requirements using Powershell scripts. For instance we used a Powershell script to report when specific service accounts get locked and we plugged that output onto our enterprise monitoring tool. That gave us near-instant visibility on these accounts so that we could react before problems were noticed by the users.
Yes, usernames, and potentially emails.
We have explored similar ideas, but we want to avoid tapping into the metadata table unless there are no other options:
1. Spotfire Server database should not be a book of records for AD (from an organization planning, not a good idea).
2. Potential usage of this table can impact Spotfire Reporting performance.
Hi, what data do you need to read from AD? If it is just groups and users you could easily configure this in Spotfire by adding the relevant extra AD contexts for those AD groups and users. We sync 4 AD domains with over 200k users and over 300 groups every 30 mins so the Spotfire Server can handle the load. Once Spotfire syncs it you can easily report on them by creating information links over the Spotfire metadata schema.
In our company, there are many reporting solutions that are based on AD information, and often against other systems of data. Having the ability to read the data as allows a centralized source of data to be used.
Currently we are doing this by asking the Active Directory product owners to create an ETL job, and loading this data into a database, only then are we consuming the data for other reporting needs. This is an extra (and error prone) step that we would like to avoid.
Hi, I suspect there are more solutions out there to read LDAP directories. But the real question here is what exactly are trying to achieve? Read LDAP directory data is clearly the means, not the goal.