Skip to content

API Explorer Overview

Introduction

API explorer page gives an overview of all existing APIs(projections)/OData services in the system. This includes Premium APIs specifically designed for integration purposes.

api explorer

This also lists down the entity sets that belong to each service.

The Different Types of APIs

IFS Cloud offers various different APIs including Standard APIs, Premium APIs, and Entity Service APIs. These can be used for integrations purposes as well as other use cases such as extension and reporting. There are specific guidelines in order to use these APIs for the right purposes. For more details, see the API Usage policy.

Inbound Integrations to IFS Using RESTful APIs

In IFS Cloud, the so-called Projections used by IFS Cloud Web can also be reused for integration purposes. These are easy to use REST APIs following the Open Data Protocol (OData) standard and standard HTTP methods (GET, POST, PUT, PATCH, DELETE) are used to call the APIs.

In IFS Cloud, there are also a number of Premium REST APIs recommended for integration. Premium APIs will have comprehensive documentation on the appropriate usage of the API and the changes to the API will be done whilst maintaining compatibility.

The REST APIs are the preferred integration method because of the ease of use. They work well in cloud hosted environments since the endpoints and protocol (https) is the same as the IFS Cloud Web. No special configuration of firewalls or file storage is required.

You can use the API Explorer in IFS Cloud Web to look up further details about the APIs, including OpenAPI v2, OpenAPI v3, Odata specifications, and the IFS REST API documentation.

The Projections use OAuth authentication. In IFS Cloud, the authentication mechanism is independent from the main/int endpoints ('Compatibility mode' that was available in Apps 10 is no longer available). In other words, basic authentication is available for both endpoints but only for ease of upgrade, that is, the basic authentication is not recommended for the consumption of integrations.

Custom Fields are also accessible through the IFS Cloud APIs. Do however note that the IFS Cloud APIs of the Standard class are atomic. If a downstream system wants to send a structured message to IFS, it needs to be broken up into several calls using a service bus or middleware such as Dell Boomi. In the example given below, a middleware is splitting an XML containing supplier and address information into several calls.

inbound_rest

Note that in IFS Cloud, Process Enrichment BPAs can be used to populate additional data. For instance, it can be used to populate the ‘Purchase’ tab when a new supplier is created. Using Custom Event Actions on IFS Applications 10 may cause “mutating tables” and require workarounds if LUs reference each other.

Optimizing Performance by Limiting Data

When using REST APIs to perform heavy integrations, it may cause system load or performance issues. To avoid this, there are certain guidelines that can be followed.

For POST and PATCH Requests

In cases where you only need to ensure that the request is successful but do not require the details of what is returned in the response body, use the Prefer:return=minimal header. This reduces the network load. In the example shown below, a new record is created in the BusinessLeadHandling projection and it is sufficient to ensure that the record is successfully created. Therefore, setting the header as follows creates a record with no response body.

no_content

For GET Requests

  • Use the $select URL parameter in the request in order to limit the attributes to the ones you require. This will reduce the payload size of the data fetched by avoiding the processing of unused attributes.

    select_filter

  • Instead of fetching all the records and processing the result, use the $filter URL parameter in the request to only fetch a subset of records that you require based on a user condition. See Get Request with Filter Options for more examples.

    Note: This is not required for cases where the GET request is already executed with a related key since the records are already limited by said key.

    filter_option

  • If the intention is to only validate whether the records exist, then use $top to limit the number of records returned. The $skip option can be used to skip records that are not required. For practical examples, see Get Request.