This article provides detailed design information about the Connected System design object and its configuration options. A connected system represents an external system that is integrated with Appian. Connected systems allow you to share base URL and authentication details across multiple integrations. You can also upload a logo image to visually identify the system.
Note: Below are details of an HTTP connected system. The following screens will change depending on the selected connected system.
Each HTTP connected system has the following properties.
|Name||The name of the connected system. Use a name that will uniquely identify this connection to the external system.|
|Description||Supplemental information about the connected system that is displayed when selecting the system in the integration designer and in the application contents grid.|
|System Logo||An image document used to visually represent the external system or service being connected to. The logo is displayed in the integration designer and in the process modeler on integrations that connect to this system (using the Call Integration Smart Service). If no document is selected a default logo will be used instead.|
|Base URL||A consistent prefix for the URLs of this connected system's integrations. This value supports environment specific configuration for variation across environments.|
|Authentication||The type of authentication to use for integrations that use this connected system.|
Connected systems allow designers to manage authentication details for multiple integrations in one place. There are several authentication options available for connected systems.
No specific authentication will be applied. You can provide custom authentication values in the integration's URL, parameters, or headers as required by the external system. Client certificate/mutual SSL authentication can be enabled by uploading client certificates in the Admin Console. Services that use self-signed or internal SSL certificates can be enabled by uploading trusted server certificates in the Admin Console.
Although API keys can be configured directly in the integration headers or parameters, the only way to securely configure an API key for an integration is by using the connected system object. The following properties are available for configuration when API key is selected as the authentication type:
|Send As||Required. This field specifies whether the API key should be sent as an http header or a query parameter.|
|Header/Parameter Name||Required. The key identifier of the API key.|
|Value||Required. The key value of the API key. This value is masked to prevent unauthorized users from seeing and should be treated as a password.|
The following properties are available for configuration when Basic Authentication is selected as the authentication type:
|Username||The username to use for authentication. This value is encrypted and supports environment specific configuration.|
|Password||The password to use for authentication. This value is masked, encrypted, and supports environment specific configuration.|
|Send credentials preemptively instead of waiting for a 401 authentication challenge||Determines whether or not authentication credentials are sent only after a 401 Not Authorized response or, when selected, before the system has challenged.|
The following properties are available for configuration when Google Service Account is selected as the authentication type:
|Service Account Key||Required. A JSON file containing service account information. This file is obtained from the Google Cloud Platform (GCP) Console.|
|Scope||Optional. List the permissions that will be requested from the protected resource. Check Google Cloud’s documentation for valid values. If left empty, the default scope is “https://www.googleapis.com/auth/cloud-platform”.|
To see the configurable properties for this authentication type, see OAuth 2.0: Authorization Code Grant.
To see the configurable properties for this authentication type, see OAuth 2.0: Client Credentials Grant.
Each time you modify and save a connected system, a new version is created. All objects that use the connected system will use the latest version. All versions are accessible to designers who can view the connected system, and a connected system can be reverted back to a previous version at any time.
For information on how to manage object versions, see Managing Object Versions.
The security rolemap of the connected system controls who can see or modify the connected system properties.
Connected systems can be used when calling an integration by any user regardless of their defined role in the security rolemap.
The following actions can be completed by each role:
|Evaluate integrations that use this connected system||Yes||Yes||Yes||Yes|
|Select this connected system when creating an integration||Yes||Yes||Yes||No|