cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
sasrsc1966
New Member

Is this workflow explanation correct about on-prem data getting to/from Power Apps

To cut to the chase, if I have data on-prem data (such as sql, sas, oracle, etc…) and I want an “automated way” to put data into the dataverse and/or consume then I need an additional step.

To get data into the Dataverse for Teams (so that a Power Apps in Teams can consume it) you need to create a Cloud Flow (Power Automate) process to act as the middle man. Cloud Flows then still need to access our data on-prem.

That is the same predicament as normal Dataverse. Regular Power Apps needs data and can use a custom connector too.

 

The difference between the two, as I understand it,

  1. is that regular Power Apps can use a Custom Connector to connect directly to our company (or an on-prem gateway) as a connector and consume directly in Power Apps. 1 step.
  2. whereas Power Apps (Dataverse for Teams) uses a Cloud Flow which uses a Custom Connector to bring the data in from our company and store the data in the Dataverse to be consumed by Power Apps.  2 steps.

 

I’m guessing that the performance will be better with #2 because Power Apps is connecting to the Dataverse and the data synch is done in batch, whereas with #1 it’s having to pull in data via connector which may mean a “longer hop” but it’s live. As you know I’m not a professional developer so I may not have the lingo correct. In the case of #1 you don’t need Dataverse as the PA will consume the data directly through the custom connector.

 

Please confirm if my assessment is correct or whether there is a better way?


1 ACCEPTED SOLUTION

Accepted Solutions
RusselThomas
Microsoft
Microsoft

Hi @sasrsc1966 ,

Hyperscale cloud-native is generally your best performance objective, where everything is in the cloud - however hybrid is a necessity we have to deal with.

 

As there are too many moving parts in an on-prem environment to predict performance, it's reasonable to assume fewer hops = better performance, and as Dataverse for Teams is operating in the same logical environment as your app, it's a good bet it will outperform other data sources which are 'further away'.  There are however, a lot of moving parts, so you may want to test this.

 

For example, I've seen data return performance on SQL using the gateway that is perceptably no different from Dataverse or SharePoint.  Is there a difference in latency?  Almost certainly.  Does it make a difference to the user experience?  That depends.

OPG can be as quick as other common connectors, or horrendously slow.  A lot is dependent on your local infrastructure, the gateway deployment architecture and where the actual data is in relation to the gateway, not to mention the performance of the actual source providing the data. 

 

If you consider PowerBI direct query - while it's really useful to query 'fresh' data, the best performance is achieved by importing data into Power BI - it stands to reason that this logic can be extrapolated  to other cloud services. 

 

SQL in Azure vs Dataverse - mmm....I wouldn't lay any bets, but I might still lean towards Dataverse - although the data scale, cost per GB or management/functionality requirements might eventually start pushing you towards SQL as a necessity - but row for row performance at lower scales, I'm guessing Dataverse will still be 'closer' and therefore faster for Power Platform consumption.  

 

Can an OPG ever be faster than cloud native, (or in this case Dataverse which exists in the same architectural environment as the app)?  I would bet 'No' - few things will be faster than cloud native - but as always, there are many factors that affect performance, so you have to be careful drawing a line in the sand.  I don't think it's impossible, but bit for bit transfer, that would be my bet.  The user experience however is your real litmus test, regardless of what the data says.

 

Your trade-off on OPG is potentially aged data, plus the admin and potential quota consumption overhead of your flow.  I'd suggest test the direct connect performance of the gateway against the Dataverse tables - if you can - then decide if the delta in performance warrants the trade-off of batched data.  If it's negligible (which it may very well be from a user experience perspective) it might be better to stick with it instead of creating duplicate data.  If not, then the additional work is warranted.

 

Kind regards,

RT 

 

 

View solution in original post

2 REPLIES 2
RusselThomas
Microsoft
Microsoft

Hi @sasrsc1966 ,

Hyperscale cloud-native is generally your best performance objective, where everything is in the cloud - however hybrid is a necessity we have to deal with.

 

As there are too many moving parts in an on-prem environment to predict performance, it's reasonable to assume fewer hops = better performance, and as Dataverse for Teams is operating in the same logical environment as your app, it's a good bet it will outperform other data sources which are 'further away'.  There are however, a lot of moving parts, so you may want to test this.

 

For example, I've seen data return performance on SQL using the gateway that is perceptably no different from Dataverse or SharePoint.  Is there a difference in latency?  Almost certainly.  Does it make a difference to the user experience?  That depends.

OPG can be as quick as other common connectors, or horrendously slow.  A lot is dependent on your local infrastructure, the gateway deployment architecture and where the actual data is in relation to the gateway, not to mention the performance of the actual source providing the data. 

 

If you consider PowerBI direct query - while it's really useful to query 'fresh' data, the best performance is achieved by importing data into Power BI - it stands to reason that this logic can be extrapolated  to other cloud services. 

 

SQL in Azure vs Dataverse - mmm....I wouldn't lay any bets, but I might still lean towards Dataverse - although the data scale, cost per GB or management/functionality requirements might eventually start pushing you towards SQL as a necessity - but row for row performance at lower scales, I'm guessing Dataverse will still be 'closer' and therefore faster for Power Platform consumption.  

 

Can an OPG ever be faster than cloud native, (or in this case Dataverse which exists in the same architectural environment as the app)?  I would bet 'No' - few things will be faster than cloud native - but as always, there are many factors that affect performance, so you have to be careful drawing a line in the sand.  I don't think it's impossible, but bit for bit transfer, that would be my bet.  The user experience however is your real litmus test, regardless of what the data says.

 

Your trade-off on OPG is potentially aged data, plus the admin and potential quota consumption overhead of your flow.  I'd suggest test the direct connect performance of the gateway against the Dataverse tables - if you can - then decide if the delta in performance warrants the trade-off of batched data.  If it's negligible (which it may very well be from a user experience perspective) it might be better to stick with it instead of creating duplicate data.  If not, then the additional work is warranted.

 

Kind regards,

RT 

 

 

View solution in original post

thank you for this assessment. I will pass that along to our IT team who is attempting to make the best decision as to how to "connect" our data.

Helpful resources

Announcements
PA User Group

Welcome to the User Group Public Preview

Check out new user group experience and if you are a leader please create your group

PA Community Call

Power Apps Community Call

Next call is happening on April 21st at 8a PST.

MBAS Carousel

Sign up for our May 4th event!

May the fourth be with you, join us online!

secondImage

Experience what’s next for Power Apps

See the latest Power Apps innovations, updates, and demos from the Microsoft Business Applications Launch Event.

Top Solution Authors
Top Kudoed Authors
Users online (59,388)