This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Querying an object via SPML and returning only one attribute

Hi, I am searching for a way to get only back one attribute when querying an object using the SPML provider. It is described that it is possible on the following site but we're struggling to find the correct syntax:
http://documents.software.dell.com/active-roles/7.0/spml-provider-administrator-guide/using-active-roles-spml-provider/samples-of-use/capability-samples

Perform complex search
This example illustrates how to have SPML Provider find all objects that meet certain search criteria and return the values of certain attributes of the objects found.
In this case, SPML Provider performs the search operation.
The request message includes the following XML elements:
The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
The <searchRequest> element asks SPML Provider to perform a search and return the identifiers and attribute values of the objects found.
The <query> element determines the scope of the search.
The <basePsoID> element specifies the distinguished name of the container object to search. For instance, this could be the distinguished name of a certain organizational unit.
The <filter> element encloses the elements that specify the search criteria.
The <attributes> element specifies the object attributes to be included in the response.
The response contains the identifiers (distinguished names) of the objects found and, for each object, the values of the attributes specified by the <attributes> element in the search request.

Is anyone able to provide an example?

Regards

Richard

  • Hello Richard

    I have done some experiments in this area and have discovered that the only way to eliminate attributes completely from the response it to drastically edit the SPMLSchemaConfig.XML file.

    In my experiment, for one user I set values in every attribute that is configured in SPMLSchemaConfig as a user class attribute.

    When I send a request with just the cn attribute in the <attributes/> element, then the response will always include the following attributes: cn; objectClass; objectCategory; objectGuid; description; manager; memberOf; sAMAccountName and userAccountControl. I think SPML must consider these as the mandatory, default collection

    When I send a request with just the title attribute in the <attributes/> element, then the response includes the following attributes: title; cn; objectClass; objectCategory; objectGuid; description; manager; memberOf; sAMAccountName and userAccountControl. This seems to back up the belief that there are 9 mandatory, default attributes

    When I send a request with no <attributes/> element, then the response includes all of the attributes listed under the user class object class definition in SPMLSchemaConfig


    As you have discovered, this means that regardless of the contents of the <attributes/> element, some attributes will always be returned, including (annoyingly) memberOf.


    However, if the spmlSchemaConfig is edited to remove unwanted attribute definition references from the user class object class definition, then it is possible to cut down the amount of data in the response. I have removed memberOf and manager and description and userAccountControl and thus count down the default attributes to only cn, objectClass, objectCategory and objectGUID

    In Practice, I think it would thus be possible to have the SPML Provider implemented on two Active Roles Administration Service servers. One with the default SPMLSchemaConfig.xml file and the other with a slimmed down SPMLSchemaConfig.xml file; with general purpose requests sent to the full size one and specific high volume traffic requests sent to the slim one.

    Regards - Martyn
  • Many thanks for sharing your thoughts and your testing result. Having two different sets of configurations might even be an option on the same server, but in a different IIS folder. Will think about if this may be something for us.
    Regards
    Richard