Connectors architecture

Each connector offers a set of operations classified as actions and triggers. Once you connect to the underlying service, these operations can be easily leveraged within your apps and workflows.

Actions

Actions are changes directed by a user. For example, you would use an action to look up, write, update, or delete data in a SQL database. All actions directly map to operations defined in the swagger.

Triggers

Many connectors provide triggers that can notify your app when specific events occur. For example, the FTP connector has the OnUpdatedFile trigger. You can build either a Logic App or a flow that listens to this trigger and performs an action whenever the trigger fires.

There are two types of triggers:

• Polling Triggers: These triggers call your service at a specified frequency to check for new data. When new data is available, it causes a new run of your workflow instance with the data as input.

• Push Triggers: These triggers listen for data on an endpoint, that is, they wait for an event to occur. The occurrence of this event causes a new run of your workflow instance.

Architecture components

Here are the architecture components and what they do:

• Credential and metadata store: A service to store connector metadata (swagger, connection, ACLs, etc.), and credentials associated with a connection.
• Connector:
  • Azure APIM (API Manager) to host all the swagger and policies. In addition to being the entry point for all calls that interact with the connector calls, Azure APIM verifies keys, tokens, certificates, and other credentials.
  • App Service Environment to host connector webapps.
• Runtime flow:

Provide feedback

We greatly appreciate feedback on issues with our connector platform, or new feature ideas. To provide feedback, go to Submit issues or get help with connectors and select your feedback type.