APEX: Filtering Fusion REST Integrations

Although this is not specific to APEX, it is certainly an item on any integration list of requirements. The ability to reduce data processing and ingestion loads and increasing response time to requests.

About this Post

In my previous article I covered APEX’s ability to provide input for external filtering using standard where clause syntax.

In this follow up, I will be exploring the the finder Query Parameter and finder name:findByKeyIdentifiers available on the Fusion SaaS Get All APIs.

Finder filter with a Key

Why is the finder option even available? There are already options to get a specific absence, lead, product, or job requisition by simply appending /{Unique ID} of the business object.

true but the goal is to improve performance by reducing the size of message and items returned, so I may be searching for business objects that fit a search criteria, having a response of 10s, 100s, 1000s or items.

The Finder string parameter allows us to constrain the response to specific characteristics of the business object at hand with the most likely candidates.

• Get All absences by an Absence’s Parameter; End date or type

• Get All MDF Claims by a specific Claim Code

• Get All Products by Product in a specific Product List

• Get All Sales Leads by Contact Id or Status Code

• Get All recruiting Job Requisitions by its Requisition Number vs. its ID

The finder query parameters aligns to each type of request and business object. The functional SME would be able to identify the most likely searches and filter options and in this instance the developers of Fusion SaaS are our SMEs.

Finder URL Syntax

The Finder URL syntax is simple and appends to the base Get All API.

?finder=<finderName>;<variableName>=<variableValue>,<variableName2>=<variableValue2>

Each API describes the finder parameter string prefixed with ?finder=

The finder name or allowed values are usually PrimaryKey or a predefined finder. The list provided by expanding the finder link in the documentation or in the finders section in the API description after running the /describe to retrieve its metadata.

"collection" : {
    "rangeSize" : 25,
    "finders" : [ {
      "name" : "PrimaryKey",
      "annotations" : {
        "description" : "Finds recruiting job requisitions using a unique ID"
      },
      "attributes" : [ {
        "name" : "RequisitionId",
        "type" : "integer",
        "updatable" : true,
        "mandatory" : true,
        "queryable" : true,
        "allowChanges" : "never",
        "precision" : 18,
        "hasDefaultValueExpression" : true,
        "properties" : {
          "fnd:GLOBALLY_UNIQUE" : "true"
        },
        "annotations" : {
          "description" : "Finds recruiting job requisitions using findByRequisitionNumber and RequisitionNumber"
        }
      } ]
    }, {
      "name" : "findByRequisitionNumber",
      "title" : "findByReqNo",
      "annotations" : {
        "description" : "Finds recruiting job requisitions using findByRequisitionNumber"
      },
      "attributes" : [ {
        "name" : "RequisitionNumber",
        "type" : "string",
        "updatable" : true,
        "required" : "Optional",
        "queryable" : false,
        "allowChanges" : "always",
        "annotations" : {
          "description" : "Finds recruiting job requisitions using findByRequisitionNumber and RequisitionNumber"
        }
      } ]
    } ],

Appending the finder string to the API URL for Job Requisitions is thus:

/recruitingJobRequisitions?finder=findByRequisitionNumber;RequisitionNumber=751

APEX REST Data Source Configuration

Finder is a URL Query Parameter string and we simply need to add this to the existing APEX REST Data Source, and omit if empty.

On pages supporting the filter, we set the finder parameter

A null or empty RequisitionNumber will still provide a full unfiltered list.

Conclusion

Fusion SaaS APIs provide several methods to that are simple to use in APEX. The Finder is similar to other query parameters in that it is passed in as a part of the URL and can be included in the Get All API requests.

The Finder differs from other query parameters as it has a set of predefined or expected values specific to the APIS business object.

Another difference is that it appears to only support the equal operator, as suggested by the string format in the documentation. I have not tested <> use cases, for example < endDate for the End Date for Absences, though it appears plausible.

This article is the second in a series that will explore the various filtering options and I hope you find this useful. I hope to discuss the Advance Search Query in a later post to close out this series.

Let me know in the comments section.