ICF Filters and Get vs Search

This topic has 1 reply, 2 voices, and was last updated 4 years, 6 months ago by gael.

  • Author
    Posts
  • #20212
     GuyPaddock
    Participant

    The documentation for the ICF SPI states:

    You can implement the FilterTranslator object in two ways:
    – The FilterTranslator translates the original filter into one or more native queries. The framework then calls the executeQuery() method for each native query.
    – The FilterTranslator does not modify the original filter. The framework then calls the executeQuery() method with the original OpenICF filter.

    Using this second approach enables your connector to distinguish between a search and a get operation and to benefit from the visitor design pattern.

    Emphasis was added by me. Can someone explain how the second approach actually can be used to distinguish between a “search” and a “get” operation? I see no advantage to shifting the responsibility of handling the ICF Filter object down to the connector itself (vs. extending the AbstractFilterTranslator class and implementing the abstract methods). Nothing in the signature of the ICF Filter object seems to help with telling if we’re just doing a simple search for a single object based on one field (like the object’s UID or NAME) vs. doing a search for multiple objects based on several potentially complex criteria.

    Moreover, I am puzzled as to why there isn’t simply a “Get” SPI that ICF connectors can implement that the ICF Connector Facade can call for the Get implementation. Instead, the facade translates Get operations as Search operations, and then the connector has to cleverly interpret / optimize single-field searches to avoid having to examine every object in the data source just to get one object.

    Am I missing something?

    #20608
     gael
    Participant

    you’re quite right.
    The GET which is defined at the API level
    https://backstage.forgerock.com/docs/openicf/1.5/apidocs/org/identityconnectors/framework/api/operations/GetApiOp.html
    is not defined at the SPI level. ICF will translate a GET to an exact search: __UID__ = XYZ
    ICF 1.5 provides a helper method in FrameworkUtil:
    https://backstage.forgerock.com/docs/openicf/1.5/apidocs/org/identityconnectors/framework/common/FrameworkUtil.html#getUidIfGetOperation(org.identityconnectors.framework.common.objects.filter.Filter)

    You can use it that way in your connector to figure out if the query is a GET or not:

    
    if (filter != null) {
        def uuid = FrameworkUtil.getUidIfGetOperation(filter)
        if (uuid != null) {
            // Get user
       
    
Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?