I am unable to find any Managed or enterprise connector on Logic App Standard plan.I see only builtin connector for Azure Logic App Standard plan.
Is there any guideline or limitation documentation available that can explain how to use the standard or enteprise connector in Azure Logic App Standard plan?
It appears that there are limitation on what connectors one can use on Azure Logic App Standard plan stateful and stateless workflow.
Only builtin connectors are available in stateless Azure Logic App based on standard plan.
Azure logic app based on standard plan can show managed connectors (with limitations) on Azure Tab for stateful workdlow only.
Related
I have a basic query on Azure Cognitive search -I have confusion that, will it comes under PaaS or SaaS service? With my understanding I feel it should be PaaS, since it requires configuration and deployment involved. Please correct me if I am wrong.
Azure Cognitive Search is a PaaS service. While there is a portal experience to help configure and evaluate the service, you need to write your own application to call the service in order to use its functionality.
Azure Cognitive Search is a search-as-a-service.
Search as a service uses a software as a service (SaaS) model.
https://en.wikipedia.org/wiki/Search_as_a_service
As a Customer of Azure cognitive search, I had to code all back-end services that can handle creating of data sources, indexers and indexes and also the same for calling the rest API to get the data, so even if it is possible to do it via the portal azure interface we still need to code to get some advanced features not yet presents in the interface.
So I believe it is a PAAS cloud type.
I am doing a project to create a login and create an account page and also store different sorts of data that needs to be securely stored in the database.
I am using react native and amazon web service. I am confused about how to use the RDS(AWS) Microsoft SQL Server and to connect with the front end. Do I use AWS amplify?
I saw a post that mentioned
Amplify is at the moment tied to dynamoDB in a very strong way. But you can use graphQL queries sent to AppSync (the backend layer of amplify) to trigger lambda functions. From there you can target any type of database you want
Is there a better or shorter process of connecting the front end with the SQL database. Please give me some tips as it is my first time working with AWS and react native.
There are many ways to accomplish this with AWS. You essentially need a backend web server component in your architecture. The classical solution would be to setup an EC2 and have this server handle REST or GraphQL requests that query your RDS.
A more modern "serverless" option would be to route your front-end traffic to an API Gateway that invokes a lambda function. This lambda function can utilize IAM permissions to query your database. There are many resources for this pattern; here's an AWS blog post about it.
I'm not familiar with the specifics of Amplify, but if you can be flexible switching datastore it seems convenient just to use a datastore that Amplify plays nicely with. I'd highly recommend trying to get Amplify working if you are not familiar with backend web software and don't have time / care to dig into the complexities of it.
I am developing an Android app using the Firebase.
It uses Firebase Auth, Real-time database, Storage.
And the App has a search feature.
For example, a customer can search another user using this feature.
If there is a user "Yoonho Aaron Kim", user want to search this user using some keyword like "yoonho", "aaron", "kim", etc...
But the Firebase Query doesn't support all of them.
It provides only "startAt", "endAt", "equalTo" methods.
Plus, I cannot use these 3 methods at the same time.
Because of this limitation, I am considering another module like "Cloud SQL", "App Engine".
Is there any good ideas please?
AppEngine is actually not a database engine, it is a "platform to build apps and scale automatically" and as such can connect to different types of databases: Cloud SQL (that you mention) a relational MySQL db (or PostgreSQL) or Cloud Datastore, a NoSQL database.
With Cloud SQL you could indeed perform some queries with a LIKE operator in a WHERE clause. With Datastore you will get the same limitations than Firebase database.
However, switching to AppEngine means that you will stop using Firebase and that you will go for another solution to develop and expose your APIs to your Android app, e.g. use a framework like Google Endpoints (https://cloud.google.com/endpoints/) .
I'm finding alternatives for Google App Engine for startup. The preconfigured service hosting include security, networking, scaling, database, backup, application, maturity and etc.. Because we have no experts on each parts. It's too hard operating whole service stack properly for only one application programmer.
What other services can I consider for this?
The term you want to search for is PaaS or Platform-as-a-Service. I do not claim to be an expert in this nacent field, however my basic understanding of the key players other than Google App Engine are:
Amazon AWS - My understanding is that Amazon's Web Services gives you bare-bones OS installs that you can completely own. While this allows for more configuration than App Engine, this also means you are on the hook for patching security holes and what not. (Right?)
Heroku - App Engine type functionality, except for Ruby
AppHarbor - App Engine type functionality, except for .NET
Microsoft Azure - Amazon AWS type functionality, except for Windows/The Microsoft stack.
The CloudCamp awards 2011 serves as a nice list of PaaS services
I am interested to build a platform on Google App Engine where one Master App provides common functionality to several child Apps (Web portals).
Master App:
Offers Common Social Networking features
Common user database
Interacts using Web services API
Child Apps (Web Portals):
Connects to Master App for user database and social networking features
Uses Local business logic for local features
My Design plan is:
Master and Child Apps will be
individual Apps on GAE Appspot (for
easy management)
All will communicate via REST/JSON?
I will enable billing for all Apps so
nothing is against Google's usage
policy.
Will use SSL for login into Master App, later use a token
(cookie) for further interactions
Could anyone kindly spot risks and suggest any improvements?
Your "Master/Child" concept will be hard to maintain, introduce issues with cross-site-scripting and most importantly be completely against Google App Engine's terms of service for combining multiple apps into one.
4.4. You may not develop multiple Applications to simulate or act as a single Application or otherwise access the Service in a manner intended to avoid incurring fees.
You could use multiple app versions (defined on app.yaml) to deploy different codebases to the same appspot.com subdomain, and access them like http://app1.myapp.appspot.com, http://app2.myapp.appspot.com for "versions" app1 and app2. You could even have one version running on Java and another one on Python.
They'll all share the same datastore, although you'd be able to use namespaces to separate them if necessary.
For the distributed nature of the architecture you proposed, I'd suggest having a deep look at Facebook's graph API and Twitter's API. They both use oAuth for authentication/authorization and already have a proven implementation of what you're trying to accomplish.