Custom API - Form no datasource selected

[joshbooker]

I have a Custom API to Northwind ODataV4 endpoints.  Connection added and PA is trying to deal with it.

The problem I'm having is trying to figure out proper DataSource and Item properties of forms controls.

Here is a sample response schema from CategoriesGet() method:

{
  "@odata.context": "string",
  "value": [
    {
      "CategoryID": 0,
      "CategoryName": "string",
      "Description": "string",
      "Picture": "string"
    }
  ]
}

As you can see the response is an object having two props (types: string and array)

PA seems to accept for DataSource: NorthwindAPI.CategoriesGet().value (this works in Items prop of a gallery too)

But nothing works in the Item prop.  For example, say I want to view the first item in the response array.  A proper expression would be: NorthwindAPI.CategoriesGet().value[0]

However none of the following works in PA: 0 , [0] , (0)

I tried First(source) function in Item prop, but how do we refernce the respective DataSource.  (tried: ThisDatSource, this.DataSource, inspected [@DataSourceInfo] whatever that is(?) - no luck)

Nor does it allow:

DataSource: NorthwindAPI.CategoriesGet()

Item: value[0]

Any suggestions including manually editing swagger would be appreciated.

TIA,

Josh

[rgruian]

Forms in PowerApps are designed to be used with tabular data sources whose schemas are known statically (i.e. at authoring time). In order to bind a form to a tabular data source, you need to add the data source to your app, then reference it by name in the formula for Form.DataSource.

Form.Item refers to the item that will be viewed or edited. This will typically be a record from that tabular data source (a row), for example First(MySpecialDataSource).

PowerApps's type system has no concept of "arrays", so there is no random access into data via numeric indices. Instead of writing foo[0], which is invalid syntax, please consider designing your data (server & swagger) and formula logic to refer to tables and rows of those tables. A row can be obtained in many different ways, for example by using the LookUp, First, or Last functions, described here:

https://powerapps.microsoft.com/en-us/tutorials/function-filter-lookup/

https://powerapps.microsoft.com/en-us/tutorials/function-first-last/

In PowerApps, the '@' symbol is used for name disambiguation. The usage you listed refers to global disambiguation, which is a way to syntactically tell PowerApps that you really mean a globally-available identifier (such as a data source), instead of a field/column with the same name in a gallery item or row scope. Disambiguation syntax is documented here:

https://powerapps.microsoft.com/en-us/tutorials/working-with-tables/

I hope this helps.

[joshbooker]

@rgruian Thanks for your reply.  My API returns a static schema which is known a design time, and I've added the data source and can set the Form.DataSource just fine.   It seems to me, the PA tooling doesn't handle the schema consistently. 

For example, the formula:

NorthwindAPI.GetCetegories().value

works fine for the Gallery.Items property and also for the Form.DataSource property.  Therefore I believe my response schema is considered a 'tabular datasource' by the tooling.

The problem is with the Item property of the Form.  I've tried First(), but I cannot get it to accept my 'table' as the source parameter.

However this formula:

First(NorthwindAPI.GetCetegories().value)

is valid in the Form.Item prop, and I can use my fields in the tool like

ThisItem.CategoryID

yet the Fields are not listed on the Options tab so I have to create every control and label manually using Custom Cards.

This behavior seems inconsistent to me. I'd love to know if there is a way to make the Form controls useful for Custom APIs.

Such as perhaps x-ms- swagger vendor extensions would light up this functionality(?)

Related question:

https://powerusers.microsoft.com/t5/PowerApps-Forum/Custom-API-swagger-vendor-extensions/m-p/10536#M...

Thanks,

Josh

[rgruian]

Hi Josh,

Forms were designed for tabular data sources. These are named, and are typically introduced via connections. For example, with a named tabular data source in place, in PowerApps you would be able to use simply 'Categories' in formulas instead of making a function call to fetch data.

What you are referring to is a custom API (service function) that returns data in tabular format -- and that is not a named tabular data source. Yes, the return schema of that function is known statically, however forms need a higher abstraction: a unique named entity that declares and encapsulates all the specifics related to CRUD operations on the underlying tabular data (i.e., forms need to know how to remove a row, how to add or edit a row, etc). Custom APIs do not provide that abstraction, and that is the sole reason why forms do not directly support them.

Have you tried migrating your data to CDS or Sharepoint?

[joshbooker]

 Hi Radu,

Thanks again for your reply. 

I now understand that, to PA, there is a difference between 'named' tabular datasource and a a custom API that returns tabular data.  What I don't understand is why there is a difference.  My API does indeed have CRUD methods.  Create, Read, Update, Delete are http methods POST, GET, PATCH, DELETE respectively.  I can see that a higher entity abstraction is needed for the tooling to work, but is there a way to map swagger operations CRUD operations of named entities?

It seems to me what PA and Flow are missing is:

1) a first-class OData connector

2) x-ms- swagger vendor extensions to enable custom API devs to light up 'entity' the tooling. 

CDS and Sharepoint (and even SQL Connector) are not an option since there are no options for server side business logic.

Josh

[joshbooker]

I can see that a higher entity abstraction is needed for the tooling to work, but is there a way to map swagger operations CRUD operations of named entities?

[joshbooker]

Can anyone confirm whether it is possible to make a Custom API connector have 'tabular' capabilities?

Please vote here:

https://powerusers.microsoft.com/t5/PowerApps-Ideas/Custom-API-with-tabular-capabilities/idi-p/13394

https://powerusers.microsoft.com/t5/PowerApps-Ideas/OData-connector-with-tabular-capabilities/idi-p/...

Thanks in advance,

Josh