Search for objects with a declarative lightweight metaverse search.
I'm trying to implement a Metaverse search using the declarative approach described the document "Implementing a Lightweight Metaverse Search ". I created a management agent to perform the declarative search, and I would like to use the search value (SValue) attribute to get, for example, a list of all persons in the MV. I tried declaring the join rule for the agent as follows: Metaverse object type: Any Data Source Attribute: SValue Mapping Type: direct Metaverse Attribute: objectType Use rules extension to resolve -> checked but my extension project doesn't get invoked; looking at the MV with the Metaverse Search, I can see that the objectType (without angle brackets) attribute is never set. How can I configure my declarative search agent to get all the objects of a given type in the metaverse when the extension is invoked? Is it possible to create a join rule with the special attribute <objectType> (with angle brackets), which does not appear in the list of mappable attributes? Thanks, Paolo P.S: in the section Create the declarative search management agent -> Configure Attributes page, point #5, the document states: "Click Object classattribute, and then, from the Object class attribute list, select ObjectType." There is no ObjectType attribute in the template file for the declarative search management agent; is this an error in the document?
August 31st, 2009 11:36am
This is correct, you can't use joins this way.The objectType attribute in the metaverse is not the same as the ObjectType of a MV object.The "objectType" is just a regular attribute you need to populate.You have to be very careful with this - the lightweight MV search is - as indicated the name -not meant to be a mechanism to create a complete drop file of a large amount of data.If you have "tons" of users in the MV, youmight run intoperformance and memory issues this way.The idea was toprovide a mechanism to drop some objects for troubleshooting purposes.Having that said, for a generic match of a set of objects, you would need a Boolean attribute populated.That way, you can define a join based on where "attribute = true" and "attribute = false", which captures all objects :o) I will look at the typo issue later.Thanks for bringing this up! Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation
August 31st, 2009 3:41pm
Hi Markus, thanks for your answer! So the only way to get all the objects of a certain type in the MV with the declarative search approach is to create a new attribute and give it a constant value? This would also require to modify the existing synchronization rules to populate the attribute or is there a way to assign a default value to the attribute? The boolean attribute in your example would be unset by default, right? so it would not be granted that searching "attribute = true" and "attribute = false" would return all objects. Cheers, Paolo P.S: the reason I'm investigating MV search is to test the system configuration. The search for all person objects will run in a test environment with a limited number of objects, so poor performance here is not an issue. I'm aware of the possible performance and memory problems, and I would never inflict the XML serialization of thousands of users to a production environment :)
August 31st, 2009 7:05pm
Paolo,I had to make sure that the scope is understood also for others who might read this - I'm sure, you understand.... Yes, you are right, flowing a constant is good enough. The general question is, whether this is just a one-off thing or something you would need for a while and also for other scenarios in your lab environment.So, would it be OK to put some dev time into this? If the answer is yes, you might want to think about the following approach.In many deployments, there is just one authoritative data source. In this case, you could Use CSExport to get the names of the CS objects Use these names to get to the object types and the MV GUIDs by using a WMI query Use the MV GUIDs for your LWS It may sound wild but it is not.You can find most of the components you need in the method to cleanup a connector space in a lab environment. Like Ive said, might be way beyond what you are looking for; however, it is really not much that needs to be done to make the solution work. Cheers,MarkusMarkus Vilcinskas, Technical Content Developer, Microsoft Corporation
August 31st, 2009 10:39pm
If this is for test code then you might consider verifying at the CS instead of the MV. This way you can use CsExport.exe to dump the CS to XML which can then be queried to find your object.Also, if the solution uses the FIM app store then you can query it using FIM's web services. The app store in theory should have the data from the MV.CraigMartin Oxford Computer Group http://identitytrench.com
September 1st, 2009 2:30am
Hi Markus. If it's necessary to modify the schema (albeit simply) to use the declarative search, then I prefer to rely on the less intrusive simple search approach. In any case, I should always be able to specify a search criteria for an object in the metaverse, e.g. an account name for a person, and get the data I want - and if I can't find a person with a given account name, then my test would fail anyway :) It would be perfectly ok to put in some development time, in fact our automatic testing attempts are requiring a good amount of coding anyway, but in our case the authoritative data sources are more than one... In any case, the document explaining how to cleanup a connector space programmatically will be extremely useful for us! Thank you very much, Paolo
September 1st, 2009 2:34pm
Hi Craig, thanks for your answer. How can I access MV data using the web service? and what kind of data is stored in FIM app store? Cheers, Paolo
September 1st, 2009 2:40pm