cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
Microsoft
Microsoft

Think there is bug with PowerApps button template + Run SQL Stored Procedure v2

Have successfully used PowerApps (trigger from) button template multiple times with exec sql stored procedure (sproc) v2 multiple times.  

Have Sproc with 5 inputs (4 strings, 1 integer) and testing flow works fine on SQL and in flow if inputs left for MANUAL inputs.  IOW when I input params to test 'manually' flow and sproc run fine.  When PowerApps SQL Stored Procedure v2 has 'ask in PowerApps' variables (passed from PowerApp trigger button) getting this error:

The input body for trigger 'manual' of type 'Request' did not match its schema definition. Error details: 'Invalid type. Expected Integer but got String.'.

 

Checked trigger schema in PowerApps button template -- it asks for 5 inputs (4 strings, 1 integer) as requested, as ordered, and required by sproc.    

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Microsoft
Microsoft

Re: Think there is bug with PowerApps button template + Run SQL Stored Procedure v2

Thank you... RIL below

If so, there are two items you can try, the first would be to setup a simple trigger from PowerApp and mirror the grab content from PowerApp and trigger that flow to see if it causes the same error.

[RJ]  I had tried a simple trigger done by, literally, input of hard coded values in SQL Sproc object vs running a 'test' using same exact inputs.  Completed successfully.

 

The other test would be to setup a variable of type integer that gets the inputted value that would go into the Integer field and have it replace the directly ask in PowerApp on the flow run to see if it needs to convert it.

[RJ]  I actually tried this too -- whereby a dynamic variable selected by "PowerApps" for each variable.  Importantly, this FAILED when trying to 'test' the flow (and providing the dynamic values within 'test' facility of Flow).  It PASSED if I tested it via the PowerApp application itself however -- using the same dynamic factors.  

 

With either of these tests that would let help to identify if the issue is that the template is not working as expected and/or if there is something not converting the value to integer properly.

[RJ] Ultimately, I have concluded that this fell into what seems to be a more traditional issue with Flow -- the disconnect between components that can happen after a Flow is altered.  Somewhere between the Flow registration of the Flow, the registration of the original flow name and potential updates to the name or Flow itself, there was some sort of comm conflict between 'trigger' component and the registered sproc it was to fire off.  My resolution to this is to simply re-build a Flow from scratch again, stick with a SINGLE name of the flow throughout, and repoint to the new Flow.  There seems too much latency or inability between the Flow engine, triggers, and 'blackbox' engineered components that Flow simply looses track of if there are changes made for what it should be doing.   From an end-user pov, if you view the sproc components requiring two strings, an integer, and two strings as input, the Flow reflects this, the inputs follow this.....then there should not be messaging stating the schema was expecting a integer and got a string.  Run the same exact thing outside of the 'test' environment with exactly the same inputs and it works...just doesn't add up for end user.   Fails in test but not when operated via PowerApp application?  Disconnect.

View solution in original post

3 REPLIES 3
Highlighted
Microsoft
Microsoft

Re: Think there is bug with PowerApps button template + Run SQL Stored Procedure v2

Adding clarity.... failure is when trying to TEST in Flow.  Does operate when connected to PowerApp but always would test successfully in Flow environment previously.

Highlighted
Community Support
Community Support

Re: Think there is bug with PowerApps button template + Run SQL Stored Procedure v2

Hello RJ911,

 

Based off your notes, this is a Flow template grabbed from within Flow, correct? And the issue is that testing it directly in the flow fails with the expecting type integer?

 

If so, there are two items you can try, the first would be to setup a simple trigger from PowerApp and mirror the grab content from PowerApp and trigger that flow to see if it causes the same error.

 

The other test would be to setup a variable of type integer that gets the inputted value that would go into the Integer field and have it replace the directly ask in PowerApp on the flow run to see if it needs to convert it.

 

With either of these tests that would let help to identify if the issue is that the template is not working as expected and/or if there is something not converting the value to integer properly.

Highlighted
Microsoft
Microsoft

Re: Think there is bug with PowerApps button template + Run SQL Stored Procedure v2

Thank you... RIL below

If so, there are two items you can try, the first would be to setup a simple trigger from PowerApp and mirror the grab content from PowerApp and trigger that flow to see if it causes the same error.

[RJ]  I had tried a simple trigger done by, literally, input of hard coded values in SQL Sproc object vs running a 'test' using same exact inputs.  Completed successfully.

 

The other test would be to setup a variable of type integer that gets the inputted value that would go into the Integer field and have it replace the directly ask in PowerApp on the flow run to see if it needs to convert it.

[RJ]  I actually tried this too -- whereby a dynamic variable selected by "PowerApps" for each variable.  Importantly, this FAILED when trying to 'test' the flow (and providing the dynamic values within 'test' facility of Flow).  It PASSED if I tested it via the PowerApp application itself however -- using the same dynamic factors.  

 

With either of these tests that would let help to identify if the issue is that the template is not working as expected and/or if there is something not converting the value to integer properly.

[RJ] Ultimately, I have concluded that this fell into what seems to be a more traditional issue with Flow -- the disconnect between components that can happen after a Flow is altered.  Somewhere between the Flow registration of the Flow, the registration of the original flow name and potential updates to the name or Flow itself, there was some sort of comm conflict between 'trigger' component and the registered sproc it was to fire off.  My resolution to this is to simply re-build a Flow from scratch again, stick with a SINGLE name of the flow throughout, and repoint to the new Flow.  There seems too much latency or inability between the Flow engine, triggers, and 'blackbox' engineered components that Flow simply looses track of if there are changes made for what it should be doing.   From an end-user pov, if you view the sproc components requiring two strings, an integer, and two strings as input, the Flow reflects this, the inputs follow this.....then there should not be messaging stating the schema was expecting a integer and got a string.  Run the same exact thing outside of the 'test' environment with exactly the same inputs and it works...just doesn't add up for end user.   Fails in test but not when operated via PowerApp application?  Disconnect.

View solution in original post

Helpful resources

Announcements
FirstImage

Microsoft Ignite 2020

Check out the announcement of Power Platform content at Microsoft Ignite!

thirdImage

Experience what's new for Power Automate

Join us for an in-depth look at the new Power Automate features and capabilities at the free Microsoft Business Applications Launch Event.

firstImage

Power Platform 2020 release wave 2 plan

Features releasing from October 2020 through March 2021

Top Solution Authors
Users online (7,781)