Browse Prior Art Database

Method to refine APIs exposed by a connector to ease consumption Disclosure Number: IPCOM000250632D
Publication Date: 2017-Aug-11
Document File: 5 page(s) / 521K

Publishing Venue

The Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

Method to refine APIs exposed by a connector to ease consumption Disclosed is a method relating to Integration Solution which can leverage the connector\Integration developer's understanding\know-how of the Enterprise Application and its APIs and elicits that on to a persistence store. BackgroundWith the proliferation of SaaS applications, the resource modelling on these SaaS applications are reaching a level of standardization. These SaaS applications further expose Metadata APIs that make the integration of these SaaS applications easier. With the metadata APIs, a connector or any other client application can understand the resource modelling of the SaaS application. The runtime APIs exposed by these Enterprise Application do not have a static structure but dynamically differ based on the metadata of the resource they are accessing. The maturity of these SaaS applications stops with having separate APIs for metadata of their resources and runtime APIs for accessing\manipulating these resources. There still exists a gap between how these objects are modelled (and exposed via the metadata API) and how they are modelled in the request or response to these runtime APIs. Example 1: Quoting an example, Marketo Enterprise Application and APIs are taken upfront. Marketo exposes APIs for both metadata and runtime calls. Metadata API will remain a GET call where the fields of a particular object “Leads” will be returned back as response in the form of a JSON structure. Now the connector/Integration developer has to use this JSON response as an input to the runtime APIs. JSON structure returned from the Metadata API for say, contains “Id”, “Name”,” Address”,” Email”,” Phone”,” IsDeleted”,” BillingCity”,” BillingCountry” and some other fields. Now if the same schema is given as input with the corresponding values to the Runtime API call for CREATE a record operation then the record does not get created at the Marketo end. Starting to debug, the record was not created as “id” field was provided as input to the CREATE Runtime API call which gives a errored response. So as part of the input for CREATE operation the “id” field needs to be removed. Example 2: For the next example, SAP Enterprise Application is taken into account. SAP has both metadata and runtime call which can be invoked to get the operation done. Objects/BAPIs/IDOCs exposed by SAP has too many fields which can be mandatory or not. At a stage it is difficult for the connector developer to ensure all the fields of an object to be marked mandatory/required or not. This involves lot of coding and maintenance. Example 3: Considering APIs as example, Salesforce exposes both standard and custom objects. Out of its standard objects, Product2 is a resource that does not work with inbound API calls. The metadata APIs for this returns the fields for Product2 but the Runtime calls does not work. So it is needed to hide this object to be tried.

Any Connector would leverage both the met...