LogoLogo
5.2
  • Docs
  • Connector Configuration
  • Knowledge Base
  • Changelog
5.2
  • Introduction
  • Migration from 5.1
  • Overview
    • Introduction
    • Component
    • Flow
    • End User Guide
  • Component Definition
    • Basic Structure
    • Manifest
      • name
      • label
      • icon
      • marker
      • author
      • description
      • auth
      • authConfig
      • quota
      • properties
      • inPorts
      • outPorts
      • firePatterns
      • tick
      • private
      • webhook
      • state
      • localization
    • Behaviour
    • Dependencies
    • Authentication
    • Quotas & Limits
    • Configuration
    • Example Component
  • Customizing UI
    • Custom Inspector Fields
    • Custom Theme
    • Custom Strings
    • Custom API
    • Custom Component Strings
    • Custom Component Shapes
    • Custom Auth Popups
  • Appmixer hosted
    • Getting started
    • Creating Custom Components
    • Using Appmixer SDK
    • Using Appmixer API
    • Using Oauth applications
  • Appmixer Self-Managed
    • Installation
    • Getting Started
    • Custom Component: HelloAppmixer
    • Using Appmixer SDK
    • Using Appmixer API
    • Using OAuth applications
    • Installation GCP
    • System Webhooks
    • Configuration
    • Appmixer Architecture
    • Appmixer Deployment Models
    • System Plugins
  • API
    • ACL
    • Accounts
    • Apps
    • Authentication
    • Charts
    • Config
    • Data Stores
    • Files
    • Flows
    • Insights
    • Modifiers
    • People Task
    • Public Files
    • Service Configuration
    • Unprocessed Messages
    • User
    • Variables
  • Appmixer SDK
    • Introduction
    • Installation
    • Quick Start
    • Constructor
    • API Module
    • UI & Widgets
      • Flow Manager
      • Designer
      • Insights Logs
      • Insights Chart Editor
      • Insights Dashboard
      • Accounts
      • Storage
      • People Tasks
      • Connectors
      • Integrations
      • Wizard
    • Developer mode
  • Appmixer Backoffice
    • Getting Started
    • Services
    • Quotas
    • Public Files
    • System Configuration
    • Modules
  • Tutorials
    • Managing Authentication
    • Sharing Flows
    • Flows Metadata & Filtering
    • People Tasks
    • Customizing modifiers
    • Setting ACL
    • Integration Templates
    • Installing and updating modules
    • Custom Webhook Trigger
    • Appmixer Virtual Users
    • Working with outport schemas
  • Appmixer CLI
    • Appmixer CLI
    • Appmixer OpenAPI Generator
      • Getting started
      • Open API Extensions
      • Examples
  • App Registration
    • Airtable
    • Azure Cognitive Services
    • Blackboard
    • DeepAI
    • DocuSign
    • Google
    • Highrise
    • Hubspot
    • Microsoft
    • Microsoft Dynamics 365 CRM
    • Quickbooks
    • Redmine
    • Salesforce
    • Schoology
    • Screenshot API
    • ServiceNow
    • Slack
    • Trello
    • Typeform
    • Utilities
      • Email
      • Language
      • Tasks
      • Test
      • Weather
    • Xero
    • Zendesk Tickets
    • Zoho
  • Connectors
    • Connector Request
Powered by GitBook
On this page
  • inPort.schema
  • inPort.inspector
  • inPort.source
  • inPort.variablesPipeline
  • inPort.maxConnections

Was this helpful?

Export as PDF
  1. Component Definition
  2. Manifest

inPorts

The definition of the input ports of the component. It's an array of objects.

Each component can have zero or more input ports. If a component does not have any input ports, we call it a trigger. Input ports allow a component to be connected to other components. Input ports receive data from output ports of other connected components when the flow is running and the data is available. Each input port has a name and configuration that has the exact same structure as the configuration of properties, i.e. it has schema , inspector or source objects. The difference is that the user can use placeholders (variables) in the data fields that will be eventually replaced once the actual data is available. The placeholders (variables) can be entered by the user using the "variables picker" in the Designer UI inspector (see below). Example:

{
    "inPorts": [
        {
            "name": "message",
            "schema": {
                "type": "object",
                "properties": {
                    "body": { "type": "string" },
                    "phoneNumber": { "type": "string" }
                },
                "required": [ "phoneNumber" ]
            },
            "inspector": {
                "inputs": {
                    "body": {
                        "type": "text",
                        "group": "transformation",
                        "label": "Text message",
                        "index": 1
                    },
                    "phoneNumber": {
                        "type": "text",
                        "group": "transformation",
                        "label": "Phone number",
                        "index": 2
                    }
                },
                "groups": {
                    "transformation": {
                        "label": "Transformation",
                        "index": 1
                    }
                }
            }
        }
    ]
}

The message from the example looks like this in the raw form:

City: {{{$.a0828f32-34b8-4c8d-b6b3-1d82ca305921.weather.[name]}}}
Humidity: {{{$.a0828f32-34b8-4c8d-b6b3-1d82ca305921.weather.[main.humidity]}}}
Pressure: {{{$.a0828f32-34b8-4c8d-b6b3-1d82ca305921.weather.[main.pressure]}}}
Temperature: {{{$.a0828f32-34b8-4c8d-b6b3-1d82ca305921.weather.[main.temp]}}}

As you can see, the placeholders for variables use a special format that the Appmixer engine eventually replaces with real values that come from the GetCurrentWeather component once the data is available.

inPort.schema

inPort.inspector

inPort.source

Definition of the source of the variables or dynamic inspector that will be available in the designer UI for this input port.

An example of how the source property can be used to generate the input port Inspector dynamically for the appmixer.google.spreadsheets.CreateRow component. When showing the Inspector for the CreateRow, we need to know the structure (columns) of the Worksheet, the Inspector input fields will copy the columns in the Worksheet

{
...
    "inPorts": [
        {
            "name": "in",
            "schema": {
                "type": "object"
            },
            "source": {
                // The ListColumns component can return an array of columns in a
                // Worksheet.
                "url": "/component/appmixer/google/spreadsheets/ListColumns?outPort=out",
                "data": {
                    // The ListColumns component needs two properties in order
                    // to get the list of columns, the Spreasheet Id and the
                    // Worksheet Id. Both will be taken from properties of the
                    // CreateRow component (the caller).
                    "properties": {
                        // Appmixer will replace 'properties/sheetId' with
                        // the actual value before making the call
                        "sheetId": "properties/sheetId",
                        "worksheetId": "properties/worksheetId"
                    },
                    // A transformer function 'columnsToInspector' from the 
                    // ListColumns.js will be executed in order to transform a list
                    // of columns to the Appmixer Inspector.
                    "transform": "./ListColumns#columnsToInspector"
                }
            }
        }
    ]
}

inPort.variablesPipeline

This object allows you to control what variables will be available to this component in the UI and in the component receive() method. By default, variables are collected from all the components back in the chain of connected components. This might not be desirable in some cases. One can set scopeDepth to a number that represents the depth (levels back the graph of connected components) used to collect variables. rawValue can be used to tell the engine not to resolve variable placeholders to their actual values but to treat variable names as values themselves. Example:

{
    "variablesPipeline": {
        "scopeDepth": 1,
        "rawValue": true
    }
}

inPort.maxConnections

Set the maximum number of links that can be connected to the input port. Maximum number of connections is infinite by default but in some applications, it might be desirable to set a limit on this, usually 1. The Appmixer Designer UI will not allow the user to connect more than maxConnections links to the input port.

PreviouspropertiesNextoutPorts

Last updated 1 year ago

Was this helpful?

Definition of the schema of the data that the input port expects. Please see the section for more details.

Definition of the inspector UI for this input port. Please see the section for more details.

Properties
Properties
Input Port Configuration using Variables